MAD2.DSK crashes on a real //e (but works on AppleWin)

[tomcw]

As reported / discussed in sosaria7/appleinpc#11, MAD2.DSK (from Oct'19) crashes on a real //e.

I have confirmed this by testing on my non-enhanced //e.

To fix the image, hex edit MAD2.DSK at offset $3318: 1A->19.

This fixed version also works on AppleWin! ...so AppleWin has a bug in that it runs MAD2.DSK with both values (1A and 19):

• Original (1A-version) should crash
• Fixed (19-version) should work

[Archange427]

Sorry but MAD2.DSK (with $3318: $1A) is working on my real A2 (non-enhanced //e)...

Edit: Both versions (with $3318: 1A or 19) are working on my real A2.

[tomcw]

Hmm... but for me on my real IIe (PAL/unenhanced):
MAD2.DSK (SUB #26) - crashes!
MAD2.DSK (SUB #25) - working

I wonder if it's a statistic thing... I will try running on my real IIe many times to see if I can get the original MAD2.DSK (with $3318: $1A) to work like you can.

[Archange427]

All I know is I've been using SUB #25 ever since.
And it runs on AW and my real machine.
I don't remember why I don't use SUB #26 anymore (probably a crash during my tests with more recent stuff ?!)
So the mystery is, why does MAD EFFECT 2 always work with SUB #26 on MY real Apple IIe ?
Btw I will update the download page with the corrected version...

[tomcw]

On a real IIe: I just tried MAD2.DSK (sub #26) 10 times... and got 10 crashes (all at the point where it first shows the Joy Division graphic). I tried 5x Ctrl-Open-Apple-Reset and 5x C600G, in case the reset was always resetting to a bad state.

It certainly is a mystery that it works on your real IIe!

btw, the fix for AppleWin is easy, and clears up a little mystery for me:
See this line:

AppleWin/source/Mockingboard.cpp

Line 1993 in f238be2

bIrqOnLastOpcodeCycle = true;

Well it shouldn't always be true, but only true if the 6522 interrupt occurred on the opcode's last cycle. This was an accidental bug, but now I know I can confidently fix it.

[Archange427]

So probably related to the MegaAudio...
And sorry about that.
I hate to have released something that doesn't work!

[tomcw]

Yes, maybe (probably?) as this emulates the 6522's using an FPGA - so maybe there's a subtle "out by 1" bug in their emulation?

[Archange427]

"Fixed" version of MAD2.dsk available on http://fr3nch.t0uch.free.fr/MAD2/MAD2.html

[tomcw]

With the above fix (for bIrqOnLastOpcodeCycle), then under emulation Mad Effect now has a graphical glitch. Sometimes there is a half-pixel glitch on the vertical edge where it transitions from GR to HGR mode.

EDIT: NB. this glitch doesn't occur in "Color (RGB Monitor)" video mode... but this mode isn't NTSC.

Trying on real Apple //e (PAL) hardware, then I can see a similar glitch, and also sometimes it is more pronounced extending for a full 7 pixels.

So this is just a note that this isn't an emulation bug.

[tomcw]

@Archange427 sent me an mp4 showing this Mad Effect demo running glitch-free on his real Apple //e (PAL), but with MegaAudio sound-card. He thinks this can again probably be explained if the MegaAudio has 1 cycle difference in IRQ.

[tomcw]

Here's a test case which demonstrates the difference between a real Mockingboard/6522 and MegaAudio's emulated 6522: TestMegaAudio.zip

It's an auto-booting DOS disk (Mockingboard in any slot), which loads and runs a small test code at $6000 (I've included the source code too).

The theory is that the MegaAudio card's 6522 emulation is asserting the IRQ but 1 cycle late.

So the test code sets the Timer1 to a count of 0x0001 in one-shot mode.

Here's my understanding of the real 6522:

• STA $Cs05 ; set T1C_H and start timer
• CLI (cycle 1): 0x0001 -> 0x0000
• CLI (cycle 2): 0x0000 -> 0xFFFF
• LDA #1 (cycle 1): 0xFFFF -> 0xFFFE ==> IRQ
• LDA #1 (cycle 2)
• IRQ taken

And the MegaAudio's 6522:

• STA $Cs05 ; set T1C_H and start timer
• CLI (cycle 1): MegaAudio's 6522 counter doesn't decrement on this initial cycle! (Just a guess)
• CLI (cycle 2): 0x0001 -> 0x0000
• LDA #1 (cycle 1): 0x0000 -> 0xFFFF
• LDA #1 (cycle 2): 0xFFFF -> 0xFFFE ==> IRQ on last cycle of opcode, so 6502 defers to next opcode
• LDA #2 (cycle 1)
• LDA #2 (cycle 2)
• IRQ taken

The code when run will finish with a BRK, with the result in A and X.

A = 1 or 2, depending on the value of A when the interrupt occurred.
X = 1 (just a check to confirm that the interrupt handler was called once)

Results:

• Real MB/6522: A=1, X=1 (My Phasor card)
• MegaAudio: A=2, X=1 (@Archange427 confirmed)

I have passed this on to @PlamenVaysilov of a2heaven, who replied with:

I will check this , may be I have not precise emulate 6522 , I will check this .
The problem is that MegaAudio cannot be updated directly, for this is needed JTAG programmer and customers cannot make it itself .

I will try to correct this bug in next releases of firmware .