I wanted to make this a "short update" on my DS progress but failed hard on that one, hahaha. To reduce the damage I put a lot of it in spoiler blocks so read them if you like...or not. This is really just a way to share my thoughts and clear my mind and show what I am doing for those who follow the BatteryCheck remake adventure.
My homebrew adventure spans many platforms already and I have a few threads open about the Wii/GameCube version here which is kind of the main thread about the development and progress. I also have a 3DS version here and worked on it for the PSP too but that one is not released. Or playable even because of issues with the devkit and generating the textures in the correct PSP format. And the list of platforms does not even end here....but that is a discussion I have already talked about a lot on my blogs
My recent rediscovery of the GBA and expanding my library of physical games sparked my interest in porting BatteryCheck to the GBA. While I really think it will be possible in theory it requires a flashcard with writable RAM inside that I can use. My first target for memory will be the SuperCard MiniSD because it's dirt cheap and I have two or three of them ( and even bought a few more to play with ) I know they are crappy flashcarts and the EZ Flash omega is considered the best cheap alternative to an Everdrive this is what I have for now. I did receive the Omega a few days ago though so I might change my mind on which cart to use first
To explain why I moved to the DS and not continue on the GBA is because of missing and outdated libraries and examples. And no doubt my inexperience on the platform. I have bashed on libgba and libfat a few weeks ago but I have to admit things are not as bad as I thought actually. It's just not as complete as I am used to and libnds has soooo much more convenient helper functions and abstractions that makes everything a lot easier. The good thing though is that the DS has evolved from the GBA and therefore the GPU in both of them is very similar except for the 3D support ofcourse that the DS has. This similarity will help me later porting stuff back to the GBA when the DS version is running well enough.
What helps the most though is that everything just seems to work on the DS. My rant about libfat and DLDI on the GBA is litteraly "plug-and-play" on the DS. The 4MB onboard memory makes converting the graphics on the DS much easier and with DLDI I can read them from any card a user throws at it (as long as there is a driver for it ofcourse). And after a few hours the installer actually worked perfectly and extracted all files from the Setup.exe like it should. Only thing that is not yet working is extracting setup.exe from the downloaded zipfile which would be more user friendly, it needs 12MB of RAM to load it in though....and the DS only has 4MB so that's not gonna fit in there is it. I have tried multiple things to work around it but it means rewriting (or cleaning up) my installer code a bit so it reads the setup in a smarter way I like to call multi-layer-streaming, hahahaha.
So how does one use multi-layer-streaming to extract the gamefiles??? Well I would need to explain a bit how my installer is working right now or it will not make sense at all I think. So what happens is the installer searched for the ZIP or EXE in the root of the storage device. If it finds the ZIP it assumes it's the original 12MB file downloaded from the instruction...without much checking if it is. With this original file I know EXACTLY where setup.exe is stored and how big the compressed size is. I am not using a ZIP file library at all to extract it but just blindly load it into memory which requires about 12MB to store the entire file. This has not been a problem on my PC, Wii, GameCube, 3DS or PSP which have enough RAM to store that file and unpack the gamefiles after that. (not sure though I have even tested this on the PSP....but it has 32MB RAM so it should fit ).
To lower the required memory there are actually two options:
- Extract setup.exe from the zip file and write it to the SD card (wasting 12MB of space and more junk on the card)
- Load the setup.exe with a "streaming wrapper" that uses a sliding window into the file
The first option is easy but would be my last resort for multiple reasons. Not only is writing to the SD slow there is also a risk of corruption and it means more wear of the card that I think can be avoided with my second option. By implementing a sliding window that moves over the 12MB file containing decompressed data just before it's requested by the installer for a game file I hope to reduce the requirement to 64-128kb of RAM to extract the files!! That is a considerable reduction from 12MB that would be required for reading the entire file into memory all at once right!
I have no idea if this method is going to be slow or if it's useful on the other platforms that have the 12MB to spare for just reading it all into RAM. This means this trick will only be usefull on the DS, GBA and anything else that has lower specs and not enough RAM.
While the above is a bit of a summary of how and why I am now working on the DS version of my homebrew instead of the GBA, I do have some progress to show in the form of a picture...which I really want to share but have doubts about since it's a bit complicated with the rights of using these graphics. Since it's an unaltered version of the original menu graphics that is just reduced in size to fit on the DS screen....and this is about the BatteryCheck game and I am not using it for commercial purposes.....hopefully this is considered "fair use" . Here it is:
This simple screen shows on real hardware that I can load the graphics and convert it directly on the DS and then use hardware scaling to make it fit on the small screen. It looks a little better in person because the screens are a bit bright for my camera (note 9) but for this purpose I think it's good enough. It may look so simple to "convert graphics and include in homebrew" from PNG, JPG and such right? Well, sure to get started that's quite simple with the provided tools....but I am not using any of those! This image is loaded directly from the original game files (Data.j2d in this case) and decompressed using zlib. The palette had to be converted from RGBA (8bit per channel) into BGR(5bit per channel) and the pixel data had to be copied to the correct VRAM addresses and background setup. To make it clear: I am not complaining or bragging (much)....just proud that it actually works now!
Getting this working on the GBA later is going to be a HUGE challenge as it requires nearly 1MB of RAM to do all the conversions. I need to load this actual image which is already 300kb on it's own. Then I need another image that shares the palette with it for some reason so another 300kb. Then I need to cutout a section of the 640x480 image to fit into the 512x512 background buffer requiring another 256kb. Converting the palette takes less than 1kb, but adding it all together requires a LOT of RAM just for this one image! Scaling it down is done by the GPU so that does not require extra RAM fortunately.
The idea is to optimize this in more ways that I can think of right now. But I want to resize them during loading and keep the resized versions in RAM whenever possible. Or maybe resize it in smaller groups of pixels using tiles...but the image is stored as a large bitmap right now. Anyway, the DS has the memory to do this so it's not yet a big problem. I was thinking of showing this screen when the installer has unpacked data.j2d and then continue or something....just to add some more fun into it.The DLDI system that works great on the DS and a lot of drivers are available for many devices...they are very much outdated and not updated anymore. While the SuperCard SD has a DLDI driver I can't seem to make it work. Not on the DS and not on the GBA! Since this is my biggest requirement for getting BatteryCheck running on the GBA I really need to get it working. I hope with some testing to at least make sure the driver is OK or that maybe the SuperCard Mini SD actually needs another driver or some tweaks. Or maybe it's just the SD card interface that does not work but I might be able to hijack the RAM inside after my homebrew has loaded. It's just a matter of writing some bytes to some address to unlock it.
If I really want to test things out I can always try out GBFS and see how that works. Then I can at least open the files on the GBA and see what's possible with the unlocked RAM. While I can not release a GBA version with the GBFS files included I could wrap it up into a generator that runs on the DS. (crazy idea ofcourse, but possible) Then it would unpack just like it does for the DS version and generate an optimized GBA version that gets attached to a GBA rom file. For a user that would just mean: Drop batterycheck.zip on the SD card and run "bc_setup-for-gba.nds" and wait a while for it to finish.Then you will have a ready to run ROM that works on the GBA
Thank you for your time.plasturion likes this.
You need to be logged in to comment