VLOAD speed enhancement

[ZeroByteOrg]

On Discord, I had an idea for how to use the existing fat32_read routine in DOS with VLOAD.
Currently VLOAD uses ACPTR to read a file byte-by-byte into VRAM.
I considered a method to enable MACPTR as follows:
Create a 'VACPTR' call which is essentially just a front-end for MACPTR.

• VACPTR will configure VERA data0 port to point to the target VRAM location with stride=1
• It will then call MACPTR with the load-to address = data0
• There needs to be some kind of flag set in memory "no-advance" which fat32_read can see.
• in DOS, the fat32_read loop which copies from the IO buffer in bank0 into RAM should check the flag before advancing the dst pointer during the loop.
  e.g.:
  BIT noadvance ; msb set = do not advance dst pointer / msb clear = normal operation
  BMI :+
  ; increment mem destination ptr
  :

[ZeroByteOrg]

Hmmm - on second thought, this won't be quite as easy, because the buffer copy counts backwards, which would put the bytes into VRAM in the wrong order....
Will give it a little more thought.

On the bright side, if a dedicated copy loop is required, then it can be jumped into using the dst address == VERA_data0 criteria instead of requiring a flag....

[ZeroByteOrg]

Planning to revisit this issue. It would make sense to just modify the existing MACPTR to support a "fixed destination" mode where the copy from fat32 buffer into memory would simply not advance the destination pointer at all during the copy, but still return the number of bytes transferred as usual.

This new behavior shouldn't be signaled by destination address==$9F23 / $9F24. "single destination mode" could be useful for other things like streaming directly into PCM FIFO register, or if an expansion peripheral is available that can take data streams, make use of it for that as well.

I'm thinking it makes the most sense to use the C flag as a calling parameter into MACPTR: clear=normal mode / set=single-destination-address mode. However, this might break existing code, so I'm curious what others think.

[mist64]

Implemented in f6a5bf5

[mist64]

commanderx16/x16-docs#102