Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
phoenix1291 wrote:
Alyosha wrote:
phoenix1291 wrote:
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
phoenix1291 wrote:
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
jlun2 wrote:
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I'm pretty confident in single speed mode at this point. There are some edge cases to clean up still but it's time to start looking ahead to double speed mode.
In preparation for that I re-synced the run of Spirou Robot Invasion to the latest dev build. To my surprise it worked on console:
http://tasvideos.org/userfiles/info/66989349617966603
The run contains some adjustments, there have been a great number of emulation changes since it was first made, but it's still almost entirely faithful to the original.
This gives me another run to check against along side pokemon TCG when I start working seriously on double speed mode pretty soon.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I tried improving my Gensan 2 run before submitting it but when I did I ran into another desync on console. This game sure is working out the bugs in GBHawk.
This one though only took a few minutes to track down (at this point there really aren't many things left that can be changed that it could be.)
The problem was in the timing of clearing interrupt flags. There's still a little room for variation in the setup I have now, but this case reduces the uncertainty down to 1 cycle.
Actually the above was wrong, the real solution is that when clearing an IRQ flag at the same time it is set in GBA mode sets it instead of clears it. This test: tc00_irq_late_retrigger_2_dmg08_outE4_cgb04c_outE0.gbc gives E4 on GBA. Before I was using the GBC04 behaviour of getting E0, which is evidently wrong at least for GBA (and likely GBC E.)
I'll still need to look over other tests to see if this breaks anything else before committing anything. Looks like Gensan 2 will wait for yet another BizHawk release.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So I think the problem with Mortal Kombat is just input resolution of GBI. On the ladder screen, the game is just spamming checks to the control register. If I change the offset built into the input script by 1 incrament, with equates to 1024 cycles at 4MHz, then Mortal Kombat syncs just fine. This also explains why TAS input syncs just fine, since I was pressing start on the ladder on the first available frame, the input was already there before the spamming started.
For now I'm not going to change the script, since I'm not entirely sure what the correct fix is (it could be only off ~200 cycles and still break the sync), but it's something I'll keep in mind.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
My goodness does this ever look like an optimization nightmare. The other run is too long for me, but 15 minutes is short enough to enjoy the level of complexity here and the thought that went into it without getting too bored. Good job, yes vote.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I think it's also worth pointing out here that over the past couple of years, several of the examples of running GB games in GBC mode and making TASes of them, with the goal of console verification, has directly lead to significant advancement in emulation accuracy. Its been good for the site, good for the pokemon people, good for emulator devs. , and really helped advance the state of the art.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
Can you elaborate why your run is slower there?
No idea, that's already way more effort then I put into comparing the runs. I'll try looking into it.
EDIT:
http://tasvideos.org/userfiles/info/66919700439251260
Here's a new file, ~120 frames faster.
Notes:
15:11.067 - fixed
18:43.767 - don't know why boss is slower, I don't know of any way to manipulate it
23:55.233 - don't know, mine cart levels are too fragile.
38:40.067 - mostly fixed, looks like some lag differences still
40:17.033 - can't fix without input file, I don't get the jumps, despite trying many times
43:47.167 - Slightly improved, but it seems like the bird section is much faster, not sure how or why, maybe less lag.
47:01.267 - don't know, Once again not sure how to manipulate a faster boss
50:40.367 - mostly fixed I think
51:52.500 - mostly fixed, but still slower, an enemy doesn't have a hitbox so I miss a boost
54:10.333 - no idea how to manipulate anything faster.
I should note that in all my different files and all the revisions I've done, boss patterns have never changed beyond 1-2 frames, and even that is probably mostly frame timing differences. I have no idea why the boss fights are slower, or for that matter why the bee fight is faster. If I'm missing something I surely don't know what it is.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I tried your suggestion, but it seemed like I always ended up losing any frames I gained somewhere else.
I did go back and save some lag on level 4 though, it added up to quite a bit. Please replace the movie file with this one:
http://tasvideos.org/userfiles/info/66897177042784615
EDIT: I tried making a console verification video of this version, kind of shaky but not too bad.
Link to video
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
EZGames69 wrote:
Was this tested on console? If so, I'd like to see the video of it.
Yes I played it back on my GBP. I don't have a capture device though, the best I could do is a poor quality cell phone video.
DJ Incendration wrote:
How is this 150 frames faster? Wasn't the previous movie a 3:41?
The previous run did not include BIOS (that's 190 frames.) Also time in VBA movies was not calculated accurately due to the way it processed loading times when the screen was off. There are ~100 extra lag frames from loading time being counted correctly in the new movie.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/66828727632451057
Here is a resync and minor improvement of this game. It is console verified. I saved a few frames in a few spots, but the last boss will need to be redone probably.
I wanted to try this game because it had a lot of interesting graphical elements to test GBHawk with. Also it is very short, a perfect combo for testing.
I'll have to put a bit more work into this before it's submittable, but it's a start.
EDIT: WIP 2, about 150 frames saved. Better movement in levels 1 and 2 saved the most time. Boss 1 was slightly improved.
http://tasvideos.org/userfiles/info/66858681884594734
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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.
There is also another test called joy_interrupt.gbc that the notes say behaves differently on GBA SP from GBC/GB.
At any rate I have tried a resynced version of this run on GBP and it doesn't work, so seems like knowledge is incomplete here.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
It sounds like you are encountering an instance of the NES DMC DMA bug. In Ninja Gaiden one this bug is dealt with by ignoring the input on the frame it occurs and using the input from the previous frame, I haven't looked at the code for 2, but if it's the same it will look like your input is lost for a frame even though it's not lag.
This is emulated in NESHawk but not FCEUX.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
It would be nice to dump some save RAM and see what actually ends up there. I tried with some games I have (mostly MBC3) and it looks like alternating blocks of FFFFFFFFF00000000 with a whole lot of junk randomly scattered about. MBC1 looked like large blocks of FFFFFFFFFFFFFFF alternating with other junk. Not sure how representative any of this is. I don't have Link's Awakening.
Probably all FF isn't too unrealistic, but anyway this is another cool demonstration of how strong save corruption is when you can reset at exactly the time you want.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
It's not like we're stuck with vague guessing, there is a run on the workbench right now that I specifically mentioned is in GB mode because of annoying sprite errors in GBC mode.
Those stray lines and Dixie's messed up sprite are a result of GBC variations.
If you look here you can see the details of one sound hardware change that breaks a game in older model GBCs, look in obscure behaviour:
https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware
There are many variations in GBC from GB, and many variations amongst different models and from GBA, even just the fact that the GBC BIOS takes less time to run dramatically changes RNG in games that don't reset the timer (ex pokemon) all other things being equal.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Made a lot of improvements to window + sprite timing and made a bunch of new tests.
Everything actually worked out pretty cleanly. The cases around 0 weren't really that bad, although I have a few more left for complete coverage.
I'll be putting all the tests I put together here:
https://github.com/alyosha-tas/Misc.-GB-Tests
This does not seem to have fixed Mortal Kombat though. I think I'll have to look closer at the serial port.
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.
Those stray lines and Dixie's messed up sprite are a result of GBC variations.
If you look here you can see the details of one sound hardware change that breaks a game in older model GBCs, look in obscure behaviour:
https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware
There are many variations in GBC from GB, and many variations amongst different models and from GBA, even just the fact that the GBC BIOS takes less time to run dramatically changes RNG in games that don't reset the timer (ex pokemon) all other things being equal.