if you do it on the real hardware you're just creating an emulator's error by altering the game. that's kind of backwards as far as the issue?

It's not really an emulator error per say. When the emulator authors were reverse engineering games, they saw that 0xFF at 0x1F was needed for the game to load certain content. In Metal Slug 0xFF at 0x1F would enable certain sfx. The content they were seeing was actually debug or prototype data. The emulator authors did not know this and they assumed the extra content was a required part of the game so they forced it on.With that said, the actual official debug cartridges would have 0xFF at 0x1F to denote they are debug carts or if that was not the case it would then be added in by the development NGPC machine. It's one or the other.

Anyways, I took the NeoPop emulator source code and modified it to do what Nemesis did years ago, and that is to have it generate the assembly as the emulator goes from place to place. I also had it generate a bitmap for every byte in the rom to denote if it is code or data.

Looks like an extension of the Z80 assembly language to me, along with "extended" 32-bit registers like XDE and XHL.

Anyways, it's interesting how they used the high byte of the RESET vector to indicate debug vs. production. I remember that many older Macintosh applications used the high byte of addresses for various flags, which caused all sorts of problems when the Macintosh II came out with its 68020 CPU.

Anyone else getting crashes in NeoPop at the end of the level when you enable debug?

If you want the short story:It's a NeoPop core simulation BIOS bug. NeoPop's core is used in a lot of NGPC emulators, but I have posted the bugfix to the multi-emu Mednafen's boards since it's the most active.

If you want a temporary fix for the bug then open up the Sonic Pocket Adventure rom in a hex editor, and change the 0xF0 at 0x3769C to 0x10.This should the stop the crashing for that case only.

If you want the long story:The NGPC has several system functions in the BIOS that can be accessed via the following assembly code:

CODE

LDF 3LD w, #some function number here#SWI 1

NeoPop simulates the BIOS and SWI call in C once it detects it, and what it does for SWI #1 is that it takes w, multiplies it by 4, and adds it to 0xFFFE00 to get the address of the interrupt to execute. Then it jumps there.

We can see at 0x2376A SWI #1 is called, so why does it crash and why does it try to go to 0x010001C0?

If we look above the SWI #1 instruction to see what w is set to, we see:LD RW3,0xF0That loads register w in bank 3 with 0xF0.

What NeoPop does in SWI #1 is that it takes w which is 0xF0, multiplies it by 4 (which is what the << 2 does in the C code), and adds it to 0xFFFE00.This gives you the bad address 0x010001C0 or 0x1C0 if we ignore the top byte.

Notice how it Ands w with 0x1F before multiplying it by 4 (via the two adds)? This is something NeoPop does not do.Obviously this is why NeoPop crashes. NeoPop was using 0xF0 stored in w when it should be doing (w & 0x1F) to get 0x10 instead of 0xF0.

So the reason Debug mode crashes is because it is a NeoPop emulator bug. To fix it, you would have to recompile the emulator and change in the above mentioned function from: pc = loadL(0xFFFE00 + (rCodeB(0x31) << 2)); to pc = loadL(0xFFFE00 + ((rCodeB(0x31) & 0x1F) << 2));