Has Lunar Pool been attempted for verification yet?
I was unable to get the original movie to sync in FCEUX after importing the fcm movie. Someone would need to attempt to resync, preferably into BizHawk (ideally using the 2.8-rc1 release or master-branch), but resyncing in FCEUX may also work. At which point, I'd be happy to attempt a verification.
Lode Runner:
Link to video
It took a bit of resyncing in terms of when to start levels, but all the game play is the same.
I also resynced 3-D world runner, but that game polls input in a crazy way (dozens of times per frame, all over the place) and the bot can't keep up.
Sure thing:
https://tasvideos.org/UserFiles/Info/637802689791802996
Note that the game is also impacted by uninitialized RAM, so may still desync, but I was only able to get immediate desyncs and it should work for at least a minute or two.
Has Lunar Pool been attempted for verification yet?
I was unable to get the original movie to sync in FCEUX after importing the fcm movie. Someone would need to attempt to resync, preferably into BizHawk (ideally using the 2.8-rc1 release or master-branch), but resyncing in FCEUX may also work. At which point, I'd be happy to attempt a verification.
I would not attempt the regular run. I doubt that's actually accurate to what an NES would output. The "no friction" run looks promising. I dumped it in FCEUX 2.5.0.
I just now heard of an in-development NES emulator called MetalNES, with the goal of being a transistor level simulation. If it finishes, it may be the last word in console-accurate NES TASing, but I bet it will also be horrendously slow, so it should only be resorted to when faster emulators desync.
https://github.com/iaddis/metalnes
I just now heard of an in-development NES emulator called MetalNES, with the goal of being a transistor level simulation.
I heard about this too. However, it'll need some sort of TASing tools in order for it to be useful for either TAS development or console verifications.
I've done a couple tests with zero initial RAM state (instead of the 0x00 and 0xFF pattern) and the results are promising.
Time Lord syncs no problem with no RAM clearing, which I'm very happy about as that is the game I most wanted to see verified and it didn't work with the clearing cart attempts. I put the video in the submission.
I also tried a Where's Waldo test run. This game also always desynced with the clearing cart, but worked right away no clearing needed with 0 initial state.
Link to video
Eventually I'll have a way to read out power on RAM, but it's starting to seem like 0 is the way to go.
I finally got around to assembling a UxROM dev board. Naturally the first thing I tested was Streemerz, and it worked!
Link to video
This uses the current movie file: https://tasvideos.org/userfiles/info/72428431403912808
This is slower than the original, so hopefully it can be optimized and made into a console accurate submission.
I always suspected that power up timing was the culprit in previous failures, but now with a proper dev board those problems are solved.
I'm really happy this finally works. Streemerz was one of my original tests and I really wanted to see a working console run.
Apparently I don't have a syncing version of the other Streemerz run, so I'll work on getting that working too.
EDIT: Working version of other run too
Link to video
movie file: https://tasvideos.org/UserFiles/Info/638060457284160338
Took another look at Castlevania III. I originally set this aside because I thought the issue was MMC5 and there weren't any test ROMs to pinpoint the problem. However in thinking about it it should have still worked in the range of IRQ timings I tested, so I thought maybe there was still some DMC edge case I was missing.
It turns out that there is a single instance where the game reads from the APU status register ($4015) at the same time the DMC channel decrements to zero. Originally I had this read back as not zero, but it turns out to be correct to have it read back as zero. This combined with adjusting the IRQ timing led to the run working on console. I am up to getting Grant, hopefully I'll have a complete run in the coming week.
EDIT: It now desyncs after the wrong warp. Lot's of crazy stuff is happening there, could be anything going wrong. Probably the new last boss of NES console verification outside of resets.
Thanks to scrimpeh resyncing the Dracula fight (again), the warp path Grant run finally works on console!
Link to video
There is a small caveat here though. It turns out open bus behaviour is more non-deterministic than previously believed, a fact discovered while working on this verification. The emulation of this is, by necessity, fine tuned to my particular console / cart. It may be different and not work for other carts / consoles. Watching the RTA runs that also use the warp path, results appear to be inconsistent. Fortunately this is only relevant for runs using the warp path, as here the game mistakenly tries to load sprites from WRAM, which Castlevania III does not possess. Other CV III runs should be deterministic with the improved MMC5 IRQ timing.
There are still some loose ends in MMC5 emulation, but it's good enough for CV III and that's about the extent of my interest in it.
I've been doing some work to clean up some loose ends of NES verifications as kind of prep work to working on SNES. One of the things that always stumped me was why PaperBoy requires sending 3 blank polls to the bot to get it to sync instead of the usual 1. Well I coincidentally encountered the same problem with Karate Champ, and decided to try to figure it out. It turns out that it's just an uninitialized RAM issue. For both games, if you start RAM with all FF, they end up in a state where they ignore the first frame of controller reading (and since both use DMC, that is 2 polls, hence why I need to send the bot 3.) Starting up with all 0 gives the expected behavior. So it seems my console has enough bits set consistently in RAM at power on to encounter the first case in both games, though I haven't bothered checking exactly which addresses are the culprit.
So, that solves that mystery, not sure why I never checked that before, it should have been the first thing I tried.
Anyway, the biggest remaining desync mystery is Batman, which works easily using frame based approach but I never got to work with poll based.
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.
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.
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
EDIT: It now desyncs after the wrong warp. Lot's of crazy stuff is happening there, could be anything going wrong. Probably the new last boss of NES console verification outside of resets.
