Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
GJTASer2018 wrote:
How would that even work in theory? Is it something that would happen online, or between two instances of BizHawk running on the same machine?
It would be the same as for Gameboy, just two copies of the system running at the same time, on the same instance, with some linking logic between them. Currently for very complicated games, such as the quake demo, my core only runs at 65 fps, so for two systems with linking logic it would probably be around 30 fps. Compare to mGBA which can run around 400 fps for the same game, it has plenty of room to run 2 systems.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Making good progress towards accurate VRAM access timing. Backgrounds and palettes are pretty much done, so all of those access timing tests work now. This allows stuff like the infamous coin flip in the Madden NFL games to work. It also makes the Tonc tte demo profiling work correctly (after I fixed a bug in cpu timing that had me stuck for quite a while.) The only one not correct is the obj one, which I haven't gotten to yet:
With numerous other small bug fixes happening along the way, things are shaping up pretty well. I expect sprite access timing to be a fair bit more difficult than the others, so it will probably take a while. I also have a fair bit of refactoring to do before the ppu can be really considered cycle accurate, but I plan to that incrementally rather than with a sweeping re-write, it's been working out well so far.
PPU emulation aside, I still need to do things like Flash save ram, gyro controls, RTC, and possibly solar sensor, I might do some of these before tackling sprite timing just to change things up a bit.
Link cable emulation would also be cool, but I don't think I can make it run full speed.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
TheAmazingYucemu wrote:
Even if my nintendo switch syncs the arduino, no matter if it's sync controllers menu on Horizon OS, the emulated pro controller never appeared on this menu after bunch of button presses tries and even tried to run a dummy TAS file to the arduino and nothing worked so i'm pernamently ceased my open-source nintendo switch tasbot development forever.
Aww, that's too bad, I was really hoping to see some cool stuff come out of this. Better luck with your next project.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
One of the things that keeps me interested in emulation is just how close you can get to being right while still ultimately being wrong. I was recently working through the newer NBA ppu tests and somehow things just were not working out. It seemed like there was some off by one issue with DMA even though many other stringent DMA timing tests worked. Several hours of tinkering got me nowhere, then by happenstance I was scrolling through my code and noticed my execution loop, where it turns out I had a made a very basic error. Here is what things looked like before:
dma_Tick(); // DMA
pre_Tick(); // prefetcher
ser_Tick(); // serial port
tim_Tick(); // timers
cpu_Tick(); // CPU
The problem here is that both the CPU and the DMA channels can read and write to the timer registers and access ROM, but the DMA tick is happening before the timers and prefetcher while the CPU is happening after. Somehow I had gone through all the grueling timer and prefetcher tests (some of which do use DMA) without realizing this. It really is amazing that it all worked. Once I put things in the correct order, a cascade of other small errors showed up. Fixing everything up took a while, but now I can get through the NBA tests that were giving me trouble while everything else still works.
I still have a small list of things to do before tackling VRAM access timing, with the top of the list being video capture DMA, but I'm pretty sure most everything else is solid. There are also some untested cases that could effect TAS console sync, like exact timing of audio FIFO DMA and DMA IRQs, multiplication timing, and probably various horrible prefetcher edge cases, but those are things I'd worry about after VRAM. Still a lot to do.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I did some tests with Metroid Fusion and Fire Emblem and they both desynced, apparently due to loading times, I believe because of VRAM access delays not implemented yet. The GBA has a feature called forced blank that allows you to access VRAM without any conflicts. A side effect of this though is that the screen fades to white. So, if you want to change scenes with a fade to black instead, which both of those game do, you have to deal with VRAM access delays as the PPU is still rendering.
Fusion made it the furthest so here is a video:
--superseded by more recent progfress--
So it looks like I'll have to implement this before further testing.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Starting to test out GBA verifications. Decided to do a test run of a short homebrew game (Feline) to test out my workflow. This test run was made entirely in my new core to test out save states and TASing tools. Seems to be working well so far. Feline is also interesting from an emulation point of view by itself because if you get seen by the lab rats, the game attempts to change ARM mode in an architecturally unpredictable way (attempting to set the thumb bit by MSR instruction.) Turns out nothing bad happens on hardware, but it took me a while to figure out why it was crashing on me in emulator. EDIT: Old video replaced with published version
Link to video
The run plays out the same in mGBA, except you can start a frame earlier in my core (presumably due to pre-fetch but I haven't checked the details), so this was a relatively easy test. Once I fix a few more emulation bugs I'll try something more difficult.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Made some good progress over the past few weeks. Most of the rendering effects are done now mainly thanks to the Tonc demos (although I probably missed some alpha blending cases somewhere.) EEPROM saving is done, and various bugs are fixed. Now I can pass the entire mGBA test suite (with the caveat that Misc edge tests -> H-Blank bit -> Flip #1 matches hardware but not what the test says) and all of the NBA tests.
The only major element left to work on is sound. In the past this has always given me the most trouble, but I already have the FIFO channels working and the others are just slightly modified GB audio channels, so I'm hopeful I can make relatively quick work of it. I also haven't done VRAM access timing stuff yet, I'll hold off on that until I see how many games really need it. Anyway, I know of a few bugs I need to sort out besides audio, after that console testing can start, hopefully in a month or two.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Game: NES Batman
Emulator: BizHawk: 2.8 (NESHawk)
Console Verification Device: TAStm32
Movie:https://tasvideos.org/UserFiles/Info/638097680760634038Description of Desync: Desyncs shortly into stage 2, Batman jumps into the acid.
Research: This game uses an MMC3A and DMC channel. There are no other verifications of MMC3A games that require careful timing such as this, (there are others using MMC3A, but don't require careful timing, and there are verificaitons of games ex. SMB3 that require careful timing but use a later MMC variant) so may be related to that revision, but it's not clear why this would be.
Possible Next Steps: ???
Status: Open
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
Levels 5 and 15 look slower than the human record. Is that correct, and can it be helped without breaking everything else?
Oh I missed checking a couple levels somehow. Unfortunate it's at the beginning. There is no RNG in this game, so it's definitely fixable, but then resyncing everything is tedious.
I'm not putting more hours into this game right now, so I'll just cancel.
If anyone wants to fix it I'll be happy to add a co-author, maybe another set of eyes can even find some more improvements.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Wow new (and open source) switch verification work, cool stuff.
What does 'NO CFW required' mean?
Good luck in development, I'll be really interested in your progress.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I haven't been able to focus on this too much over the past few months, but I have a bit of time now and am back to making progress. The biggest thing I've done is port the core over to C++. The C# core was just way too slow, and was falling under 60 fps even in simple cases. I expected I would have to do this so built the C# core to be conversion friendly from the start, but it still took a bit of effort. Converting to C++ and making a few basic optimizations about doubled the speed, and now I at least have a bit of headroom to work with. I expect more complicated scenes to still fall below 60 fps until I optimize a bit more, but that's a concern for further down the road once the rendering pipeline is finished.
Aside from that I made a bit of progress with rendering timing and open bus emulation, so I can get past the misc edge case timing test on the mGBA test suite:
I still plan to develop the rendering pipeline in C# as it's just much easier to bug fix in it, so for now both cores will be developed together. Sprites are the next thing to do.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Oh cool strat, seems obvious but I never thought to try it. I don't really have the will do deal with this game's RNG again, so free improvement for anyone I guess.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Removed Rolo. Also removed Ranma, since it's pending publication, thanks to ShesChardcore.
This leaves 11 runs in total, a lot of progress has been made this year. pretty cool!
On a more bureaucratic note, I currently have #756: JXQ's NES Skate Or Die 2 in 10:28.37 listed in the 'added after vault' category, but this is incorrect, it was just published later. In fact #780: Highness's Genesis Legend of Toki - Going ape spit in 28:25.37 and #979: Luke's NES Deadly Towers (USA) in 15:20.27 also fall into the category of runs submitted earlier than the last submitted 'First 500' run, which is Star Ocean. So for consistency I should either add Toki and Deadly towers or remove Skate or Die. I'm not concerned with such nuances, as the project is First 500 publications not First 1000 submissions, so I'll just remove Skate or Die, bringing the total to 10.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
arnaud33200 wrote:
I'm curious, how is it an improved run if there are more lags?
is it just about the number of frames?
Aside from accuracy, VBA also has the very annoying feature of counting all lag frames where the screen is off (usually when the game is loading stuff) as a single input frame. Modern emulators do not do this. Over the course of a run this can add up to many seconds worth of extra lag frames. VBA does however add back in loading times when making encodes, for correct sounding audio. If you look at the displayed time of the previous Kirby run it is listed as 8:44.65, however if you watch the encode it actually runs for about 8:55. So basically you have ~11 seconds of loading time. The bios takes about 3 seconds as well. So with no emulation differences, the previous run would have had a time of ~8:58.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
--
Made it through level 45. Looking back it looks like the RTA run is faster in level 39, but I'm going to loop back through all the levels anyway so can fix it later.
Honestly this isn't as interesting as I thought it would be, I'll grind it out to a completed run though.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Link to video
Console verification of Samsara's most recent improvement.
Note that this game's use of NROM + CHR RAM is technically not officially supported, but nothing is physically preventing it from being implemented.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
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
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
ShesChardcore wrote:
Alyosha wrote:
Nice work! Wasn't expecting such a big improvement here.
Thanks. There's 2 games on the list I felt like I could do. This one and Lee Trevino. I don't know if I have the patience left to do both courses though haha.
With numerous other small bug fixes happening along the way, things are shaping up pretty well. I expect sprite access timing to be a fair bit more difficult than the others, so it will probably take a while. I also have a fair bit of refactoring to do before the ppu can be really considered cycle accurate, but I plan to that incrementally rather than with a sweeping re-write, it's been working out well so far.
PPU emulation aside, I still need to do things like Flash save ram, gyro controls, RTC, and possibly solar sensor, I might do some of these before tackling sprite timing just to change things up a bit.
Link cable emulation would also be cool, but I don't think I can make it run full speed.
The only major element left to work on is sound. In the past this has always given me the most trouble, but I already have the FIFO channels working and the others are just slightly modified GB audio channels, so I'm hopeful I can make relatively quick work of it. I also haven't done VRAM access timing stuff yet, I'll hold off on that until I see how many games really need it. Anyway, I know of a few bugs I need to sort out besides audio, after that console testing can start, hopefully in a month or two.
I still plan to develop the rendering pipeline in C# as it's just much easier to bug fix in it, so for now both cores will be developed together. Sprites are the next thing to do. 
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.