Apple II Mockingboard Test Disk issues

[ryandesign]

Thanks for adding Mockingboard support to the Apple II! 🎉

It's not quite right yet. Try the Mockingboard v1 Test Disk 1/2 from Sweet Micro Systems.

What happens in MAME 0262 and Virtual ][ 11.4 is that a note is played repeatedly from the left speaker while the letters of the word "MOCKINGBOARD" fly onto the screen four times. When each letter settles, a percussive sound is played from the right speaker. Then, two rising tones play while the entire screen scrolls up and out of view, after which the main menu loads.

In today's Clock Signal code, the repeated note is not the same as that in MAME and Virtual ][. Clock Signal repeats it at a faster rate. I think this is a problem with a parameter of the hardware envelope generator. (Disclaimer: I don't have a real Mockingboard in my Apple II so I can't say for certain whether the MAME and Virtual ][ behavior is correct.)

Then, sometimes, in Clock Signal, during the rising tones, the screen does not scroll up and the main menu is not displayed.

[TomHarte]

I guess it's also possible that I have the 6522s incorrectly clocked or similar — possibly some part of the demo is interrupt driven? I'll look into it.

[ryandesign]

In the Pure Noise demo from French Touch, most of the voices (those using square wave or noise) sounded like they do in MAME and Virtual ][, but those using the hardware envelope to create low buzzing basses didn't sound right—they sounded out of tune. But I figured it would be easier to test with the simpler Test Disk from the Mockingboard manufacturer.

[ryandesign]

Thanks, the pitches sound better after that change.

There is still a peculiar oscillating quality, at a period of about 1.4 seconds, in the left channel of Clock Signal's output on the test disk's splash screen that I don't hear in MAME or Virtual ][.

I'm still seeing the test disk's splash screen fail to scroll up more often than not. If I patch the HELLO program on that disk to make it stay in text mode by adding this line:

65 POKE 32778,81

And saving it to disk with:

UNLOCK HELLO
SAVE HELLO

Then I see that after the splash screen is drawn (which due to the patch will no longer be displayed) and just before the rising tone begins playing, the program has exited to the Monitor's * prompt. I have not traced the code to see why it's doing that yet.

[TomHarte]

I haven't yet been able to reproduce the failure to scroll; I guess that's therefore pointing to some sort of uninitialised variable, and my having a lucky environment? Will keep looking.

[ryandesign]

Here's a test program that repeatedly prints the first 16 bytes of a slot (configure the slot number on the 0th line):

0 S = 4
1 T = 8:B = 49152 +256 *S: TEXT : HOME : PRINT "C"S"00 +";: HTAB T: FOR H = 0 TO 15: PRINT " ";: GOSUB 5: NEXT : POKE 34,1: PRINT
2  HTAB T: FOR A = B TO 15 +B:HH =  PEEK(A): GOSUB 4: NEXT : PRINT : IF  PEEK(49152) <128  THEN 2
3  POKE 49168,0: TEXT : END
4 H =  INT(HH/16): GOSUB 5:H = HH -H *16: GOSUB 5: RETURN
5  IF H <10  THEN  PRINT H;: RETURN
6  PRINT  CHR$(55 +H);: RETURN

Here is normal output for slot 4:

Bytes 4 and 5 are timer 1 and bytes 8 and 9 are timer 2 and they're expected to change like this.

But eventually something goes wrong and the slot returns totally wrong data:

Once the problem occurs, it affects all slots except 0 and 3; I can't use the disk anymore with PR#6 for example. The wrong data is different in each slot but is always the same for that slot across multiple runs of Clock Signal.

I don't know what conditions lead to the problem. It doesn't seem to happen if I just leave the above test program running. I have to leave the emulator not doing anything for awhile before it'll happen.

I believe this is the cause of the Sweet Micro Systems test disk failure to scroll. I think it could also cause another problem I saw occasionally with the Pure Noise disk where it would load the first song but never advance the track time display and the audio was just garbled noise.

[ryandesign]

1BAD 61C0 8505 A2FF 9AA9 F085 36A9 FD85 are the bytes in the Apple IIe unenhanced ROM starting at offset 0x4400 from the beginning of the ROM file.

[ryandesign]

1BAD 61C0 8505 A2FF 9AA9 F085 36A9 FD85 are the bytes in the Apple IIe unenhanced ROM

This would suggest that INTCXROM has become active (i.e. there was a write to C007).

I believe this is the cause of the Sweet Micro Systems test disk failure to scroll.

After encountering the issue again, I checked C400–C40F and it looked reasonable (FCFF 07FF B624 00CF F70A 0040 0040 80FF) and C015 was non-negative so INTCXROM was not active. So the failure to scroll appears to have a different cause and I'll have to continue reading through their code to see what they're doing.

Since interrupts aren't normally in use on the Apple II but they are with the Mockingboard, I could imagine a problem with how interrupts are handled, depending on when the interrupt happens, relating to the just-in-time emulation, much like that issue with the Disk II state machine timing.

[ryandesign]

This would suggest that INTCXROM has become active

I have to break this out into a separate issue because it occurs even in a build of Clock Signal from before Mockingboard support was added.

[ryandesign]

There is still a peculiar oscillating quality, at a period of about 1.4 seconds, in the left channel of Clock Signal's output on the test disk's splash screen that I don't hear in MAME or Virtual ][.

GitHub doesn't seem to allow attaching audio files but here they are in a zip archive.

LeftChannelAudio.zip

[TomHarte]

I'm still no closer to determining the source of this, but have also been considering my options for audio filtering; it currently uses a FIR because graphics output does too and it's easier to have only the one source of coefficients, and for most machines — including the Apple II — each input sample is only going to contribute to at most two output samples so there's no real distinction on efficiency.

The just-introduced Archimedes though has a shocking 2.2Khz low-pass filter, which I've declined yet to modify the filter-generation code for. But a net effect is that with a 44.1Khz output, 953 (!) input samples contribute to every output sample, meaning that each individual input sample is used something like 42 times (!!)

So an IIR there would be an obvious win, though whether that's the right choice versus just being smarter in FIR implementation I don't yet know.