Hacking EZ Flash Omega disc_io library project

[Xilefian]

This is intended for homebrew/ROM-hack developers.

See it on GitHub: github.com/felixjones/ezfo-disc_io

I created this project to enable SD card filesystem access for EZ Flash Omega homebrew, as this is a feature I've been craving from EZ Flash for a very long time, so I went ahead and inspected the open-source kernel implementation of the file system and saw where that matches up with DISC_INTERFACE of libfat.

The original goal was (and sort of still is) to add EZ Flash Omega to devkitpro's libgba's rather dated list of inbuilt disc interfaces, however the need to execute OS mode related code in memory has put me off completing this task. Some help is needed here.

Another issue is NOR game support isn't here. The issue is not knowing what ROM page to return to for NOR games. I've done a lot of work with detecting what page a loaded NOR game is in, but it is incredibly slow (involves hashing ROMs - yuck!) and fails for identical ROMs (which isn't really a problem, just a small bit of grossness). As a result, I've decided to remove NOR support until a better method is found.


An example source file of using this system is also in the repository. The example reads a file from the SD card (if it exists), increments the number written in the file and writes the new number into the file (or creates the file if needed).

Basic usage is:

const bool ismount = fatMountSimple( "fat", &_io_ezfo ); // _io_ezfo from io_ezfo.h
if ( ismount ) {
  const int cderr = chdir( "fat:/" ); // Change working directory to fat:/ device
  if ( cderr == 0 ) {
    // Mount success
  } else {
    // Change directory fail
  }
} else {
  // Mount fail
}

This is an open-source project, so contributions, improvements and fixes would be much appreciated. If we can get this to a state where it is suitable for devkitpro inclusion then the goal would be to get it merged into libgba and made part of the default disc interfaces.

 

[FAST6191]

What examples of such homebrew is there for the GBA?

I think there was a proof of concept version of either goomba or pocketnes made, maybe a save dumper (hotswap based or something) but that is about it.

If someone does want to make a nice version of that GSM player ( http://pineight.com/gba/gsm/ ) or http://www.gameboy-advance.net/emulated/musicplayer_advance_gba_mp3.htm (if source is even available or there is something you could fake it with) then that would be appreciated though.

 

[Xilefian]

What examples of such homebrew is there for the GBA?

I think there was a proof of concept version of either goomba or pocketnes made, maybe a save dumper (hotswap based or something) but that is about it.

If someone does want to make a nice version of that GSM player ( http://pineight.com/gba/gsm/ ) or http://www.gameboy-advance.net/emulated/musicplayer_advance_gba_mp3.htm (if source is even available or there is something you could fake it with) then that would be appreciated though.

The devkitpro GBA example "biosdumper" - which does what it says on the tin - is an example of FAT storage access. It's a very simple modification to get that working with EZ Flash Omega using the library and usage example here.

Beyond that, FAT storage on GBA has been a scarce environment for many years now. There is indeed a save dumper demo sitting out there that does not work with EZ Flash Omega; that would definitely be a handy thing to get fixed. Unfortunately I don't think hot-swapping is possible as that resets the device with the EZ Flash Omega (well, it does for me). Would have to be link cable & multiboot based (GBA A with EZFO sends multiboot app to GBA B with target game in, GBA B reads save data and sends it back over link cable to GBA A which saves to SD storage).

Music players are definitely what I had in mind for this.

 

[kuwanger]

however the need to execute OS mode related code in memory has put me off completing this task. Some help is needed here.

My gut feeling would be that the "best" approach would be to incorporate the interface into the kernel and jump to there, but I really don't know how viable that would actually be (would probably involve a lot of rewriting to avoid memory clobbering). It would reduce a lot of redundancy and make the library code a lot simpler though. :/

Anyways, just a thought if you want to try a different approach.

 

[Xilefian]

My gut feeling would be that the "best" approach would be to incorporate the interface into the kernel and jump to there, but I really don't know how viable that would actually be (would probably involve a lot of rewriting to avoid memory clobbering). It would reduce a lot of redundancy and make the library code a lot simpler though. :/

Anyways, just a thought if you want to try a different approach.

I considered this, but I'd like this to be usable on the official kernel and not require a branch. I'm sure it's possible and doing it this way would avoid touching EWRAM/IWRAM entirely as it would just be ROM page switching. Similarly, a solution to the NOR page problem could be done with a kernel modification exposing this as a ROM function (maybe write the page of the loaded ROM into the last chunk of NOR and the function could read that).

 

[kuwanger]

I considered this, but I'd like this to be usable on the official kernel and not require a branch.

Well, I'm not sure if it's going to happen on not, but given they've open source the code, perhaps in the future they'll start incorporating community changes to make it part of the official kernel. But, yea, I entirely understand wanting to make it work regardless. That's the main reason I put "best" in quotes since it really comes down to what your intentions are.

For example, my fork of the kernel was done mostly as a proof-of-concept. In most instances you're better off using plugin2gba or similar so you have a compilation and otherwise have something that "just works". But, if the EZ Flash team were to incorporate my changes (or something like it) into the official kernel, that'd be great. Otherwise, I'm actually sort of tempted to refactor out a lot of the kernel. That's a lot of work though, which means a lot of commitment I'm not sure I have.

 

[Xilefian]

I'm actually sort of tempted to refactor out a lot of the kernel. That's a lot of work though, which means a lot of commitment I'm not sure I have.

I was looking at this idea myself briefly. The current source code is very handy (don't get me wrong), but it certainly reads like it was cobbled together progressively over time. A neat re-factor and all around clean-up (probably straight re-implementation) would be a nice project if one had the time to do so.

Using NOR space for storing boot information would be incredibly handy. Could store FAT path of executable (if on PSRAM), ROM page, launch parameters (if applicable), and executable code for FAT read/write (so it doesn't have to live in game ROM or system memories).

One of those projects that sits alongside my weird desire to re-factor libgba to be more consistent and remove the old API cruft.

EDIT: Dreams of a kernel that would allow sending multiboot ROMs over link cable or wireless adapter...Take full advantage of everything GBA.

 

[Sterophonick]

Hey!

When I compile your demo, the machine always throws a "[FAIL] Failed to mount or init a FAT device." Is there anything I could be doing wrong?