Jump to content

Change of product direction, good and bad news!


What should we do?  

373 members have voted

  1. 1. Should we release the Commander X8?

    • Yes, it should replace Phase-3. It's good enough.
    • Yes, but you should still offer a Phase-3 Commander X16 eventually too.
    • No, don't release the X8, stick with the original plan.
  2. 2. Should we still make a Phase-2 product?

    • Yes, Phase-2 is what I want
    • No, skip and go straight to Phase-3
  3. 3. For the X16 Phase-1, do you prefer a kit or a somewhat more expensive pre-assembled board?



Recommended Posts

22 minutes ago, Scott Robison said:

This is why I want to create a dream computer made with vacuum tubes. Transistors are just too dang magical. 😄

The funny thing is I understand transistors at a physical level better than I understand vacuum tubes. In the 70s, there were not various vacuum tube electronics magazines explaining them to me ... it was assumed anyone who cared already knew.

  • Like 1
Link to comment
Share on other sites

Just now, BruceMcF said:

The funny thing is I understand transistors at a physical level better than I understand vacuum tubes. In the 70s, there were not various vacuum tube electronics magazines explaining them to me ... it was assumed anyone who cared already knew.

In reality, my understanding of either is pretty superficial. I just figure there's always a more primitive technology that someone can pull out of their posterior because technology X is just too modern and difficult to understand.

  • Like 3
Link to comment
Share on other sites

2 minutes ago, Scott Robison said:

In reality, my understanding of either is pretty superficial. I just figure there's always a more primitive technology that someone can pull out of their posterior because technology X is just too modern and difficult to understand.

I'm not saying my understanding of transistors is more than superficial, but compared to my superficial understanding of electrons passing or not passing through semiconductors, my understanding of vacuum tubes is pretty much nonexistent.

The issue of the complexity of the system has more than one dimension, though ... one is how close to the metal can you get in understanding it, or IOW how many layers of magic sauce are underneath the parts you understand ... another is the stability. A system that is simple but where every implementation has this or that tweak to "fix this design decision" or "optimize it for this application" still has an unbounded variety of things to learn to truly master it.

Edited by BruceMcF
  • Like 1
Link to comment
Share on other sites

12 minutes ago, Robinkle said:

I don't mind the use of FPGA's and CPLD's. I see them as ASIC's. 

Because they are ... little ASICs with an eraser so that their fabric can be repaired as needed (from one perspective, anyway).

I realize that not all FPGA are "reprogrammable" ... some are like a PROM, write it once and throw it away if it doesn't work. But reprogrammable ones are more and more common.

Edited by Scott Robison
  • Like 1
Link to comment
Share on other sites

Speaking of ASICs...probably way off topic, but what's the possibility of just burning some that duplicate the VIC? Is there some weird licensing thing going on for a 40+ year old chip no one uses anymore?

The intent here being you could completely duplicate a VIC-20 with off-the-shelf parts.

Edited by Brad
  • Like 1
Link to comment
Share on other sites

3 hours ago, Scott Robison said:

Because they are ... little ASICs with an eraser so that their fabric can be repaired as needed (from one perspective, anyway).

I realize that not all FPGA are "reprogrammable" ... some are like a PROM, write it once and throw it away if it doesn't work. But reprogrammable ones are more and more common.

Many (possibly most?) FPGAs have one-time programmable fuses in addition to SPI bootstrapping. That way a bad actor doesn't flash a new design onto your stove and have it think that it needs to run the gas for 300 seconds instead of milliseconds before igniting it. And your company doesn't have to pay to have the design fabricated into an ASIC.

Link to comment
Share on other sites

49 minutes ago, Wavicle said:

Many (possibly most?) FPGAs have one-time programmable fuses in addition to SPI bootstrapping. That way a bad actor doesn't flash a new design onto your stove and have it think that it needs to run the gas for 300 seconds instead of milliseconds before igniting it. And your company doesn't have to pay to have the design fabricated into an ASIC.

I think that was at one time true, but with the continued decrease in cost of memory is isn't nearly as common as it once was. Certainly not the types of FPGAs we would easily have access to that are often used for education or prototyping. But you're right, there are cases where you want a one time programmable ASIC. If nothing else, it will help keep Skynet at bay for a little longer. 🙂

Link to comment
Share on other sites

5 hours ago, Wavicle said:

In re-watching David's original dream computer video, he mentions that the VIC-20 was simple enough that a hobbyist could understand what every chip on the board does. I assume he didn't use the C-64 because it had a PAL to handle the address decoding complexity. I think that is driving the 74xx series vs. GAL/SPLD decision. While internally an SPLD is a very simple circuit, the implementation is still hidden from you.

