Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Alright so I improved prefetcher emulation so that the new AGBEEG cart tests now pass, improved sprite horizontal mosaic based on a new test rom by fleroviux, and fixed latching of rotation parameters so that Gadget Racers now displays correctly. Plus I fixed some other miscellaneous bugs. Making steady progress.
I looked around at the various emulator issue trackers and looked over the test roms I have, and it looks like I fail the following tests:
world_map.gba - some kind of hblank timing issue maybe EDIT: The issue here is Audio DMA happening at the end of a scanline, delaying the HBL IRQ code from starting, which in turn delays updates to rotation and scaling parameters until after the start of the next scanline. Need exact audio DMA timing and FIFO emulation.
win_demo.gba - I don't yet implement the glitchy vertical window effect
vram-mirror.gba - some kind of check for upper VRAM memory map mirrors, haven;'t figured it out yet.
test_obj_window.gba - glitchy effects of the OBJ window that I haven't looked at yet
sbb_reg.gba - I need to emulate open bus on the ppu vram accesses for OOB addresses
So if I can get these working I will be passing all test ROMs that I know of. Aside from that I need to emulate STOP mode and RTC / light sensor for basic functionality (ignoring things like e-reader and other peripherals.) Finally getting close to the frontier of GBA emulation.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
What an incredible homebrew, very impressive work by the dev team. Also good work on the TAS, Roll's fast movement and quick attacks keep this one interesting.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I haven't had time to focus on this recently but going into the summer I hope to make a big push towards getting accuracy high enough to get first party games console verified.
I realized I had skipped some cases in my prefetcher emulation. which was causing some accuracy issues. Fixing this made the Inside-cap visual novel (Higurashi no Nakukoroni (J)) finally pass the emulator check. Note to actually play this on GBAHawk you need to fix the header, which requires adding the Nintendo logo and fixing the checksum (address 0xBC to be 0x23.)
At the same time this also helped Fire Emblem sync pass the title screen (because I wasn't making accessing SRAM impact the prefetcher.) It still desyncs a little ways into the first level, but its getting further at least.
Surprisingly this didn't effect Metroid Fusion at all, oh well.
I'm not quite done with prefetcher yet, the new version of AGBEEG cart tests adds some tests that I currently fail, but these seem to effect enabling and disabling the prefetcher, (which games don't really do, they tend to just turn it on and leave it) so I don't think that that will effect much. I'll still fix it anyway though.
So the accuracy grind continues.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Link to video
I found an improvement in Coin Fall and console verified the improved movie in GBAHawk. So along with Power Pig this can eventually be submitted to add another 2 runs to the console verified list.
This game samples input at irregular intervals, so I needed a slight adjustment to the dump script to get it to work. Something I'll need to keep in mind when investigating desyncs in the future. I don't believe I verified where input is sampled for Metroid Fusion or Fire Emblem, I'll have to double check and keep better notes.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I recompiled NESHawk with much faster decay rate (by a couple orders of magnitude) and the run still syncs. This decay rate is faster than I saw on my own NES, so presumably the run would work there, except I don't have the hardware to do so. In fact this rate is even faster than Bigbass' console, so seems like it has a chance of working there too if it was done from power on and the power on states match. So seems plausible.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
https://tasvideos.org/UserFiles/Info/638189969203933938
I tried a bit more to get a good Kraid fight. I ended up about 5 seconds ahead of the published run leaving Kraid's lair. Currently the run desyncs due to an extra enemy spawning that I don't know how to fix. If anyone can fix it feel free to continue the run.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Link to video
V2 test. Same basic results as V1. Seems to be a couple orders of magnitude faster than what NESHawk has now (but shouldn't really matter since in this case the reads seem to be happening during rendering, so even quicker decay should still be ok.)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Currently all published GBC homebrew TASes are console verified, a minor achievement but still something I think worth noting. There are a lot of pieces involved in console verification so I think breaking things down into little categories can be helpful in identifying where gaps exist. I can't say the same about GB homebrew for example because I don't have a suitable MBC1 flash cart. A lot of modern NES homebrew rely on a modern mapper so those need their own dedicated board as well (or a multi-mapper board where timing isn't too critical.)
I tried a few of the GBC bootlegs as well, some don't sync in modern emulator versions. Some, like Donkey Kong 5, poll input in an uneven way not suitable for the current GBI based approach. It's already known that some GB/C games require a verification process with a smaller time resolution to work so this isn't anything new, just another example.
There is also a lot going on with Genesis homebrew, even if there aren't that many TASes yet, could potentially be a good way to jump start Genesis verifications.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I changed version to USA so I could console verify but then was able to save frames in level 2 by somehow getting a different spring pattern where i didn't have to wait at the end.
https://tasvideos.org/UserFiles/Info/638178796134699589
This happened by random chance I don't know why it's different.
EDIT: the bouncing springs can randomly start in one of 3 different positions, I just accidentally changed things to get the bast spawn at the end.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Link to video
Here is a video of the original version.
Note that this uses mapper 2 rather than mapper 7 in the original since I didn't have a mapper 7 dev board. There's no bank switching and both use CHR RAM so seems reasonable.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
JosJuice wrote:
While you may be able to get around disc drive inconsistencies with this, you're unfortunately left with all the same problems as the N64. GameCube emulation currently doesn't have CPU and GPU timing accuracy anywhere near what would be required for console verification, and all GameCube games I know of configure the hardware to regularly poll controllers automatically, so you can't detect lag frames.
Oh, interesting, I had thought such things were already quite advanced for GameCube. In your estimation, how far off is it? Like, for NES for example even a relatively inaccurate emulator can generate console verifiable runs a good fraction of the time, would the same be true with GameCube? Maybe there are games that spend a lot of time in an idle loop for example that would stand a chance?
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Darkman425 wrote:
Is that glitch related to the weird one I never figured out where I took damage randomly?
I'm not sure, I don't know why this new glitch works either. General homebrew glitchiness isn't surprising to me, so I'm not really looking too deeply into it.
EDIT: although looking at it again, it looks like I now have 3 lives throughout the run, so maybe something changed? Perhaps I can improve some stages where waiting was required before.
EDIT2: Turns out no more time can be saved with damage boosts, but only because you have to wait for the skip glitch to line up. Also my other time save also didn't end up saving time due to waiting, so the only time save is in waiting for the skip glitch.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Link to video
By pure chance I stumbled upon a big time save in Powerpig. There is one frame every so many frames where you can complete one level and skip the next level intro, saving a couple seconds every level. It is possible to hit this glitch just moving normally through a level, so it seems Darkman425 was just extremely unlucky to have not stumbled upon this in the original. I found it while improving another level, so this skip glitch isn't the only improvement.
I console verified this new run as well, so finally I have an actual console verified improvement over an existing publication. Eventually I will ask for GBAHawk to be accepted for publications, so it's nice to already have a relevant example, even if only in homebrew.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Here's a few possibly useful notes about this:
- Mesen has a different power on state than NESHawk, they are not directly compatible for careful timing cases like reading from ppu.
- You can change the cpu / ppu alignment in Mesen, this may or may not give more chances at success.
- BigBass' test was done from reset, which isn't the same as doing the test from power on.
- I briefly looked at where the ppu registers were being read, and it looks like it happens during rendering. Even if the test was done during power on, this gives a very low chance of success, probably worse than 1/8. I would try myself, but I have neither the game nor an adapter to play famicom games on my NES.
- Reading from ppu write only registers has not in general been carefully tested.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Thanks to Bigbass grinding out more NES verifications, we've reached over 300 currently published runs console verified, awesome! With 2890 currently active movies, we remain above 10% of all movies.
It's worth saying that the influx of short homebrews for both NES and GB/C have allowed for some quick and easy verifications, so this stacks the numbers somewhat, but oh well.
Aside from just raw numbers, there's also a good amount of R&D type work being done. Castlevania III led to some new research into NES edge case behaviours, Streemerz finally works with a new dev board, and SMB Stop and Swap managed to push the envelope of NES verifications in an innovative new direction. Some notable failures also occurred, such as Dragon Quest (J), so even for NES issues remain.
A lot of GBA work has happened recently as well. NanoboyAdvance and my own GBAHawk can now make it through the entire mGBA test suite, as well as many other timing sensitive tests, so console verifications of first party GBA games is (hopefully) on the horizon. In both cases issues remain, but I'm pretty optimistic. The pipeline for such verifications was already in place, not being much different than the GB/C version, so it's really just waiting on emulation. Even with mGBA though some runs have worked, with Sushi the Cat being the first GBA verification in over 2 years.
In somewhat relevant news I saw this cool video about loading games on Gamecube while bypassing the disc drive:
Link to video
Maybe something like this can lead to the possibility of Gamecube verifications down the road (admittedly cheating a bit but would still be cool.)
I'm not aware of anything happening for other ssystems, but Sour has returned to working on Mesen (which includes SNES and now PCE) so maybe down the road something will be found that can give more SNES games a chance at verification. Also Ares is now in BizHawk, so maybe n64 has more of a chance now besides SM64 and Mario Kart, but I'm not aware of any console testing yet.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
OnehundredthCoin wrote:
In SMB3, the final instructions to execute are what sets up that variables to start SMB1 in world 'N', so it would seem everything is being executed, though it's certainly possible something is going wrong during the setup.
Interesting, this would then point to something on the SMB1 side (even though it's still strange the bot doesn't exit the SMB3 part correctly.)
Recent work on open bus behaviour shows some inconsistency, and I haven't personally tested unofficial opcodes on my NES, so there are several variables at play.
Some kind of test to verify the baseline behaviour would probably help sort things out.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I tried a few more times, and it seems like the SMB3 part of the run isn't being completed properly on console. It looks like some inputs are not being processed. This is occasionally a problem for games that require processing input very rapidly.
Maybe someone with a different bot or a V4 TAStm32 could make it work.
I'll try some more when an updated movie is made.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I always like seeing new innovations in TAS technology, and this one is really cool, nice work!
I tried console verifying, but it crashes in various ways at the axe grab. Not sure what this means. here is an example:
Link to video
I hold reset in between cart changes. Gives pretty consistent results up until the axe grab.
EDIT: Upon reading the submission text, it seems it's probably crashing at the unofficial opcode, or maybe the payload is not getting written properly.
