Hacking Developing a custom ROM for EZ-Flash

[MyFairJulie]

Hello users, especially hello to EZ-Flash2,

as you all are probably aware, the source code of the EZ-Flash Omega ROM is available on GitHub. The Omega is probably the most easily hackable flashcart available to market.

This sounds really great on paper, but in practice not much has happened with the EZ-Flash. Only a few translated versions where the chinese translation has been replaced with e.g. spanish, one reskinned ROM and there's a pull request with a very small addition (Press L while booting to load the first game on NOR memory).

I see two reasons for that:

1. Lack of documentation
We may be able to figure out over time what the code does anyway, but i think it is helpful if you (EZ-Flash2) would provide a documentation on how the Omega works, how to interact with the memory, etc. In my opinion, a good documentation is much more inviting and encouraging to modify the Omega.

2. Lack of a good test environment
As i mentioned before, there have been only small changes made. I think the biggest reason is because we do not have a good testing environment. We can only test on real hardware, which could be easily bricked. I personally doubt that the devs were exclusively testing on real hardware. What i kinda hope for is to get some tools or info on how you (EZ-Flash2) are working with the Omega. How do you develop and test the ROM? Ideally we could use a software emulating not only the GBA hardware, but also the EZ-Flash Omega hardware (especially the SD card reader and NOR memory). Something that allows us to test and debug our modified software before we put it on the real Omega. Or we could use info on how to reflash a bricked EZ-Flash if something went horribly wrong.

I hope we can get help and encourage more people to develop custom ROMs for the Omega. I for one have some ideas i wish to try out, but i am scared of bricking my own EZ-Flash Omega.

 

[FAST6191]

For the EZ4 we did once have a simple mod that would not care if it failed to detect the SD/NOR/RAM/whatever and boot just fine in VBA and/or desmume for their respective versions. You might be able to null out any checks to them that cause execution to halt if you want to fiddle with that side of things.

Also as far as alternative versions then did https://gbatemp.net/threads/ez-omega-with-pogoshell-alpha.510778/ pass you by?

Don't know what risk of bricking there is for the Omega. Might be possible to make a build you launch as a ROM but acts as a loader once loaded -- I doubt emulators are going to be recoded to fake being an Omega any time soon similar to how we have DLDI functionality for DS emulators. I similarly don't know what was done as far as using said GBA emulators -- they might have made them load from the cart but probably far easier to build a ROM builder, especially a single ROM builder, into the game -- in game menus for those might be able to tell us something here.

I would probably also add
3. The existing loader loads ROMs and their attendant saves just fine, has cheats, has support for a handful of popular platforms the GBA emulates well, does not burn your eyes to look at for the few seconds it is on screen and otherwise does what it needs to do. It is not like the acekard firmwares on the DS where new games were coming out, or the EZTeam's own 3 in 1 where teams would want to implement support into their own devices and homebrew.

 

[kuwanger]

(1) The Github includes a good pdf documenting memory access. You can look at the various gba*.s files to get an idea of how reset/rts saving works . I haven't looked hard at cheats but I presume that's something that can be figured out pretty easy as well . I'm not saying it's all trivial to understand (I'm not sure how FAT_table_buffer works except so far as it clear is passing information to the FPGA on what sectors to save to). Overall, though, I'd say as far as flash carts go it's actually pretty clear.

(2) I'm not that worried about bricking the EZ Omega--bricking other peoples EZ-Omega is another story--, but I would admit it'd be nice to have a copy of the bootloader and info on how to reflash it if necessary--there seems to be pins on the board for programming. That alone would be enough to avoid 99.9% the issue of bricks if you're that worried.

(3) This is very true. In fact my only real complaint is there's no coordination with the FPGA to remove the issue of corruption. I understand why the FPGA itself isn't open source, but it'd be nice to have a little bit more documentation on how it coordinates things (via my comment in 1).

I'd also throw in, there's been Pogoshell plugin support added by me and that was heavily dependent on having a good grasp of modifying stuff in PSRAM safely. It actually was quite trivial to add because in many ways it was an extension of what was already done for the built-in emulation. Having said that, sure it'd be nice if the code was heavily refactored. It's just not a high priority for me (or really anyone) because of (3). There's just not much that I can think could really be added to a loader that'd mean a lot. Maybe expanded theme support? Personally, I got out of that kick while adding a bunch of pointless bells and whistle to my old Unofficial Pogoshell fork.

 

[EZ-Flash2]

There is no way to brick the EZFLASH OMEGA in software method, because we built the recovery system in the FPGA.
As long as the chips on the card have no hardware level damage, you will never brick the card.
We also have boot-loader recovery image and documents. you can grab it at here

About the development environment, we use DevkitPro, NO$GBA, VBA, but most the test works were completed on the real GBA console, with a development board and a logic analyzer.

 

[kuwanger]

We also have boot-loader recovery image and documents. you can grab it at here

Thanks. Now we can fiddle with the bootloader too, if we want. Admittedly, I'm probably not going to do that but it's nice to have a clean copy and recovery instructions.

 

[fightabunny]

There is no way to brick the EZFLASH OMEGA in software method, because we built the recovery system in the FPGA.
As long as the chips on the card have no hardware level damage, you will never brick the card.
We also have boot-loader recovery image and documents. you can grab it at here

About the development environment, we use DevkitPro, NO$GBA, VBA, but most the test works were completed on the real GBA console, with a development board and a logic analyzer.

Thank you very much for providing the bootloader! The availability of this recovery mechanism gives me more confidence with making modifications.

I am the user who opened this simple PR on GitHub to add the boot to NOR feature. As a general question, is the EZ-Flash team even interested in community contributions for feature requests and bug fixes? Or do you prefer to keep all of the development in house?

I am happy to continue making modifications to improve my own experience but it would be nice if they could trickle back to other users eventually