Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Mockingboard: Playing SC-01 speech on an SSI263
514 views
Skip to first unread message
TomCh
Apr 5, 2021, 7:29:32 AM4/5/21
to
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
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
Andrew Roughan
Apr 5, 2021, 9:07:19 AM4/5/21
to
TomCh <tomcharl...@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,
> 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.
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.
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
TomCh
Apr 5, 2021, 12:25:26 PM4/5/21
to
On Monday, 5 April 2021 at 14:07:19 UTC+1, Andrew Roughan wrote:
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
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
Rob J
Apr 11, 2021, 4:15:41 AM4/11/21
to
> btw. Does anyone even have an old SC-01-based Mockingboard?
>
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
TomCh
Apr 11, 2021, 5:08:47 AM4/11/21
to
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
> 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.
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)
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
Rob J
Apr 11, 2021, 7:05:14 AM4/11/21
to
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
TomCh
Apr 11, 2021, 2:42:25 PM4/11/21
to
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
> 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.
>
Thanks,
Tom
TomCh
Apr 13, 2021, 4:32:30 PM4/13/21
to
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
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
TomCh
Apr 23, 2021, 2:59:37 PM4/23/21
to
Have you had a chance to test this newer version yet?
Thanks,
Tom
Thanks,
Tom
Rob J
Apr 26, 2021, 6:37:27 AM4/26/21
to
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
TomCh
Apr 27, 2021, 12:29:07 PM4/27/21
to
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
>Slot #4: Mockingboard failed test: 6522
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
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
Rob J
Apr 29, 2021, 7:44:10 AM4/29/21
to
Hi Tom,
> 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
> 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.
/Rob
TomCh
May 1, 2021, 1:17:28 PM5/1/21
to
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
> > 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.
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
TomCh
May 2, 2021, 4:54:09 AM5/2/21
to
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 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
Rob J
May 3, 2021, 11:53:18 PM5/3/21
to
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
TomCh
May 4, 2021, 3:55:57 PM5/4/21
to
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
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
TomCh
May 5, 2021, 4:26:08 PM5/5/21
to
(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
Michael J. Mahon
May 5, 2021, 4:38:32 PM5/5/21
to
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
TomCh
May 5, 2021, 5:58:08 PM5/5/21
to
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
@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
Rob J
May 6, 2021, 4:48:30 AM5/6/21
to
> 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.
> So here's v0.6:
> https://github.com/tomcw/play-sc01-using-ssi263/releases/tag/v0.6
>
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
TomCh
May 7, 2021, 5:00:45 PM5/7/21
to
> 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
Rob J
May 9, 2021, 3:45:42 AM5/9/21
to
> 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?
/Rob
TomCh
May 9, 2021, 4:31:57 PM5/9/21
to
> 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.
Tom
TomCh
May 11, 2021, 11:31:19 AM5/11/21
to
>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
TomCh
May 11, 2021, 4:53:11 PM5/11/21
to
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:
>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.
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
Rob J
May 12, 2021, 6:59:04 AM5/12/21
to
> 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.
> 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
And I get AY=3 on my MB-C card ok.
All working nicely now!
/Rob
TomCh
May 12, 2021, 4:56:31 PM5/12/21
to
> > 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!
> 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!
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
0 new messages