Loading the disk is slower than I expected

1

SP4CEBAR 2024-01-24 14:54 (Edited)

I did a benchmark with the following bit of code:

GLOBAL COUNT
COUNT=0

ON VBL CALL RESET_COUNT

DO
  LOAD 4,$A000,1,COUNT
  'V=PEEK($A000)
  'FOR I=0 TO 5000
  'NEXT I
  INC COUNT
LOOP

SUB RESET_COUNT
  NUMBER 0,0, COUNT,20
  NUMBER 0,1,TIMER,20
  COUNT=0
END SUB

This disk loading command lasts the entire frame (the shown count value is "1"), even though it loads a single byte. Interestingly, NX's CPU monitor is at 01%, as if the "LOAD" command has a "WAIT VBL" inside, but if that were the case the count value would be "0".

What this means for the MIDI API is that it needs a cache bucket for each track, to minimize the LOAD commands.

SP4CEBAR 2024-01-24 15:56 (Edited)

This may very well have been the cause of one of the the hanging note problems: big files have tracks within multiple cache segments, so the player has to change the cache a lot to be able to play these tones at the same time

Timo 2024-01-26 08:47

I don't really remember the exact logic behind it and a quick look into the source code didn't help :/
But I guess the CPU cycles depend on the number of bytes you load from a file. And probably it always has the additional effect of a WAIT VBL.

SP4CEBAR 2024-01-26 11:10

Thanks for your effort!
now that I think about it, if I were to benchmark a wait VBL with this program, the shown count from the second frame onward would likely be "1". So it is indeed likely that the load command has a wait VBL inside

Log in to reply.