Very interesting observation.  Thank you for that.

Link to comment
Share on other sites

58 minutes ago, Brad said:

Speaking of ASICs...probably way off topic, but what's the possibility of just burning some that duplicate the VIC? Is there some weird licensing thing going on for a 40+ year old chip no one uses anymore?

The intent here being you could completely duplicate a VIC-20 with off-the-shelf parts.

The hard part of duplicating any chip, be it in FPGA or ASIC, is knowing the exact internal structure of the original. That's what takes time. If you have the masks that define the original and still have access to the original tech, duplication is relatively easy.

It would be "simple" (I think) to create a VIC compatible chip in FPGA if all one wanted to do is create something that matched the datasheet. Or the VIC II or SID or whatever. But these chips all have weird undocumented / unintended features that people have learned to exploit. Getting all of those 100% correct is what is hard.

  • Like 1
Link to comment
Share on other sites

20 minutes ago, Scott Robison said:

I think that was at one time true, but with the continued decrease in cost of memory is isn't nearly as common as it once was. Certainly not the types of FPGAs we would easily have access to that are often used for education or prototyping. But you're right, there are cases where you want a one time programmable ASIC. If nothing else, it will help keep Skynet at bay for a little longer. 🙂

One might be surprised - the feature exists mostly for security, though cost savings helps a little also. The iCE40UP5K used in VERA is part of Lattice's ultra-low power, high performance FPGA line. If you want to believe Lattice's marketing (??!) it is the "World’s Most Popular Low Power FPGA". It costs ~$6 in single unit quantities and has a one-time programmable configuration ROM (or, as they call it "Non-Volatile Configuration Memory"); here's an example from the the iCE40 Programming and Configuration Tech Note:

image.png.3987dc93c5ca245d7e8a0893af32d467.png

Personally, I like the iCE40 primarily because Lattice doesn't charge me $400/month for the software tools to program it *cough*Intel*cough*. (Maybe there are free tools out there for Intel's mid-range FPGAs, but I haven't found them. Lattice gave me the tools for free and if they pulled the free license, there are open source toolchains for iCE40 FPGAs also.)

  • Like 1
Link to comment
Share on other sites

19 minutes ago, Wavicle said:

One might be surprised - the feature exists mostly for security, though cost savings helps a little also. The iCE40UP5K used in VERA is part of Lattice's ultra-low power, high performance FPGA line. If you want to believe Lattice's marketing (??!) it is the "World’s Most Popular Low Power FPGA". It costs ~$6 in single unit quantities and has a one-time programmable configuration ROM (or, as they call it "Non-Volatile Configuration Memory"); here's an example from the the iCE40 Programming and Configuration Tech Note:

image.png.3987dc93c5ca245d7e8a0893af32d467.png

Personally, I like the iCE40 primarily because Lattice doesn't charge me $400/month for the software tools to program it *cough*Intel*cough*. (Maybe there are free tools out there for Intel's mid-range FPGAs, but I haven't found them. Lattice gave me the tools for free and if they pulled the free license, there are open source toolchains for iCE40 FPGAs also.)

All true, and maybe this is a distinction without much of a difference, but there are (at least) two ways to "permanently" configure an FPGA. Fuse or antifuse based configuration means that the FPGA is really and truly permanently configured. It is internal to the FPGA and can't be reversed any more than a PROM can be reversed.

When they have a ROM based solution, the ROM is permanent but it still has to be loaded into the FPGA fabric every time the FPGA is powered up. So while it is not practical to replace the ROM portion of the board, the FPGA is still programmable, we've just made it difficult to do so because of the ROM.

What I don't know: is the one time programmable NVCM a discrete component that lives next to the FPGA or is it embedded in the FPGA die? One will be "easier" than the other.

Anyway, there are reasons for all of the above. If an FPGA has internal SRAM to hold the configuration, it can be reprogrammed though it might not be practical. If it uses fuse/antifuse configuration, it will never be reprogrammed again.

Link to comment
Share on other sites

im a bit bummed the case is going away -- would be nice to offer a template to at least be able 3d print our own case. id like the preassembled  X16 personally. I dont mind paying extra for it.

Edited by davidpgil
Link to comment
Share on other sites

1 hour ago, Scott Robison said:

The hard part of duplicating any chip, be it in FPGA or ASIC, is knowing the exact internal structure of the original. That's what takes time. If you have the masks that define the original and still have access to the original tech, duplication is relatively easy.

It would be "simple" (I think) to create a VIC compatible chip in FPGA if all one wanted to do is create something that matched the datasheet. Or the VIC II or SID or whatever. But these chips all have weird undocumented / unintended features that people have learned to exploit. Getting all of those 100% correct is what is hard.

