Hi Rob,

Thanks for digging into this... I understand my mistake now. Try this one:
https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.4

My main misunderstanding was to think that the 2nd 6522 (at $Cn80) was connected to both IRQ & NMI. Whereas obviously(!) the S/S card is wired like this:
- 1st 6522/VIA at $Cn00 (for the SC-01) is wired to IRQ
- 2nd 6522/VIA at $Cn80 (for the AY-3-8913) is wired to NMI

So in the 2nd part of that test (for the 6522 at $Cn80) it wasn't seeing an IRQ, and hence the failure.

Then when you re-ran the test, because I wasn't zeroing the variable isrIFR_B, then the IRQ was still pending from the first run, so in the earlier CLI/SEI code the IRQ would fire and set this flag.

Anyway, hopefully all understood now & fixed.

Let me know!
Tom

On Tuesday, 4 May 2021 at 20:55:57 UTC+1, TomCh wrote:
> Hi Rob,
>
> Thanks for digging into this... I understand my mistake now. Try this one:
> https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.4
>
> My main misunderstanding was to think that the 2nd 6522 (at $Cn80) was connected to both IRQ & NMI. Whereas obviously(!) the S/S card is wired like this:
> - 1st 6522/VIA at $Cn00 (for the SC-01) is wired to IRQ
> - 2nd 6522/VIA at $Cn80 (for the AY-3-8913) is wired to NMI
>
> So in the 2nd part of that test (for the 6522 at $Cn80) it wasn't seeing an IRQ, and hence the failure.
>
> Then when you re-ran the test, because I wasn't zeroing the variable isrIFR_B, then the IRQ was still pending from the first run, so in the earlier CLI/SEI code the IRQ would fire and set this flag.
>
> Anyway, hopefully all understood now & fixed.
>
> Let me know!
> Tom

Oops, I forgot to set the NMI vector for the main SC-01/Timer1 interrupt handler.
(So there was a small chance v0.4 would hang mid-way through an SC-01 speech phrase)

This update fixes that:
https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.5

Tom

TomCh <tomcharlesworth26@gmail.com> wrote:
> Hi Rob,
>
> Thanks for digging into this... I understand my mistake now. Try this one:
> https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.4
>
> My main misunderstanding was to think that the 2nd 6522 (at $Cn80) was
> connected to both IRQ & NMI. Whereas obviously(!) the S/S card is wired like this:
> - 1st 6522/VIA at $Cn00 (for the SC-01) is wired to IRQ
> - 2nd 6522/VIA at $Cn80 (for the AY-3-8913) is wired to NMI
>
> So in the 2nd part of that test (for the 6522 at $Cn80) it wasn't seeing
> an IRQ, and hence the failure.
>
> Then when you re-ran the test, because I wasn't zeroing the variable
> isrIFR_B, then the IRQ was still pending from the first run, so in the
> earlier CLI/SEI code the IRQ would fire and set this flag.
>
> Anyway, hopefully all understood now & fixed.
>
> Let me know!
> Tom
>

Shame on the Mockingboard designers for using NMI at all. It renders the
card functionally incompatible with any code requiring interrupts to be
disabled (Disk II access, for example).

IRQ could easily serve both interrupt sources with the addition of a little
checking code in the interrupt routine.

It is much safer to have your sound/speech synthesis briefly interrupted
than to have your disk blown by an NMI during a disk write!

BTW, it’s not their only error: they neglected to diode-OR the /RESET line
to the AY’s and the speech chip, resulting in continuous sound if the
machine is reset while a sound is being generated. (I had a short article
in Call-A.P.P.L.E. describing how to fix this.)

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Hi Rob,

I hacked AppleWin to support the S/S card, complete with NMI for the 2nd 6522... and hit another bug in my code :-/
So here's v0.6:
https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.6

@Michael: yes, shame on them - I 100% agree!
Of course they fixed this design issue in their newer Mockingboard A & C variants, by only using IRQ.
An as you say, it's simple enough to check the 6522's interrupt flag register (IFR) to determine the interrupt source.

Of course, some games interrupt handlers didn't bother, and just assumed the interrupt was from a certain source.
See my "Willy Byte" talk from KansasFest last year for fun times...
https://www.youtube.com/watch?v=6Bnc6zYOlcI

Tom

