Hacking EZ-FLASH OMEGA kernel source code released

[EZ-Flash2]

repo

Since the early days of OMEGA development, we have set a goal for open source in the future. The entire project uses DevKit Pro development instead of the previously used "Big N SDK".

We sincerely hope that the developers of the community will use their inspiration to create a more convenient and humane OS.

 

[Cartoni]

Awesome, great move! Hopefully could the community increase the performance of the Omega

 

[ChaosEternal]

You guys are the best. I've never seen a flash card developer so dedicated to working with the community, even going so far as to release the source code. I look forward to your future endeavors!

 

[Razor83]

Fantastic, thanks for releasing this @EZ-Flash2

Is there any chance you might also consider releasing the source code for the EZ-Flash IV?

 

[x65943]

So glad you guys made good on this promise! I hope this leads to further development and improvements.

Open source is the future!

(Also, I kind of chuckled when you said you wanted a more "humane" OS - makes the current OS sound malevolent)

 

[EZ-Flash2]

So glad you guys made good on this promise! I hope this leads to further development and improvements.

Open source is the future!

(Also, I kind of chuckled when you said you wanted a more "humane" OS - makes the current OS sound malevolent)

hmm google translate sucks

 

[SirNapkin1334]

If I ever get a GBA, is this flashcart the best choice?

 

[FAST6191]

Put it up on the front page earlier. Always nice to see more open source

Anyway ideas for things the community could make

If the saves are emulated then maybe an autoboot of sorts for the DS and gamecube games. A way it might work is in a GBA then set a flag in the file for next boot to autoload a game. As no GC or DS game will expect it there immediately after it boots and you don't hot insert things then you can probably have it power up, in the likely more than 30 seconds it takes for the GC or DS to boot then the .