Well, I’ve seen FPGA SIDs and isn’t someone currently developing a VICII? Further, VICE implements these chips somehow…obviously they work well enough that converting to ASIC would be possible with little work. I’d guess! The differentiation between hardware and software is so blurred now with emulation, virtualization, containers, etc. 

Link to comment
Share on other sites

9 minutes ago, Brad said:

Well, I’ve seen FPGA SIDs and isn’t someone currently developing a VICII? Further, VICE implements these chips somehow…obviously they work well enough that converting to ASIC would be possible with little work. I’d guess! The differentiation between hardware and software is so blurred now with emulation, virtualization, containers, etc. 

It is definitely possible. It just takes a while. The VIC II replacement has been under development for over a year now. The VICE emulation is good, but a software implementation doesn't necessarily translate to a "hardware" implementation in a straightforward way. The biggest benefit of a good emulation is that you have something to compare against as you work on the hardware (where FPGA is hardware) version. But it would not surprise me to discover that there is some corner case somewhere that isn't covered.

Compare this to the development of VERA. VERA is not trying to be compatible with anything else, so it is free to do things however it wants. If I wanted to create a VIC or VIC II or SID that I wanted to use in a new computer, I could (if I had the skills) create something that matches the datasheet but didn't try to get all the edge cases in. As long as I didn't care about demo compatibility, it would be "easy".

There is saying about the last 10% of a project taking 90% of the time. This is especially true (or even worse) when you have very exacting requirements and you can't declare it done until it is 100% perfect.

Of course, I like a variation on that saying. The first 90% of the project takes 90% of the time. The last 10% also takes 90% of the time. 🙂

Link to comment
Share on other sites

12 hours ago, BruceMcF said:

