Commander X16

8 minutes ago, BruceMcF said:

I said "I hope someone" because there's no way on this green earth that it would be me. If xForth development goes well in my time off this fall after getting back to the US, I might seriously consider putting in signed fixed point. Though come to think of it, maybe 24.8 rather than 16.16.

Chuck Moore would approve. I think he does all his floating point maths in fixed point integer.

1 hour ago, paulscottrobson said:

Chuck Moore would approve. I think he does all his floating point maths in fixed point integer.

He also did his "matrix of forth processors" chip with 20bit cells, saying it made doubles largely uneccesary, and fixed point on a power of two on a byte boundary makes it especielly parsimonious, which was his favorite virtue.

1 hour ago, paulscottrobson said:

I haven't seen it. I would be interested to know what the pins are used for. USB in, Audio out (D/A ladder ?), Video out of some sort , SD Card interface.



I think making it cheap opens up a whole new vista, and adding your serial RAM chip opens it up even more.  If 8 bit Dave does release the X8 I hope they spend a little bit of time tweaking the design. An option or a slightly larger port and you could use VRAM as an extended memory like A000-BFFF is now if you weren't using all of it.



But then I never bought the authenticity argument. I still don't really, as a learning experience. I don't buy the whole thing educationally, not that there mightn't be a use for it, but the old Microsoft BASIC is just unusable for that. I was teaching programming nearly 40 years ago and it was antiquated then.

I don't know what all of the original Vera pins are, but all of them except the system bus interface would still be used.

SPI is a serial bus, with master in / slave out, master out / slave in, and serial clock going to all devices, but each device has its own select line and it only reacts to the serial clock if its select is pulled low.

It is already used for the SD card, and for the serial flashROM. So two selects already come out. They can be brought without decoding and use an external decoder. So %11 selects a serial shift register. Write a byte to it with one bit low, you have set the external select. %00 then makes that select active. %10 and %01 select the SD card and serial ROM like before.

A simple block header and you can plug an expansion card on top, and basically any serial interfaced chip that can be made to work with SPI can be put on that card. At the quantities they'd be making them, a dual 2>4 decoder, a serial shift register, a pin block header and an eight resister block would each be less than $0.50. So for less than $2 added to the bill of materials ... maybe $+5 to the final price ... $40-$55 instead of $35-$50 ... suddenly plugging an expansion card on top is possible.

As far as data storage, the X8 "videoram" access is already pretty handy ... instead of (W),Y and increment W+1 on page crossing, $0400,Y and increment the page address register on page crossing. At that price, I'm OK with keeping the code inside 62K - size of the Kernel.

As far as Basic v2 and education, the exact amount of Basic v2 used should be the minimum required to set the system up to autostart the real system. It's like BAT with Dos computers ... nobody was "taught in" BAT, except the poor unfortunates who had to write the batch files for users at a company.

 

16 hours ago, BruceMcF said:

I don't know what all of the original Vera pins are, but all of them except the system bus interface would still be used.



SPI is a serial bus, with master in / slave out, master out / slave in, and serial clock going to all devices, but each device has its own select line and it only reacts to the serial clock if its select is pulled low.



It is already used for the SD card, and for the serial flashROM. So two selects already come out. They can be brought without decoding and use an external decoder. So %11 selects a serial shift register. Write a byte to it with one bit low, you have set the external select. %00 then makes that select active. %10 and %01 select the SD card and serial ROM like before.



A simple block header and you can plug an expansion card on top, and basically any serial interfaced chip that can be made to work with SPI can be put on that card. At the quantities they'd be making them, a dual 2>4 decoder, a serial shift register, a pin block header and an eight resister block would each be less than $0.50. So for less than $2 added to the bill of materials ... maybe $+5 to the final price ... $40-$55 instead of $35-$50 ... suddenly plugging an expansion card on top is possible.



As far as data storage, the X8 "videoram" access is already pretty handy ... instead of (W),Y and increment W+1 on page crossing, $0400,Y and increment the page address register on page crossing. At that price, I'm OK with keeping the code inside 62K - size of the Kernel.



As far as Basic v2 and education, the exact amount of Basic v2 used should be the minimum required to set the system up to autostart the real system. It's like BAT with Dos computers ... nobody was "taught in" BAT, except the poor unfortunates who had to write the batch files for users at a company.



 

The SPI flash is also used to configure the FPGA during reset, a sequence which is driven by either a hardware state machine or embedded microcontroller. If the CS pin for SPI flash goes low, that component must start responding or the FPGA will fail to configure itself properly. You could use an SR latch connected to the SD's CS (set) and reset (reset) to drive a multiplexer select, but that's adding even more external hardware.

