Bjarne
PypeBros@breathing-retro.bsky.social got to check whether https://github.com/Alfombracitario/Alfombra-s-Pixel-Art-Editor-DS/blob/main/source/formats.cpp could have a "import .spr / export .spr" functions ... Done with #blocksds, btw.
Haven't tried the #BlocksDS alternative for #ndsdev yet. I guess I should #booxread https://gbatemp.net/threads/devkitpro-vs-blocksds.677924/
DevKitPro vs BlocksDS?
Recently started a homebrew project for Nintendo DS. Years ago I learned the existence of DevKitPro as the go-to toolchain to develop for the DS. I went as far as setting up a basic build pipeline for myself and managed to build some of my own code, using DevKitPro, that runs on DeSmuME...
asieThose of you who have been following me for a while may be aware that I've been involved with the #BlocksDS DS/DSi toolchain project.
I've spent the last few days looking into its SD card I/O situation. There's a lot of moving parts involved; a file read operation goes something like this in our stack:
user <-> picolibc stdio <-> FatFS <-> libnds <-> ARM9->ARM7 inter-CPU FIFO queue <-> DSi SD card driver
Most of these components required some amount of optimization-centric patching. Here's the in-progress results of this work, with our current numbers on the right, and numbers the homebrew community has been used to on the left. Special thanks to ChaN for the legendary FatFS (which I've made performance patches to), profi200 for reading through an unfathomable amount of material to build a high-quality DSi SD card driver, and AntonioND for setting the wheels of the BlocksDS project in motion.
Also, thanks to all of you for following our collective work, of course. Your support and enjoyment of it means everything to me.
(Testing methodology: Samsung EVO Plus 256GB SDXC U3 A2 V30 - the fastest card my friend had on hand in order to minimize the I/O bound, provided by @[email protected] - and the benchmark as written at https://github.com/asiekierka/nds-sd-benchmark)
I've spent the last few days looking into its SD card I/O situation. There's a lot of moving parts involved; a file read operation goes something like this in our stack:
user <-> picolibc stdio <-> FatFS <-> libnds <-> ARM9->ARM7 inter-CPU FIFO queue <-> DSi SD card driver
Most of these components required some amount of optimization-centric patching. Here's the in-progress results of this work, with our current numbers on the right, and numbers the homebrew community has been used to on the left. Special thanks to ChaN for the legendary FatFS (which I've made performance patches to), profi200 for reading through an unfathomable amount of material to build a high-quality DSi SD card driver, and AntonioND for setting the wheels of the BlocksDS project in motion.
Also, thanks to all of you for following our collective work, of course. Your support and enjoyment of it means everything to me.
(Testing methodology: Samsung EVO Plus 256GB SDXC U3 A2 V30 - the fastest card my friend had on hand in order to minimize the I/O bound, provided by @[email protected] - and the benchmark as written at https://github.com/asiekierka/nds-sd-benchmark)
