I was curious to hear how playing back SC-01 phonemes would sound on real SSI263 h/w. NB. Some old Mockingboards had the SC-01 speech chip, whereas the newer ones had the SSI263 chip.

So I dumped the SC-01 phonemes from 7 phrases from 4 games (The Spy Strikes Back, Crime Wave, Crypt of Medea & Berzap!), and then wrote some code to play them back using the SSI263. I used the same 64-phoneme translation table that's in AppleWin, and
just do it on-the-fly in my SSI263 interrupt handler.

There's more info here: https://github.com/tomcw/play-sc01-using-ssi263/blob/main/README.md

And also there are recordings from the real SSI263 and .dsk so that you can try it (it works on Mockingboards with either SC-01 or SSI263... and poorly on AppleWin).

btw. Does anyone even have an old SC-01-based Mockingboard?

The use-case for this would be to patch old SC-01-only games to work with the SSI263. But in reality there are only 4 games that use the SC-01, so it'd be a lot of effort for little gain (and Berzap! already supports Mockingboards with SC-01 or SSI263).

IMO the results of the SSI263 just playing back on-the-fly translated phonemes are pretty good, ie. the phrases are reasonably intelligible!

Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

TomCh <tomcharlesworth26@gmail.com> wrote:

So I dumped the SC-01 phonemes from 7 phrases from 4 games (The Spy
Strikes Back, Crime Wave, Crypt of Medea & Berzap!), and then wrote some
code to play them back using the SSI263.

Hi Tom,

Very interesting. Thank you for investigating and making some code
available.

I am interested in identifying all the phrases that are used and the location(s) in memory within the games.
Do you have any notes you can pass on about where the phrases you’ve found are in memory?

The use-case for this would be to patch old SC-01-only games to work with the SSI263.

As you know, but others may not,
I have another goal which is to convert all TotalReplay games that use
speech to use software SAM instead. This takes a bit of RAM and will
therefore require Apple //e 128k aux memory but is plausible so people
without Mockingboard speech can hear the speech in game.

I’d happily receive any help in this direction from anyone with a desire to contribute. Here’s where progress is being tracked: https://github.com/a2-4am/4cade/issues/272

Thanks!
Andrew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, 5 April 2021 at 14:07:19 UTC+1, Andrew Roughan wrote:

TomCh wrote:

So I dumped the SC-01 phonemes from 7 phrases from 4 games (The Spy Strikes Back, Crime Wave, Crypt of Medea & Berzap!), and then wrote some code to play them back using the SSI263.

Hi Tom,

Very interesting. Thank you for investigating and making some code available.

I am interested in identifying all the phrases that are used and the location(s) in memory within the games.
Do you have any notes you can pass on about where the phrases you’ve found are in memory?

The use-case for this would be to patch old SC-01-only games to work with the SSI263.

As you know, but others may not,
I have another goal which is to convert all TotalReplay games that use speech to use software SAM instead. This takes a bit of RAM and will therefore require Apple //e 128k aux memory but is plausible so people without Mockingboard speech can hear the speech in game.

I’d happily receive any help in this direction from anyone with a desire to
contribute. Here’s where progress is being tracked: https://github.com/a2-4am/4cade/issues/272

Thanks!
Andrew

Hi Andrew,

To dump the phoneme data, I just used AppleWin in a debug/logging mode to output each phoneme as it was played... so not what you are after. But it should be fairly simple to adapt this to output the address of the code, and then inspect it for the
phoneme data location. You could just search around this address for other phrases, as some may only playback for specific points in the game.

Berzap! is interesting, as it supports both SC-01 and SSI263 chips. I thought it may be doing what I've done, ie. convert phonemes via a look-up table, but it doesn't. Instead it just has separate phoneme data for each speech chip. What it does do is
vary things like the SC-01 pitch (b7:6) and SSI263 rate attributes for different in-game effects. Whereas all other games just use constant phoneme data.

Crypt of Medea (SC-01) and Classic Adventure (SSI263) are different as they will no doubt use a text-to-speech (TTS) routine, since there is so much spoken text. Presumably you can just hook this and redirect to the SAM TTS routine?

I will have a poke around (looking for phrase addresses) and comment directly in the GH issue.

Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

btw. Does anyone even have an old SC-01-based Mockingboard?

Hi Tom,

I have a Sound/Speech I card with the SC01. I had a try of your disk with it, but it does not seem to detect it and exits out to the monitor. It displays the headings, then the CPU type, and then exits directly to the monitor and I get the * prompt.
Looks like it might be triggering an NMI as these cards have one via hooked to irq and one to nmi. If I hack the nmi vector at 3fb with an rti ($40) and then run the program again it looks like it works ok.