I'd consider repurposing the the debug UART as I2C and plug a board with an I2C to UART chip into it when a serial connection is needed for debugging (e.g. MaxLinear XR20M1280IL32-F). If I2C isn't fast enough and enough extra pins are available, that IC can also be configured to communicate over SPI.

4 hours ago, Wavicle said:

The SPI flash is also used to configure the FPGA during reset, a sequence which is driven by either a hardware state machine or embedded microcontroller. If the CS pin for SPI flash goes low, that component must start responding or the FPGA will fail to configure itself properly. You could use an SR latch connected to the SD's CS (set) and reset (reset) to drive a multiplexer select, but that's adding even more external hardware.

A hardware state machine or embedded microcontroller inside the FPGA, or outside? Below, I am presuming inside, since if outside, it would go through an AND with the CS_flash line from the FPGA and there would be no change.

With the external decode, if the the FPGA puts out %01 on those pins, then the CS pin for the SPI flash WILL go low.

If the build is logic resource bound, that is more logic to have the FPGA reset state machine drive CS_flash low AND CS_SD high, independent of the simulated register state (or, during FPGA reconfiguration, existence!) versus the status quo where it only drives CS_flash low and that is nothing but an AND.

It's also less logic to have it not decode the state of CS_flash and CS_SD from the two setting bits in the register.

But the logic is likely not in the same place.

So ... well, if it builds, it builds, if it doesn't, back to the drawing board.

Then there is the mystery pin. If it is available (at least when none of the three are decoded) and CS2, CS1 and CS_flash=CS0 are taken out, then you can have three external selects with a single three to eight decoder: CS_SD=%001, CS_EXT1=%011, CS_EXT2=%101, CS_EXT3=111. With CS_flash directly to the flash and decoded %xx0 not connected, the CS_flash select effectively over-rides the SD and External selects, with no FPGA logic required. That's a single glue logic, pull up resisters and a pin block header. And the pin block header is smaller, to boot ... +3.3V, GND, SCLK, MOSI, MISO, CS_EXT1, CS_EXT2, CS_EXT3 ... 1x8 long/wide.

On the debug serial port, how usable is the debug serial port as-is, if operated from the X8?

If it's an I2C bus master, and the I2C bus being mishandled is why you need to debug, I don't know enough about I2C and what would likely be already built into the fpga dedicated serial module to know if that is problematic. If that works, heck, just add that to the block pin header and make it 10 long. I2C_1, I2C_2, +3.3V ... or for a more stable base for a hat, a four block pin header with I2C and power, and a six block pin header with just SPI, on parallel edges.

I don't know enough about I2C to know if this is what you were proposing or it it's feasible, but if for debugging purposes, the UART/I2C bridge is connecting with the X8 acting as an I2C peripheral, that's a really appealing change, since then doing the same thing without the UART means the X8 can be plugged straight into the X16 I2C bus.

 

 

On 8/26/2021 at 9:29 PM, BruceMcF said:

... a Kernel that implements the Commodore Kernel interface would likely need a development team, since by their nature their first impression would be that they were built on Commodore IP that Cloanto claims, and they would have to document that they are "clean code".

Mega65 has a repo started for this, and a defined process to ensure IP is not violated.  I was excited to see this, even though it’s not a priority. An open source KERNAL ... seems to have a lot of appeal.

 

https://github.com/MEGA65/open-roms

23 minutes ago, rje said:

Mega65 has a repo started for this, and a defined process to ensure IP is not violated.  I was excited to see this, even though it’s not a priority. An open source KERNAL ... seems to have a lot of appeal.



https://github.com/MEGA65/open-roms

Yes. However, implementing the Kernel interface would be even easier than producing a KERNAL rom image that is compatible with the bulk of C64 games and applications, so a project with the less ambitious goal could take what they have so far and likely complete it substantially faster.

12 hours ago, BruceMcF said:

A hardware state machine or embedded microcontroller inside the FPGA, or outside? Below, I am presuming inside, since if outside, it would go through an AND with the CS_flash line from the FPGA and there would be no change.



With the external decode, if the the FPGA puts out %01 on those pins, then the CS pin for the SPI flash WILL go low.



If the build is logic resource bound, that is more logic to have the FPGA reset state machine drive CS_flash low AND CS_SD high, independent of the simulated register state (or, during FPGA reconfiguration, existence!) versus the status quo where it only drives CS_flash low and that is nothing but an AND.

The SPI master configuration process is documented in the iCE40 Programming & Configuration technote (TN 2001) section 9.4. The SPI_SS pin is expected to have an ~10kohm external pull up which is how the SPI master configuration mode is selected. Once the mode select is detected, the FPGA will assert SPI_SS and begin downloading the design configuration from the SPI flash. It's an automatic process that begins after POR or regular CRESET_B rising edge transition and cannot be modified. Whatever mechanism you plan to use for multiple SPI chip select lines, that pin must still function as expected during that critical time period.

