TUNE.COM - YM2149 Sound board not recognized by ROMWBW in SC126

[MorfeoMatrixx]

Hi Wayne, in my case, using the TUNE.COM CP/M program with the YM2149 board configured in the $60 IO address range for the SC126, the card is not recognized and defaults to the SCG adapter:

---

G>user 3 G>dir G: ATTACK PT3 : BACKUP PT3 : BADMICE PT3 : DEMO MYM G: DEMO1 MYM : DEMO3 MYM : DEMO3MIX MYM : DEMO4 MYM G: HOWRU PT3 : ITERATN PT3 : LOOKBACK PT3 : LOUBOUTN PT3 G: NAMIDA PT3 : RECOLL PT3 : SANXION PT3 : SYNCH PT3 G: TOSTAR PT3 : TUNE COM : VICTORY PT3 : WICKED PT3 G: YEOLDE PT3 : YEOVIL PT3 G>tune demo4.mym

Tune Player for RomWBW v2.0, 28-Jan-2018 RetroBrew SCG ECB Adapter, delay mode

Hardware error, sound chip not detected!

---

I made a minor fix to the TUNE.ASM code in the Platform Id section (attached) and now it works (and sounds...) OK:` tune-fix.txt

---

B>g: G>user 3 G>tune attack.pt3

Tune Player for RomWBW v2.1a, 17-Nov-2019 SC Z180 w/ Ed Brindley Sound Module, delay mode

Playing... Done

G> B>g: G>user 3 G>tune attack.pt3

Tune Player for RomWBW v2.1a, 17-Nov-2019 SC Z180 w/ Ed Brindley Sound Module, delay mode

Playing... Done

G>

---

Could you please check if the fix is correct or I'm screwing up something with your code ? I also made some format changes just for my understanding of the code

Thanks and regards, JL.

[wwarthen]

I always appreciate software fixes and contributions. I am very busy with real life at the moment, but will review as soon as possible.

Wayne

On Tue, Nov 19, 2019 at 10:22 AM MorfeoMatrixx notifications@github.com wrote:

Hi Wayne, in my case, using the TUNE.COM CP/M program with the YM2149 board configured in the $60 IO address range for the SC126, the card is not recognized and defaults to the SCG adapter:

G>user 3 G>dir G: ATTACK PT3 : BACKUP PT3 : BADMICE PT3 : DEMO MYM G: DEMO1 MYM : DEMO3 MYM : DEMO3MIX MYM : DEMO4 MYM G: HOWRU PT3 : ITERATN PT3 : LOOKBACK PT3 : LOUBOUTN PT3 G: NAMIDA PT3 : RECOLL PT3 : SANXION PT3 : SYNCH PT3 G: TOSTAR PT3 : TUNE COM : VICTORY PT3 : WICKED PT3 G: YEOLDE PT3 : YEOVIL PT3 G>tune demo4.mym

Tune Player for RomWBW v2.0, 28-Jan-2018 RetroBrew SCG ECB Adapter, delay mode

Hardware error, sound chip not detected!

I made a minor fix to the TUNE.ASM code in the Platform Id section (attached) and now it works (and sounds...) OK:` tune-fix.txt https://github.com/wwarthen/RomWBW/files/3865385/tune-fix.txt

B>g: G>user 3 G>tune attack.pt3

Tune Player for RomWBW v2.1a, 17-Nov-2019 SC Z180 w/ Ed Brindley Sound Module, delay mode

Playing... Done

G> B>g: G>user 3 G>tune attack.pt3

Tune Player for RomWBW v2.1a, 17-Nov-2019 SC Z180 w/ Ed Brindley Sound Module, delay mode

Playing... Done

G>

Could you please check if the fix is correct or I'm screwing up something with your code ? I also made some format changes just for my understanding of the code

Thanks and regards, JL.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wwarthen/RomWBW/issues/59?email_source=notifications&email_token=AATNT2O3FFS6MEPRI2OIXK3QUQVHHA5CNFSM4JPHOBC2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H2NUV3A, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATNT2LY6ZA2ILFQUFCAVM3QUQVHHANCNFSM4JPHOBCQ .

[MorfeoMatrixx]

Thanks Wayne, hope everything is going well. Don´t worry, I'm OK with the fix I made; I opened the issue because another RC2014 User Group member posted a question about a similar setup.

I can provide the fix if someone needs it, no need for you to rush on this low priority issue.

Cheers, JL.