If someone wants to make a super robust reference grade cheat engine that would be nice ( http://doc.kodewerx.org/hacking_gba.html , and maybe even look at some of the things the DS carts got).

For savestates while I reckon they are probably about as good as the standard approach will take you then if you want to allow some game specific stuff for the write only areas, or some code to inject that can create some viable data in the write only areas then that might be nice. Similarly if you want to match their exact format to one or more popular GBA emulators some might like that, and it should mostly just be a matter of changing some offsets or padding they use (no GBA emulators should compress their savestates.

A DS loader of sorts (would be nice to dump DS games and saves with it, possibly even the large ones it is hard to squeeze into the 2 gigs available for GBA carts), such a thing would likely need a new DLDI patch as well.

Possibly a ROM hack patch loader. IPS (the format favoured for most GBA hacks, and most could be converted to it) is braindead simple as a format (it is basically a long list of location and size of following section, I think some have a RLE implementation and some other variations have other things. None of them should have any kind of relocation, not to mention for the GBA it is usually pointless to relocate things) and should be just fine to add to the load into PSRAM routine. I don't know how easy offhand it would be to implement UPS (one aimed at being a successor to it

Media player in loader perhaps -- technically there are DLDI libraries for the GBA (and possibly even some ARM7 focused DLDI patches from that old DS video wavelet compression thing if you can still find them) but if it is already in the loader then that can hopefully skip that.

Homebrew fingerprinting. While we can probably add serials to homebrew that might lack it there are other tells you might use and making people jump through a few more hoops. The various emulators would probably be a good start.

Speaking of homebrew emulators I don't know if a few others could be wedged into it, or virtual ROM creators could be made for it all. There are quite a few very nice and very playable emulators for the GBA that are not in the current loader. I don't know if we can get the PCE CD stuff working (it was made to work for the EZ3) but it might be nice if so.

 

[Dimensional]

I wonder how long until someone manages to release a firmware update that allows for roms installed to the NOR be read by DS games, like Pokemon DPP, Castlevania Aria of Sorrows, or even some of the Megaman DS games, with the ability to read the saves, possibly even natively without patching the DS games. Obviously this patch would present a problem with multiple games written to NOR, as the DS games couldn't read them all. Maybe holding down a button on the DS would tell EZ which rom header to show.

 

[FAST6191]

Most games on that list ( http://nintendo.wikia.com/wiki/List_of_Nintendo_DS_games_with_GBA_connectivity for the others playing along at home) can be unlocked with cheats in the DS game. The save stuff for things like pokemon, and I guess a megaman game, is where cheats tend to fall short, and if it is one of those games with multiple choices for GBA slot games then it can get a bit more complicated.

If you want to make such cheats then anything that reads in the 08000000h range of memory on the DS will probably be where you want to start (it is where the GBA cart can be found in DS memory, most games will probably* just read the serial or something to confirm it is there and carry on)

*many years ago I did a test with my old EZ2 and just wrote the header of a game, still worked for I think it was advance wars. Though actually for things other than pokemon that might be an alternative route if you can just mess with the GBA header of the loader or whatever.

 

[kuwanger]

Out of curiosity, has anyone gotten this to build yet? When I tried on Linux with devkitarm r48, I get:

make[2]: .../omega-kernel/build/Makefile: No such file or directory
make[2]: *** No rule to make target `.../omega-kernel/build/Makefile'.  Stop.
make[1]: *** [build] Error 2
make: *** [build] Error 2

If I copy the Makefile to build I get:

linking cartridge
.../devkitPro/devkitARMr48/bin/../lib/gcc/arm-none-eabi/8.1.0/../../../../arm-none-eabi/lib/thumb/gba_crt0.o: In function `CIDExit':
(.crt0+0x20c): undefined reference to `main'
collect2: error: ld returned 1 exit status
make[2]: *** [.../omega-kernel/build/build.elf] Error 1
make[1]: *** [build] Error 2
make: *** [build] Error 2

Just looking at the source has been pretty interesting, though. There's multiple binary blobs (HZK12.h for Chinese fonts, Newest_FW_ver.h for the firmware, pocketnes.h and goomba.h for each respectively, and asc126.h for English fonts). ff13b is of course the fat library and images has bin2c of the various UI images. It doesn't look like it'd be too difficult to introduce Pogoshell support, presuming I could get it to compile.

 

[Coto]

Great iniciative, you ez-flash devs are pouring your heart on your products. I have seen the wave of posts where people have firmware issues, and you are there coding non-stop. Also supporting OpenSource.

Kudos to you all

 

[Xilefian]

Builds fine for me and I'm able to update with my modified kernel perfectly fine. Very well done for this release, thank you for your efforts.

I've been attempting to get file-system access from within games using information in the kernel source, however I'm having great difficulty switching into OS mode from inside a game - is anyone able to get this working?

The lack of file-system access (libfat or otherwise) has been quite painful for some time now, I'm hoping we can finally add it in now that the kernel is open-source.

 

[kuwanger]

With a bit of finagling, I was able to get the omega kernel to compile on my Windows 10 system. Looking through make -d on both systems, and I presume it's because I'm using such an old version of make. :/ So, guess I have to update this system first.

I've been attempting to get file-system access from within games using information in the kernel source, however I'm having great difficulty switching into OS mode from inside a game - is anyone able to get this working?

I'm not sure. Reading the document included "
PSRAM:SetRompage(0x200)
...
Change Mode
We can toggle between OS mode and Game mode by set the bit 15 of Rompage to 1 or 0.
Set rompage = 0x8000, system goes to OS mode. Set rompage(0), system goes to Game
mode.
PSRAM only have one map address in Game mode, address 0 maps to 0x08000000, Read
only.
"

So, my vague understanding is maybe 0x8200 and 0x0200 to toggle between the two? Ez-flash2 would undoubtedly know more.

 

[EZ-Flash2]

If you want to access PSRAM under OS MODE, you have to access from the window address. use SetPSRAMpage to set the window

 

[slaphappygamer]

If I ever get a GBA, is this flashcart the best choice?

If I didn't already have a little collection of flashcarts, I'd get this one. The price is right and the functionality seems nice. The fact that the team is going out on a limb to release the source this early in the carts life will open many doors. The GBA is great. Do you know what model you would want?
Also, nice new avvy you got there.

 

[SirNapkin1334]

If I didn't already have a little collection of flashcarts, I'd get this one. The price is right and the functionality seems nice. The fact that the team is going out on a limb to release the source this early in the carts life will open many doors. The GBA is great. Do you know what model you would want?
Also, nice new avvy you got there.

Unsure...what I know is that AGB-101’s are more desirable for some reason. It just seems like a nice console.

 

[FAST6191]

Unsure...what I know is that AGB-101’s are more desirable for some reason. It just seems like a nice console.

Short version.
Original GBA did not come with a lit screen, this despite them being common in other devices at the time, everybody and their dog making light attachments for previous models and Nintendo even themselves technically making a lit screen gameboy model ( http://nintendo.wikia.com/wiki/Game_Boy_Light , naturally limited numbers and exclusive to Japan). At the time there was a mod to have a lit screen (see GBA afterburner) which many enjoyed, today there are also options for it which do better still (we had the whole bright white LED revolution since then).

GBA SP hits. It has a frontlit screen by default. Far better but others had seen the wonder that was backlit screens in other devices and still wondered.
GB Micro somewhere in the middle of this.
GBA SP AGS 101 model is released in limited amounts (even more so in Europe), DS is already a thing by now I think and actually kicking off (surprising to many it was touch and go for a while there) so limited amounts of them are out there. Anyway the 101 has a lovely backlit screen and thus was probably the best official way at the time, and probably still the best official way to play GBA games in handheld form (only the DS lite stands much of a chance of beating it, obviously a gamecube with component cables and a GB player with https://www.gc-forever.com/forums/viewtopic.php?t=2782 is the best you are going to get in official form).

Similarly I have never been impressed by a GBA clone device. Some people took to retrofitting either original GBAs or original GBA SP lines with 101 screens and other screens but that is a discussion for another day.

 

[Xilefian]

If you want to access PSRAM under OS MODE, you have to access from the window address. use SetPSRAMpage to set the window

I do not fully understand. I don't know if I need to access PSRAM (do I?).

FATFS FileSystem;
memset( &FileSystem, 0, sizeof( FileSystem ) );

// What to do here?
SetRompage( 0x8000 ); // I wish to access OS mode for f_mount
// System stopped after this

SD_Disable();
FRESULT res = f_mount( &FileSystem, "", 1 );

// What to do here?
SetRompage( 0x0 ); // I wish to go back to game mode after f_mount

if ( res != FR_OK ) {
  printf( "Error %d\n", res );
} else {
  printf( "Success\n" );
}

I am unable to see this information in the PDF (I might be an idiot).

Thank you very much for any help and assistance you can provide - I am very happy with EZ Flash Omega, just wish I could access file system from my home-built games.

 

[kuwanger]

I'm curious what you're trying to do with your example code? Are you planning to wrap all file systems access to wrappers like the above to switch to/from OS mode? I presume your code is running in IWRAM/EXRAM?

Having said all that, yea, still need Ez-Flash2 to answer. My last attempting with such fiddlings bricked my EZ-Flash IV, so I'm not inclined to "toy around" with such code.

 

[Xilefian]

I'm curious what you're trying to do with your example code? Are you planning to wrap all file systems access to wrappers like the above to switch to/from OS mode? I presume your code is running in IWRAM/EXRAM?

Having said all that, yea, still need Ez-Flash2 to answer. My last attempting with such fiddlings bricked my EZ-Flash IV, so I'm not inclined to "toy around" with such code.

My plan is to at least get something working before planning the best course of action.

I'm not afraid to brick the Omega as it has the recovery mode - I did indeed screw up the device yesterday messing around with this stuff (so it certainly is dangerous), but recovery mode saved my bacon.

Because of how dangerous these calls are, it could be that it's best to play it safe and wrap them in minimal OS mode switches - haven't settled on this. My plan is to make an open-source library that people can use with their GBA game development to access the Omega's file-system. After a formal library is created, then I am thinking about adding the support for the Omega's file-system in a popular open-source GBA emulator, which would absolutely help out GBA ROM developers.

EDIT: To answer your actual question (sorry I was rambling there) this code is just to initialise the file system and print out if it worked out not. 100% of the code is running in IWRAM, just to make sure it's not an issue with ROM execution, but if it does switch from ROM execution it absolutely needs to return to it.