Oh cool another de-sync, looks like maybe another bad VRAM access? Maybe we can learn some more about this glitch. Hopefully I can look into this weekend. Thanks for letting me know.
EDIT: After resyncing the run to GBHawk and getting back up to that point, it's definitely the end of line VRAM glitch.
It was pretty easy to get a similar desync after I upgraded GBHawk's emulation of the glitch, but I didn't get the exact same thing.
It looks like the critical details are in emulating the glitch correctly when the PPU is doing the first accesses for a a tile. When doing this it accesses 2 regions of VRAM at once. The returned value in this case is what we need to find.
I made some modified versions of the existing test to see if I could narrow things down at all, but it was just more confusing. I'll look at it in more detail this weekend when I have more time to sit down and think about it.
I made a modification to the vram_reads_eol test ROM by changing the byte written to the upper part of VRAM to CC instead of 33. This was the only change I made to the ROM.
The results from my GBP are much different then expected. No 00 for the first read, not sure where 22 comes from exactly.
I think this is something that needs a comprehensive, and possibly even interactive, test ROM to get the full details of what is happening.
EDIT: After resyncing the run to GBHawk and getting back up to that point, it's definitely the end of line VRAM glitch.
It was pretty easy to get a similar desync after I upgraded GBHawk's emulation of the glitch, but I didn't get the exact same thing.
It looks like the critical details are in emulating the glitch correctly when the PPU is doing the first accesses for a a tile. When doing this it accesses 2 regions of VRAM at once. The returned value in this case is what we need to find.
I made some modified versions of the existing test to see if I could narrow things down at all, but it was just more confusing. I'll look at it in more detail this weekend when I have more time to sit down and think about it.
While I do not understand the glitch, the fact you managed to resync the run up to that in 3 days is incredibly motivating. Thanks a lot for the work and good luck!
While I do not understand the glitch, the fact you managed to resync the run up to that in 3 days is incredibly motivating. Thanks a lot for the work and good luck!
Resyncing only took about an hour, but unfortunately I also don't understand the glitch, so I can't really go any further right now. I could make the dev build output a message whenever you encounter the glitch (if you wanted to continue in GBHawk), and can therefore simply avoid it, but that's the best I could do at the moment.
While I do not understand the glitch, the fact you managed to resync the run up to that in 3 days is incredibly motivating. Thanks a lot for the work and good luck!
Resyncing only took about an hour, but unfortunately I also don't understand the glitch, so I can't really go any further right now. I could make the dev build output a message whenever you encounter the glitch (if you wanted to continue in GBHawk), and can therefore simply avoid it, but that's the best I could do at the moment.
Sorry for the late reply; I haven't checked forums in a while. That would be helpful; is this detectable using lua btw? Thanks very much!
Not detectable with LUA.
In the dev build now, any time you encounter the glitch it will show up as "VRAM Glitch" followed by a bunch of number in the console log.
I was able to avoid the glitch in the room where it desynced on console and made it to the next level:
http://tasvideos.org/userfiles/info/67272359711138584
Unfortunately I got stuck there and wasn't able to easily fix it from there, but I don't actually know what I'm doing with that OOB stuff so maybe you can do it easily.
The glitch still happens in the early parts of the run, but that's already verified to work right on console so no problem there, just be aware that in any other parts of the run that you see that message pop up, there is no guarantee it is being emulated correctly (I'm pretty confident the timing is correct, just not the results.)
Also remember to set 'Read Domains on VBLank' to true so your script works.
Not detectable with LUA.
In the dev build now, any time you encounter the glitch it will show up as "VRAM Glitch" followed by a bunch of number in the console log.
I was able to avoid the glitch in the room where it desynced on console and made it to the next level:
http://tasvideos.org/userfiles/info/67272359711138584
Unfortunately I got stuck there and wasn't able to easily fix it from there, but I don't actually know what I'm doing with that OOB stuff so maybe you can do it easily.
The glitch still happens in the early parts of the run, but that's already verified to work right on console so no problem there, just be aware that in any other parts of the run that you see that message pop up, there is no guarantee it is being emulated correctly (I'm pretty confident the timing is correct, just not the results.)
Also remember to set 'Read Domains on VBLank' to true so your script works.
Sorry for the late reply, but thanks very much! Now I'm curious what other games have this bug, and what non glitch scenario would it occur.
I'm using BizHawk 2.5.2.
How exactly is GBHawkGambatte tracking RTCs? Time seems to progress far too quickly to make any sense.
- <1 minute of in-game and movie time: Monday, 3:52AM (set manually at this point)
- properly at ~28000 frames, Monday: 4:00AM (~28000 frames being roughly 8 minutes)
- 18 minutes of in-game and movie time: Monday, 12:30PM
- 36 minutes of in-game and movie time: Thursday, 3:19 AM
What's going on here? The game is Pokemon Crystal. I had to set the clock to Monday at the start of the run for a specific item, and the time was important too, but the timer is going far faster than I can ever reach the item where Monday is necessary.
EDIT: I am using Gambatte, not GBHawk.
It keeps track of RTC one cycle at a time. Seems to be working fine to me (I just tested 2.5.2 and master.)
If you can upload a movie where things are getting messed up I can take a look at it.
Did I miss something, I don't think it's possible to launch Ninja Spirit Game Boy on GBHawk or Gambatte?
Oops I missed this comment. What kind of error are you getting? What is the hash you have for the game? Ninja Spirit looks like a standard game it would be very unusual for it to fail in both cores.
It keeps track of RTC one cycle at a time. Seems to be working fine to me (I just tested 2.5.2 and master.)
If you can upload a movie where things are getting messed up I can take a look at it.
Alright. This is off of a minor ROM hack (one that shouldn't alter how the RTC works at all) so I'll include the .IPS file too.
https://ufile.io/4rqj72ct
Included are three movie files.
- Part 1 starts the game and sets the RTC. By the end of part 1, the RTC is advancing far too quickly in comparison to movie/in-game time (I combine them because they're a similar enough metric right now).
- Part 2 begins right as Part 1 ends, already on an accelerated time. By the time Part 2 ends, it's now *Thursday*, implying some three days have passed for only 36 minutes of tracked gameplay.
- Part 3 is just me loading the game to see the time at the end of Part 1.
I also feel the need to correct myself in case GBHawk isn't actually the same programming (and I believe it isn't or it wouldn't be a differently named core)---I use the Gambatte core, not GBHawk. I find this very odd as Gambatte is supposed to be nearly flawless in cycle accuracy?
EDIT: Fixed the upload, one of the movies were incorrect.
Part 1 ends at 4:10-4:11 AM Monday for me, seems correct.
Part 2 appears broken, it loads from SRAM and immediately desyncs.
No idea how you are obtaining the results you describe, I can only recommend grabbing a fresh version of 2.5.2 and trying again (and when doing so do not use any old files, start fresh exactly as it is in the zip file.)
EDIT: part 3 says it's wednesday 7:59 am
Well, with a completely fresh one, it doesn't remember the RTC being set.
1: I downloadeded the Windows Binary for BizHawk 2.5.2 from this post: http://tasvideos.org/forum/viewtopic.php?p=500247#500247
2: I played the movie files on an American copy of Pokemon Crystal patched with the provided .ips.
3: Movie file 1 is 68058 frames. At frame 68058, I click Stop Movie, then load Movie file 2.
4: When Movie file 2 is loaded, it doesn't remember there being an RTC setting and asks me to redo it.
So let's try doing this with the same vanilla/fresh download, but with the GBC bios added.
1: I downloadeded the Windows Binary for BizHawk 2.5.2 from this post: http://tasvideos.org/forum/viewtopic.php?p=500247#500247\
2: I add the GBC bios to the Firmware folder.
3: I played the movie files on an American copy of Pokemon Crystal patched with the provided .ips.
4: Movie file 1 is 68058 frames. At frame 68058, I click Stop Movie, then load Movie file 2.
5: When Movie file 2 is loaded, it doesn't remember there being an RTC setting and asks me to redo it.
I have no idea why it's not remembering the RTC now?
Movie file 2 only starts from SRAM. It does not know what the internal state of the clock should be.
Try using the 'From Now' setting when starting recording for movie 2 instead.
The RTC is only an internal state to Gambatte, it doesn't actually use any real world RTC (not in BizHawk anyway by default), so whenever you reset the emulator core, the state is lost.
I believe older versions had an option to use real world RTC, but not sure how reliable it was. EDIT: actually the setting is still in Gambatte, try setting Realtime RTC to true, not sure it actually works though.
EDIT: also just so you know, if you want console accuracy you have to record movies using the official BIOS (you can enable it in the settings), the homebrew ones used by default will not result in console accurate RNG, and are for casual play only.
I am going to assume when you save "doesn't remember RTC being set" you mean GSC's "TIME NOT SET" message. This isn't the game forgetting RTC was "set" but rather the Day Counter in the RTC went over 16383.
Also, the RTC is never actually "set" by the game. The RTC does not really have any concept of which hour it is, or what day of the week it is. The RTC is just a counter that ticks up, and has seconds, minutes, hours, and days, although again, it's only counter so it essentially starts from 0 in all these and just counts up. When you set the time in the game, the game simply stores the "StartTime" (this start time is just the time selected minus the elapsed RTC, so adding the elapsed RTC with this start time will result in the time selected). This is part of the save file, so it won't just forget the StartTime (barring save corruption which doesn't seem to be the case here). And if RTC were to somehow reset back to its default state (for Gambatte that would be all 0's iirc), then the game would report the StartTime as the current time, and wouldn't go to the "TIME NOT SET".
Even then RTC data is appended to the SaveRAM, although iirc it is essentially just some Unix timestamp, and Gambatte is supposed to fudge that into cycle based RTC, which to work, it will take into account the time passed since that save file was made (assuming behavior is the same as upstream), while this idea is fine for casual use and RTA (although even then it's broken anyways lol), it does not work at all for syncing movies lol
Movie file 2 only starts from SRAM. It does not know what the internal state of the clock should be.
Try using the 'From Now' setting when starting recording for movie 2 instead.
The RTC is only an internal state to Gambatte, it doesn't actually use any real world RTC (not in BizHawk anyway by default), so whenever you reset the emulator core, the state is lost.
I believe older versions had an option to use real world RTC, but not sure how reliable it was. EDIT: actually the setting is still in Gambatte, try setting Realtime RTC to true, not sure it actually works though.
EDIT: also just so you know, if you want console accuracy you have to record movies using the official BIOS (you can enable it in the settings), the homebrew ones used by default will not result in console accurate RNG, and are for casual play only.
I figured SRAM was more reliable for segmented gameplay since it's off of a fresh reset instead of continuing on a very lengthy singular movie.
From Now, does it make a save state for future playback for where "Now" is? I don't record a video of my runs until they're done since I often go back to a previous part if I found a better path/etc.
@CasualPokePlayer
That's very intriguing. I thought that message meant it can't save the time, not that it did but too much passed.
I also had no idea that's how time is stored. So for a single-segment run, things would work perfectly fine under how Gambatte handles it, but for segmented ones, Gambatte falters? Does GBHawk handle time differently? Or do I need to alter my PC's clock whenever I start a new segment?
EDIT: I've checked my BizHawk 2.5.2 folder and setup. I am indeed using the official BIOS, but apparently Gambatte doesn't show the "GAMEBOY..." white screen before the game starts? GBHawk does. Is GBHawk more accurate or would this not really matter as far as that goes?
Ok minor correction, it's not the day counter going over 16383 (that was bullshit coming from pokecrystal comments), rather it can only occur in two cases: the day count exceeded 511, or the halt flag is set. It's likely the first option since Gambatte's RTC handling is known to be broken in these cases.
Anyways, just using "from now" should be an okay fix (also assuming you never hard reset because that's fucked lol), or just using GBHawk (whose RTC isn't broken in these cases anyways).
Also, on the BIOS... wait where is the ... in "GAMEBOY..." coming from? The CGB only has GAMEBOY in its BIOS. I guess assuming in case I'm looking too deep into this, I would have to guess Gambatte is still using the homebrew bios, and you didn't tick the setting to change that (and note that your recorded movies will just follow the sync settings stored in them, so if they are made with the homebrew bios they will use the homebrew bios when you play them unless you manually edit the sync settings in the movie file). Really tho, it doesn't matter in the end as I'm guessing this isn't meant to be submitted and/or console verified.
Ok minor correction, it's not the day counter going over 16383 (that was bullshit coming from pokecrystal comments), rather it can only occur in two cases: the day count exceeded 511, or the halt flag is set. It's likely the first option since Gambatte's RTC handling is known to be broken in these cases.
Anyways, just using "from now" should be an okay fix (also assuming you never hard reset because that's fucked lol), or just using GBHawk (whose RTC isn't broken in these cases anyways).
Also, on the BIOS... wait where is the ... in "GAMEBOY..." coming from? The CGB only has GAMEBOY in its BIOS. I guess assuming in case I'm looking too deep into this, I would have to guess Gambatte is still using the homebrew bios, and you didn't tick the setting to change that (and note that your recorded movies will just follow the sync settings stored in them, so if they are made with the homebrew bios they will use the homebrew bios when you play them unless you manually edit the sync settings in the movie file). Really tho, it doesn't matter in the end as I'm guessing this isn't meant to be submitted and/or console verified.
511? Interesting. I've seen the "TIME NOT SET" message appear from legitimate players too who were doing a certain challenge that requires the first part have 400-something days pass... I had absolutely no idea that's why.
I'll remember that from now on (ha) regarding From Now. As long as it works the way I want it to, to resemble a reloaded savefile (and it should since a soft reset does everything a hard reset does), I don't really mind.
I'm not aiming to submit it at all and although console verification is neat, I have no means to do that or record it. I'm just very particular when I upload runs of games, usually niche runs and stuff, that it's as accurate to the real games as possible and that no strange emulation glitches appear and that's why something happened/etc. I don't have a capture card but I like to upload stuff and although I can't play like other people do on real devices I want to make sure it's gameplay accurate.
https://i.imgur.com/iFfgpsL.png This is what I meant for the "GAMEBOY" message, sorry for adding the ellipsis. It only appears when I use GBHawk though, even though the Config menu says no matter what core I am using that it's finding the BIOS.
If you want to see the gameboy screen in Gambatte, you have to go to GB->settings->enable official nintendo bios and set it to true. Then reboot the core. Then you can start recording a new movie and the bios screen will show up.
You can reference a table key name with a space in it like:
local tbl={}
tbl["P1 A"]="true"
Or whatever. I didn't test this. But any table key name can be used as a string inside square brackets.
Did I miss something, I don't think it's possible to launch Ninja Spirit Game Boy on GBHawk or Gambatte?
Oops I missed this comment. What kind of error are you getting? What is the hash you have for the game? Ninja Spirit looks like a standard game it would be very unusual for it to fail in both cores.
The game just doesn't start for me, I don't have any specific errors.
I didn't check if there was something specific in the log window.
I made a modification to the vram_reads_eol test ROM by changing the byte written to the upper part of VRAM to CC instead of 33. This was the only change I made to the ROM.
The results from my GBP are much different then expected. No 00 for the first read, not sure where 22 comes from exactly.
I think this is something that needs a comprehensive, and possibly even interactive, test ROM to get the full details of what is happening.
