Hidden bug

[jotego]

I have been trying to catch a bug in a new arcade core I'm working on. In one stage, the game enters a loop and stays there for 20 minutes or more until it eventually gets out, and the gameplay continues.

I am starting to think that this could be a bug in the fx68k softcore. I don't have any replacement I can just swap and test, and I am not sure what the best way to debug this is.

Maybe you have some reference emulator that you can simulate side by side with your core in a system Verilog environment. If that's the case, please share it and I will try to reproduce the problem in simulation so we can catch the discrepancy.

[jotego]

Here is a video showing the bug.

[a1exh]

Are you using the code which is on master now? Or the modified version in #6

[jotego]

I am using the master branch. I am running now a very long sim that reproduces the issue. But unless there are signals going to X, it will be hard to get anything from it.

[ijor]

Hi Jotego,

Sorry for the delay ... I'm not sure I can be very helpful since you have no idea if the error is in FX68K or somewhere else. I would gladly help if you might have some hints about what could be problem

Regarding emulators, I don't know if there is an emulator you can run side by side. I never tried that. But, AFAIK, currently the most accurate 68K software emulator is the one that is part of Winuae.

[jotego]

We found another odd behaviour that could be related to fx68k. This is in a CPS2 game: Gigawing. During the fight with the last boss, at some point, the AI breaks, and the music turns into a constant buzz. You can see it in this video around 1:20. The boss will stop firing and just stay still.

The glue logic in CPS2 is rather different from that of System 16. There is a hard to implement communication between the Z80 address and data buses and the M68000. So, as in System 16, I cannot be 100% sure that the problem comes from the fx68k, but it raises my suspicions.

There are two other odd problems in CPS2 games that could be ascribed to a CPU bug. One is a reported difference in bullet patterns in Progear. Another is an odd tile within a large sprite in the Armored Warriors intro. Another one is the unlimited speed at which Mars Matrix runs (the interrupts are received and processed, but the game runs at higher FPS than the screen refresh rate)

Maybe you could publish your test benches so we can try to identify something that wasn't tested for. If that compromises your workflow, and you'd rather not publish them, could you give some description of how you tested the logic, please?

[jotego]

I replaced the fx68k module with the j68_cpu one. The bug in Shinobi goes away:

The chance of the problem being in the glue logic is much less after this test. A bug in the CPU is the most likely culprit. I will try to debug fx68k using j68_cpu as a reference.

[jotego]

I think I found the offending instruction: subq. I have started a different issue #9 now that we have a clear culprit.

[jotego]

9 was a fiasco. The search continues

[blackwine]

I can reproduce behaviour from the video in second comment in the MAME emulator. If I change tas to tst.b (location $129cc or $129d4 depending on romset) it gets the same bug like in the video.

I also did test the other way around. I've patched tas <ea> with tst.b <ea> and bset #7,<ea> on the MiSTer FPGA romset and the bug shown in the video disappears.

Could it be that the highest bit is not being set at the effective address on tas opcode execution in some circumstances?

[ijor]

I also did test the other way around. I've patched tas with tst.b and bset #7, on the MiSTer FPGA romset and the bug shown in the video disappears.

Interesting. TAS being so special, it could also be a DMA issue, or the handling of a read-modify-write bus cycle.

Can you provide the exact code sequence and ea of the TAS instruction please. Did you replace TAS with multiple instructions? That means that you relocated the rest of the code?

[jotego]

There is no DMA in the System16 code:

// No peripheral bus access for now
assign BRn   = 1;
assign BGACKn= 1;

Looking for a time diagram for a read-modify-write bus, I found this:

/AS isn't toggled for the write part, my glue logic only checks /AS, not /LDS or /UDS. I think that must be the problem.

Let me try correcting it. I will report back here.

[blackwine]

Yes, tas is rarely used in typical m68k code. I did another test with Minimig core which supposedly uses fx68k as the cpu core in 68000 mode and TAS behaviour is correct there.

 0129CC  tas     ($23,A6)                                    4AEE 0023
 0129D0  bne     $129d8                                      6606
 0129D2  move.w  #$440, ($1a,A6)                             3D7C 0440 001A
 0129D8  move.w  #$568, ($10,A6)                             3D7C 0568 0010

I have patched tas at 0129CC to tst.b (4A2E) and inserted jump to relocated routine where it does remaining stuff at 0129D8 which is common point for two sides of the branch.

 01BFE2  move.w  #$568, ($10,A6)                             3D7C 0568 0010
 01BFE8  bset    #$7, ($23,A6)                               08EE 0007 0023
 01BFEE  jmp     $129de.l                                    4EF9 0001 29DE

I would look at read-modify-write bus cycle, this is a special case, and it may be handled differently by @jotego's core than minimig's, where the write misses spot...

[sorgelig]

TAS made specifically for cases when need to hold the bus while updating the flag. I think it's made for multiprocessor systems. In Genesis core incorrect TAS implementation leads to non-working Gargoyle game. So it was specifically tested there.

[jotego]

Changing the way DTACK is generated so it reacts to DSWn signals too as well as ASn has fixed the proble for Shinobi It was the read-modify-write cycle used by the TAS instruction. Thank you very much for finding the offending instruction, @blackwine

[jotego]

SDI (System16) boots up correctly now too, the crazy speed in Mars Matrix (CPS2) is fixed too. I haven't tested Gigawing all the way yet but the small glitch in the 1st stage seems gone too. I think I can close the issue. Thank you very much to everyone for their support and help. I have got to learn more about FX68K during this time and appreciate its accuracy. Thanks, Ijor for sharing this awesome piece of technology with everyone!