I'm currently using NESHawk (BizHawk 2.8), will definately try to make a new TAS on BizHawk but not any sooner. So far I tried converting this fm2 into bk2 and shifted the inputs 1 frame earlier (as BizHawk power on 1 frame sooner than FCEUX) and it desyncs because you get different grenade guy door in level 1.
Additionally all the NBA RAM access tests work correctly. I fixed numerous other bugs along the way as well, so now some of the more complicated homebrews like Vroom3D work correctly.
Unfortunately, all of this still isn't enough to make Metroid Fusion sync on console. There are still a few more things I need to work on, so hopefully one of those fixes it.
The repo is a bit out of date and I definitely need to clean it up. I also have a decent amount of local work that isn't on github yet. I'm planning to tackle that cleanup in the next few weeks and make some more progress on this project,
I'll probably add in solar sensor etc. for the Boktai games next.
The resulting rendering code is considerably longer and more complicated than it was before though, and it comes at a pretty steep performance cost of 10% (or more for complicated scenes.) Some games now run under 60 fps at times. I still have to rewrite the sprite pipeline too, but I don't think that will have as big an impact, so things shouldn't get much slower. but I'll definitely need to focus a lot on optimization now to claw back some of that lost fps.
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?
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.
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.
dma_Tick(); // DMA
pre_Tick(); // prefetcher
ser_Tick(); // serial port
tim_Tick(); // timers
cpu_Tick(); // CPU
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.
Levels 5 and 15 look slower than the human record. Is that correct, and can it be helped without breaking everything else?
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.