Commander X16

On 5/12/2021 at 12:42 AM, Ed Minchau said:

That's definitely not what the emulator is doing. Data loaded directly to VRAM doesn't touch the CPU at all.

That's when the host filesystem is being used ... the data appears "by magic" because the emulator is not EMULATING how the system will access the actual filesystem, because the ACTUAL filesystem will be on an SD card with a defined storage format

Using the host filesystem could be in any of a wide number of storage formats, which the CX16 being emulated doesn't, and needn't, have any way of handling.

On 5/12/2021 at 11:12 AM, Ed Minchau said:

That doesn't make much sense to me; if the data is already on VERA and destined for VERA, why route it through a CPU only 1/3 as fast instead of keeping it on the FPGA?

The FPGA isn't a microcontroller, it's implementing hardware. It's not like the FPGA is emulating an SPI port and so it "has" the data and then "puts it out" ... it is a programmed circuit that IS an SPI port. The SPI port is just a shift register with a carry line that puts out the serial bit from one side of the register onto the MOSI line and latches the serial bit to the other side of the register from the MISO line, shifting across one bit for every clock pulse, all at the correct clock phases to work with the SD-card SPI mode. It makes the contents of the SPI available on the data lines when the "data register" is selected, and when the "control register" is selected, it offers select and speed control and a "ready" bit to find out when 8 clock pulses have completed.

An SPI circuit won't be using much of the FPGA logic resources ... it's such a simple circuit it can be implemented on a fairly small CPLD. That's why SD cards HAVE an SPI mode ... because from the start they were intended for popping into things that didn't necessarily have a full fledged modern computer inside, then popping them out and putting them into a reader connected to a PC to access the pictures or sound files or whatever.

Since the SPI circuit doesn't use the RAM bundled into the FPGA, the data never touches that RAM unless the CPU puts it there.

If you want things timed according to the actual CX16 timing, you need to use data in the SD filesystem.

_________________

On 5/12/2021 at 4:55 PM, Scott Robison said:

I've read some posts that indicated that the existing functionality pretty much maxes out the current FPGA when someone suggested more video RAM, and that the next size up would increase the cost.



The reality is that there is always something more than could be done with an FPGA if you just had more logic blocks or more IO pins or more interconnects or whatever, but those increase the cost, and this is already costing more than I believe was originally desired (though they can likely bring the price down in the future, I believe is the plan).

Oh my goodness yes! Replicating what the CPU does to get data off of the SD card would require a co-processor on the FPGA, which would be many multiples of the logic slices as what is required to implement a simple single-byte, single-mode, two clock speed SPI port.

12 hours ago, BruceMcF said:

 It makes the contents of the SPI available on the data lines when the "data register" is selected, and when the "control register" is selected, it offers select and speed control and a "ready" bit to find out when 8 clock pulses have completed.

So it *can* put the contents of the register on the data lines for one channel. Only now it's putting those contents on one channel to output to the CPU, and then to put it in VRAM the CPU is putting that same data on the other channel, which automatically increments.  This is an unnecessary step. Sure, you can use the CPU to set up the address lines etc. for that channel initially, but the bulk of the process doesn't need the CPU at all; just make that data available on the other channel! The CPU could just get the process going - initialization stuff the FPGA doesn't handle - and wait for an EOF interrupt. 

2 minutes ago, Ed Minchau said:

So it *can* put the contents of the register on the data lines for one channel. Only now it's putting those contents on one channel to output to the CPU, and then to put it in VRAM the CPU is putting that same data on the other channel, which automatically increments.  This is an unnecessary step. Sure, you can use the CPU to set up the address lines etc. for that channel initially, but the bulk of the process doesn't need the CPU at all; just make that data available on the other channel! The CPU could just get the process going - initialization stuff the FPGA doesn't handle - and wait for an EOF interrupt. 

Yes, it is physically possible to build the functionality you would prefer directly into the FPGA. It would mean either getting a larger FPGA, which would cost more money, or it would mean decreasing the amount of video RAM or other functionality (such as audio).

There ain't no such thing as a free lunch. Something has to pay for the increased functionality which does not happen magically.

The goal of the platform is to provide an 8-bit system in the style of what was used 40 years ago today (and suddenly I feel old). Modern support chips are in the opinion of some a step too far, but given the lack of available modern production of equivalent chips for video, audio, and so on, it is a necessary compromise without which there would be no real possibility of a Commander X16.

Forcing the 65C02 to be involved in processing means that the process is less efficient than it could ideally be. That is the compromise that was selected for this design. Every design has compromises. Regardless of what we might like to see, it (almost definitely) isn't going to change at this point. I qualify it thusly because I don't make any decisions and acknowledge that it is a statement of opinion, but it is an informed statement of opinion.

I don't see why sending data to one channel rather than the other and changing some handshaking/initialization code in ROM would require a bigger FPGA, but I agree nothing is likely to change at this point. I do hope future versions of the documentation make it clear that all the data is passing through the CPU so others don't make the same mistake I did.

4 hours ago, Ed Minchau said:

I don't see why sending data to one channel rather than the other and changing some handshaking/initialization code in ROM would require a bigger FPGA, but I agree nothing is likely to change at this point. I do hope future versions of the documentation make it clear that all the data is passing through the CPU so others don't make the same mistake I did.