12 hours ago, BruceMcF said:

On the debug serial port, how usable is the debug serial port as-is, if operated from the X8?



If it's an I2C bus master, and the I2C bus being mishandled is why you need to debug, I don't know enough about I2C and what would likely be already built into the fpga dedicated serial module to know if that is problematic. If that works, heck, just add that to the block pin header and make it 10 long. I2C_1, I2C_2, +3.3V ... or for a more stable base for a hat, a four block pin header with I2C and power, and a six block pin header with just SPI, on parallel edges.



I don't know enough about I2C to know if this is what you were proposing or it it's feasible, but if for debugging purposes, the UART/I2C bridge is connecting with the X8 acting as an I2C peripheral, that's a really appealing change, since then doing the same thing without the UART means the X8 can be plugged straight into the X16 I2C bus.

Again, keeping in mind I'm basing this on Verilog code posted 8 months ago and I'm not an authoritative source --

The debug serial port as implemented is driven from a UART design that is in Verilog and not a hard IP block in the FPGA. I'm not sure that making the X8 an I2C slave makes sense, but in any case the component I mentioned does not operate as an I2C master. I'm not aware of any such component that does.

9 hours ago, Wavicle said:

The SPI master configuration process is documented in the iCE40 Programming & Configuration technote (TN 2001) section 9.4. The SPI_SS pin is expected to have an ~10kohm external pull up which is how the SPI master configuration mode is selected. Once the mode select is detected, the FPGA will assert SPI_SS and begin downloading the design configuration from the SPI flash. It's an automatic process that begins after POR or regular CRESET_B rising edge transition and cannot be modified. Whatever mechanism you plan to use for multiple SPI chip select lines, that pin must still function as expected during that critical time period.



Again, keeping in mind I'm basing this on Verilog code posted 8 months ago and I'm not an authoritative source --



The debug serial port as implemented is driven from a UART design that is in Verilog and not a hard IP block in the FPGA. I'm not sure that making the X8 an I2C slave makes sense, but in any case the component I mentioned does not operate as an I2C master. I'm not aware of any such component that does.

So a reset system can be simply some form of switch that connects the FPGA CS_rom to a ~10kohm external pull up.

So there is a simpler system, which is to just generate ONE external select from the undecoded CS_rom and CS_SD. The CS_rom is just an informative input to the decoder, the CS_rom from the FPGA is connected straight to the serial ROM CS. The CS_SD and CS_EXT are %01 and %11 respectively. %00 and %10 then both actually select CS_rom, so there is no SPI bus contention despite CS_rom and CS_SD no longer being decoded.

So I will just look at the options if there is no extra pin available ... if there is, the options proliferate.

1. If there is no extra pin, I2C only approach:

• 
  CS_rom and CS_SD are brought out decoded
  


• 
  There is an internal setting which switches the two UART pins to I2C
  

2. If there is no extra pin, UART centric approach:

• 
  CS_rom and CS_SD are brought out undecoded and decoded externally, to CS_rom, CS_SD and CS_EXT, the CS_rom line is also connected through the FPGA hard reset switch to a reset pull-up resister and AND'd with the decoded CS_rom line.
  


• 
  %11 is brought out as CS_EXT.
  


• 
  The UART is left alone, to provide a built in serial port connection.
  

3. If there is no extra pin, I2C centric approach:

• 
  CS_rom and CS_SD are brought out undecoded and decoded externally, to CS_rom, CS_SD and CS_EXT, the CS_rom line is also connected through the FPGA hard reset switch to a reset pull-up resister and AND'd with the decoded CS_rom line.
  


• 
  %11 is brought out as CS_EXT.
  


• 
  There is an internal setting which switches the two UART pins to I2C
  

If there is no extra pin, and if there are the logic resources to support the I2C, my preference would be the third. SPI is convenient to breadboard. If there was a desire to have multiple SPI parts on a single hat, an I2C 8bit GPIO expander could generate the extra selects. And of course, if there is a desire to have multiple I2C parts on a single hat, they just need to have unique I2C addresses. It also means less of an issue if the I2C cannot support HS mode, since the External SPI bus supports 12.5Mbps.

Now, if the "extra pin" is really there, the simplest external expansion is to put it out low when the two CS bits are high. That avoids any extra build cost of the external circuitry, and provides a "normal operation" "all deselected" state at %00.

 

 

I wonder if it's worth considering the x16 with a full FPGA implementation like the X8? Not sure what it would mean for the YM chip but perhaps there is already FPGA for that too. It would allow for complete "firmware" upgrades in the future and could simplify the overall design. Not sure if it would help reduce manufacturing costs. Yes, my idea is a little radical I know, especially with all the work and time spent so far on the hybrid FPGA / non FPGA chips approach. ?