barcrest\mpu3.cpp: Correct 100hz signal to pia6821 ic3

[blueonesarefaster]

100hz signal to the pia was previously done with m_pia3->cb1_w(~m_signal_50hz);
As m_signal_50hz was an int with a value of 0 or 1 this meant cb1_w() was always being called with a non-zero value.

In addition to the above, it's supposed to be a 100hz signal, not 50hz.

This fixes software which boots and then locks with TURN-ON-DELAY 30 on the display.
Also, fixes software which use the WAI instruction and then lock.

[rb6502]

This comment should be updated to say 100 Hz.

[rb6502]

While you're here, may as well clean it up a little: "m_signal_100hz ^= 1" would work to toggle it without needing the compare.

[blueonesarefaster]

BTW, there are a couple of games which don't run due to a problem in the 6802 core.
The CLR instruction actually performs a read-modify-write cycle but the emulation only does a write.
Similarly, the TST instruction also does the same, although only the CLR instruction stops the games from running.

As the cpu core covers several processors I'm not going to mod it at this point.

Might be worth making a note of this somewhere for the future ?

[rb6502]

Those 6802 fixes seem like pretty low-risk changes, but I can check them out if you can give me more info on which MPU3 games break (and ideally the program counter of the bad CLR instruction).

[happppp]

I don't think 6800 TST is read-modify-write?
CLR: Yup, 6800 manual talks about it too.

Try this suggested fix in 6800ops.hxx:
line 832: INDEXED; RM(EAD); WM(EAD,0);
line 984: EXTENDED; RM(EAD); WM(EAD,0);

I see the read cycle too in Hitachi 6301Y0 manual, so Hitachi kept the dummy read in.

[blueonesarefaster]

I don't think 6800 TST is read-modify-write? CLR: Yup, 6800 manual talks about it too.

Try this suggested fix in 6800ops.hxx: line 832: INDEXED; RM(EAD); WM(EAD,0); line 984: EXTENDED; RM(EAD); WM(EAD,0);

I see the read cycle too in Hitachi 6301Y0 manual, so Hitachi kept the dummy read in.

I had that change in my local copy and I know it fixes the games which don't currently start.
Just wasn't sure it applied to all variations of the chip from different manufacturers.

The 6802 datasheet lists the TST instruction together with CLR and all other RMW instructions but there is a note attached to it which I didn't spot.
So, for TST the write cycle actually happens but the valid memory address signal remains inactive so the write shouldn't actually happen.

I'm happy to do the CLR changes if everyone else is happy they're safe ?

[rb6502]

Yeah, go ahead and add hap's fixes. Also, for the second change, you put:

m_signal_100hz = m_signal_100hz^=1;

That's one too many assignments, which is why the auto build is complaining. Just "m_signal_100hz ^= 1;" works. And we prefer it with the spaces between the parts like I have there.

[ajrhacker]

M6801 never performs a write cycle for TST. CLR, on the other hand, is in fact executed as a unary read-modify-write operation on M6800 and M6801, much like it is on M68HC11, M6809, MC68000 (but not its 16-bit and 32-bit successors) and most PDP-11 models.

[happppp]

That CLR fix is better placed in a new PR. But instead, it's faster to just add it directly, which I did: 035b34a

I think at most, a few drivers will get a spammy error.log (debug->new error log window). If it gets too bad, they can add a nopr().

[blueonesarefaster]

Thanks happppp, I was just about to do that.

I've now fixed the toggle of m_signal_100hz and changed comments on some games.