Looking for people who are interested in reverse engineering firmware!

[Abbin21]

Hello!
I am interested in reverse engineering the Super Card SD firmware, and possibly recreating the entire firmware. I have decompiled the firmware with Ghidra but unfortunately, it is too much work to do alone. Therefore, I am looking for people who also are interested in reversing the firmware, and are able to help out! If you feel like you're up for the task, just let me know"

 

[FAST6191]

Why would you put such efforts, and they would be absolutely huge for homebrew/flash cart circles, into doing this for an awful GBA flash cart?

 

[cearp]

EZ-FLASH is opensource, if you were not aware:
https://github.com/ez-flash

Good luck with what you want to do though

 

[Abbin21]

Why would you put such efforts, and they would be absolutely huge for homebrew/flash cart circles, into doing this for an awful GBA flash cart?

After all, it is the cheapest flashcard you can get, and the firmware is awful. I've seen several posts in various forums where people ask about modded firmware or source files. So, the is an interest in the subject, why not provide what people (and myself) want when you have the knowledge and interest to do it? That's my motive.

 

[FAST6191]

I have seen fire cards cheaper, possibly a 3 in 1 at one point.

It is also cheap for a reason -- the onboard chips are too slow to properly run GBA games so the compatibility suffers massively (everything else is "if it fits it runs")

It is not a good card but for them cheaping out on the firmware. It is actually an awful card but for the Supercard team putting an absolutely massive effort into the firmware to get it to a mediocre at very best card and beaten by anything else out there.