It's not just a matter of sending a byte from one channel to another. There is a file system that has a definite structure. The CPU is what processes that structure. Looking up the file allocation table, enumerating directories, opening files, seeking to offsets, reading clusters, copying the data around. That's not functionality that comes easy to an FPGA without having a programmable interface. 6502 is one of the smaller mainstream CPUs and it takes by one estimate about 700 lookup tables (https://electronics.stackexchange.com/questions/400504/how-many-luts-are-needed-to-implement-a-cpu).

There is a lot of logic that goes into processing a file system. I've worked for a couple companies over the years that dealt with file system processing, and I've written a complete user mode implementation of NTFS and FAT32.

In other for the FPGA to decide where to send a byte it has to have an implementation that can process all the details of the filesystem. It can be done, but it is far more complicated than just "send the byte to channel X".

Edit: I wrote complete read-only implementations of those file systems to read data from a cold backup image that was just stored as a collection of clusters. I've not written a writable interface, but since we're talking about reading from the file and writing to memory, I have direct experience with that. I even have a patent on identifying what files changed in an incremental image based backup. I don't mean that to brag, just to establish credentials.

11 hours ago, Ed Minchau said:

So it *can* put the contents of the register on the data lines for one channel. Only now it's putting those contents on one channel to output to the CPU, and then to put it in VRAM the CPU is putting that same data on the other channel, which automatically increments.  This is an unnecessary step. Sure, you can use the CPU to set up the address lines etc. for that channel initially, but the bulk of the process doesn't need the CPU at all; just make that data available on the other channel! The CPU could just get the process going - initialization stuff the FPGA doesn't handle - and wait for an EOF interrupt. 

No, it cannot "put" the contents of the registers on the data lines, in the sense that a processor puts data somewhere, following a program ... it SELECTS the register to output using logic wired as demultiplexors and other glue logic, and does not select any of the other lines that are connected to the data bus pins, because it is WIRED to do it that way.

It is not AN extra step for the FPGA to fill the VRAM from the SPI register, it is MULTIPLE extra steps. First step is to build a co-processor that can manage the SD card reading process: right now, the 6502 handles that. Second step is to store the routines for the co-processor to perform those activities. Those steps are needed for the correct "byte" to be sitting in the SPI interface in the first place. THEN the THIRD step is to add the logic to have the SPI register and the FPGA Static RAM block both be addressable by the coprocessor. The FOURTH step is to work out how to avoid contention for access to the FPGA Static RAM block by the internal coprocessor and by the CPU, because if people are correct about the FPGA they see on the board, that's single ported Static RAM and cannot be accessed by two different processors simultaneously.

You have to HAVE a CPU to access the data on the SD card. "It's already in the FPGA" doesn't matter if there is no processor inside the FPGA in order to DO something with the data in the SPI port independently of the CPU.

It's like you are imagining that the FPGA is implementing an SD2IEC, when in reality all it is doing is implementing an SPI port. Or else imagining that there are endless slices and lookups to add a processor to the FPGA, when what has been reported is that it's close to being maxed out.

You're imagining this to be far more complicated than it actually is. Beyond setting up the handshaking and initialization, the CPU would be in a WAIT state until receiving an End Of File interrupt. There wouldn't be contention between the CPU and FPGA at all for those data lines because the CPU wouldn't do anything until that interrupt.

And you're not doing any processing on the data. Instead of using two channels you only use one. When the SPI has a complete byte, it puts the data on the same channel that it is expecting to receive data, and the exact same signal that would have let the CPU know there is data ready to be input would instead signal the other part of the FPGA that is expecting input to store in VRAM that data is ready on that channel. The difference is a *single* logic gate on the FPGA and different initialization code on the ROM.

3 hours ago, Ed Minchau said:

When the SPI has a complete byte

What byte, exactly? How does it know? You've been given a pretty thorough explanation of how it is actually more complicated. What you are asking for requires another set of control registers, and that's simply not possible. If you think it is easy, please show your work. ROM code, VHDL, the whole deal, and then you can roll your own VERA module and ROM image because the fact is that the dev team is not changing this. It is what it is. I think it's time to drop this fruitless conversation.

4 hours ago, Ed Minchau said:

You're imagining this to be far more complicated than it actually is. Beyond setting up the handshaking and initialization, the CPU would be in a WAIT state until receiving an End Of File interrupt. There wouldn't be contention between the CPU and FPGA at all for those data lines because the CPU wouldn't do anything until that interrupt.



And you're not doing any processing on the data. Instead of using two channels you only use one. When the SPI has a complete byte, it puts the data on the same channel that it is expecting to receive data, and the exact same signal that would have let the CPU know there is data ready to be input would instead signal the other part of the FPGA that is expecting input to store in VRAM that data is ready on that channel. The difference is a *single* logic gate on the FPGA and different initialization code on the ROM.

What do you mean "you are not doing any processing on the data"?

Even doing it A BYTE AT A TIME, you are setting up the SPI register to transfer a byte with the SD card. You are moving it from the SPI register to SOMEWHERE in the Static RAM attached to the FPGA.

The "single logic gate" you are talking about is if a SINGLE byte is moved, and it's much more than a single logic gate: you actually have to wire up the circuitry to DO THE MOVING. The "other part of the FPGA that is expecting input to store in VRAM" is WIRED to react to an action on the CX16 bus.

And you are talking about zooming through until "End of File" ... then you have to get those bytes a segment at a time. And then you have to find out which segment is the next segment in the file, and instruct the SD card that you want the next segment. All of that is data processing, even if you don't change the contents of the segments at all.

Getting an entire file requires a CPU of some sort, so if the 6502 is not doing that, you have to build a coprocessor into the FPGA.