Thank you so much! It works great, and I don't miss vsync, but it looks like I still have a bug in the way I think I'm writing my level file, or the way I think I'm reading it. I verified using hexdump, cut, and diff that the first 1024 sectors of the level file match what I get reading the first 1024 sectors using this function, so the function works properly, I just have to track down my bug.Jubatian wrote: ↑Mon Apr 02, 2018 7:38 am Eh, if you need it so much, here is a solution in an attachment. Add it to the Makefile like any other assembly module (check the lines used for including kernel stuff), then you can use it as described in its header file.
Still, I wouldn't especially recommend this route. When designing the bootloader library, I could experience some of my SD cards being really slow. I mean so slow that even with the normal CRC enabled reading, waiting for the data token took occasionally more than the read itself. So realistically if you wanted to support any SD card, you may still need to spare a full VBlank for a read (it may not always happen, but if it does, be prepared to handle it in a sensible manner).
CunningFellow's streaming (Tempest background) on the other hand may still work fine even on such slow cards. If you issued a CMD18 at the beginning of the VBlank, then left the card to do whatever it needs to do to get the data ready, it may be ready to read by the time the next frame starts, and the cards are designed to be fast with sequential access.
EDIT: What about the write support I submitted as an experimental branch above? If it works okay, I would like to merge it in!
For the write support, can it only overwrite an existing file? And can I just keep calling FS_Next_Sector to extend the file properly?