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.
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.
