SuperFW: a (very much WIP) supercard firmware

[Xyvir]

I was thinking on adding RTC patches for Pokemon games. There's not many other games that use RTC anyway, and pokemon are the most played ones. They are rather easy since they are fully decompiled and their symbols well known.
I thought about adding some in-game-menu option to adjust the clock, so that you can change the time while playing, by entering the said menu.

Hey we also got that MMBN 4.5 real operation I wouldn't mind having an RTC patch for

https://www.therockmanexezone.com/wiki/Rockman_EXE_4.5_Real_Operation

 

[KuaJmC]

Hi, long time lurker but I dusted off dust from my old DS lite, screen modded my wife’s old GBA and bought a new Supercard to relive The past. Some experiences:

GBA (agb-001)/General issues:
- Hit and miss when loading a 16MB ROMs. It may crash during writing flash. Unsure of why. Tried changing batteries, using 1900 Eneloops and 2450 IKEA LADDAs. Lowered the screen brightness. Changed SD CARDS too. Would say around 75% chance of loading 16 MBs. (SCFW was stable, but took ages)

- Saving is also hit and miss. It will save when switching off/on immediately. But leaving it off for a couple of minutes before rebooting gives me an empty save. Should I suspect a dead battery in the newly bought Supercard?

- File listing seems random. No way of sorting.

DS:
- loading is stable. No crashing on 16MB.

Looking forward for the next release

 

[davidgf]

Hey, i was finishing up my investigation on the supercard Lite, and i realized a thing by looking at how you're handling the flashing in your superfw flasher tool (so far i was modifying SCKILL instead), it turns out that the SC Lite uses different address to flash the chip, but not because they decided to mess things around, but actually because they're not using the permutated wires, in fact on the supercard lite the target magic are simply 0x08000AAA and 0x08000554, the only other thing to keep in mind for the supercard lite is that the flashable size is 0x7C000 instead of 0x80000, as the last blocks contain hardcoded values used by the fpga very likely, and also that to enter flash write mode, the mode value has to be 0x1510.
Here i made the relevant commits to SCKILL to have it properly detect the type of supercard and change things accordingly https://github.com/ApacheThunder/SCKILL/pull/1/files

