Possible to add read-ahead or asynchronous reads?

Support for the GBA/DS/Gamecube/Wii media card library
Post Reply
Posts: 1
Joined: Wed Aug 24, 2011 9:44 pm

Possible to add read-ahead or asynchronous reads?

Post by FluBBa » Wed Aug 24, 2011 9:51 pm

Streaming CDDA while emulating the PC-Engine is quite cpu intensive and I'm now wondering if there is a possibility to add some kind of read-ahead or asynchronous file read for libfat...

Can I help with the implementation, if so where do I start?
How does the file reading work?
is it that my program calls the read function (ARM9) and that function calls some functions on the ARM7 and then the ARM9 idles until the ARM7 is done with the reading?

Site Admin
Posts: 1478
Joined: Tue Aug 09, 2005 3:21 am
Location: UK

Re: Possible to add read-ahead or asynchronous reads?

Post by WinterMute » Thu Aug 25, 2011 2:28 am

libfat already has a read-ahead cache but no means to make it asynchronous. I'm really not sure how this could even be approached without some major hackery.

You could try messing with the cache size using fatMount instead of fatInitDefault - the default for the DS is 16 pages of 8 sectors, increasing the sectors per page will increase the amount read at a time. You can get a disk interface for that from dldiGetInternal but this won't currently work for code run on the DSi via Sudukohax.

The low level disk functions in the DLDI section are run on the arm9, internal arm7 functions are used on the DSi when access to the internal SD card is available - i.e. booted via Sudukohax. The DSi functions currently block until the read is completed and, being honest, I have no idea how to allow for background reads safely with the current libfat and stdio layer. The DLDI should have been built to run on arm7 but some cards, notably the R4, have this code built for arm9. In theory it should be possible to run this code in main memory on the arm7 but this will most likely lock out the arm9 when it attempts to use the external bus. Dealing with asychronous reads using stdio is another kettle of fish entirely - we don't have implementations for aio_ functions nor do we have threads. There's also the small matter of cache coherency.
Help keep devkitPro toolchains free, Donate today

Personal Blog

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest