Hacking EZ-FLASH Junior TestFlight

WiLLiW

Well-Known Member
Member
Joined
May 2, 2020
Messages
124
Trophies
0
Age
115
XP
503
Country
Brazil
sadly 1.05e killed my gb boy compatibility.
it just reboots and reboots until it freezes :S on my gba it works flawless

It worked after serveral tries now... Strange behaviour

Strange. Now it works everytime...
Have you tried yet 1.04 ?
 
D

Deleted User

Guest
this seems to be more stable than 1.05e tbh ^^
i use fw5 now and 1.04e
the reboots came from a low power battery. had to change them in addition.
 
Last edited by ,

WiLLiW

Well-Known Member
Member
Joined
May 2, 2020
Messages
124
Trophies
0
Age
115
XP
503
Country
Brazil
this seems to be more stable than 1.05e tbh ^^
i use fw5 now and 1.04e
the reboots came from a low power battery. had to change them in addition.
At the moment, for my GBL, the k1.04e is the better choice over the newer betas ones. Hope the OP keep updating EZ-Flash Jr kernels. :bow:
 

DrunkenMonk

Well-Known Member
Member
Joined
Sep 30, 2007
Messages
523
Trophies
1
Age
31
XP
1,751
Country
United Kingdom
I just posted a new release of my RTC tests: https://github.com/aaaaaa123456789/rtc3test/releases/tag/v003

It's giving mixed results on these new tests. Some of the writes' timings are OK, some are far off.
I also noticed my cart's RTC is fast. The tick time is 996.9ms, i.e., it's fast by 0.31%. This might not seem like a lot, but it's a drift of over four minutes per day, so it adds up really fast. @EZ-Flash2 maybe check with the RTC chip manufacturer? This can't be right.
Yeah I was getting the tick time showing 1019.5ms then 996.9ms fairly consistently I imagine that's software induced idk? I have no idea but my RTC doesn't deviate from what i've noticed day to day. I've re-set the time to the correct second just today and I'll check it again tomorrow to see if it deviates (since before I only set the minute and hour and it was difficult to check for deviations)

sub-second write test comes back slightly different each run, not really sure how that works either
example of two test runs:

Code:
first test         second test
503.0             480.3
888.0             910.7
70.7               48.0
591.4             614.0
205.2             182.5
793.6             816.2
296.9             296.9
0.0                 0.0
 

aaaaaa123456789

Well-Known Member
Newcomer
Joined
Apr 16, 2020
Messages
63
Trophies
0
Age
32
XP
365
Country
Argentina
Alternating 996.9 and 1019.5 might point to some self-correction. The long-term tick time average is probably close to 1000ms in that case.
As for the sub-second write test, that just shows that the implementation is severely non-conformant. I don't blame them: there are no docs. But I hope that these tests will help people making RTC implementations in general.

EDIT: for the record, this is what a successful test looks like:
image.png
 
Last edited by aaaaaa123456789,

WiLLiW

Well-Known Member
Member
Joined
May 2, 2020
Messages
124
Trophies
0
Age
115
XP
503
Country
Brazil
SGB enhanced support was done. test firmware will release in days.
Yay! I'm your fan! Quick question! The real-time-save-states in EZ-Flash Jr is not on the development agenda, correct? So ... can we expectate some rumble support on the future? I would love to play Pokémon Pinball and Pocket Monsters Midori with it!
 

DrunkenMonk

Well-Known Member
Member
Joined
Sep 30, 2007
Messages
523
Trophies
1
Age
31
XP
1,751
Country
United Kingdom
Alternating 996.9 and 1019.5 might point to some self-correction. The long-term tick time average is probably close to 1000ms in that case.
As for the sub-second write test, that just shows that the implementation is severely non-conformant. I don't blame them: there are no docs. But I hope that these tests will help people making RTC implementations in general.

EDIT: for the record, this is what a successful test looks like:
image.png

A little less than 24 hours later and my RTC has actually lost exactly 5 seconds so far, so it is actually still out a bit, I assume it's something they can accommodate for though since they managed to deal with correcting the 996.9 seemingly decently? I guess that does depend on the crystal a little bit though, hopefully they end up nailing RTC entirely though. I'd love a flash cart capable of 1:1 replication of the RTC functions
 

Shadow#1

Wii, 3DS Softmod & Dumpster Diving Expert
Member
Joined
Nov 21, 2005
Messages
12,341
Trophies
2
XP
7,984
Country
United States
Yay! I'm your fan! Quick question! The real-time-save-states in EZ-Flash Jr is not on the development agenda, correct? So ... can we expectate some rumble support on the future? I would love to play Pokémon Pinball and Pocket Monsters Midori with it!
What rts?
 

kerobscure