> I hacked AppleWin to support the S/S card, complete with NMI for the 2nd 6522... and hit another bug in my code :-/
> So here's v0.6:
> https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.6
>
Wow, that some extra effort there. I did do a quick test yesterday and noticed it did not work, but wanted to make sure I wasn't doing something stupid with it.

The new version v0.6 works great. I did test with both SoundSpeech I and a Mockingboard C clone I have with a SSI263 and it works great with either. Nice work hacking that in to test and debug.

/Rob

> The new version v0.6 works great. I did test with both SoundSpeech I and a Mockingboard C clone I have with a SSI263 and it works great with either. Nice work hacking that in to test and debug.
>

That's great to hear.

And this is timely too, as I'm working on a Mockingboard/Phasor "audit" to test real h/w and also emulators (a release is imminent!). I will fold in these fixes so that your S/S card is better supported. NB. Since I can't read back the AY-3-8913 registers after writing them, then if I detect an S/S card I will just hardcode the number of AY's to be 1.

btw, if I add you SC-01 recording to my "play-sc01-using-ssi263" GitHub page + credit you... I assume that's OK?

Thanks,
Tom

> And this is timely too, as I'm working on a Mockingboard/Phasor "audit" to test real h/w and also emulators (a release is imminent!). I will fold in these fixes so that your S/S card is better supported. NB. Since I can't read back the AY-3-8913 registers after writing them, then if I detect an S/S card I will just hardcode the number of AY's to be 1.

Sounds interesting, will keep an eye out for the release. I'd forgotten about that reading issue from the AY. It seems another odd behavior, i did check the wiring and it looks the same as the other cards. So maybe some timing issue. I'll try to have a play with that and see if i can see why.

> btw, if I add you SC-01 recording to my "play-sc01-using-ssi263" GitHub page + credit you... I assume that's OK?
Yes, sure, happy for you to add that in your github page.

/Rob

> Sounds interesting, will keep an eye out for the release.

See comp.emulators.apple2 for my announcement about "mb-audit".
If you get a chance then please try your S/S card (using emulation this time, I hope I've nailed all the issues with your card).

>I'd forgotten about that reading issue from the AY. It seems another odd behavior, i did check the wiring and it looks the same as the other cards. So maybe some timing issue. I'll try to have a play with that and see if i can see why.

Thanks, and if you need any new builds to experiment with then let me know.

Tom

>I'd forgotten about that reading issue from the AY. It seems another odd behavior, i did check the wiring and it looks the same as the other cards. So maybe some timing issue. I'll try to have a play with that and see if i can see why.

My code for reading AY registers looks dodgy!

Yes it works OK on my ReactiveMicro's Mockingboard, but on looking at it again the order I'm doing things (PSG READ -> PSG INACTIVE -> read VIA PortA) looks clearly wrong. Also the timing can definitely be tightened up.

I'll try to rework this code later this evening.

Tom

On Tuesday, 11 May 2021 at 16:31:19 UTC+1, TomCh wrote:
>I'd forgotten about that reading issue from the AY. It seems another odd behavior, i did check the wiring and it looks the same as the other cards. So maybe some timing issue. I'll try to have a play with that and see if i can see why.

Here's a fixed version that should now read the AY registers on both of your cards:
https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.7

Use the 2nd entrypoint at $2004, eg. CALL 8196 to check reading the AY registers. For your S/S you should see:
Slot #4: NMI: 6522A=0 6522B=1 SC01=0 AY=2

NB. I checked on my Phasor (in Mockingboard mode) and AY reading is now working for me with this card too. And it continues to work with my ReactiveMicro's MB-C card.

Tom

> Here's a fixed version that should now read the AY registers on both of your cards:
> https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.7
>
> Use the 2nd entrypoint at $2004, eg. CALL 8196 to check reading the AY registers. For your S/S you should see:
> Slot #4: NMI: 6522A=0 6522B=1 SC01=0 AY=2
I tested with my S/S and get that result now.
And I get AY=3 on my MB-C card ok.

All working nicely now!

/Rob

> > Slot #4: NMI: 6522A=0 6522B=1 SC01=0 AY=2
> I tested with my S/S and get that result now.
> And I get AY=3 on my MB-C card ok.
>
> All working nicely now!

That's wonderful to hear!
Thanks very much for your patience and suggestions/help in tracking these issues down.

I've already merged these fixes into my more extensive "mb-audit" (v0.2-beta) test suite.

Tom