I made a recording of the speech and added them to an existing dropbox folder (with card pics) I had if you are interested to have a listen. They are the sc01_speech files. (wav and mp3 versions)
https://www.dropbox.com/sh/gw2exw8g77acjuv/AAAhs5SsJ2B896XJOJQXlLHHa?dl=0

I also have a Mockingboard C with the SSI263, and that works great and is able to play the speech phrases ok.

/Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Rob,

Looks like it might be triggering an NMI as these cards have one via hooked to irq and one to nmi. If I hack the nmi vector at 3fb with an rti ($40) and then run the program again it looks like it works ok.

Ah, interesting - I see this is the same fix that you submitted to Total Replay. Now I understand why that fix was added.
Still it'd be interesting to see under what conditions the NMI is triggering, eg. Is it: 6522 interrupt or SC01 interrupt or both?

I made a recording of the speech and added them to an existing dropbox folder (with card pics) I had if you are interested to have a listen. They are the sc01_speech files. (wav and mp3 versions)

This is interesting, as your real SC01 speech is much slower than MAME's emulated SC01 speech. It is great to now be able to compare the two. I'll raise a bug against MAME asking them to look at this.

OK, I'm going to fix my code to hook NMI (+add some debug code to identify the NMI source), and then I'll probably ask for your help in running it.

Thanks,
Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, April 11, 2021 at 7:08:47 PM UTC+10, TomCh wrote:

Hi Rob,

Looks like it might be triggering an NMI as these cards have one via hooked to irq and one to nmi. If I hack the nmi vector at 3fb with an rti ($40) and then run the program again it looks like it works ok.

Ah, interesting - I see this is the same fix that you submitted to Total Replay. Now I understand why that fix was added.
Still it'd be interesting to see under what conditions the NMI is triggering, eg. Is it: 6522 interrupt or SC01 interrupt or both?

I made a recording of the speech and added them to an existing dropbox folder (with card pics) I had if you are interested to have a listen. They are the sc01_speech files. (wav and mp3 versions)

This is interesting, as your real SC01 speech is much slower than MAME's emulated SC01 speech. It is great to now be able to compare the two. I'll raise a bug against MAME asking them to look at this.

OK, I'm going to fix my code to hook NMI (+add some debug code to identify the NMI source), and then I'll probably ask for your help in running it.

Thanks,
Tom

I forgot to mention in the first reply, thanks for putting this together. Nice to have a good way to test and compare. And it is interesting to see them mapped from the SC01 to SSI263 and see how they come out.

There is a trimpot on the board that sets the pitch/speed of the SC01. I think I had it set quite slow. I did a couple more recordings with it set faster, there in the same folder, so i think the previous link should work. Have a listen, i think it does
sound better set a bit faster.

Not sure which is triggering the NMI, i think its probably the timer in the via, but not sure. I'm happy to test any code for this, just let me know.

/Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Rob,

I forgot to mention in the first reply, thanks for putting this together. Nice to have a good way to test and compare. And it is interesting to see them mapped from the SC01 to SSI263 and see how they come out.

The code also first does some basic 6522 checks, eg. tests data lines and IRQ (+ I need to add tests for address lines) - useful to quickly check that your Mockingboard's 6522s are correctly connected.

There is a trimpot on the board that sets the pitch/speed of the SC01. I think I had it set quite slow. I did a couple more recordings with it set faster, there in the same folder, so i think the previous link should work. Have a listen, i think it

does sound better set a bit faster.

OK, in the Votrax/SC01 data-sheet I see that the master clock can be controlled by an external source, and they give an example with a variable resistor.

Thanks,
Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Rob,

v0.2 available here: https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.2

Firstly this should fix the NMI issue for your "Sound/Speech I" card.

Secondly, I've added a 2nd entrypoint at $2004, eg. CALL 8196.
This uses a slightly different NMI handler to detect when NMI occurs.
Hopefully you'll get some output like this for you S/S I card:
Slot #4:NMI: 6522A=1 6522B=1 SC01=1 AY=2

The first 3 values (6522A,6522A,SC01) are flags that will indicate which interrupt sources generate NMIs (ie. 6522A-Timer1, 6522B-Timer1, SC01). I expect all 3 flags to get set to 1. Of course SC01 is routed via 6522A, but maybe 6522A is not connected to
NMI, but SC01 is directly connected. We'll see... (And btw, the NMI code is untested, as I have no hardware/emulator to check it with.)

The last value (AY) detects the presence of AY8913s by writing values, then reading them back. I just want to see if this is supported on your Mockingboard (as it is on my ReactiveMicro Mockingboard-C, but not on Phasor cards). It's a bitmap, so for your
MB-C it'll be set to 3 (ie. AY8913 at $Cn00 and $Cn80), and for you S/S card it should be 2 (ie. only an AY8913 at $Cn80).

When you get a chance to try it, then let me know the results.

