1 2
14 15 16
19 20
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
Cool, I'll get to LADX eventually but seems like it's not that strict. The game Race Days does not verify on either Gambatte or GBHawk (if you pick Dirty Racing at least.) It reads from uninitialized RAM at C224, so this is probably the culprit.
02EB:  EA 24 C2  LD   (#C224h),A         A:00 F:90 B:A8 C:FC D:02 E:00 H:A0 L:00 SP:DFFA Cy:61216123 LY:128 ZnhCie
EDIT: Race Days reads lots of memory locations before writing, it looks like it's testing if if needs to clear the regions, but anyway it desyncs in all kinds of ways with every reset, probably no hope for that one unless by chance you can reset right after it's done initializing and nothing changes between loading segments. Wave Race seems to work, but you either have to flash SRAM before starting or use a movie that contains the game's default SRAM after clearing, otherwise it will desync.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
I did some follow up research on Warioland GEG. First I tried Double Dragon 3 in GBI since it is a rare example of a game that uses the controller interrupt to read the inputs, so I wanted to verify everything worked. It works fine for both normal play and when playing back a movie. I still believe that control inputs should un-stop the system correctly though for the game end glitch run, so I figured something else must be up. Looking at the trace log, it turns out the STOP was an incorrectly formatted STOP, STOP $04 instead of STOP $00. I didn't notice this before since the trace log just ignored the second byte and the Hex Editor displayed 10 00 which is STOP $00 but that is only true at the start of the frame. Since the GB hardware test ROMs indicate that STOP $## do not behave correctly, this seems to be the problem. I'm not sure if everything can be made to line up correctly for a STOP 00 with everything else correct as well, but I guess I'll try testing. hopefully I can get an instance of a STOP 00 that does something after un-stop so at least I can verify that it actually happens. EDIT: actually it seems like STOP XX shouldbehave normally, so I'm not really sure what's wrong here. EDIT2: Warioland II is another game that either needs SaveRAM flashed to FF or a movie that starts from default saveram that gets written on data clear. It won't sync otherwise.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
I made test runs of Prehistorik Man (worked fine) and RC Pro AM (desynced due to reading from uninitialized RAM at FFCC-FFCD.) R.C. Pro AM also desynced with a run made in Gambatte. It's a bit disappointing to find such a high percentage of games that use uninitialized RAM even just in the limited number of tests I've done. GBHawk initializes RAM to all zeroes, both WRAM and HRAM. I did test HRAM initialized with all 0xFF instead and that run did sync on 2 spereate tries. So maybe starting up with all 0xFF is accurate? At least for HRAM maybe, WRAM seems to be much more random in my testing with Dirty Racing. On a side note, it's been 3 whole years since I started this thread, where'd all that time go! It seems like there's always more to do and less time to do it, I'm happy to still be making steady if slow progress though.
TiKevin83
He/Him
Ambassador, Moderator, Site Developer, Player (155)
Joined: 3/17/2018
Posts: 358
Location: Holland, MI
We verified Kirby's Pinball Land last night. I'll link here when I have the GBI movie archives finished for the last few verifications
Emulator Coder, Judge, Experienced player (729)
Joined: 2/26/2020
Posts: 781
Location: California
Alyosha wrote:
I made test runs of Prehistorik Man (worked fine) and RC Pro AM (desynced due to reading from uninitialized RAM at FFCC-FFCD.) R.C. Pro AM also desynced with a run made in Gambatte. It's a bit disappointing to find such a high percentage of games that use uninitialized RAM even just in the limited number of tests I've done. GBHawk initializes RAM to all zeroes, both WRAM and HRAM. I did test HRAM initialized with all 0xFF instead and that run did sync on 2 spereate tries. So maybe starting up with all 0xFF is accurate? At least for HRAM maybe, WRAM seems to be much more random in my testing with Dirty Racing. On a side note, it's been 3 whole years since I started this thread, where'd all that time go! It seems like there's always more to do and less time to do it, I'm happy to still be making steady if slow progress though.
It largely depends on where it's reading uninitialized RAM (I believe some places in RAM would have swaths of 00 data and then another place with swathes of FF data, with random bits not set in the FFs and such), and besides that, a lot of random bs in the real world.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
TiKevin83 wrote:
We verified Kirby's Pinball Land last night. I'll link here when I have the GBI movie archives finished for the last few verifications
Cool, that will be a neat one to see.
CasualPokePlayer wrote:
It largely depends on where it's reading uninitialized RAM (I believe some places in RAM would have swaths of 00 data and then another place with swathes of FF data, with random bits not set in the FFs and such), and besides that, a lot of random bs in the real world.
That's what it does for WRAM, but what about HRAM (FF80 - FFFF)? I see in Gambatte initstate.cpp that it has a 'ffxxDump' array that it initializes from, but where is that from? And is it different for GBA then for GBC? GBA handles some memory related things differently from GBC, so it might be worth getting a dump from a GBP. So far in my testing there is a consistent de-sync in gambatte with it's HRAM initial state and GBHawk with it's 0x00 initial state, and a consistent sync with 0xFF initial state.
RetroEdit
Any
Editor, Reviewer, Player (169)
Joined: 8/8/2019
Posts: 152
Just want to weight in here on something related: I think handling of uninitialized RAM should ideally be a sync setting. That way it's documented in the movie file, instead of something floating around in the ether of emulation implementation details. Though, some uninitialized RAM may be more consistent than others, so maybe my idea isn't fully robust.
Editor, Reviewer, Skilled player (1358)
Joined: 9/12/2016
Posts: 1646
Location: Italy
RetroEdit wrote:
Just want to weight in here on something related: I think handling of uninitialized RAM should ideally be a sync setting. That way it's documented in the movie file, instead of something floating around in the ether of emulation implementation details. Though, some uninitialized RAM may be more consistent than others, so maybe my idea isn't fully robust.
Maybe you mean to "report it" inside the header. It's not like we can "set" the emulator to not use uninitialized RAM.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Emulator Coder, Judge, Experienced player (729)
Joined: 2/26/2020
Posts: 781
Location: California
Alyosha wrote:
That's what it does for WRAM, but what about HRAM (FF80 - FFFF)? I see in Gambatte initstate.cpp that it has a 'ffxxDump' array that it initializes from, but where is that from?
I don't think that's based on any actual testing, it seems to be just a padding value put in (not like it super matters anyways, the values would very likely be cleared out by the game, and also more accurate behavior would essentially be non-deterministic... which is bad for the purposes of a TAS).
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
CasualPokePlayer wrote:
Alyosha wrote:
That's what it does for WRAM, but what about HRAM (FF80 - FFFF)? I see in Gambatte initstate.cpp that it has a 'ffxxDump' array that it initializes from, but where is that from?
I don't think that's based on any actual testing, it seems to be just a padding value put in (not like it super matters anyways, the values would very likely be cleared out by the game, and also more accurate behavior would essentially be non-deterministic... which is bad for the purposes of a TAS).
With a name like 'ffxxDump' it seems like it must be dumped from somewhere. The BIOS uses about half of HRAM, and the values in that array match what is left in HRAM after the BIOS ends (for the ones it uses) so I'm guessing at some point in the past it was dumped from a GBC or GBA. Anyway, I looked at some trace logs of what the game is doing with unitialized RAM:
FFCD > 0x02 (FFCD unwritten)

FFCC != 0xDE (checks 3 times, FFCC unwritten)

FFCC != 0xDE (checks 3 times, FFCC unwritten)

FFC9 != FFC8 (FFC9 unwritten, FFC8 written 1)
So basically, as long as these 3 things are true, the game will sync. I made a much longer run with 0xFF state and it synced completely (~91000 frames.) Actually, all of the above are true for Gambatte as well: FFCD = 0x97 FFCC = 0x46 FFC9 = 0x6D It must desync for a different reason, I'm trying to figure out what that is. EDIT: there is at least one difference so far, reading from STAT in the transition from LY = 0 (line 153) to LY = 0 (line 0): GBHawk:
39F6:  F0 41     LDH  A,(#FF41h)         A:01 F:20 B:01 C:47 D:C7 E:47 H:89 L:E9 SP:DFF3 Cy:14813571 LY:0 znHcIe
39F8:  E6 03     AND  #03h               A:85 F:20 B:01 C:47 D:C7 E:47 H:89 L:E9 SP:DFF3 Cy:14813583 LY:0 znHcIe
Gambatte:
39F6:  F0 41     LDH  A,(#FF41h)     A:01 B:01 C:47 D:c7 E:47 F:20 H:89 L:e9 LY:99 SP:dff3  Cy:14813568
39F8:  E6 03     AND  #03h           A:84 B:01 C:47 D:c7 E:47 F:20 H:89 L:e9 LY:99 SP:dff3  Cy:14813580
EDIT2: The test mode1_disablestat_end_dmg_mode indicates that Gambatte is getting this wrong.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
4384:  FA 5D D9  LD   A,(#D95Dh)         A:00 F:80 B:C2 C:91 D:0A E:00 H:C2 L:91 SP:C0B9 Cy:323183331 LY:149 ZnhciE
4387:  FE 01     CP   #01h               A:00 F:80 B:C2 C:91 D:0A E:00 H:C2 L:91 SP:C0B9 Cy:323183347 LY:149 ZnhciE
I was looking through different games and runs for uses of uninitialized memory and saw this example in Pokemon Crystal. It happens during the start of the credits. I tried setting D95D to one, and it does take a different code path but I didn't notice anything really different happening. Not sure what it could be related to, just thought I'd make note of it.
Emulator Coder, Judge, Experienced player (729)
Joined: 2/26/2020
Posts: 781
Location: California
Alyosha wrote:
4384:  FA 5D D9  LD   A,(#D95Dh)         A:00 F:80 B:C2 C:91 D:0A E:00 H:C2 L:91 SP:C0B9 Cy:323183331 LY:149 ZnhciE
4387:  FE 01     CP   #01h               A:00 F:80 B:C2 C:91 D:0A E:00 H:C2 L:91 SP:C0B9 Cy:323183347 LY:149 ZnhciE
I was looking through different games and runs for uses of uninitialized memory and saw this example in Pokemon Crystal. It happens during the start of the credits. I tried setting D95D to one, and it does take a different code path but I didn't notice anything really different happening. Not sure what it could be related to, just thought I'd make note of it.
That is initialized. That's wPlayerState, 0 means the player is walking, 1 means the player is biking, etc. And besides that, Pokemon literally 0's all of WRAM and HRAM on boot...
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
It doesn't 0 everything. 0x3000-0x5000, 0x5200-0x6000, and 0x7000-0x7990 in WRAM are all uninitialized, if I default them to 0xFF they stay that way. It looks like maybe it wants to check the player state but is in the wrong RAM bank, it reads from 0x595D WRAM which is in the never initialized range. Seems like it doesn't really matter though, doesn't have any actual impact. EDIT: the game Daiku no Gen-san - Ghost Building Company (Japan) uses uninitialized RAM at the start of level 2, this causes a desync towards the end of the level. I'm going to compile all the uninitialized RAM stuff in the opening post at some point.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
Daiku no Gen-san - Robot Teikoku no Yabou (Japan) I found an interesting case in this game today. It behaves slightly differently on GBHawk and Gambatte, and neither produces an input file that works on GBI. The first immediate difference between GBHawk and Gambatte is in a timer interrupt, which is pretty strange since timer emulation needs to be practically perfect for pokemon games to work, so there must be a weird edge case happening somewhere. The input files produced are slightly different, varying in timing in 6 places throughout the movie, but they both desync in the same way on console, and the inputs work out the same in terms of emulated frames. I also don't see any uninitialized RAM used, at least not in an obvious way that my checker picks up on. I'll be looking deeper into this, might be something interesting here. EDIT: Alright, so two things came up in this case. First, the primary desync was caused by an edge case of enabling the timer on the same cycle that a state change would occur. In this case, the timer was enabled by writing 5, which tells the timer to check bit 3 of the divider register. At this time, the divider register is 59591, which is 7 (mod 8), so this would trigger a state change since the divider register would increment at the same cycle. What should happen, on GBP at least, is that an extra timer increment should occur. Now, the details of this are not fleshed out that well. There is a test ROM for it called tac_set_disabled.gbc, and GBHawk and Gambatte both fail it in different ways, with neither getting really close. Also, the results are different depending on GBA variant. It's a race condition, so some cases could even be console dependent I suppose. It would probably be a good idea to run this test ROM on various GBP's and see what the results are. Anyway, if I implement the simplest possible case of going from off to on on the same cycle as an increment, then GBHawk desyncs in the same way as GBP. Gambatte on the other hand was already doing this. It desynced for a different more familiar reason, mode 3 timing:
083A:  CB 4E     BIT  1,(HL)             A:66 F:20 B:00 C:0C D:D8 E:85 H:FF L:41 SP:D9F8 Cy:461806951 LY:47 znHcie
083C:  28 03     JR   Z,0841h            A:66 F:20 B:00 C:0C D:D8 E:85 H:FF L:41 SP:D9F8 Cy:461806963 LY:47 znHcie
083E:  FB        EI                      A:66 F:20 B:00 C:0C D:D8 E:85 H:FF L:41 SP:D9F8 Cy:461806971 LY:47 znHcie
083A:  CB 4E     BIT  1,(HL)         A:66 B:00 C:0c D:d8 E:85 F:20 H:ff L:41 LY:2f SP:d9f8  Cy:461806948
083C:  28 03     JR   Z,0841h        A:66 B:00 C:0c D:d8 E:85 F:a0 H:ff L:41 LY:2f SP:d9f8  Cy:461806960
0841:  E1        POP  HL             A:66 B:00 C:0c D:d8 E:85 F:a0 H:ff L:41 LY:2f SP:d9f8  Cy:461806972
Top is GBHawk, bottom is Gambatte. This is at a part of the game where there is a lot of sprites + scrolling. Gambatte fails the test ROMs associated with this case. It's pretty crazy that one movie that I just recorded in a casual way by hand ran into 2 desync cases. I've attached the files for reference. I'm not sure exactly how I want to implement the timer fix in GBHawk yet, it might wait until after 2.5. http://tasvideos.org/userfiles/info/65391155339899622 http://tasvideos.org/userfiles/info/65391163693719305 EDIT: Actually the timer thing is adifferent case from what is tested in tac_set_disabled.gbc. The behaviour here depends on the initial state of the DIV register. I tried running a bunch of Gambatte's timer tests. It looks like the expected timer DIV initial state for GB is zero, and for GBC is 0xFFFF. Almost all of the tests work in GBC mode if I set timer to 0xFFFF. However if I do this then the Gensan 2 run syncs again because it doesn't get an additional timer increment. I need to determine what the initial state is for GBA to narrow down what is going on here. EDIT2: regardless of the initial value of DIV, an extra increment needs to occur in order for this run to sync. I'm currently not sure where it comes from, but it works perfectly on a much longer run , up to 25000 frames, if there is an extra increment when enabling. Note that the starting value of DIV being 0 or 0xFFFF is invisible to the pokemon TASes because they only read DIV and don't use the timer the same way, and invisible to pokemon TCG because DIV is reset by speed switch.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
I have made various improvements to GBHawk's timer emulation. It now passes all of Gambatte's timer tests in both GB and GBC mode, while still syncing console verified runs and passing the other available timer tests. This doesn't fix the problem in Gensan 2, but it does narrow it down to being a purely GBA issue. Still not sure exactly how I will handle that one yet. I also made a test movie for Pinball Fantasies, and that run worked on console, so that was good. EDIT: I implemented a basic version of the GBA glitch. Basically if you are enabling the timer while changing frequency and the old frequency is different from the new frequency, and the old div position was a high bit and the new one is a low bit, then an extra increment of timer happens. This doesn't capture all of the details of the glitch, but gets all the basic cases, including Gensan2. The glitch is rare enough that it doesn't impact existing runs, but the details are strange enough that it's something to keep an eye on.
Skilled player (1741)
Joined: 9/17/2009
Posts: 4981
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Not sure if this is the right place to ask, but how does one use motion control for games like Kirby's Tilt n Tumble? I can't seem to find an option for it.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
jlun2 wrote:
Not sure if this is the right place to ask, but how does one use motion control for games like Kirby's Tilt n Tumble? I can't seem to find an option for it.
GB -> settings -> sync settings -> controller -> tilt EDIT: Also I went through Gambatte's Halt tests and fixed a couple more edge cases. Passes all but the double speed mode tests now (which rely on mode 3 timing anyway.)
Editor, Reviewer, Skilled player (1358)
Joined: 9/12/2016
Posts: 1646
Location: Italy
Why do the tilt controls need to be explicitly set? It's confusing, user-unfriendly. It's not like you can choose to not use them when you play on real hardware, as it's part of the cartridge itself, or decide to use it for other games.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Skilled player (1741)
Joined: 9/17/2009
Posts: 4981
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Thanks. Changing to tilt mode however disabled my dpad, which I need to select stuff in menus. Is there a way to enable both? Also do I need to change anything else? I can't seem to move still in game.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
ThunderAxe31 wrote:
Why do the tilt controls need to be explicitly set? It's confusing, user-unfriendly. It's not like you can choose to not use them when you play on real hardware, as it's part of the cartridge itself, or decide to use it for other games.
Eventually I want to make different motion models for the control scheme. Right now it is Tilt (realistic.) Eventually I will add Tilt (simplified) and maybe some others that allow linear accelerations (speedrunners seem to use quick linear jerk motions to make Kirby jump, the accelerometers work just as well sensing any kind of acceleration.)
jlun2 wrote:
Thanks. Changing to tilt mode however disabled my dpad, which I need to select stuff in menus. Is there a way to enable both? Also do I need to change anything else? I can't seem to move still in game.
The tilt controls don't have default settings. Go to config -> controllers to set them. EDIT: Maybe I can make the tilt scheme a different sync setting, I'll think about how to do it. EDIT2: Ok controller setting now only effects MBC7 games
Editor, Reviewer, Skilled player (1358)
Joined: 9/12/2016
Posts: 1646
Location: Italy
I just found another graphical bug with GBHawk and SubGBHawk. The first 11 frames of the GBC BIOS sequence consist in a black screen. I can confirm this behavior is NOT present on any real console: GBC, GBA, GBI.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
ThunderAxe31 wrote:
I just found another graphical bug with GBHawk and SubGBHawk. The first 11 frames of the GBC BIOS sequence consist in a black screen. I can confirm this behavior is NOT present on any real console: GBC, GBA, GBI.
Fixed in master.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
Gensan 2 continues to provide challenges for console verification. http://tasvideos.org/userfiles/info/66301728356726713 Here is a file for gambatte (2.4.2) that desyncs on console on the second boss in a deterministic way. I have confirmed a version in GBHawk matches this run cycle for cycle in the boss area. GBHawk has an IRQ priority issue that is fixed in my local build that made it desync in a different way, but once I fixed that it syncs to the end of the game just like Gambatte. So there is some un-implemented behaviour in both GBHawk and Gambatte that is causing desync on actual hardware. I didn't see any uninitialized RAM so I don't think that is the cause. Also in this run mode 3 timing does not seem to be the issue (at least to the extent testable.) Currently I don't have any idea why this desyncs.
RetroEdit
Any
Editor, Reviewer, Player (169)
Joined: 8/8/2019
Posts: 152
Alyosha wrote:
Here is a file for gambatte (2.4.2) that desyncs on console on the second boss in a deterministic way.
Does that file sync in 2.5? Gambatte was updated in 2.5.
Emulator Coder, Judge, Experienced player (729)
Joined: 2/26/2020
Posts: 781
Location: California
RetroEdit wrote:
Does that file sync in 2.5? Gambatte was updated in 2.5.
Playing through the movie in 2.5, it appears to desync, so there's probably a good chance the cause of the console desync is fixed in 2.5?
1 2
14 15 16
19 20