Commander X16

1 minute ago, Elektron72 said:

CPU has to process each byte

That's what I suspected. I know it works the same way when LOAD-ing to regular RAM. The emulator traps out the kernal call and just does an fread into the emulator RAM.

1 hour ago, Elektron72 said:

I usually use the emulator with an SD card image so I can access features that are not supported when using the host filesystem. I have used the debugger to step through the routine that handles loading to VRAM, and can confirm that when an SD card image is used, the CPU has to process each byte. On the other hand, loading to VRAM (or anywhere else) does not involve the CPU when the host filesystem is used, as the emulator itself handles calls to the load routine.

That doesn't make a lot of sense. When loading from SD to VRAM, why push it to the CPU at all? Data is going from SD to VERA to CPU and back to VERA unchanged.  I hope @Frank van den Hoef sees this discussion and can clear this up for us.

4 minutes ago, Ed Minchau said:

why push it to the CPU at all?

It's not pushed. The SPI interface doesn't run independently of the CPU. When a byte is pulled into the SPI_DATA register, the CPU needs to load it to a register to then store it in its final destination, whether that is RAM, VRAM, or some other I/O register.

4 hours ago, SlithyMatt said:

It's not pushed. The SPI interface doesn't run independently of the CPU. When a byte is pulled into the SPI_DATA register, the CPU needs to load it to a register to then store it in its final destination, whether that is RAM, VRAM, or some other I/O register.

It was my understanding that the SD interface is on VERA, not the motherboard. 

14 minutes ago, Ed Minchau said:

It was my understanding that the SD interface is on VERA, not the motherboard. 

I am not an expert, but ...

Yes, the SPI interface is on VERA. But it is a relatively low level interface. It probably doesn't natively understand the format of the data on the SDCARD, just that there is a collection of bits and bytes. It is probably necessary for the CPU to control the SPI IO ports, just as it controls the video and audio IO ports, then interpret the data to decide what commands to issue next. After receiving the data the software running on the CPU can decide what to do with that data (copy it to main system memory, a RAM bank, or back to VERA on another IO port).

FPGA flexibility means that you can have one "chip" on the FPGA that does a certain level of work and communicates it over selected IO pins. In the case of SPI, it would not surprise me if the routing of the signals for SPI goes directly from the SPI hardware that connects to the physical SDCARD, then is minimally routed to specific pins that the CPU can access through a given address.

Again ... I am not an expert, I'm just theorizing as one who has (literally only) played with FPGA and has not seen any of the HDL that is used to create the bitstream for the FPGA. I could be completely wrong. Mainly I just wanted to opine to see how close my theory is if an answer is ever provided.

1 hour ago, Ed Minchau said:

It was my understanding that the SD interface is on VERA, not the motherboard. 

Yes the SD is on the VERA daughter board, connected to the FPGA's SPI interface. However, there is no function built into the VERA to load data from SPI to VRAM. The SPI control just passes straight through the control register and is completely under control of the CPU. There's no VERA register that you can tell it "copy this file to this address of VRAM". It is much lower level than that. All the VERA does is bitbang the SPI based on what is written to the control register, and then shifts bytes in and out of the data register. The way the emulator cheats the file I/O for the convenience of using the host file system is not at all representative of how the hardware works.

2 hours ago, SlithyMatt said:

Yes the SD is on the VERA daughter board, connected to the FPGA's SPI interface. However, there is no function built into the VERA to load data from SPI to VRAM. The SPI control just passes straight through the control register and is completely under control of the CPU. There's no VERA register that you can tell it "copy this file to this address of VRAM". It is much lower level than that. All the VERA does is bitbang the SPI based on what is written to the control register, and then shifts bytes in and out of the data register. The way the emulator cheats the file I/O for the convenience of using the host file system is not at all representative of how the hardware works.

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?

1 minute ago, 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?

Because the VERA doesn't have a CPU. To add the logic to do that would require a larger, more expensive FPGA, and at that point just stick the whole thing on an FPGA.

5 hours ago, 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?

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

Well, poop. That means my video demos won't work on the actual hardware.