Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
Coincidentally I just attempted SMB3Mix and SMB3 Ridley X Hack 6 earlier today. Both desynced after several minutes. Think the former reached about 8 minutes in.
Ahhh, too bad. I was kind of hoping to just be able to knock all these SMB3 hacks out easily, kinda disappointing.
Back to the testing grind.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
I haven't had much luck with Mario 3 rom hacks so far. Super Orb Bros desyncs in NESHawk, and I can't seem to fix it. Super Sheffy Bros desyncs on console, in a consistent way at the start of the pyramid stage.
So, out of curiosity I put Batman on the dev boarrd, to see if it would desync in the same spot as the original cart. It did in fact desync in the same way. The original uses MMC3A, and my dev board uses MMC3B, so this confirms that it's not a revision dependent thing.
Currently I have no ideas what the issue is, and I can't imagine what edge case Sheffy Bros encounters that much longer SMB3 runs do not.
Maybe I'll take another look at MMC3 clocking.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
GJTASer2018 wrote:
Alyosha wrote:
The first game I tried to verify was actually Extra Mario Bros, but that game doesn't work on console because it doesn't set the mmc3 bank before jumping to 0x8000.
Has this been reported to the hack creator so that they have a chance to fix it on their end instead of you having to jury-rig something to get a console verification?
Well I can try to contact ATA on romhacking.net, but at any rate there is a convenient row of 0xFF in the last block that I can edit to easily fix the banks.
Superfast Mario 2:
Link to video
I'll try some Mario 3 hacks next.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
Link to video
After many failed attempts at soldering the mmc3 chip, I finally got it working and verified my first mmc3 game, Indivisible. The first game I tried to verify was actually Extra Mario Bros, but that game doesn't work on console because it doesn't set the mmc3 bank before jumping to 0x8000. Maybe I will hack the hack to get it to work properly on console. This took me a lot of time to figure out because I was also struggling with the mmc3 soldering at the same time. I also toasted one of my mmc3 dev boards in the process, but I'll count that as climbing the learning curve, oh well. In the end though it's cool to have a mmc3 dev board working, now I can verify a bunch of mario rom hacks (assuming they don't make the same mistake Extra Mario Bros does.)
I also put together an MMC1 dev board, but the only game I found that actually uses it, SMB 35th anniversary edition, desyncs on console due to uninitialized RAM. (Mario gets hit by a cheap-cheap in 3-2.)
I think for NES now the biggest capability I am missing is mapper 30 (NESMaker) but I'm not sure when I'll get to it.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
After a lot of additional testing, I believe I finally have a complete implementation of the LDM^ glitch. Implementing this involved basically having an extra copy of the entire ARM mode code path for the cpu to execute when the glitch is activated to avoid performance penalties, but aside from that it wasn't that bad. The glitch is somewhat simpler than originally thought, as it really just amounts to OR'ing regs together in certain instances, there are no cases of both banked and user mode reg's being written to at the same time. Also the STM* version does not seem to trigger the glitch.
With that done I can start thinking about how to properly fix the mGBA suite background test.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
Link to video
I made a recording of a test rom that checks the power on ram state of the nes. My console is pretty consistent in terms of the overall pattern of 00's and FF's, but is pretty noisy between trails and many bits change between 0 and 1 randomly.
My results don't seem to match what others have mentioned ex. on nesdev, but that's not surprising.
EDIT: rom from here: https://forums.nesdev.org/viewtopic.php?t=13334
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
GJTASer2018 wrote:
Alyosha wrote:
In the next few weeks I'm hoping to have MMC1 and MMC3 dev boards up and running. A lot of recent homebrew use those.
Is there a particular reason why those dev boards seem to be in fashion for homebrewers these days?
I think it's just a combination of rom hackers / homebrewers becoming more skilled and having access to modern tools and techniques that make it easier to make full use of the chips. People come up with a lot of cool ideas and there's only so much you can do with the 32k prg and 8k chr that nrom gives you. MMC3 gives you 512 prg and 256k chr and a scanline interrupt with minimal overhead.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
I'm slowly building dev boards to continue hardware research and console verification efforts. I get my boards from mouse bite labs: https://mousebitelabs.com/ pretty cool stuff!
I now have a cnrom board, so I verified Bob-omb Mario by HappyLee:
Link to video
This was simple in terms of verification but it's the first new capability I've added to my verification tools for NES in a long time.
In the next few weeks I'm hoping to have MMC1 and MMC3 dev boards up and running. A lot of recent homebrew use those. Some interesting new test ROMs have come up recently that use boards other than nrom as well.
Still looking for something to point me in the right direction on Batman, more verifications means more chances to find something new.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
So the input I missed adjusting was around frame 8300 at the wiggling back and forth part while waiting to get dropped down the vent. Evidently this doesn't change RNG all the way up until the room where the enemy drops bombs to drop through the floor at the bottom of the stairs at frame 21710. At least for small changes.
I noticed that this enemy has a pause in between dropping bombs (drops 2, pauses, then drops another 2) where as in my original run he drops 4 bombs straight in a row. Maybe it's possible to use the waiting part at the vents to manipulate out the best bomb dropping RNG?
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
I wasn't even close, ha!
I resynced to GBAHawk and tried console verifying but no luck. Desyncs around frame 21710. The timer for the characters idle animation where he slowly raises his gun a few pixels after turning around seems incorrect. It is the same in mGBA.
I don't know where to look for this in RAM, do you have any idea where to start from your botting tools eien86?
Would you leave some bank account info to accept straight donations too?
I submitted some movies for the purpose of console verification testing, and now I feel a little awkward because the life challenges made me postpone the making of full TAS movies, and I don't know when I will ignore them all for the sake of this thing
I don't have anything like that set up at the moment. Maybe I can set up pay pal or gofundme or something, Not sure what the best approach is, I'll look into it.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
I have resisted doing this in the past, but I just have to admit that I can't continue to finance both console verifications and new hardware research on my own anymore. I keep hoping used game prices will go down, but it never happens, and it's become too hard to justify spending the high prices for games that I might verify once and never look at again.
So, I am now accepting game and hardware donations!
See my homepage for info if you are interested: https://tasvideos.org/HomePages/Alyosha
(And not just GBA, I'll accept anything anyone is interested in seeing verified.)
My idea here is to use donated games / hardware for the day-to-day efforts of testing sync and console verificaitons, so I can focus resources on things for new hardware tools and research (like dev boards and electrical components and such.)
For the record, it cost $75 for a six month lease of the PO Box, so with current game prices even getting as few as 2-3 games could already be worth it.
Feel free to PM me if anyone has any questions. Thanks!
If you guys need missing callbacks in quickerNES, I can add them. Just let me know exactly what's needed
What's needed is an IInputCallbackSystem callback that fires on controller latch. Having this allows poll based dumping. In this case it would also help in conversion to SubNESHawk using lua.
EDIT: for quickerNES it would be inside this if check on line 838 of core.hpp:
if (input_state.w4016 & 1 & ~data)
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
I tried resyncing, and I made it up to stage 9, but I can't seem to get any further. It could be that SubNESHawk is needed to make sure all the inputs line up correctly. There are about 50 inputs per frame, so this would take a long time.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
I checked again, and the main thing keeping the run from syncing is power on RAM state. QuickerNES uses 0xFF for everything, and if I use that, I can successfully sync the first level with only minor input changes in NESHawk.
I believe the run is not too timing sensitive otherwise, so it's unfortunate that start up state has such an impact.
So, with some re-syncing effort, assuming nothing else is wrong, this in fact can probably be console verified assuming the bot can handle the input spam.
Well, and assuming enough of the 0xFF RAM state can be maintained with RAM setting cart.
EDIT: Bisqwit's original can also be resynced, but you need to remove a reset press that gets put on frame 0 when importing the fcm.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
CoolHandMike wrote:
Alyosha wrote:
CoolHandMike wrote:
This was fun to watch. Curious though if either this version or the previous one can be console verified.
Not syncable to NESHawk, even the first 2 shots, so no way it will work on console.
For both versions? Too bad.
It's the same for Bisqwit's run.
I looked at a trace log, and it looks like the primary issue is that the game polls for input constantly. Most games poll input during or immediately after vblank, but apparently polling for input is this game's version of a busy loop. This means both emulation timing (in the case where a latch happens to fall near an NMI), and how / when the emulator handles input, are both factors for sync.
NESHawk only changes input state on latch, and changes controller state on vblank. I'm not sure how FCEUX and QuickerNES do it.
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
Also emulation differences make it so that executing a shot under the same conditions (angle, position, power, power increase/decrease direction) would result in different outcomes.
What is it that makes this the case? That seems strange.
It's impressive botting work as usual, though I'm not really a fan of using QuickerNES for cases like this where emulation accuracy matters, to me it's like using a lot of resources to get an incorrect answer. But I'm not the one doing the work either. Out of curiosity though, how fast would an accurate emulator need to be for you to consider using it for botting?
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player
(3991)
Joined: 11/30/2014
Posts: 2870
Location: US
EDIT: removed, new run submitted
Here's a complete run that beats the game. The wart fight is sloppy still but that's fixable.
Overall I lost ~ 30 frames to resyncing, still a ~6 second improvement overall.
