1. WiLLiW

    WiLLiW Advanced Member
    Newcomer

    Joined:
    May 2, 2020
    Messages:
    56
    Country:
    Brazil
    Have you tried yet 1.04 ?
     
  2. voddy

    voddy No Title Available
    Member

    Joined:
    Jul 14, 2013
    Messages:
    589
    Country:
    United States
    No
    Ist there a Link somewhere
     
  3. aaaaaa123456789

    Newcomer

    Joined:
    Apr 16, 2020
    Messages:
    48
    Country:
    Argentina
    I doubt it; someone did say that Zelda wasn't working.
    :)
     
    WiLLiW likes this.
  4. voddy

    voddy No Title Available
    Member

    Joined:
    Jul 14, 2013
    Messages:
    589
    Country:
    United States
    Huh ?
    Sorry haha. I meant link as url xD couldnt Test 1.04 as i dont have an url
     
  5. WiLLiW

    WiLLiW Advanced Member
    Newcomer

    Joined:
    May 2, 2020
    Messages:
    56
    Country:
    Brazil
    and there here it goes :grog:
     

    Attached Files:

  6. voddy

    voddy No Title Available
    Member

    Joined:
    Jul 14, 2013
    Messages:
    589
    Country:
    United States
    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 voddy, Sep 27, 2020
  7. ndsLight

    ndsLight Member
    Newcomer

    Joined:
    Dec 28, 2019
    Messages:
    23
    Country:
    Belarus
    Same here. ezgb.dat from fw5 just does not work properly. ezgb.dat from 1.04 works ok.
     
  8. WiLLiW

    WiLLiW Advanced Member
    Newcomer

    Joined:
    May 2, 2020
    Messages:
    56
    Country:
    Brazil
    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:
     
  9. DrunkenMonk

    DrunkenMonk GBAtemp Fan
    Member

    Joined:
    Sep 30, 2007
    Messages:
    435
    Country:
    United Kingdom
    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
     
  10. aaaaaa123456789

    Newcomer

    Joined:
    Apr 16, 2020
    Messages:
    48
    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:
    [​IMG]
     
    Last edited by aaaaaa123456789, Sep 28, 2020
    VinsCool, DrunkenMonk and zfreeman like this.
  11. EZ-Flash2

    OP EZ-Flash2 Official EZ-FLASH Stuff
    Member

    Joined:
    Jul 16, 2003
    Messages:
    550
    Country:
    China
    SGB enhanced support was done. test firmware will release in days.
     
  12. WiLLiW

    WiLLiW Advanced Member
    Newcomer

    Joined:
    May 2, 2020
    Messages:
    56
    Country:
    Brazil
    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!
     
  13. DrunkenMonk

    DrunkenMonk GBAtemp Fan
    Member

    Joined:
    Sep 30, 2007
    Messages:
    435
    Country:
    United Kingdom
    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
     
  14. Shadow#1

    Shadow#1 Wii, 3DS Softmod & Dumpster Diving Expert
    Member

    Joined:
    Nov 21, 2005
    Messages:
    8,974
    Country:
    United States
    What rts?
     
  15. kerobscure

    kerobscure Advanced Member
    Newcomer

    Joined:
    Oct 28, 2015
    Messages:
    74
    Country:
    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

     
  16. voddy

    voddy No Title Available
    Member

    Joined:
    Jul 14, 2013
    Messages:
    589
    Country:
    United States
    i'd like to ask why save states are not possible at all. (i m pretty interested tbh)
     
  17. EZ-Flash2

    OP EZ-Flash2 Official EZ-FLASH Stuff
    Member

    Joined:
    Jul 16, 2003
    Messages:
    550
    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.
     

    Attached Files:

    bbsan2k, VinsCool and Jayro like this.
  18. Jayro

    Jayro MediCat USB and Malwarebytes Bootable Developer
    Developer

    Joined:
    Jul 23, 2012
    Messages:
    8,150
    Country:
    United States
    You are amazing, and thanks to you and the team.
     
  19. ndsLight

    ndsLight Member
    Newcomer

    Joined:
    Dec 28, 2019
    Messages:
    23
    Country:
    Belarus
    I don't have SGB, but thanks for your work!
     
  20. aaaaaa123456789

    Newcomer

    Joined:
    Apr 16, 2020
    Messages:
    48
    Country:
    Argentina
    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?
     
Draft saved Draft deleted
Loading...

Hide similar threads Similar threads with keywords - TestFlight, Junior, FLASH