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.
Try in Gambatte but with 'use official bios' false in the settings. If it works then you probably have a bad ROM and it's failing the logo check in the real bios.
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.
It works. Thanks very much!
Alyosha wrote:
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
I finally completed far enough of the GBC version to continue the GB run. When playing it back, I noticed that while the lag counter never rises within a stage, changing input (such as removing those pauses, which reduces lag in some cases) desyncs the run as if there's some invisible lag frames. The fact the run still somehow syncs when copying the level itself from Gambatte is kinda magical. Thanks very much for this!
Edit: I somehow managed to avoid the VRAM bug's 1st occurance by pressing select right before it happens? Pressing Select also triggers it sometimes around that spot:
The message I get normally there:
I played it in dev build and it looks fine to me. I'll try to console verify it in the next couple of days (I'll try to capture video of the last couple of minutes.) The glitch is cycle exact, so if the game takes a few extra cycles to process a button press it can change alignment and you won't encounter it.
__________________________________
I've also been making progress on double speed mode. The timing of the speed change seems right now (some of the existing tests play out differently on different revisions, so it took e quite a while to work out what is supposed to be happening and why.) Mode 3 timing tests seem to all pass as expected, so no major surprises there. LYC seems to behave differently, almost like the logic gets clocked twice as fast in double speed, but several LYC behaviours are also revision specific and this also passes all the tests so I'm going with it.
I think the only obstacle at this point is HDMA timing. This is what is currently keeping Men In Black the Series from syncing correctly.
Link to video
I had some time so I did the console verification today.
I only recorded around the time where the old one desynced.
It synced all the way to the end though, so looks like simply avoiding the VRAM glitch is the best approach for now.
I've finally upgraded GBHawk's HDMA and double speed mode timing implementation enough that Men in Black the series finally syncs on console:
http://tasvideos.org/userfiles/info/67676199274271440
Besides one obvious bug that slipped through my testing until now, the main thing I needed to understand to make this work is that HDMA only starts on the edges of instructions, similar to IRQs. Once I implemented this correctly everything worked out.
Men in Black requires pretty much perfect emulation of most of the system to sync correctly, so at this point I think I can ramp up console verification of more GBC games.
Unfortunately HDMA is something with many, many horrible edge case effects that I have so far only implemented the basics of, so there is still more work to do. As long as games aren't doing anything too crazy though I expect most of them to work. Experience has shown that this assumption is bound to fail eventually, but the implementation now is pretty robust so I should be able to sort out edge cases as they pop up.
With all of GBHawk's recent upgrades I decided to look at an untested run to see if it would now work on console. And here it is, Mega Man Xtreme, now console verified:
http://tasvideos.org/userfiles/info/67682588245482745
Here is a brief video of the last few boss refights and sigma fights. Apologies for the extremely poor quality, my phone decided it didn't like focusing anymore. I should get a capture card at some point so I can make proper videos.
Link to video
This run isn't too picky about accuracy, but it did require a resync compared to 2.5.2 so it wouldn't have worked before now.
Did I miss something, I don't think it's possible to launch Ninja Spirit Game Boy on GBHawk or Gambatte?
Checked it and it launches fine on both GBHawk and Gambatte. As a minor note, this game seems to have been hit with the same regression that affected Mortal Kombat, so on 2.4.1-2.5.2 it has graphical issues in GBC mode on Gambatte (fixed in 2.5.3 dev).
Not sure how I'll deal with that yet. The screen can't go white immediately or cinematics on some games like MiB won't work. I'll consider it low priority for now, will have to get done eventually though.
I'm making steady progress on a lot of HDMA cases and other miscellaneous timing stuff. I think the biggest weakness in overall timing right now is LY/LYC around the 153->0 transition in double speed mode. Timing of audio stuff in double speed mode also isn't that great yet, but I haven't looked at audio closely in a while so that's to be expected.
I'm going to make a few more test runs of tricky games like Wacky Racers as well and see what comes up, that has proved useful before.
If anyone has any GBC games they want to see console verified as well let me know. I think I'm going to look at the oracle of ages /seasons TASes soon also.
I fixed screen fading to white in GBC mode.
I also made a big improvement to mode 1 timing, fixes a lot of tests but doesn't seem to effect any games yet. Mode 1 isn't used that often.
I made a test run of Wacky Racers. GBHawk and Gambatte agree cycle for cycle, but the run desyncs on console with default input script. I adjusted the script so that inputs are set slightly later (about 2000 cycles at 4MHz) and then it worked fine on console. I think the problem is that the game processes input at scanline 143, very non-standard, as you'd normally expect input processed sometime into vblank. I tested a bunch of other possibilities why emulation might not be right, but it seems to be right so I'm leaving it there for now.
http://tasvideos.org/userfiles/info/67994414567448321
I resynced the Zelda oracle of ages TAS to GBHawk. The above movie will play back in the current dev build.
I have successfully console verified it as well. I recorded the last few minutes so I'll post a video tomorrow.Messed up the video so no upload. The run isn't an exact duplicate of the original, but it's correct to within a couple dozen frames, mostly just adding or subtracting a frame here and there to adjust.
This run revealed a bug in GBHawk's implementation of the ram bank register. The wrong warp at the end of the game requires a return value of 0 when zero is written, even though bank 1 is used. It also requires upper bits to read back as 1s.
This game reads uninitialized memory at start up, so I also adjusted GBHawk's initial RAM state to match an idealized version of Gambatte's to match timing a bit closer. But, the games isn't too picky about timing anyway.
I also added a setting in GBHawk to allow dumping of double speed mode games to be used with GBI.
I'll be working on the Oracle of Seasons run too, that one will probably not be done very soon though as it was made in VBA so will be much more tedious to sync. I think it will be worth the effort in the end though.
http://tasvideos.org/userfiles/info/68123456048984346
Well I tried resyncing oracle of seasons but it hit a hard desync a little over half way through the run at a mini boss. For some reason RNG advances in the middle of the fight in GBHawk but not VBA. Even if you edit the fight it will desync shortly after also due to RNG.
But that doesn't really matter, because on console it desyncs in the Hero's Cave at the start of the game. After getting the first key Link is supposed to walk over a pit, but on console he falls in.
No idea why this would be, I tried changing the input timings slightly but that just makes it worse. Oracle of Seasons seems to run pretty much the same as Ages, so not sure wy one syncs but the other doesn't.
I put the run into Gambatte as well and plays the same as in GBHawk, and I confirmed that executed cycles match between the two cores. I also dumped input from the Gambatte run and it desyncs the same way on console. I'm going to put this one in the failures for now.
I'm going to be doing a test stream of some GB console verificaitons in about an hour (11 pm eastern time) if anyone wants to watch.
I'll be doing batman return of the joker, battletoads, and maybe zen intergalactic ninja if things go smoothly.
It will be alyosha_tas on twitch.
Thanks to everyone who watched the test stream / gave helpful advice.
Here is a repo of the input timestamp files I used, I'll be adding more as I get more organized: https://github.com/alyosha-tas/GBI_timestamps
I'll link this in the opening post too.
Also I did some more research on oracle of ages / seasons. Seasons was randomly syncing occasionally despite not properly clearing RAM, so I went back to Ages to see if maybe I missed something.
It turns out that when I was verifying ages I was writing 0 to SRAM before playing the game, not 0xFF. Desptie this fact, I played the run on console several times this way and it always synced. In emulator though, 0xFF was written. If I tried writing 0xFF to the game, it now desyncs on console. How can that be?
Ages reads several areas of unintialized RAM in order to set start up values. So, it must be that the initial state in GBA mode is different then in a CGB, so that the error in the time spent clearing WRAM cancels out the error in the time spent clearing SRAM when it is 0xFF. As unlikely as this sounds, it's basically the only variable that can change.
I tried a few different possible initial RAM states, and indeed there are some possibilities where the difference in cycles executed after initial startup is only a few hundred cycles.
So I think we really need a dump of WRAM from a GBP to see what it actually is.
Ambassador, Moderator, Site Developer, Player
(155)
Joined: 3/17/2018
Posts: 358
Location: Holland, MI
I would be more suspicious that the cart battery isn't holding since it sometimes will work anyway and settle into FFs, but doesn't always work that easily.
I would be more suspicious that the cart battery isn't holding since it sometimes will work anyway and settle into FFs, but doesn't always work that easily.
I tested the battery on my Ages cart and it holds zeroes when I write zeroes.
https://cdn.discordapp.com/attachments/183641696788152320/751870160398319727/urmomhahaxd_.sav
Here's a dump of GBP WRAM I did some time ago (around the time of DK94 verification). Note for this, WRAM bank 2 is init by the bios, so you can ignore that part. Also note that additional dumps do, of course, indicate some randomness with uninit WRAM.
Also, I discovered around the time of this research that all of WRAM will be written with 00s if the GBA bios is played (ie, what happens if you boot a GBA without a cart inserted). That should be something to note for the TAS (from personal tests, the games seems to desync if I 0 out WRAM like this).
Also also, I checked the game on reading unit SRAM, and the issue is indeed 00s. The game has two guards against save corruption: a checksum, and a sentinel value. For whatever reason, this game decides to check the checksum first, then check the sentinel value. And the checksum is literally just the 16 bit sum of all the bytes in the save file, so a 00 filled SRAM will make this checksum pass, although it will fail on the sentinel value check. Still, the cycles are bumped, and the game does use the timer interrupt, so it would be expected that this will eventually desync.
Interesting, so definitely not the pattern like CGB, basically random junk. I'll do some more testing.
Also, it seems like RAM bank automatically gets set to 1 on he write to FF50. I was only doing this on GB compatibility mode, but Gambatte seems to be doing it in CGB mode too, that is probably also important.
Huh, I guess I confused myself somewhere along the way.
Anyway, I changed GBHawk to just set initial WRAM to 0xFF in GBA mode, since the game seems to check for 0 which is unlikely in most bytes from that dumped file.
This gives sync on console that is now actually consistent with emulator when writing 0 to SRAM. So looks like problem solved there.
I'll make a new movie for Ages and a new test for Seasons with writing 0xFF to SRAM now since that has been the standard.
I'll be doing another stream at alyosha_tas today at 10:30 eastern time.
Runs will be Men in Black the Series, Spirou Robot Invasion, and Megaman Extreme.
Also I updated the movie file in the opening post for oracle of ages to work in the dev build. Now it is consistent with console when writing 0xFF to SRAM. I'll try Oracle of Seasons again over the weekend, but I'm pretty sure the new initial WRAM state should solve the consistency problems there as well.
I tried working on Seasons again. The initial desync was due to me improperly clearing SRAM, so I closed out the post in the de-verified thread about that one. I also got by the RNG desync that was stopping me before. The bad news is that the run deterministically (or at least the 2 times I tried) desyncs on console about half way through (~190000 frames in.) I tried changing WRAM initial state to reproduce this, I can get runs that desync at about ~100000 frames in, but not this exact desync. I would still guess some initial RAM value is causing the problem, but I don't want to spend forever figuring out exactly which one.
I'll probably finish resyncing a run that at least will work in 2.5.3, even though it won't work on console, then move on, there's too much other stuff to do.
I'll be streaming again at alyosha_tas at 10 pm eastern time tonight.
Runs will be Oddworld 2, Kwirk, Super Mario Bros Deluxe (any% and You vs Boo)
I don't think I ever posted the resynced Oddworld 2 run, it's still in gambatte just now it works in 2.4.2 and doesn't use equal length frames: http://tasvideos.org/userfiles/info/67165593974849577
The message I get normally there:
