gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Fat Library optimization by adding a task scheduler?

#107148 - Dwedit - Fri Oct 27, 2006 5:33 am

This probably requires that the DS or GBA have some kind of operating system to handle task switching, but it looks like a huge possible speed improvement to the FAT library.
There are time where the FAT library spinlocks on when the disk is ready, and on when the data becomes available. Since afterwards, the transfer is quick, I think that the spinlock should be converted into timed polling, and while it's busy, yield the processor to another task.
This could allow an API including functions like fread_background, which would update a size counter indicating how much has been read, so a file could call this, test if enough has been transferred into a buffer, then work on what data is available. Data could be processed during the time formerly used for spinlock. I think it could speed up media-playback programs quite a bit.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#107151 - josath - Fri Oct 27, 2006 6:58 am

A possible issue might be that from what I understand, some of the FS drivers require EXACT timing. Having stuff running in a separate thread might impact that timing.

#107239 - tepples - Fri Oct 27, 2006 10:39 pm

Then would it be possible to have some function that tells whether the inserted card supports non-blocking sector reads? Or the exact timing issue could be solved by running the block device driver on ARM7 while game code runs on ARM9.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#107253 - josath - Sat Oct 28, 2006 12:48 am

I think libfat can already be run on arm7, in which case this would be pretty easy to implement. Simply have a function on arm9 which requests the arm7 to read data in the background, and then arm7 will alert the arm9 when the read is done.

#107284 - tepples - Sat Oct 28, 2006 5:55 am

And here's an idea to make this work, which resembles the way it's done in Real Operating Systems(tm) and on Real Game Consoles(tm): Run the file system on the ARM9 and the block device driver on the ARM7. Have the ARM7 prefetch up to 64 kilobytes of sectors when it gets free time. This way, sector requests from the ARM9 appear to complete almost immediately.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#107296 - Dark Knight ez - Sat Oct 28, 2006 9:34 am

With extensive music playing libraries on the ARM7 (libmikmod in some projects), wouldn't they (the lib executing and FAT code executing) hinder each other?
I'm hoping most projects will put their music playing libraries on ARM7, which is the cleaner way to do things, so I am hoping this is given some thought.

#107302 - OOPMan - Sat Oct 28, 2006 10:19 am

Hmmmm, if you multi-threaded them (The sound and background reading functionality) on the ARM7 then you might do okay. Might.
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

#107343 - tepples - Sat Oct 28, 2006 8:34 pm

OOPMan is right. It probably wouldn't be too hard to prefetch sectors from the block device as requested by the ARM9 during any period that the ARM7 isn't doing touch screen I/O or mixing sound.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.