Thanks,
Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Rob,

v0.2 available here: https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.2

Have you had a chance to test this newer version yet?

Thanks,
Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, April 24, 2021 at 4:59:37 AM UTC+10, TomCh wrote:

Hi Rob,

v0.2 available here: https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.2

Have you had a chance to test this newer version yet?

Thanks,
Tom

Hi Tom,

Sorry for the delay, I did finally get a chance run it. When I boot the disk I get:
Slot #4: Mockingboard failed test: 6522
after the cpu is detected.

When I run the 2nd entry point, I get:
Slot #4: NMI: 6522A=0 6522B=1 SC01=0 AY=0

I believe that the SC01 is only connected to the 6522 and not directly to any interrupt.(will trigger the interrupt via the 6522)

Hope this helps.
Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Rob,

Slot #4: Mockingboard failed test: 6522

I can't fully explain this failure: perhaps an issue with the card (which is what it's designed to detect), or a bug in my code.

It's interesting that on your 2nd run (via entrypoint $2004 - but same 6522-test codepath) it succeeds this basic 6522 test.

If possible, can you retry by power-cycling and running the same tests (CALL 8192, then CALL 8196) to see if you can repeat this 6522 test failure?

When I run the 2nd entry point, I get:
Slot #4: NMI: 6522A=0 6522B=1 SC01=0 AY=0

OK, so the 6522A (at $C400) doesn't generate NMI, nor does the SC01 (which is connected to that 6522A VIA).
Only the 6522B (at $C480, with the AY8913 attached) generates an NMI.

And "AY=0" means that it can't read the AY regs for the 6522/AY8913 located at $C480.
I was expecting "AY=2" (it's a bitmask, so "2" means it can write, then read AY8913 regs at $Cn80).

This is a bit of a shame, as it limits the real h/w testing that can be done from code... and this works for the newer Mockingboard-C variants.
Although if there is a h/w issue (as suggested above) then this may explain why the AY8913 can't be written/read back.

Thanks.
Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tom,

If possible, can you retry by power-cycling and running the same tests (CALL 8192, then CALL 8196) to see if you can repeat this 6522 test failure?

I did a few times and I always get the error for the first run, and then the second one works ok. If i remove the run from the hello program, then run the second test first after boot, then it gets the error. If I then run the second test again, it works
without the error. So something odd going on.

This is a bit of a shame, as it limits the real h/w testing that can be done from code... and this works for the newer Mockingboard-C variants.
Although if there is a h/w issue (as suggested above) then this may explain why the AY8913 can't be written/read back.

I double checked the wiring of the AY to the via, and it looks exactly like the later C rev. So its puzzling why its getting an error when trying to read back. I'll try and just run that part separately to see if its one register it cannot read, or some
general thing different. Will update back here what I find.

/Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Rob,

If possible, can you retry by power-cycling and running the same tests (CALL 8192, then CALL 8196) to see if you can repeat this 6522 test failure?

I did a few times and I always get the error for the first run, and then the second one works ok. If i remove the run from the hello program, then run the second test first after boot, then it gets the error. If I then run the second test again, it

works without the error. So something odd going on.

Under emulation, I can't reproduce this error:

I've tried with models: Apple II+(6502), Apple //e(6502) and Enhanced //e(65C02).

I also hacked AppleWin to make it appear to have just a single S/S card in slot-4 (6522+SC01 at $C400 and 6522+AY8913 at $C480). Again tested with the above 3 models, but couldn't reproduce.

NB. AppleWin doesn't support NMI, so I couldn't test that under emulation.

Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Rob,

I noticed an off-by-one buffer-overrun error (when saving/restoring the 3-byte NMI vector), so here's a fixed version:
https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.3

(Tested on real h/w & emulator)

I hope this fixes the error (although I can't reason why yet).
Tom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, May 2, 2021 at 6:54:09 PM UTC+10, TomCh wrote:

Hi Rob,

I noticed an off-by-one buffer-overrun error (when saving/restoring the 3-byte NMI vector), so here's a fixed version:
https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.3

(Tested on real h/w & emulator)

I hope this fixes the error (although I can't reason why yet).
Tom

I tried that but it did not make any difference :-(

I looked a bit more, and this is where it seems to be failing the first test. If I nop out the second branch to the error, before running, it passes ok.
ldy #SY6522_B_BASE+SY6522_IFR
lda #IxR_TIMER1
and (MBBase),y
beq @6522_err

cli
sei

and isrIFR_B
beq @6522_err --nop this out, then passes

@6522_ok
clc
rts

@6522_err
sec
rts

The isrIFR_B is set inside the IRQ handler, but then VIAB does not have any interrupts. When the NMI fires, this does not seem to get updated, so it is still zero. Not to sure why it works next time around.


/Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)