RomWBW boot beep

[Martin Giese]

Hi there!

I got a batch of 5 YM2149 from China, and all of them work just fine (gasp!).  

I used an ATF16v8 for the address decoding and dividing the clock by 4.  TUNE.COM works, and I even get a little beep at startup.

I’d like play with the sound of that startup beep.  I assume it’s SND_BEEP that does it, but I can’t find the place where that gets called at startup?  I don’t want to change every beep into a grand fanfare.

Martin

[Wayne Warthen]

Hi Martin,

The beep function is implemented in each sound driver.  However, it most cases, the driver just calls SND_BEEP in hbios.asm.  During the boot process, hbios.asm will call the first sound driver's BEEP function.  That driver will then call the common SND_BEEP in hbios.asm.

So, if you want to play with the beep that is issued at startup, you can modify hbios.asm at about line 3837.  You will need to change it to not call the driver BEEP function, but instead play whatever tone(s) you desire.  You can model this from SND_BEEP, but don't modify SND_BEEP itself or you will change all beeps.

Thanks, Wayne

[Martin Giese]

Thank you Wayne!

I found the code where you left it :-)

I changed it to test (as before) whether there is a sound device, and if so if device 0 is an AY-3-8910 type.  If yes, it calls "AY_CHIME" which I added to ay38910.asm; otherwise it calls the system beep as before.  The chime itself is a little chord with an envelope, and probably not everybody’s cup of tea, so I won’t send a pull request for that.

I did stumble across spk.asm however, which is coded around the assumption that the 1 bit speaker is controlled by bit 2 of the RTC latch.  My own little beeper happens to be on bit 0 of port 1.

I refactored this so that there are config variables like this in cfg_MASTER.asm

SPKENABLE .EQU FALSE ; SPK: ENABLE RTC LATCH IOBIT SOUND DRIVER (SPK.ASM)
SPKPORT .EQU RTCIO ; SPK: THE PORT WITH THE SPEAKER IO BIT
SPKSHADOW .EQU HB_RTCVAL ; SPK: THE SHADOW VALUE FOR THE PORT THAT HAS TO BE MAINTAINED
SPKMASK .EQU 00000100b ; SPK: THE BIT MASK TO ACTUALLY TOGGLE

So SPKSHADOW is the address of the shadow value the port should be returned to after the beep.  Simply setting the enable to true (as is done in the few system config files that use it) should give the same behaviour as before.  But it’s now easy to adjust to other IO bits.

The only problem, as usual: I can’t actually test whether it doesn’t break any other system.

Want me to send a pull request?

Martin

[Wayne Warthen]

On Sun, Jul 6, 2025 at 10:29 PM Martin Giese <mabar...@gmail.com> wrote:

I changed it to test (as before) whether there is a sound device, and if so if device 0 is an AY-3-8910 type.  If yes, it calls "AY_CHIME" which I added to ay38910.asm; otherwise it calls the system beep as before.  The chime itself is a little chord with an envelope, and probably not everybody’s cup of tea, so I won’t send a pull request for that.

Glad that worked out.

I did stumble across spk.asm however, which is coded around the assumption that the 1 bit speaker is controlled by bit 2 of the RTC latch.  My own little beeper happens to be on bit 0 of port 1.

I refactored this so that there are config variables like this in cfg_MASTER.asm

SPKENABLE .EQU FALSE ; SPK: ENABLE RTC LATCH IOBIT SOUND DRIVER (SPK.ASM)
SPKPORT .EQU RTCIO ; SPK: THE PORT WITH THE SPEAKER IO BIT
SPKSHADOW .EQU HB_RTCVAL ; SPK: THE SHADOW VALUE FOR THE PORT THAT HAS TO BE MAINTAINED
SPKMASK .EQU 00000100b ; SPK: THE BIT MASK TO ACTUALLY TOGGLE

So SPKSHADOW is the address of the shadow value the port should be returned to after the beep.  Simply setting the enable to true (as is done in the few system config files that use it) should give the same behaviour as before.  But it’s now easy to adjust to other IO bits.

The only problem, as usual: I can’t actually test whether it doesn’t break any other system.

Want me to send a pull request?

Yes, please do.  I may or may not use it depending on testing, but I suspect it will be useful.

Thanks, Wayne