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.
1 hour ago, paulscottrobson said:
Chuck Moore would approve. I think he does all his floating point maths in fixed point integer.
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.
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.
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.
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".
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
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.
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.
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.