Page 37 of 78

Change of product direction, good and bad news!

Posted: Wed Aug 25, 2021 10:31 pm
by rje


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.


Change of product direction, good and bad news!

Posted: Wed Aug 25, 2021 10:34 pm
by Scott Robison


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.


Change of product direction, good and bad news!

Posted: Wed Aug 25, 2021 11:13 pm
by Wavicle


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.)


Change of product direction, good and bad news!

Posted: Wed Aug 25, 2021 11:40 pm
by Scott Robison


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.


Change of product direction, good and bad news!

Posted: Thu Aug 26, 2021 12:17 am
by davidpgil

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.


Change of product direction, good and bad news!

Posted: Thu Aug 26, 2021 12:18 am
by Brad


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. 


Change of product direction, good and bad news!

Posted: Thu Aug 26, 2021 12:34 am
by Scott Robison


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. ?


Change of product direction, good and bad news!

Posted: Thu Aug 26, 2021 4:48 am
by BruceMcF


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.)


Change of product direction, good and bad news!

Posted: Thu Aug 26, 2021 5:45 am
by Cyber


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.


Change of product direction, good and bad news!

Posted: Thu Aug 26, 2021 7:35 am
by James Anders Banks


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.