Thanks!
Yeah I do not plan to add any lite support just yet, since I do not own a device. Perhaps later once the DS support is there (I'm working on DS support a bit now).
For the address scrambling, I did a bit of research using scope and soldering many wires
The scramble function was easy to understand once I ran a couple of simple address swipes. You can find it here for now (this is in the repo, but won't make it public just yet): Essentially some bits are permutated in weird ways

Post automatically merged: Oct 28, 2024

Other questions asked:

Homebrew/Game hacks will most likely require patches. If they are popular enough I will try add them to my ROM pack and generate patches for them. More custom patches might need work but if the game is popular enough, perhaps. Haven't looked into RTC patches yet, I assume that pokemons might be very similar and perhaps I can automate patching.

SuperFW is quite fast at loading data from SDs, I optimized it using a logic analyzer to squeeze performance, however it seems that I am perhaps not loading the data at the right edge (the way data is loaded is weird). I need to look into this cause I also noticed that sometimes it doesn't load correctly on older devices, or when using a cart interceptor (introduces delay and capacitance in the lines). I need to rewrite some of these routines for other reasons (creating a DLDI driver with better support) so I will take my time to improve it. Unfortunately all my devices are quite OK and seem to fail very rarely. Perhaps I need to borrow an Analog Pocket for better testing.

RIght now I'm working on:
- DLDI driver (for future NDS mode).
- Implementing a Direct-Save mode, so that flash-based games (ie. poke) or eeprom-based games can directly save to SD card without having to go through reboot or using the in-game menu (specially useful for games where the in-game menu doesnt work well or makes the game slow). This will also make 128KB saves work well (again poke).

Next will work on:
- Improve SD I/O driver, make it more reliable and improve the DLDI driver compatibility.
- Implement a rough NDS mode, where we load boot.nds on NDS (to load twilightmenu or another launcher)
- Add cheat support (will use several databases and allow for custom cheats).
- Implement the patching engine (i.e patch any game that's not in the database, slow but nice to have).
- Start adding some translations. Support already exists.

Allright then, stay tuned for the next beta version!

 

[edo9300]

Thanks!
Yeah I do not plan to add any lite support just yet, since I do not own a device. Perhaps later once the DS support is there (I'm working on DS support a bit now).
For the address scrambling, I did a bit of research using scope and soldering many wires
The scramble function was easy to understand once I ran a couple of simple address swipes. You can find it here for now (this is in the repo, but won't make it public just yet): Essentially some bits are permutated in weird ways

Post automatically merged: Oct 28, 2024

Other questions asked:

Homebrew/Game hacks will most likely require patches. If they are popular enough I will try add them to my ROM pack and generate patches for them. More custom patches might need work but if the game is popular enough, perhaps. Haven't looked into RTC patches yet, I assume that pokemons might be very similar and perhaps I can automate patching.

SuperFW is quite fast at loading data from SDs, I optimized it using a logic analyzer to squeeze performance, however it seems that I am perhaps not loading the data at the right edge (the way data is loaded is weird). I need to look into this cause I also noticed that sometimes it doesn't load correctly on older devices, or when using a cart interceptor (introduces delay and capacitance in the lines). I need to rewrite some of these routines for other reasons (creating a DLDI driver with better support) so I will take my time to improve it. Unfortunately all my devices are quite OK and seem to fail very rarely. Perhaps I need to borrow an Analog Pocket for better testing.

RIght now I'm working on:
- DLDI driver (for future NDS mode).
- Implementing a Direct-Save mode, so that flash-based games (ie. poke) or eeprom-based games can directly save to SD card without having to go through reboot or using the in-game menu (specially useful for games where the in-game menu doesnt work well or makes the game slow). This will also make 128KB saves work well (again poke).

Next will work on:
- Improve SD I/O driver, make it more reliable and improve the DLDI driver compatibility.
- Implement a rough NDS mode, where we load boot.nds on NDS (to load twilightmenu or another launcher)
- Add cheat support (will use several databases and allow for custom cheats).
- Implement the patching engine (i.e patch any game that's not in the database, slow but nice to have).
- Start adding some translations. Support already exists.

Allright then, stay tuned for the next beta version!

Supporting a lite should be pretty straightforward now as well, since the flashing is easy, also i too i'm currently working on updating the sdhc driver available for it by ausar, and focusing on NDS mode. The sdhc driver from ausar is now working properly on both lite and normal supercard (the lite required adding 4 bit sdio to the write commands, and not using waitstate 2,1), with not bad performance https://github.com/edo9300/SuperCard-SDHC-DLDI, but i suppose that with your tools you might be able to squeeze some extra performance out of it as well

Post automatically merged: Oct 28, 2024

As for NDS mode, i made a "fork" of SCFW for my own needs, where i'm just bundling a pre dldi patched hbmenu https://github.com/edo9300/SCSFW, it shoudl be easy for you as well to add it to your firmware

 

[JORGETECH]

As for NDS mode, i made a "fork" of SCFW for my own needs, where i'm just bundling a pre dldi patched hbmenu https://github.com/edo9300/SCSFW, it shoudl be easy for you as well to add it to your firmware

That's really cool, I will try this new firmware when I can. The part about it being compatible with nds-bootstrap sounds exciting since that's the only advantage stock FW had (and it was a PITA to use it anyways).

EDIT: @edo9300 Can you provide instructions on how to compile Stage1? I already have devkitARM installed and I was able to compile GBA Stage2 but I'm stuck trying to compile the ARM assembly file into a flashable firmware file.

EDIT2: Nevermind, I'm a dumdum . I was able to compile it myself, then I realized there were instructions in your repo. I successfully flashed your firmware and PassMe booted straight to hbmenu!

 

[OuYeaaah]

Thanks!
Yeah I do not plan to add any lite support just yet, since I do not own a device. Perhaps later once the DS support is there (I'm working on DS support a bit now).
For the address scrambling, I did a bit of research using scope and soldering many wires
The scramble function was easy to understand once I ran a couple of simple address swipes. You can find it here for now (this is in the repo, but won't make it public just yet): Essentially some bits are permutated in weird ways

Post automatically merged: Oct 28, 2024

Other questions asked:

Homebrew/Game hacks will most likely require patches. If they are popular enough I will try add them to my ROM pack and generate patches for them. More custom patches might need work but if the game is popular enough, perhaps. Haven't looked into RTC patches yet, I assume that pokemons might be very similar and perhaps I can automate patching.

SuperFW is quite fast at loading data from SDs, I optimized it using a logic analyzer to squeeze performance, however it seems that I am perhaps not loading the data at the right edge (the way data is loaded is weird). I need to look into this cause I also noticed that sometimes it doesn't load correctly on older devices, or when using a cart interceptor (introduces delay and capacitance in the lines). I need to rewrite some of these routines for other reasons (creating a DLDI driver with better support) so I will take my time to improve it. Unfortunately all my devices are quite OK and seem to fail very rarely. Perhaps I need to borrow an Analog Pocket for better testing.

RIght now I'm working on:
- DLDI driver (for future NDS mode).
- Implementing a Direct-Save mode, so that flash-based games (ie. poke) or eeprom-based games can directly save to SD card without having to go through reboot or using the in-game menu (specially useful for games where the in-game menu doesnt work well or makes the game slow). This will also make 128KB saves work well (again poke).

Next will work on:
- Improve SD I/O driver, make it more reliable and improve the DLDI driver compatibility.
- Implement a rough NDS mode, where we load boot.nds on NDS (to load twilightmenu or another launcher)
- Add cheat support (will use several databases and allow for custom cheats).
- Implement the patching engine (i.e patch any game that's not in the database, slow but nice to have).
- Start adding some translations. Support already exists.

Allright then, stay tuned for the next beta version!

Wohooo i'm ready i'm ready

 

[Tsila]

Hi @davidgf , how about the AGB-001 game loading problem? Will it be fixed in the next release? Waiting for the next release with impatience here

 

[JORGETECH]

I've been doing some testing using edo9300's fork with NDS DLDI and overall it works great but I did encounter some weird behavior. At first I was using an R4i SDHC Gold Pro with YSMenu as the PassMe device and that works well, however, the M3 DS Real PassMe implementation seems to have problems, when I use it the HBMenu loader works but as soon as I try to load any homebrew (for example, TwilightMenu++), it gets stuck loading with a message that says "Running fat:<name of binary> with 1 parameters". After researching old wikis I found out flashcart manufacturers used to have specific PassMe implementations for their GBA flashcarts so I wonder if that has anything to do with it.

Since then I have decided to install FlashMe in one of my DS Lites since I've never done it before, I soldered the SL1 contacts together since it seemed to be the safest method and now I'm testing SCSFW with FlashMe, FlashMe works as well as the YSMenu PassMe implementation.

So far I found some homebrew that has problems in my limited testing:

• DOOM64: It succesfully launches and shows the id software logo but it crashes with a guru meditation error after trying to start a new game.
• DSCraft: Instant guru meditation error when trying to launch, it doesnt' matter wether I use HBMenu or TwilightMenu++.

Speaking of TwilightMenu++, most commercial software seems to work fine, which is really impressive taking into consideration it removes the need for the horrible Supercard patching software, so far the only game that has failed to launch for me is Asphalt Urban GT 2 (the first game works for some reason).

 

[edo9300]

I've been doing some testing using edo9300's fork with NDS DLDI and overall it works great but I did encounter some weird behavior. At first I was using an R4i SDHC Gold Pro with YSMenu as the PassMe device and that works well, however, the M3 DS Real PassMe implementation seems to have problems, when I use it the HBMenu loader works but as soon as I try to load any homebrew (for example, TwilightMenu++), it gets stuck loading with a message that says "Running fat:<name of binary> with 1 parameters". After researching old wikis I found out flashcart manufacturers used to have specific PassMe implementations for their GBA flashcarts so I wonder if that has anything to do with it.

Since then I have decided to install FlashMe in one of my DS Lites since I've never done it before, I soldered the SL1 contacts together since it seemed to be the safest method and now I'm testing SCSFW with FlashMe, FlashMe works as well as the YSMenu PassMe implementation.

So far I found some homebrew that has problems in my limited testing:

• DOOM64: It succesfully launches and shows the id software logo but it crashes with a guru meditation error after trying to start a new game.
• DSCraft: Instant guru meditation error when trying to launch, it doesnt' matter wether I use HBMenu or TwilightMenu++.

Speaking of TwilightMenu++, most commercial software seems to work fine, which is really impressive taking into consideration it removes the need for the horrible Supercard patching software, so far the only game that has failed to launch for me is Asphalt Urban GT 2 (the first game works for some reason).

Hey, thanks for testing, for the passme stuff, maybe now I know why the scfw code is manually trying to change the mode before doing anything else (thing that I just didn't bother updating as it worked on my end), I'd also say it's good to have other homebrews not working, so far I've been having issues with some specific games through nds bootstrap, and that made debugging basically impossible.
Also, wherever you read that soldering the SL1 contacts is the safest way, was totally wrong you shouldn't have them soldered.
Anyways, I'd say better not post these "results" here, as it really is outside the scope of this thread, maybe I'll make my own soon (atm I'm working on the supercard lite, that happened to be a monster, managing to do 7mb/s reads, so that would require its own post for sure).
If you want you can find me on the ds(I) mode hacking discord, so we could try things out if needed

 

[JORGETECH]

Also, wherever you read that soldering the SL1 contacts is the safest way, was totally wrong you shouldn't have them soldered.

Oh, why is that? Are you talking about the risk of bricking in the future for having SL1 connected? I did remove the bridge after installation using some solder-wick so that should be fine now, if there's another reason I would like to know. I did that method because I didn't trust having a steady hand in the installation procedure. It hasn't caused any issue so far.

Anyways, I'd say better not post these "results" here, as it really is outside the scope of this thread, maybe I'll make my own soon (atm I'm working on the supercard lite, that happened to be a monster, managing to do 7mb/s reads, so that would require its own post for sure).
If you want you can find me on the ds(I) mode hacking discord, so we could try things out if needed

I completely agree, in the future I'll report in Discord or the hypothetical dedicated post if it's created.

 

[Xyvir]

I've been doing some testing using edo9300's fork with NDS DLDI and overall it works great but I did encounter some weird behavior. At first I was using an R4i SDHC Gold Pro with YSMenu as the PassMe device and that works well, however, the M3 DS Real PassMe implementation seems to have problems, when I use it the HBMenu loader works but as soon as I try to load any homebrew (for example, TwilightMenu++), it gets stuck loading with a message that says "Running fat:<name of binary> with 1 parameters". After researching old wikis I found out flashcart manufacturers used to have specific PassMe implementations for their GBA flashcarts so I wonder if that has anything to do with it.

Since then I have decided to install FlashMe in one of my DS Lites since I've never done it before, I soldered the SL1 contacts together since it seemed to be the safest method and now I'm testing SCSFW with FlashMe, FlashMe works as well as the YSMenu PassMe implementation.

So far I found some homebrew that has problems in my limited testing:

• DOOM64: It succesfully launches and shows the id software logo but it crashes with a guru meditation error after trying to start a new game.
• DSCraft: Instant guru meditation error when trying to launch, it doesnt' matter wether I use HBMenu or TwilightMenu++.

Speaking of TwilightMenu++, most commercial software seems to work fine, which is really impressive taking into consideration it removes the need for the horrible Supercard patching software, so far the only game that has failed to launch for me is Asphalt Urban GT 2 (the first game works for some reason).

Also on this topic I have recovered an old SuperCard NDS game patching DB from wayback and found the esttings them to be working pretty well. There were a number of games I couldn't get to launch from TWM++ that worked fine when using the supercard native patcher. (Like Monkeyball Touch and Roll for one) I don't really know much about the devlopment of any of these projects behind either way may this info could help make TWM++ Slot 2 NDS mode more compatible somehow? Or maybe games could be patched to work from TWM++ Slot 2 and not just supercardSD natively launched?

I haven't bothered mirroring the DB online yet but I have intentions to once the semester is over.

I also want to clean it up cause it's kind of hard to parse as it.

Just let me know

Let me know if anyone is interested in this.

 

[davidgf]

Hey there! Still alive
Been working on finishing the DLDI driver and improving the I/O stuff (ie. detect bad writes and retry them, allow for unaligned pointers, etc). I also went ahead and implemented an NDS mode. It just boots /BOOT.NDS. However still not working (really close to booting an NDS though). This will help testing the DLDI driver I am hopeful my implementation is good I've been testing this with my R4 clone and with lifehackerhansol/PassMeLoader as "passme" emulators.

I will get to the direct-save patches for pokemon and other 128KB flash games. With a validated DLDI driver should be a piece of cake! Haven't had the chance to implement them in the in-game menu yet.

On the TWL++ Slot2 compatiblity: it uses more or less the same approach as SCFW when it comes to GBA game patching. It is a "basic" patching mechanism, so a few games won't work. I tried to come up with a better (but much slower) mechanism, and provided a database to speed it up (pretty much instant). This can be trivially ported to TWL++ slot2 implementation to make it work as well as SuperFW. I might contribute some of this in the future

 

[edo9300]

Hey there! Still alive
Been working on finishing the DLDI driver and improving the I/O stuff (ie. detect bad writes and retry them, allow for unaligned pointers, etc). I also went ahead and implemented an NDS mode. It just boots /BOOT.NDS. However still not working (really close to booting an NDS though). This will help testing the DLDI driver I am hopeful my implementation is good I've been testing this with my R4 clone and with lifehackerhansol/PassMeLoader as "passme" emulators.

I will get to the direct-save patches for pokemon and other 128KB flash games. With a validated DLDI driver should be a piece of cake! Haven't had the chance to implement them in the in-game menu yet.

Nice work, I really hope for your driver to become the default for the supercard sd in future. Regarding the ds mode "booter", you could use https://github.com/asiekierka/nds-miniboot, and have pretty much the job done already (only needs your dldi to be working properly), so you don't have to spend time on those unrelated things

 

[lordelan]

Nice, please keep this up!

 

[JORGETECH]

Let me know if anyone is interested in this.

I think it's interesting to have this mirrored and cleaned up, it's getting harder to find old flashcart stuff.

 

[edo9300]

Nice work, I really hope for your driver to become the default for the supercard sd in future. Regarding the ds mode "booter", you could use https://github.com/asiekierka/nds-miniboot, and have pretty much the job done already (only needs your dldi to be working properly), so you don't have to spend time on those unrelated things

On the topic of this, in the end i integrated nds miniboot support in my SCSFW with automatic dldi patching and support for different in case the supercard is lite/sd https://github.com/edo9300/SCSFW

Post automatically merged: Nov 16, 2024

So should be drag and drop once this other dldi for the Supercard SD is completed

 

[edo9300]

I completely agree, in the future I'll report in Discord or the hypothetical dedicated post if it's created.

Well, the post is now there https://gbatemp.net/threads/scsfw-s...m-firmware-for-supercard-all-variants.663797/