On Tue, Nov 19, 2019 at 8:21 PM Wayne Warthen notifications@github.com wrote:

I always appreciate software fixes and contributions. I am very busy with real life at the moment, but will review as soon as possible.

Wayne

On Tue, Nov 19, 2019 at 10:22 AM MorfeoMatrixx notifications@github.com wrote:

Hi Wayne, in my case, using the TUNE.COM CP/M program with the YM2149 board configured in the $60 IO address range for the SC126, the card is not recognized and defaults to the SCG adapter:

G>user 3 G>dir G: ATTACK PT3 : BACKUP PT3 : BADMICE PT3 : DEMO MYM G: DEMO1 MYM : DEMO3 MYM : DEMO3MIX MYM : DEMO4 MYM G: HOWRU PT3 : ITERATN PT3 : LOOKBACK PT3 : LOUBOUTN PT3 G: NAMIDA PT3 : RECOLL PT3 : SANXION PT3 : SYNCH PT3 G: TOSTAR PT3 : TUNE COM : VICTORY PT3 : WICKED PT3 G: YEOLDE PT3 : YEOVIL PT3 G>tune demo4.mym

Tune Player for RomWBW v2.0, 28-Jan-2018 RetroBrew SCG ECB Adapter, delay mode

Hardware error, sound chip not detected!