Well-Known Member
Newcomer
Joined
Oct 28, 2015
Messages
88
Trophies
0
Age
30
XP
534
Country
Yay! I'm your fan! Quick question! The real-time-save-states in EZ-Flash Jr is not on the development agenda, correct? So ... can we expectate some rumble support on the future? I would love to play Pokémon Pinball and Pocket Monsters Midori with it!

At the moment, magic not exists... The cartridge don't have a rumble physically but rumble is impossible in this cartridge, and savestates, question to aaaaaa123456789

Save states are completely impossible. I'll be happy to explain if anyone wants more info, but I warn you, it's very technical.
 
D

Deleted User

Guest
i'd like to ask why save states are not possible at all. (i m pretty interested tbh)
 

EZ-Flash2

Official EZ-FLASH Stuff
OP
Member
Joined
Jul 16, 2003
Messages
1,104
Trophies
3
XP
3,455
Country
China
Here is the FW5 SGB test firmware. use it with the kernel 1.05RC.

This is a test firmware only been tested with a few tester. It may not suit with your equipment. It may brick your card. If you are not sure what is this and its risk, Please wait for the final release.

If you don't own a SGB, you have no need to update this firmware.

Usage:

You still have to enter the kernel by press RESET on card(why this, it is a another looooooooooong story which I have no time to explain). I suppose all of you SGB guys know how to operate it.

Launch the SGB enhanced GB games as normal.

SGB enhanced function which we tested is ok. needs more reports from you guys.
 

Attachments

  • Update_FW5_forSGB_9-29.rar
    144.2 KB · Views: 246

Jayro

MediCat USB Dev
Developer
Joined
Jul 23, 2012
Messages
12,884
Trophies
4
Location
WA State
Website
ko-fi.com
XP
16,776
Country
United States
Here is the FW5 SGB test firmware. use it with the kernel 1.05RC.

This is a test firmware only been tested with a few tester. It may not suit with your equipment. It may brick your card. If you are not sure what is this and its risk, Please wait for the final release.

If you don't own a SGB, you have no need to update this firmware.

Usage:

You still have to enter the kernel by press RESET on card(why this, it is a another looooooooooong story which I have no time to explain). I suppose all of you SGB guys know how to operate it.

Launch the SGB enhanced GB games as normal.

SGB enhanced function which we tested is ok. needs more reports from you guys.
You are amazing, and thanks to you and the team.
 

aaaaaa123456789

Well-Known Member
Newcomer
Joined
Apr 16, 2020
Messages
63
Trophies
0
Age
32
XP
365
Country
Argentina
i'd like to ask why save states are not possible at all. (i m pretty interested tbh)

A savestate is a file that contains the entire state of the device, so that it can be restored in order to resume gameplay. An emulator can handle this easily, since it controls (and thus knows and can overwrite) the entire state — its own state, really. But a flash cart has to play by the rules of the hardware, and it only has the Game Pak bus to interact with it. Let's break down what this device state entails, and how it could be accessed:

  • ROM, banking state and save data. This is the easiest by far, because the flash cart already controls it.
  • General-purpose RAM (WRAM, HRAM). This (and every item below this) requires running code in the device to access.
  • Display RAM (VRAM, OAM). This has the additional complication of timing restrictions.
  • CPU registers. These are easy to access if you can run code in the device, but hard to preserve, because any attempt at doing so will destroy something else, and attempting to preserve something else first will destroy them.
  • I/O and interrupt registers. These are the hardest part of the state by far. Many of them aren't readable at all (e.g., interrupt master enable). Many of them are completely inaccessible (e.g., internal halves of timers). Most of them can't simply be restored to their old state (e.g., audio registers: writing back the old values would restart the current sound). And some of them can't be restored at all (e.g., serial transfers).

There's a lot of special cases I'm not going over in that last category because just about everything is a special case. But one particular area of complexity is timing: many games (either accidentally or on purpose) rely on the internal synchronization of components, and thus the timing of every component must be identical when the game is resumed as it was when it was stopped. For instance, it would have to be resumed rendering the same exact part of the screen it was rendering when it was stopped.

