Hacking New Theme for EZ-Flash Omega!

[kuwanger]

AFAIK, all cheats are ram cheats and are called once per frame--that is whenever keyinput happens which is in most games checked once per frame. On-the-fly toggling of cheats could be done pretty trivially with a 32-bit mask or 64-bit mask (limiting active cheats to 32 or 64 depending on how you wanted to make it) and would hence require 4 or 8 bytes of RAM. Actually code wouldn't be too difficult--it should only require a mov r0,r0,lsr#1 and a movcc .... The hard part would be constructing and displaying the menu, the number of codes would be more fixed, and finding the RAM to actually store the active cheats flags. It'd also use up 2x as much CPU time per frame (or more) which makes it more likely to glitch out in games.

Overall, not impossible to do but it doesn't seem worth all the trade-offs IMHO.

 

[Sterophonick]

AFAIK, all cheats are ram cheats and are called once per frame--that is whenever keyinput happens which is in most games checked once per frame. On-the-fly toggling of cheats could be done pretty trivially with a 32-bit mask or 64-bit mask (limiting active cheats to 32 or 64 depending on how you wanted to make it) and would hence require 4 or 8 bytes of RAM. Actually code wouldn't be too difficult--it should only require a mov r0,r0,lsr#1 and a movcc .... The hard part would be constructing and displaying the menu, the number of codes would be more fixed, and finding the RAM to actually store the active cheats flags. It'd also use up 2x as much CPU time per frame (or more) which makes it more likely to glitch out in games.

Overall, not impossible to do but it doesn't seem worth all the trade-offs IMHO.

I stand corrected.

 

[GBAResearcher]

Thanks for all the insight guys. If what kuwanger said could be done then I think it's worth incorporating. Make it an experimental mode with a disclaimer of the risks. I'm sure some codes would be easier to use on certain games than others so as long as people understand that then why not. I'll donate to anyone willing to add this function.

 

[noda]

After a lot of fiddling, I've created a new version of reset_ez4.s for the EZ Omega. The major difference is simply waiting ~5 seconds before actually doing the reset. This is important because one of the last things pocketnes, goomba, etc does is save menu settings to the SRAM, and that could lead to corruption. The solution the EZ Omega kernel does is to simply NOP out the writeconfig(), but that has the unfortunately side-effect of settings not being saved. And it still leaves users to wait the necessary time to not cause corruption.

The reason it took me so long with fiddling is because later versions of pocketnes include built in code to do resetting for Visoly, EZ, G6, and M3 carts (there might be more). So, it turns out you need to do the waiting before issuing those magic writes (AFAIK all the relevant code is in EXWRAM/IWRAM so it's not that), so I ended up having to reorder the function calls. The oddity to me most of all is that it froze. *shrug*

Anyways, here's the new binary and source. It only takes 16 more bytes to actually do the wait so it should fit with all the other patched plugins. I hope you find this useful.

Edit: Patching Goomba Paletted is also a little more complicated because it supports ez4 reset built in. So, I just overwrote the last 16 bytes before the return address in visoly's init_flashcart function since that's really otherwise pretty much a dummy function.

Thanks! How to use your provided reset patch on existing emulators?

@Stereophonick Are the emulators provided with your theme already exit-patched, or do we have to be careful?

 

[kuwanger]

Thanks! How to use your provided reset patch on existing emulators?

Each one has to be individually patched, which I haven't gotten around to. I really only included the information as an FYI if people did start seeing a clear pattern of using emulators and corruption for a possible fix. As it stands, though, there isn't anything clear and if there are corruption issues it really needs to be addressed in the firmware because it applies to more than just emulators but possibly all games. :/

 

[Sterophonick]

They are exit patched, but they do not wait for 3 seconds

 

[kuwanger]

More specifically, when you select exit, there's a write to SRAM, then the exit patch runs a fraction of a second later. So, presumably either (1) the SRAM write happens fast enough that the FPGA (or whatever it is they're using) doesn't notice, (2) the SD card is written to successfully in that fraction of second, or (3) something else is happening. :/

 

[GBAResearcher]

BTW thanks for this firmware. I'm using it and really don't want to revert to default.

 

[Robert McCoy]

Can't wait for this to be updated with the new firmware release! Excited.

 

[Sterophonick]

It is being worked on.

 

[Sterophonick]

Update 2.3:
- Updated to Kernel 1.06, FW 7.
- Improved Chip-8 Emulation
- Improved Arcadia 2001 Emulation

 

[flatgba]

Update 2.3:
- Updated to Kernel 1.06, FW 7.
- Improved Chip-8 Emulation
- Improved Arcadia 2001 Emulation

Beautiful work as always. Thank you for the update!

 

[Sterophonick]

Beautiful work as always. Thank you for the update!

Aww shucks~

 

[kuwanger]

Thanks for the update. Source?

 

[Sterophonick]

It will be pushed when I get the chance.

 

[Sterophonick]

The source has now been pushed.

 

[kuwanger]

A few things. One, a small bug fix for ezkernel.c. Two, a file case change so draw.c will compile. Three, some plugins with source (a different sb.gba and a fork of Maxim's vgmplayer to support compressed/grouped vgm files). Also, gsm files do work for me but my test example was <1MB and the bug I fixed applies to >~8MB stuff.

Edit - Re-uploaded pogoplugins_with_source to change sb.gba to do proper reset; includes precompiled libmm.a (you'll have to fix the Makefile to make it find the mm library for mmgba to compile). Tried to just compile vgmplayer and even the oldest copy of devkitarm I have (r26) causes the background to go all red which I think means 100% CPU usage. So, uh, yea, not going to be as trivial to fix. :/

 

[Yrouel]

Hello, I like the added features of Simplelight compared to the stock version however I very much prefer the original look of the interface (and the double GameBoy boot is a bit annoying too). Is there a way to have the original look and the new features?
To be honest I hope the new emulators and stuff could be merged to the official firmware/kernel, Sterophonick should very well be an official developer at this point

 

[maniacnny]

....however I very much prefer the original look of the interface

I like original theme to, and want to see font like this https://gbatemp.b-cdn.net/attachments/skinner_mod-png.120706/

THANK YOU!

 

[Sterophonick]

Hello, I like the added features of Simplelight compared to the stock version however I very much prefer the original look of the interface (and the double GameBoy boot is a bit annoying too). Is there a way to have the original look and the new features?
To be honest I hope the new emulators and stuff could be merged to the official firmware/kernel, Sterophonick should very well be an official developer at this point

Aww, that's so nice.