I made a minor fix to the TUNE.ASM code in the Platform Id section (attached) and now it works (and sounds...) OK:` tune-fix.txt https://github.com/wwarthen/RomWBW/files/3865385/tune-fix.txt

B>g: G>user 3 G>tune attack.pt3

Tune Player for RomWBW v2.1a, 17-Nov-2019 SC Z180 w/ Ed Brindley Sound Module, delay mode

Playing... Done

G> B>g: G>user 3 G>tune attack.pt3

Tune Player for RomWBW v2.1a, 17-Nov-2019 SC Z180 w/ Ed Brindley Sound Module, delay mode

Playing... Done

G>

Could you please check if the fix is correct or I'm screwing up something with your code ? I also made some format changes just for my understanding of the code

Thanks and regards, JL.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/wwarthen/RomWBW/issues/59?email_source=notifications&email_token=AATNT2O3FFS6MEPRI2OIXK3QUQVHHA5CNFSM4JPHOBC2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H2NUV3A , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AATNT2LY6ZA2ILFQUFCAVM3QUQVHHANCNFSM4JPHOBCQ

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wwarthen/RomWBW/issues/59?email_source=notifications&email_token=ACCWCKAT4FNWZNWQPGCN4XLQURYFZA5CNFSM4JPHOBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEQD7OY#issuecomment-555761595, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCWCKATTVEXEMG6MES5FK3QURYFZANCNFSM4JPHOBCQ .

[b1ackmai1er]

If the build process was changed so that you nominate the platform prior to building the disk images then the platform config file from hbios/source could be copied over the the apps directory and #included in the apps (i.e. tune.com) assembly process so fixed port addresses in code could be eliminated.

[MorfeoMatrixx]

Thanks for the tip, I will try this better approach an make a proper PR request when it's working ok.

El mié., 20 nov. 2019 11:22, b1ackmai1er notifications@github.com escribió:

If the build process was changed so that you nominate the platform prior to building the disk images then the platform config file from hbios/source could be copied over the the apps directory and #included in the apps (i.e. tune.com) assembly process so fixed port addresses in code could be eliminated.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wwarthen/RomWBW/issues/59?email_source=notifications&email_token=ACCWCKGARYV3AG5WDXRQLTLQUVBYRA5CNFSM4JPHOBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEESEB3A#issuecomment-556024044, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCWCKB2GL5BW4HRRFBJ6DLQUVBYRANCNFSM4JPHOBCQ .

[wwarthen]

Hi Folks,

Please do not attempt to change the build process to set the platform before building the disk images. One of the specific objectives I have for RomWBW is that a floppy or hard disk image should be completely system agnostic. Although it complicates applications like XM and TUNE, However, I believe it is worth it. At present, you can place a disk image on a CF Card or SD Card and move it between systems at will which I consider very cool.

In a perfect world, access to the sound chip would be abstracted into HBIOS itself. However, as with XModem and TUNE, applications that are highly performance sensitive cannot sustain the overhead of the bank switching. So, the compromise is to use the platform id or something similar in HBIOS to dynamically select the I/O ports, etc. at startup.

Thanks!

Wayne

[wwarthen]

OK, I think I have worked through most of this. Your updates are fine, but it turns out that there are more issues.

The quark delay function was not recognizing the RCZ180 or SCZ180 as having a timer. This is easy to fix and I will take care of that.

The sound module uses the system clock divided by 4 for the PSG clock input. The PSG clock input should be 2MHz or below. Unfortunately, when using the normal speed Z180 (18.432MHz), this results in a PSG clock that is far too fast (over 4MHz). It seems to function, but the tune files are distorted when played.

The sound module really ought to have it's own oscillator, but it doesn't. So, I think what I will need to do for the RCZ180 and SCZ180 is change the CPU clock rate to divide by 2 while the sound file is playing. That will result in about a 2.25 MHz PSG clock. Still not good, but I don't see any other options right now. It will also muck up the serial port baud rates during the playing of the tune which means that pressing a key to abort playing may not work.

Any thoughts on this would be appreciated.

-Wayne

[MorfeoMatrixx]

Wayne, IMHO, I think that you're right about not changing the build process; maintaining portability & compatibility (in both platforms and media) is one of ROMWBW's most valuable contributions.

The proposed solution should be OK. Even at a different baudrate, there is a good chance that a random key pressed at the terminal will still be recognized as a valid serial frame but different character by the program, so tune playing can still be stopped. I can test this and we can select a specific key that is consistently recognized.

Cheers, JL,

On Wed, Nov 20, 2019 at 8:27 PM Wayne Warthen notifications@github.com wrote:

OK, I think I have worked through most of this. Your updates are fine, but it turns out that there are more issues.

The quark delay function was not recognizing the RCZ180 or SCZ180 as having a timer. This is easy to fix and I will take care of that.

The sound module uses the system clock divided by 4 for the PSG clock input. The PSG clock input should be 2MHz or below. Unfortunately, when using the normal speed Z180 (18.432MHz), this results in a PSG clock that is far too fast (over 4MHz). It seems to function, but the tune files are distorted when played.

The sound module really ought to have it's own oscillator, but it doesn't. So, I think what I will need to do for the RCZ180 and SCZ180 is change the CPU clock rate to divide by 2 while the sound file is playing. That will result in about a 2.25 MHz PSG clock. Still not good, but I don't see any other options right now. It will also muck up the serial port baud rates during the playing of the tune which means that pressing a key to abort playing may not work.

Any thoughts on this would be appreciated.

-Wayne

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wwarthen/RomWBW/issues/59?email_source=notifications&email_token=ACCWCKAXK2AOKJGBOMBLA4LQUXBVFA5CNFSM4JPHOBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEWDWLA#issuecomment-556546860, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCWCKF5RX3R5MFVVCLLS6DQUXBVFANCNFSM4JPHOBCQ .

[wwarthen]

Well, good news/bad news.

Good news: I have just checked in an updated TUNE application. It does a much better job resolving the hardware environment and adapting to it.

Bad news: I ran into unexpected issues with slowing down the Z180 CPU speed while playing a tune. The main problem is that when the CPU speed is changed, the timer interrupt frequency is also changed, so the resulting playback is totally borked. While I could do a lot of fancy stuff to adjust the timer on the fly when I change the CPU speed, I think this has gotten far too complicated.

There are two ways to resolve this issue of using the Ed Brindley sound module on a Z180 at normal (18.432 MHz) speed...

The first and by far the best is to convince Mr. Brindley to add an onboard oscillator to his sound module. I think this should be pretty straightforward.

The second is to use a YM2149 PSG and set the jumper at JP6. The YM2149 PSG has the ability to halve the clock internally. By setting JP6 w/ YM2149, you will wind up with a PSG clock of 2.3 MHz which is exactly the same thing as if I reduced the Z180 clock speed in half. Note that 2.3 MHz is still faster than it should be which is why the first option of adding an onboard oscillator is so much better. Regardless, I find that using a YM2149 + JP6 does result in reasonable playback.

I am open to further thoughts on this.

Thanks,

Wayne

[MorfeoMatrixx]

Wayne, another hardware option "for Mr. Brindley" is to replace the 74HCT74 (dual D type FF) with a 74HCT175 (quad), so we can divide the CLK by 8 at the sound board without slowing down the CPU. I think I'll try this way modding the PCB.

Cheers, JL.

On Thu, Nov 21, 2019 at 9:37 PM Wayne Warthen notifications@github.com wrote:

Well, good news/bad news.

Good news: I have just checked in an updated TUNE application. It does a much better job resolving the hardware environment and adapting to it.

Bad news: I ran into unexpected issues with slowing down the Z180 CPU speed while playing a tune. The main problem is that when the CPU speed is changed, the timer interrupt frequency is also changed, so the resulting playback is totally borked. While I could do a lot of fancy stuff to adjust the timer on the fly when I change the CPU speed, I think this has gotten far too complicated.

There are two ways to resolve this issue of using the Ed Brindley sound module on a Z180 at normal (18.432 MHz) speed...

The first and by far the best is to convince Mr. Brindley to add an onboard oscillator to his sound module. I think this should be pretty straightforward.

The second is to use a YM2149 PSG and set the jumper at JP6. The YM2149 PSG has the ability to halve the clock internally. By setting JP6 w/ YM2149, you will wind up with a PSG clock of 2.3 MHz which is exactly the same thing as if I reduced the Z180 clock speed in half. Note that 2.3 MHz is still faster than it should be which is why the first option of adding an onboard oscillator is so much better. Regardless, I find that using a YM2149 + JP6 does result in reasonable playback.

I am open to further thoughts on this.

Thanks,

Wayne

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wwarthen/RomWBW/issues/59?email_source=notifications&email_token=ACCWCKGCG2L46LLHSUQ6JGTQU4SWNA5CNFSM4JPHOBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE4EIYQ#issuecomment-557335650, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCWCKCFZ5KJBDXL3TGGNBLQU4SWNANCNFSM4JPHOBCQ .

[wwarthen]

Well, yes, but keep in mind that the ideal PSG clock frequency is about 1.75 MHz for accurate sound file playback (because that is the frequency used by MSX and ZX Spectrum computers). The additional divide on a Z180 running at 18.432 MHz will result in a PSG clock of 2.3 MHz which is fairly far off of the target.

[b1ackmai1er]

Hi JL, just for your info, I was advising Wayne, I also realized I was having problems with my ECB-SBC + ECB-PSG as well. Using TUNE, music was not stopping at end. Turns our 10Mhz Z80 is too fast. Was able to overcome using CPU clock divider on my board. I originally implemented this as a patch here: https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:sbc_v2:start#speed_switch_modification and then fully implemented it here: https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:sbc_v2:sbc_v2-004.

I'll upload version sbc-v2-004z schematic which has the corrected clock divider circuit on it. May be of some use as reference.

Regards Phil

[feilipu]

Another hardware option is to replace the 74HCT74 (dual D type FF) with a 74HCT175 (quad), so we can divide the CLK by 8 at the sound board without slowing down the CPU.

For a similar application, I needed to get a clock rate of less than 3MHz off the z180 PHI. I used a SN74LS93 which gave me options to divide by 8 or 16.

Perhaps the alternative part SN74LS90, being divide by 10, would be about right? It would still be a bit fast, but within the spec. Although it is a LS part, the front end runs up to 32MHz, which is sufficient for this application.

[MorfeoMatrixx]

Phil, you’re right, divide by ten would be the closest match. Or free ourselves from the CPU clock fitting the sound board with a 3.58 NTSC color burst oscillator divided by 2, maybe that’s what the Sinclair Spectrum does.

Cheers, JL.

On Sat, Nov 23, 2019 at 7:41 AM Phillip Stevens notifications@github.com wrote:

Another hardware option is to replace the 74HCT74 (dual D type FF) with a 74HCT175 (quad), so we can divide the CLK by 8 at the sound board without slowing down the CPU.

For a similar application, I needed to get a clock rate of less than 3MHz off the z180 PHI. I used a SN74LS93 which gave me options to divide by 8 or 16.

Perhaps the alternative part SN74LS90, being divide by 10, would be about right? It would still be a bit fast, but within the spec. Although it is a LS part, the front end runs up to 32MHz, which is sufficient for this application.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wwarthen/RomWBW/issues/59?email_source=notifications&email_token=ACCWCKHBR5DPP76DZGOQQRLQVECFRA5CNFSM4JPHOBC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7SNWQ#issuecomment-557786842, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCWCKA446TUEXFXIIYUV3DQVECFRANCNFSM4JPHOBCQ .

--

Saludos, José Luis.

[wwarthen]

I am going to go ahead and close this issue. The original problem with hardware detection is definitely resolved. The first follow-up issue of slowing down I/O for the PSG on the Z180 is resolved. The second follow-up issue of CPU frequency on the RC2014 Z180 system variants is not resolved by code. However, I think it is reasonable to consider this a hardware level issue for which several workarounds have been described