But none of this matters when you can't get past the first hurdle: getting CPU access. The Game Pak bus is mostly one-way, where the CPU requests an operation (a read or a write) and the cart fulfills it. This is pretty standard: there's no reason for the cart itself to have any control of the system (that's why you put a program in it that gets loaded by the console), and giving the cart control of the device would require an immensely more complex interface. (This is not an "old consoles" thing; modern consoles work the exact same way.) In principle, the game's code could be executing from anywhere — it's perfectly legitimate to write code to RAM and run entirely from there, and if a game does this, the cart would no longer have any control of the code being run. A truly generic solution would meet a complete showstopper here; there is no way around this problem. But since (as far as I know) commercial games don't usually do this, let's imagine a more realistic scenario.

All data from ROM (or SRAM) is delivered to the CPU pretty much in real time. (Technically, one or two cycles in advance, but that doesn't make a difference here.) That means that if the game is executing code from ROM, as games normally do, the cart could just feed the CPU any code it wants to instead of the original. However, it's virtually impossible to determine (externally and in real time) if a given access corresponds to code or data, and feeding the CPU altered data could have disastrous consequences, so this technique can't be used without care. Some instructions are also two or three bytes wide, and these bytes are fetched one at a time, so the cart cannot know in advance whether it's returning the beginning of an instruction or some follow-up byte for it — meaning it can't blindly replace code even after knowing it really is code.

There is some hope, though. Most CPUs have something called interrupts — events that the CPU will detect that will interrupt the current flow of code and cause some special handler code (called an ISR (interrupt service routine), or more commonly an interrupt handler) to run instead. The Game Boy has five of them, and the handlers are at fixed addresses, starting at $0040. All of these addresses are in ROM! If the cart could know that an interrupt handler is about to execute, it could replace the handler's code with its own, and thus gain CPU access.

User programs (I'm not calling them "games" because there's no requirement for a cart to actually contain a game, after all) can choose what interrupts they use, though. And they'll almost never contain interrupt handlers for interrupts they never enable in the first place. If they don't use a particular interrupt, they may use that area of ROM for anything else (and this isn't as uncommon as it would seem), and we would be back to square one. Fortunately, one of the interrupts, the very first one (the VBlank interrupt), is very common.

CRT screens render images by shooting electrons at the screen in a pretty mechanical way: there is an electron beam that moves across the screen and renders each pixel. When it reaches the end of the line, it has to stop rendering pixels while it moves back to the beginning of the next line; this short render pause is known as the horizontal blanking period, or HBlank for short. Likewise, when the beam reaches the end of the screen (typically the bottom right corner), it has to move all the way up to the opposite corner to render the next frame; this significantly longer pause is the vertical blanking period, or VBlank. The Game Boy doesn't have a CRT screen, of course. But while the PPU (the component that does the actual screen rendering) is rendering pixels to the LCD, the CPU cannot access display memory at all; therefore, it needs some rendering pauses so that the CPU can access display memory and thus actually put data there. Nintendo chose to emulate the HBlank/VBlank model, already familiar to developers of CRT-screen-based devices, where these pauses are merely PPU delays so that the CPU will get a chance. VBlank takes up 10% of the time spent in every frame, and thus it is the moment where games will do almost all of their rendering to screen. Since this interval is so important, there is a dedicated interrupt that fires at the beginning of VBlank, letting user programs place their rendering code in the interrupt handler instead of having to manually track each frame's timing. And this interrupt is nearly universally used. So this particular interrupt is the best hope of getting the cart to run its own code on the Game Boy's CPU.

Hooking the VBlank interrupt also has two advantages. One, when an interrupt fires, the return address is pushed to the stack, so the stack must be usable — which makes it easier to be able to preserve CPU registers. And two, the PPU state is known, so there are no frame timing issues. This, of course, is assuming that the VBlank interrupt fires on time (which may not happen; interrupts may be enabled when there's a VBlank interrupt pending), that the handler isn't simply called, and so on. But we're talking about the optimistic scenario here.

So, let's assume we get all the conditions right. The game uses the VBlank interrupt, the interrupt is enabled, and nothing else reads from the handler's address. The user hits the savestate button on the cart (for the sake of the example we'll assume it's a physical button on the cart; using a key combination is much more complex), the cart waits, and a read for address $0040 is requested. The cart starts sending its own code to the CPU (instead of the actual ROM contents at $0040) and the code runs fine. The cart's replacement handler begins by pushing the CPU registers to the stack to save them, and this works just fine: there is enough room on the stack and no useful data is overwritten. So far, this scenario isn't particularly unlikely, so if this works out, we might have a solution that works for many games, if not most.

Except that this was just the first hurdle. The music playing will often rely on timers, which are hard to preserve and restore. RNGs often depend on the divider register, which is another internal timer that is very hard to preserve and restore. Audio registers themselves are mostly unreadable. On-going DMA transfers would be very hard to resume.

And finally, there's the problem of how to trigger a savestate in the first place. I mentioned a hypothetical savestate button on the cart. But these carts don't have a button, and no firmware update will manufacture a button out of nowhere. The only option is to trigger them based on some key combination. But this goes back to the "no access to the CPU" problem, because CPU access is needed to detect key combinations in the first place. There is a joypad interrupt, but this is unreliable in most contexts and rarely used; most games do their own joypad reading using code that could be anywhere in the ROM. Working around this would require per-game patches to even get going. These are on top of the per-game patches that would be needed to solve all of the problems mentioned in the previous paragraph (by restoring the state each game expects). All of these patches would be very custom and would have to be developed independently for every single game that could support the feature.

And if you're going to make complex edits to games to support savestates, why not just edit the games to allow you to save at any time instead without relying on a flash cart?
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    LeoTCK @ LeoTCK: yes for nearly a month i was officially a wanted fugitive, until yesterday when it ended