Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I can't reproduce this. Either delete the config.ini file in your bizhawk folder or just start from scratch with a new download. If that doesn't help, try some older versions and see if they work. 2.3.2 an 2.4.2 are pretty stable versions to try.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Most likely you accidentally started it from a savestate, in which case there isn't much that can be done about it.
bk2 movies are just normal compressed files that can be opened with something like 7zip or whatever utility you like. Open it up and look in the header file, if it says something like 'starts from savestate' then that's why.
Whenever you record a movie, make sure you select 'power on' and not 'now' if you don't want this to occur.
You would need to add more specific details and exact reproduction steps for us to be able to look into this further, I've never heard of this problem before.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Cioss wrote:
Can anyone help, It's a pain to have to wait constantly beczuse I made a mistake or because I have to check if it works. And turbo seek doesn't help either. Before, it didn't do that and it simply didn't seek at all only when going backwards.
I have also had this problem, but unfortunately I can't reproduce it consistently, so I haven't been able to figure out a fix.
As a workaround, whenever this is happening to you, reset the greenzone by adding and then removing a random input at the start of the movie. Then once the movie plays back up to where you want it to it should work fine from there.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Game: Warioland II (USA) (GB Version)
Emulator: BizHawk: Gambatte (but also behaves similarly in GBHawk) in GBA mode
Console Verification Device: Gameboy Player with GBI
Movie:http://tasvideos.org/userfiles/info/67631410422598803
Description of Desync: On emulator, player character beats the level using out of bounds at ~ frame 50000. On console, there is a desync in the out of bounds section and the level does not complete.
Research: This is a case of trying to read VRAM on the same cycle it is released by the ppu. This is not emulated correctly and currently the details are not known.
Possible Next Steps: This needs an exhaustive test ROM.
Status: Open. The current work around is to simply avoid the glitch, which is cycle exact so is easy to avoid with irrelevant button presses
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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 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.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I recently fixed a couple bugs in movie recording where it was possible to record inputs to the movie file while not sending them to the core.
If anyone is able to test the dev build and make sure I didn't introduce any other issues accidentally at the same time I would very much appreciate it.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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
(3536)
Joined: 11/30/2014
Posts: 2733
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.
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.