Hunting down remaining emulator bugs

Ask anything your want about Megadrive/Genesis programming.

Moderator: BigEvilCorporation

Post Reply
Wuerfel_21
Newbie
Posts: 6
Joined: Sat Feb 12, 2022 4:22 pm

Hunting down remaining emulator bugs

Post by Wuerfel_21 » Fri Feb 18, 2022 8:24 pm

So, over the last year or so, I've assembled pieces of code that eventually congealed into a decently functional Megadrive emulator that runs on Parallax P2 microcontrollers (about ~7K lines of assembly, almost all written from scratch). It's a high-level emulator (68000/VDP/Z80/YM all run asynchronously in different CPU cores. VDP/YM are locked to scanout / DAC timing, Z80 runs at approximately real speed, but 68000 runs as fast as it can (because there are some worst-cases where it can't keep up with real MD)), so extreme timing edge cases will never work right (though on the upside, slowdown/framerates are generally improved), but there's a few issues that I'm really sure are based in some logical error that can be fixed. And I'd like to do that before I refactor it all to add a nice GUI and non-terrible config system (which will make debugging slightly more obnoxious, which it already is, since it changes timing relations.). A lot of the valuable info for the project came from this here forum, so I ask here if anyone's got any pointers or ideas. If not, that's fine, too.
  • There doesn't seem to be a thorough instruction test for 68000 like there is for Z80, so any tips on how to weed out the last few bugs? I've looked through all the instructions at least twice (and did find some oversights that way), but it's still not perfect (see below).
  • There's this particular oddity in Panorama Cotton (which oddly enough was one of the earliest games I got to run properly...) wherein the shadows beneath objects always use the smallest sprite. I'm quite sure this is a 68000 core bug, but the game seems a bit complex to debug (multiple layers of indirection + not using DMA)
    shadowbug.png
    shadowbug.png (233.58 KiB) Viewed 5552 times
  • There's that strange text crawl in Monster World IV that seems to be broken on a lot of emulators. I've seen the issue mentioned a bunch of times (including on this very forum), but never an explanation as to it's root cause. From what I can tell, it's just trying to render it into VRAM, but it seems to not do that (advances to the next scene totally fine though). Exodus actually seems to crash on this scene, lol.
  • If you wonder what TITAN's Overdive looks like, uhhhh here you go. Not pretty ;=) https://www.youtube.com/watch?v=uJLdYdJWhQo A lot of the effects are broken because of timing issues that are just not in the scope of a high-level emulator, but IDK what's going on with the 3D cube part. Seems to mistakenly clip the right edges to the screen edge? I've suspected the CMP instructions, but I've triple checked them all and they should be working right. Also lol at the bugged credits.
  • Music in Thunderforce IV slows down heavily, especially during boss fights, despite the actual game not slowing down much at all. Sound test is fine. It doesn't seem to be related to the Z80 actually being halted (there doesn't seem to be any correlation between Z80 halt time and screen action), so I guess it must be missing timer steps?
If you care to read through 7k lines of assembly for an ISA you likely never heard of (or are just curious), source code is here: https://github.com/IRQsome/MegaYume/blo ... ower.spin2

Thanks for listening to my nonsense.

Wuerfel_21
Newbie
Posts: 6
Joined: Sat Feb 12, 2022 4:22 pm

Re: Hunting down remaining emulator bugs

Post by Wuerfel_21 » Fri Jul 08, 2022 5:49 pm

Wuerfel_21 wrote:
Fri Feb 18, 2022 8:24 pm
If not, that's fine, too.
It infact is.

Anyways, if anyone wonders, I did infact figure out the shadow issue for Panorama Cotton... by way of writing a NeoGeo emulator with the same 68000 core and then debugging why Waku Waku 7 didn't boot on that. True big brain solution. (Note: the same issue also causes a crash in Contra Hard Corps during the 3rd demo (and presumably also in the actual level, but I never tested that))

The issue is that reading with MOVEM.W wasn't performing the sign extend that it should. (Note that it sign extends when reading into data registers, too! I just noticed that while writing this post here. How odd. But the issues detailed above relate to address regs only (Well, a lot of animations in WW7 were broken with just the address registers sign-extending))

I guess MOVEM.W is just such a rare instruction that most games run fine even when its totally broken?

Other issues mentioned still stand.
Screenshot 2022-07-08 03-22-15.png
Screenshot 2022-07-08 03-22-15.png (233.57 KiB) Viewed 4817 times

Mask of Destiny
Very interested
Posts: 615
Joined: Thu Nov 30, 2006 6:30 am

Re: Hunting down remaining emulator bugs

Post by Mask of Destiny » Sat Jul 09, 2022 5:41 am

Wuerfel_21 wrote:
Fri Jul 08, 2022 5:49 pm
I guess MOVEM.W is just such a rare instruction that most games run fine even when its totally broken?
So I think it's not so much that it's a super rare instruction, but that it's not very typical to do movem.w and then depend on the full longword value.
There's that strange text crawl in Monster World IV that seems to be broken on a lot of emulators. I've seen the issue mentioned a bunch of times (including on this very forum), but never an explanation as to it's root cause. From what I can tell, it's just trying to render it into VRAM, but it seems to not do that (advances to the next scene totally fine though). Exodus actually seems to crash on this scene, lol.
So Monster World IV depends on some edge case behavior for writing to the address/CD registers. It seems like it writes some garbage data to the data port at some point and it's depending on the destination getting changed by a VDP register write. Honestly, the behavior of the control port on the VDP is kind of wacky and doesn't make a lot of sense from a hardware implementation perspective. I think the implementation in Genesis Plus GX covers all the known edge cases though

Wuerfel_21
Newbie
Posts: 6
Joined: Sat Feb 12, 2022 4:22 pm

Re: Hunting down remaining emulator bugs

Post by Wuerfel_21 » Sat Jul 09, 2022 7:23 pm

Thanks for the hint!

I tried making it so that register writes latch the lower part of the VDP address as genplusgx does, but that alone doesn't seem to do the trick. Can't really try latching the CD bits without significant effort (due to how I implemented all the nonsense), but I think CD1=1 CD0=0 is not a useful write mode, anyways? (As implemented, register writes just disable data writes from doing anything. Tried without that (leaving previous mode), but that isn't it, either)

Post Reply