Heck, I see that the SD card SPI CS and the serial ROM SPI CS is side by side in a control register in the X8, and there might be one spare pin (if it isn't a pin stranded by lack of logic resources), and I'm like, "hey, that's a job for a 74x138, just send three bits out on pins undecoded, and you get 7 alternative SPI selects."

...

... OOH! WAIT! It might be possible to finesse away the need for a spare pin!

Use the next decoder! A 74x139 dual active low 2>4 decoder ... that's the ticket!

See, if you include a GPIO extender, you can use some of that GPIO for system uses. So you have one decoder, /EN tied to ground so it's always on, tied to the two pins that were original SD and serial flashROM CS's. So %01 SD card, %10 serial flash ROM %11 GPIO extender ... %00, SPI expansion bus. ...

Oh, sticker price shock ... I looked at Mouser and one of those PI 28-port port extenders is like $6+ Q1 ... as a rule of thumb, double for built cost and add 20% operating margin, maybe $15 added to the price of the board.

OK, that locks in the 7x139 decoder approach even more.

I believe the following works, but don't have any hardware to test it, so it's all speculative. Also the X8 specifics that it is based on are unofficial sources as well, so they may be incorrect.

As above, don't decode the SD and flash ROM selects internally, just send the state out to the pins, and put those two pins into one half of the 2>4 decoder. The other half is used to filter the SPI serial clock so that the shift register only receives the serial clock when the serial shift register is "enabled". Both decoders have their output enable tied on.

The first decoder outputs are %01 to the SD card CS, $10 to the flash ROM CS, %11 to the serial shift register register clock and to be decoded by the second decoder, %00 goes to the output enable of the serial shift register.

The low enable from %11 goes into the register clock line of the shift register. It also goes to the second decoder as the b1 input, with the SPI SCLK as the b0 input. The serial shift register clock is the %00 output of the second decoder, so that it only goes low when both serial shift register select and SCLK are low. MOSI goes to the serial input of the serial shift register, MISO goes to the carry output of the serial shift register.

So when you write a byte into the serial shift register, those are the 8 CS on the SPI expansion port that are selected when the SPI select code is %00. To disable the expansion port, you write $00 to the serial shift register and then %00 leaves everything at rest. For the 74x596, pull up resisters are on the X8 board, since the register outputs are open collector.

Hats shouldn't stack too high, so the SPI hat board specification is simple. The block pin header has SCLK, MOSI, MISO, +3.3V, and CS0-CS7.

The hat specification is as simple as could be, since "hat" boards really shouldn't stack too high, and there are for practical purposes chip selects to spare.

If there truly is a spare pin, and it is not just stranded by lack of logical resources to put it to use, a common Alert line input to the X8 from the boards can be provided. In the lowest logic resource implementation, it is simply a bit in some register somewhere that must be polled. If more logic is available, a second bit might set whether it triggers an IRQ.

There is no protocol on how to find out which of up to 8 SPI devices sent the alert ... while some SPI devices can send alerts (UARTs, I2C bus masters, RTC alarms, GPIO edge detection, etc.) there is no universal standard for how to poll an SPI device to see if it has sent an alert, so that is necessarily left "up to the specific SPI part interface".

  • A "top hat" board, without a pass through block header, use chip select 0 optionally up to 3 and ignores chip selects 4-7.
  • A "pass through" board uses chip selects 4 optionally up to 7, and passes chip selects 0-3 through to its own block pin header, while CS4-CS7 are just NC, pulled high with pull up resisters.

(Note that when this 74x139 decoder is combined with a Mode0 SPI SCLK, the result is not true Mode0 synchronization, since the rising of the output register clock and will be accompanied by an "extra" rising serial clock. According to the datasheet, the correct value will be in the output register, but the serial shift register itself will be one shift ahead. So the "echo" of the old contents received on MISO might be seven of the prior bits, shifted one bit. However, this wouldn't affect the functioning of the SPI expansion port CS lines.)

Link to comment
Share on other sites

12 hours ago, Wavicle said:

In re-watching David's original dream computer video, he mentions that the VIC-20 was simple enough that a hobbyist could understand what every chip on the board does. I assume he didn't use the C-64 because it had a PAL to handle the address decoding complexity.

I remeber David himself mentioned two reasons:
1. All VIC-20 chips (except for VIC chip) are still available today;
2. VIC-20 has static memory map, everything stays at the same place all the time.

Neither of these apply to C-64.

Link to comment
Share on other sites

7 hours ago, davidpgil said:

im a bit bummed the case is going away -- would be nice to offer a template to at least be able 3d print our own case. id like the preassembled  X16 personally. I dont mind paying extra for it.

I think the case will come back. I really do. The idea is too irrisistible. The team will make a lot of money from the X8 and maybe a caseless version of the X16, and find a way to put out a cased version. Off the shelf, so MAYBE, given the right politics, it ends up in some schools or colleges -- or at least people can buy it for their kids.

  • Like 1
Link to comment
Share on other sites

15 minutes ago, James Anders Banks said:

I think the case will come back. I really do. The idea is too irrisistible. The team will make a lot of money from the X8 and maybe a caseless version of the X16, and find a way to put out a cased version. Off the shelf, so MAYBE, given the right politics, it ends up in some schools or colleges -- or at least people can buy it for their kids.

Don't forget that it's only the X16p case under discussion. All of the work toward the smaller X16c case is still there.

So they can always launch a crowd fund of the X16c as a cased unit, and if it hits its funding goal, then it's a go, without needing sales of other members of the family to fund it. Indeed, if the X8 can be released in the form factor of one of the RPi's, so 3rd party cases are widely available so it can be sold as a single SKU, you have a very easy to manage product line.

  • (1) X16p kit, +kbd, (1b) Limited number per batch built X16p, +kbd.
  • (2) Cased X16c, +kbd
  • (3) X8, (3b)  X8 +kbd
Edited by BruceMcF
Link to comment
Share on other sites

2 hours ago, BruceMcF said:

Don't forget that it's only the X16p case under discussion. All of the work toward the smaller X16c case is still there.

So they can always launch a crowd fund of the X16c as a cased unit, and if it hits its funding goal, then it's a go, without needing sales of other members of the family to fund it. Indeed, if the X8 can be released in the form factor of one of the RPi's, so 3rd party cases are widely available so it can be sold as a single SKU, you have a very easy to manage product line.

  • (1) X16p kit, +kbd, (1b) Limited number per batch built X16p, +kbd.
  • (2) Cased X16c, +kbd
  • (3) X8, (3b)  X8 +kbd

My bad. I haven't followed this as well as I had thought, I didn't realise there was a case still on the table.

Both are/were cases with separate keyboards - the X16p case was to be bigger to allow for expansion?

Why is one case dropped and not the other, does the smaller case not have to be assembled in China? No doubt the answers are above but there's five hours reading material on this post now!

So:

  • (1) X16p kit, +kbd, (1b) Limited number per batch built X16p, +kbd. -----OK, KIT FORM SO NO PROB WITH CHINA
  • (2) Cased X16c, +kbd -----YES, SO WHY CAN THIS GO AHEAD YET THE ONE ABOVE CAN'T HAVE A CASE?
  • (3) X8, (3b)  X8 +kbd -----RPI SIZE SO CAN USE AN RPI CASE

 

 

  • Like 1
Link to comment
Share on other sites

11 hours ago, Scott Robison said:

The hard part of duplicating any chip, be it in FPGA or ASIC, is knowing the exact internal structure of the original. That's what takes time. If you have the masks that define the original and still have access to the original tech, duplication is relatively easy.

It would be "simple" (I think) to create a VIC compatible chip in FPGA if all one wanted to do is create something that matched the datasheet. Or the VIC II or SID or whatever. But these chips all have weird undocumented / unintended features that people have learned to exploit. Getting all of those 100% correct is what is hard.

There are already open VIC implementations on FPGA. The Ultimate 64, Turbo Chameleon, and MiSTer C64 cores all have VIC-II implementations. 

They also all have "turbo" modes that are faster than the Commander X16, so if all you want is a faster Commodore 64, you can have one of those pretty much immediately.

 

Link to comment
Share on other sites

1 hour ago, James Anders Banks said:

My bad. I haven't followed this as well as I had thought, I didn't realise there was a case still on the table.

Both are/were cases with separate keyboards - the X16p case was to be bigger to allow for expansion?

Why is one case dropped and not the other, does the smaller case not have to be assembled in China? No doubt the answers are above but there's five hours reading material on this post now!

So:

  • (1) X16p kit, +kbd, (1b) Limited number per batch built X16p, +kbd. -----OK, KIT FORM SO NO PROB WITH CHINA
  • (2) Cased X16c, +kbd -----YES, SO WHY CAN THIS GO AHEAD YET THE ONE ABOVE CAN'T HAVE A CASE?
  • (3) X8, (3b)  X8 +kbd -----RPI SIZE SO CAN USE AN RPI CASE

To be very clear, discussion has focused on the two things that have prototypes already built, the X16p and the X8.

The "X16c" at this point is a design goal, not a completed design ... the team have described it in general terms, but specifics have not been announced, and (as an outside observer) it seems likely that some of the specifics have not been decided on yet. So before launching a cased X16c crowdfund, the team would have to settle on final specifications, hammer out a crowdfund budget, and then use that to set the crowdfund price per unit and minimum order amount for the X16c final development and then production process to begin. Obviously some of those design decisions will involve cost versus features trade-offs that will be controversial.

But, "why cases for the X16c and not the X16p"? It's about cost and economies of scale.

The market for the X16p in kit form is people who are willing to tackle building a board of this complexity. It also has a lot of people who actually prefer their own case ... or already have a suitable one.

And the CX16p in built form required people to build it ... we aren't set up anymore with the assembly lines for soldering those kinds of boards, like back in the 80s (and those were also generally working for the computer maker, not working as an "assembler for hire") so it would likely have to be done by hand at something like a $100 builder charge. So not only is the market size limited by the higher price, but the market size may be even more limited by the number of boards that can be hand assembled in a reasonable period of time.

And you need a minimum number of cases in order for the case option to work. The makers will only do the customization part of the job if you hit a certain minimum order size.

You take the size of the market for people who will hand build something like this, minus the percentage who would rather not HAVE the CX16p case, plus the number willing to order at the higher X16p built price point that it is sensible to accept orders to build, minus the percentage who want to save on the (highest) price by using their own case ...

... and it may not be realistic to try to pursue a "customized" version of case for the X16p.

By contrast, the X16c would be made with surface mount versions of the chips (maybe with one exception). Modern, partly automatic, board assemblers and solder ovens would be able to handle it. Indeed, for that kind of board, a built board would be cheaper overall than a kit, when packaging and handling costs are included. And it never has been considered as an option for a kit form. So for the CX16c, they can do the minimum crowdfunding orders required to meet the minimum order for the cased systems, and if they hit it, they can have the boards start to be built by a modern partly automated batch type small board assembly, and place the case order. It's actually less confusing to just have a single, cased, X16c unit on offer.

Now, there is no guarantee that the X16c will get the crowdfund numbers in order to go into production, but if it doesn't, you refund people's money (but of course, give them an option to take part of their refund in a keyboard and/or an X8). That's how the crowdfunding works ... if it doesn't hit the launch target, the money is refunded.
 

Edited by BruceMcF
  • Thanks 1
Link to comment
Share on other sites

Thanks for such a detailed answer.

So the X16c would be a proper board, it wouldn't be a FPGA in a box, it would be a proper assembled board, but of a modern kind that can be assembled largely by machines.

Where can I find a photo of the kind of case the X16c would likely be in? If I recall the photo that used to be on the commanderx16 homepage was for the x16p.

Sorry if I should know the answer to this, but this topic has gotten so long, and I clearly lost track early on of the different versions.

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Please review our Terms of Use