If you have enough skills to reverse engineer the firmware, and maybe do some speed patches as well, you have mroe than enough skills to improve the homebrew designs (haven't checked what compatible NOR chips go for but not a lot, if it is going to be a RAM-NAND combo then probably even less).

 

[Yogurtcreeper]

Hello!
I am interested in reverse engineering the Super Card SD firmware, and possibly recreating the entire firmware. I have decompiled the firmware with Ghidra but unfortunately, it is too much work to do alone. Therefore, I am looking for people who also are interested in reversing the firmware, and are able to help out! If you feel like you're up for the task, just let me know"

I don't really know much about this, so can i ask what will this accomplish will it make it a better experience? and fix the issues it has.

 

[FAST6191]

I don't really know much about this, so can i ask what will this accomplish will it make it a better experience? and fix the issues it has.

Short version. No.

Longer version. Maybe but it will be a lot of effort and you could have yourself a fleet of EZ Omegas/Everdrives and matching tarted up GBAs with the fancy screens/batteries/amps/whatever else the kids are doing these days if you put the same amount of effort into a paper round, never mind the sorts of skills needed for this being used in industry (it is not quite the sort of thing you might confuse an offer for a phone number but not so very far off).
The supercard GBA cards are awful because they used slow memory that was not enough for the comparatively fast speeds the GBA expected and also the save thing but that is neither here nor there really. You can go through the GBA code and find those things where there was not enough speed (it was common but not all the time in every instruction) and recode things to handle the slowdowns or even negate the slowdowns -- safe coding to avoid cache misses and race conditions is nothing too terribly drastic as a concept. By the GBA then games were frequently moving away from the linear older games and everything was having minigames, extra mechanics, animated mid sections and more besides so you then also possibly get to play entire games as a full on play tester/bug finder (possibly also building an emulator to replicate the slowdowns but that is easy enough if you are even vaguely capable of a project like this -- find cycle accurate emulator/debugger and manually add relevant delay for cart reads, possibly even dual emulation to see what would have happened had it not crashed*). Repeat for possibly several thousand games (though regions that probably play near enough identically to the point where you know where to look and games nobody cares about/priority targets and you being there to fix issues as they arise drop that number a bit). The supercard team did actually do some of this for the low hanging fruit and at least some of the games people would want to play and had financial incentives to carry on doing it. Nobody is going to do it for the love of it or a bit of beer money in current space year when there are far better options for next to nothing really (GBA flash carts back when were often north of $100 and nothing people would want to use being all that much less) or even the option to build your own flash cart ( http://www.brolinembedded.se/projects/flashcart/ https://web.archive.org/web/20150810222526/http://reinerziegler.de/GBA/gba.htm#homebrew flash cart and making that some kind of multiboot nice thing would be way easier than this project).

*technically detecting a crash is not a trivial task (literally one of the fundamental discussions of computing along with/as part of halting problem) but easy enough in this case to be 99.999999...% sure.

 

[DanTheManMS]

I believe there was once an effort to "hack" the slot-2 Supercard firmware, but the most it did was allow custom colors on the menu or something equally cosmetic and not functional. It couldn't fix any of the inherent hardware problems with the Supercard, namely the slow RAM as described in detail by FAST6191.

It was an older version of the firmware, I wanna say 1.63, and then the people who DID try using it had trouble once the Supercard team released official updates beyond that version.

Apparently the SCDev forums aren't as dead as I thought. Here's the only thread I could find on that subject:

http://www.scdev.org/forum/index.php/topic,15413.0.html

 

[Sakitoshi]

why so much negativity?
i have several flashcarts (2 ezflash iv, 1 omega de and a supercard micro sd) and from all of them the supercard is the only capable of playing music and video almost directly, no need to create a rom with meteo or other software only to have a couple of minutes of video or audio.
and there is one area that can be improved, it only reads regular sd cards, no hc or xc, meaning you are limited to 2gb and those are harder to find as time passes.

 

[DanTheManMS]

It's not so much "negativity" -- it's more just knowing the limits of what can and cannot be done. I can say with 99% certainty you'll never be able to hack a slot-2 Supercard firmware into accepting anything higher than a 2GB card.

 

[Sakitoshi]

maybe, but by reverse engineering its firmware it may be possible to port its media capabilities/direct sdcard access (which is what i assume the supercard does, just let the media player rom access the whole sdcard instead of just rom space) to other carts.

 

[metroid maniac]

maybe, but by reverse engineering its firmware it may be possible to port its media capabilities/direct sdcard access (which is what i assume the supercard does, just let the media player rom access the whole sdcard instead of just rom space) to other carts.

You can already use DLDI for that. It's not very well supported for GBA homebrew because it arrived late and apparently is rather heavy on RAM usage. But nearly all NDS homebrew uses it.

 

[Sakitoshi]

but no gba homebrew that i know uses it.
nds is its own beast and not what i'm talking at all.

 

[FAST6191]

I think I would sooner figure out either bankswitching or SD access for other carts (some of which might not be possible -- the EZFlash team shot down the option for the Omega in a thread a while back I believe, GBA DLDI is kind of a thing but rare as it is mostly a proof of concept and I think a similar proof of concept for pocketnes), that or sort soft reset and make some kind of manual soft builder for meteo and http://www.gameboy-advance.net/emulated/musicplayer_advance_gba_mp3.htm or tepple's old GSM audio thing (or I guess some of the sequencers/trackers but 32 megs is reasonable for those) similar to the emulators seeing flash carts building virtual ROMs and setups for them https://pineight.com/gba/gsm/ .
Granted all of this is lipstick on a pig compared to something like moonshell on the DS but I can certainly see the appeal of a nice SP playing some audiobooks or something.

 

[DanTheManMS]

maybe, but by reverse engineering its firmware it may be possible to port its media capabilities/direct sdcard access (which is what i assume the supercard does, just let the media player rom access the whole sdcard instead of just rom space) to other carts.

If this helps at all: the media capabilities were stolen directly from the GBA Movie Player; you use the GBAMP converter programs to create the files that I think were in *.gbs and *.gbm format (it's been a while, memory is vague). The "filmplay.gba" file somehow manages to access the sound and movie files on the SD card, correct. I always kinda wondered how the Supercard team managed to do that long before DLDI was a thing.

All that said though, I found it a better experience to use Tepples's GSM Player for music and METEO for videos. A little bit more work on the front-end to compile the GBA files first, compared to direct SD card access, but in my mind it was worth the trade-off.

Same with the built-in emulators. Sure I *could* launch the GBC file directly, but the version of Goomba Color built-in to the firmware was "Alpha 6" and had a lot of background graphics issues. Much better to use the latest version of Goomba Color to create my own compilation and play the games that way, rather than using the Supercard's function.

I get the desire to want to fix these issues, I truly do. I just don't think it's realistic to expect anything.

 

[aoikurayami]

And here I hoped I'd never have to return to this weird forum.
Guess Fast can't do it all by emself...


For the RE:
Why so SC specific ?
It is arguably one of the worst carts on the market.
Slow read speeds, error prone.

You even got a "free" slowdown effect (not a bug, but a feature)

but no gba homebrew that i know uses it.
nds is its own beast and not what i'm talking at all.

There are some. DLDI Homebrew for the GBA:

•chishm's "cart_save"
Def. my fav GBA homebrew.
Saved me and my friends saves and came in handy more than once

•http://pineight.com/gba/#cf_bench

•Some NES Emu (?)

uwould sooner figure out either bankswitching

That's interesting.
I once had a discussion with s.o. on gbadev (or was it mail?) about increasing size of roms via bankswitching on the gbamp.
But there is barely any need for it...

Unless someone can tell me something different
----------

BTW @FAST6191

I don't know if you still do, but every so often your links are just broken (here an oldie)
strm-to-wav-wav-to-strm.109761/post-3152808

Even github pages would make a better place to put them on..
As for Filetrip, we saw what became of that...

 

[FAST6191]

That's interesting.
I once had a discussion with s.o. on gbadev (or was it mail?) about increasing size of roms via bankswitching on the gbamp.
But there is barely any need for it...

Unless someone can tell me something different

There is always scope to have fun with such things. Golden Sun Voice acting experiment is much as it sounds and as the GBA is not really suited to decoding voice quality audio from super compressed formats you have to go the other way which means space, and voicework does take up space. https://gbatemp.net/threads/golden-sun-voice-acting-rom-hack-experiment.141064/
Could also do similar for general games to have full audio tracks in them.
Mother 3 was a fairly impressive effort in data management from what I have seen/saw when it was being done, though that might be a unique case as very little is 256Mbit and even less actually needs all the space/does not have a massive blank space at the end.

In the end there officially was bankswitching or something akin to it for commercial games (or more accurately videos)
https://mgba.io/2015/10/20/dumping-the-undumped/

All that said yeah most people are not going to come close to running out of space on a GBA game -- any ROM bar those bankswitching things above can be trivially expanded to 32 megabytes with no issues beyond those with flash carts that do better with 16 megs or less ROMs (and frankly most 16 meg/128Mbit ROMs, which is most games https://gbatemp.net/threads/buying-a-gba-flash-cart-in-2013.341203/page-18#post-4756995 having the list of 256Mbit titles, have a load of extra space at the end that will do for the vast majority of hacking purposes).

 

[aoikurayami]

You just reminded me of the voice acting in the GBA "Max Payne" port haha.
Skrunkly but cute.


That person that decoded that video gba stuff was probably part of the "just because" support grop of anonymous -bored with their day to day job- coders

At least ppl like Sweeny (@tangobattle) make cool stuff
(Don't remind me how Capcom will deliver us a "no multiplayer" mmbn collection, those lazy fools... ASM sure, then just build a wrapper or a seperate mode... disgusting)


PS:
I believe the EZ Omega has a way to load files up to 64 meg irrc !?
So yeah... When in doubt..

 

[FAST6191]

The Omega DE can load the games the mgba link discusses
https://gbatemp.net/threads/ezflash...on-gba-flash-cart-in-house-at-gbatemp.581991/
Don't think the original Omega can though, nor do I think the everdrives gained it.

Max Payne was actually a solid version of that game. Pretty hard, especially the early missions but get used it to or have a liberal application of savestates and it is a really nice example of a GBA port done right.

The 16 meg thing is mostly noted for the EZ3 in 1, EZ3 and most of the EZ4 line (if you are lucky enough to have a lite deluxe which has the PSRAM of the 256Mbit persuasion, or unlucky enough to have a lite compact which is more limited, then different story), and I guess those handful of old NOR era carts that topped out at 128Mbit. Anyway the former ones can run 256Mbit titles but you have to write it to the NOR first (quite slow to write so you tend to want to leave things there, first in last out, though fast to load as well compared to RAM which is nice) so if possible then people avoid going beyond 16 or indeed slamming their extra code* to the end of the ROM.

*several trainers, some older revisions of reset patches, sleep patches and more decided to use that space rather than searching for the first reasonable selection** of 00/FF at the end of the ROM and using that.

**there were some games that legitimately needed some trailing 00s as those trimming ROMs found out, if memory serves it was a teenage mutant ninja turtles game that is the main thing people note in this.

 

[aoikurayami]

Max Payne was actually a solid version of that game. Pretty hard, especially the early missions but get used it to or have a liberal application of savestates and it is a really nice example of a GBA port done right.

I agree. Unpopular opinion, but. I prefer this to the PC version


BTW:
Do you have an opinion on:
"MMBN Legacy collection" no multiplayer ?

@Prof9 posted some stuff on twitter. Some ASM talk...

But I still hate that modern games have *less* features than their gba predecessors