Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Game: Avenging Spirit (USA/Europe)
Emulator: BizHawk; Gambatte in GBA mode
Console Verification Device: Gameboy Player with GBI
Movie: http://tasvideos.org/submissions/6943.zip
Description of Desync: On emulator, the player character beats the second boss. On console, the player character fails a jump to avoid the crusher in the second boss' room, resulting in a Game Over.
Research: Adding 1 frame before the second boss fight results in emulator having the same desync as console. 2.5.2 and 2.5.3 dev have the same result. A resync on GBHawk desyncs at the beginning of the first stage.
Possible Next Steps: ?
Status: Closed
Resolution: Adding 1 audio sample to the GBA->GBC offset and changing the floor to a ceiling resulted in successful sync.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
> glitchless
> Attempted to get fastest possible score
???
So why glitchless? I really don't see how forgoing any SMB glitch actually makes the TAS more enjoyable. Although I'll refrain from voting until an encode is up.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
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.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
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
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
> Super Game Boy 2 ROM image
> HLE
HLE SGB emulation (ie Sameboy core in Bizhawk) doesn't take those ROM images at all. (Not like it would be strictly required for this to work, nothing within the ROM image is needed for the link port to work)
Also why would this be added to Bizhawk when the cores are super outdated? And even they're waterboxed so lol
Don't know why you would do this anyways, not like there is really much reason to TAS in SGB mode, let alone TASes that use the link cable.
(non-rerecording emulators can already do this anyways if you aren't looking to TAS something with this)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Bizhawk doesn't have that functionality yet. That's an open issue on Github so it'll be done eventually. If you don't care about re-recording features, you can use upstream mGBA (which is able to disable RTC).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Tremane wrote:
on Gameboy it also works with A+B+Start+Select at the same time (might not be the reset you want though)
That's the typical combination for a soft reset (which not all Gameboy games actually implement anyways, and they might even have some different combination), and Yellow save corruption requires a hard reset.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
By default TAStudio hides the Power column, which is used for hard resets. This can be changed by simply going into the Columns tab and clicking Power there. Note for traditional TASing, hard resetting is only possible in Gambatte; (Sub)GBHawk must go through TAStudio to do a hard reset.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Can I ask if playing a CGB game on the GBA game counts as "pseudo-emulation" and should that be disallowed for nearly all cases? For nearly all CGB enhanced games, there isn't any enhancements for the GBA, so by this logic nearly all CGB games should not be allowed to use GBA mode for the sake of console verification.
Also "pseudo-emulation" would really be closer to something like the Analogue Pocket, claiming the CGB has "pseudo-emulation" of the DMG is really like saying the SGB has "pseudo-emulation" of the DMG, or maybe saying the DS has "pseudo-emulation" of the GBA, or maybe even the Wii having "pseudo-emulation" of the Gamecube.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
haha no just keep it the same
(totally not saying this out of laziness considering much of the movie would have to be redone to actually have that work lel)
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Are you sure this updated movie file has the right cycle count? The sync settings were not changed to account for cgb in gba handling being changed from 2.5.1 to 2.5.2, so I'm suspecting the cycle count was off simply because the wrong bios was used.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Nach wrote:
Those features, not that I know of. But SGB games have other improvements like better sound via the SNES. I think we may have had a run or two which did that, but I could be mistaken. Donkey Kong on an SGB has the game adjusting the color throughout, and AFAIK, does this better than a CGB, and has better sound, it baffles me the game was submitted using CGB.
Are we talking publications or submissions? Publications this can't apply considering every SGB TAS published used VBA's SGB mode (and on that note the last SGB publication was 7 years ago lol).
Also, even then you then have to realize the current SGB emulation available to TASes is really... outdated. Sameboy/BSNES on Bizhawk? Outdated as fuck, hasn't been updated to upstream in a long time. lsnes has better SGB emulation, and even then it's still fairly outdated and misses out on a ton of emulation updates from upstream. And even then I have no idea if the SNES sound emulation thing is even emulated for lsnes, or if it is on Sameboy/BSNES for that matter.
Also, the rules at its current moment are kinda guaranteeing DMG will obsolete SGB, as SGB enhancements add a ton of lag to a game and easily allows DMG to beat SGB in framecount. This lag is also why SGB is generally not ever used in RTA, except for games that don't even have SGB enhancements (where this added lag doesn't apply).
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
warmCabin wrote:
A 1-byte checksum? It's free real estate!
I'm not sure I fully understand this, though. Was a checksum collision not necessary before to get the game to load a corrupted file?
It was not, due to the way the game decided to save. The game saves different chunks of data, and notably separates party data from the main data. And after saving every chunk of data, it proceeds to calculate the full checksum and write it every time... which already appears to really bad. Then it gets worse when you realize that after the main data is saved, the game proceeds to save box data (which is not checksummed) before saving party data... which leads to haha nice 4 frame window for corruption humans can trivally hit.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
feos wrote:
I have a different question. For GB games that are supposedly not supported explicitly by GBC, it still somehow assigns colors in a meaningful way, it's not an utterly random mess. How is this determined on the hardware level? It's not full-color like actual GBC games are, but still looks sensible. Are there also GB games that have completely wrong colors assigned in the GBC mode?
It's software and hardware.
For the hardware side, you somewhat need to understand how colors work on the DMG and CGB. For the DMG, the background map, sprite palette 0, and sprite palette 1 are all assigned 4 colors... with those four colors being black, white, and 2 shades of gray. These are all technically separated, and colors can be swapped around (albeit it's limited because you're only really swapping around the 2 shades of gray).
However, for CGB enhanced games, this isn't used at all. For those games, the CGB allows full on colors with the background map and sprite palettes 0 to 7, and uses different registers for this.
But as I've said, this is for CGB enhanced games. Whether a game is CGB enhanced depends on what its header reports. If the header reports CGB enhancement, then the bootrom will boot the GBC normally and will use its standard coloring system.
But if the header reports the opposite, the bootrom instead boots the GBC into DMG compatibity mode, which along with locking out GBC only features (like double speed mode), it will also revert its coloring system to essentially the monochrome system the DMG has.
The bootrom will however actually assign actual colors to what would be shades of gray. And as I've said, the background map and sprite palette data 0 and 1 are all separated, so the bootrom is happily able to assign the grays for each of these with different colors (which is where some graphical issues might come from, since games might swap around the background and sprites around, which doesn't go that well).
For how the bootrom assigns colors, it's either with user input or the header. If the user doesn't do any input to change palettes on the bootrom, then it's determined by the header. (edit: I have no idea how it determines it via the header lol)
For user input, you can use a directional (or a directional + A or B) to choose palettes, resulting in 12 different combinations that can be choosen. This user input also happens to be a nice fix for any game that might have some weird palette on it, as the user can easily override whatever the bootrom is choosing from the header. There are also some palettes (like grayscale) that color the background map and sprites the exact same, which can also be chosen to avoid graphical issues.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
ThunderAxe31 wrote:
This is really interesting, thanks for your contribute! I need to ask you some questions about that:
How hard it was to figure out what each game expects/prefers as an empty state SRAM?
After having looked this much, do you think there could be any game that could be hard to figure out in that regard?
Do you think, at this point, that it would be more accurate and more functional for the GB/C emulators to initialize SRAM as 0x00 bytes, instead than 0xFF?
1. It's really not that hard to find, usually it's just putting a write breakpoint at A000-BFFF with no actual save file which the game will respond with some for loop writing 00 bytes.
2. It could be tricky in regards to games that might clear some part of SRAM for scratch/stack/etc, but if you can point the for loop coming from a failed sentinel value and/or checksum check then it's fairly obvious what the intent is.
3. No, it wouldn't. While FF essentially guarentees that both a sentinel value and checksum check would fail, 00 really only guarentees the former to fail, while the latter will actually very likely pass. Which if some game for some dumb reason only uses a checksum (eg DKL3), that might end up having issues.
Really, these patterns you see when yoinking out the battery of a cart would likely be better than the current system, but that does raise some interesting questions for determinism.
But then again bsnes has a randomized ram state so that argument of determinism is probably also bs, I guess it would be somewhat annoying for console verification... but then again not really lol
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
Alyosha wrote:
The test speed_change_cancel.gbc expects a speed change (which uses STOP) to be exited if a button is pressed even though joypad interrupts are not set in register FFFF. Maybe this is only for speed change, but not sure.
1. This is a DMG game, speed change is locked out.
2. Button press exits stop mode, interrupts don't have anything to do with stop.
EDIT: For the joy_interrupt, the differences in the behavior (ie switch bounce) are really just due to how the buttons are hooked onto the system, if someone were to theoretically make some tasbot for the DMG, it would not have the effects of switch bounce (the same would also apply if you manage to hook a keyboard or some other controller to the DMG). Also looking at that test, it 0's out rP1 regardless, which as I've said allows button presses to go through lol
I guess in the end this is overall moot. Movie doesn't work on console or updated emus, so it can be obsoleted by nameless branch.
Emulator Coder, Experienced Forum User, Judge, Published Author, Experienced player
(609)
Joined: 2/26/2020
Posts: 698
Location: California
So I should of posted this sooner. But I'm going to have to give some bad news. This TAS abused an emulator bug, and is therefore invalid. The bug in question is regarding the stop opcode. This opcode puts the GB into "stop mode" and this mode can only be exited with a button press (and this button press needs to be seen by the cpu). This is impossible as bits 4 and 5 of FF00 would be set (and this can be verified looking at the tracelog a bit further back than what is provided in this submission). Old gambatte code was broken and did not follow this at all, and this submission happens to abuse that broken code.
I guess as the author points out, it would be possible to avoid the stop opcode, however from my testing it seems like a completely different setup would be required for this to work in the end, so a completely new TAS would be needed to properly do the game end glitch without freezing at stop. I guess the nameless branch can probably obsolete this branch, at least until someome figures out an actual valid use of this ACE.
