I Crashed My Fiesta: If a Torch beeps in a forest, does it make a sound?

So, the Torch emulator is ticking along nicely. But silently. It's fair to say that the Torch is not exactly endowed with an extensive sound system such as was had by the Amiga or even the C64. As per most 'serious' computers of the time, it basically had a beeper. It was a little more advanced than the IBM PC since it does not have a discrete speaker, rather the beeps are piped through the video output connector.

Content warning again. Because this is about audio, this blog doesn't have many screenshots. It has a youtube video at the end, though.

At startup, the system beeps a la PC but then once the initial memory is tested OK, it makes a rising 'whoop' sound before loading in the main Caretaker software to continue starting up. Except that the emulator doesn't. It's currently completely silent. So what to do.

Using the SDL library for sound should be relatively straightforward but we still need to know how the 'audio' is actually generated. To the schematics, Batman!

Video Connector Pins

We can see from this where the sound comes out but we need to follow the lines back to the origin of the 'AUDIO' signal. Fortunately, as the system is simple (at least for sound) the AUDIO signal only appears on one other sheet, which shows that the 6303 service processor is the source of the sound. From pin 9. :)

Audio from pin 9 on the 6303

So, the audio is a simple square waveform (as previously seen from the hardware when testing the Torch motherboard) which is generated by the 6303. This then passes through a simple amplifier circuit and out to the speaker pins on the video output socket. Easy.

Error beeps from the real hardware

But now what? I know that the system does its 'whoop' before anything else appears to happen so I think it's safe to assume that the code for that is in the Caretaker ROM. After a bit of analysis it seemed that there was code specifically for the 6303 but also for the 68010. Given that the audio is generated by the 6303 I assumed that the code for the 68010 could be discounted - at least for now. But what the Caretaker ROM did include was a series of what looked like progressively shorted speaker pulses. This would be exactly what you would see to create a 'whoop' noise.

The original code of the emulator (which if you recall, was not actually done by me) is running the timer needed but it just isn't turning the output into sound.

The key thing about all this is that the emulator was missing the specific VSYNC signal required by the service processor. This is received by the 6303, marking the start of each video frame. That signal prompts it to run a regular housekeeping routine. The new code adds a simulated 50 times a second signal, along with handling the interrupts to allow the firmware (Caretaker) to receive and acknowledge it. That housekeeping routine controls the sound duration (and another surprise for later).

So, when I came to test the code (after eliminating the usual sausage fingers and low-talent related errors), I was quite surprised by the results. The sound works perfectly. The 'beep' and 'whoop' at startup worked great and the entering the command:

echo -ne '\007'

resulted in the expected 'beep'. The ASCII 007 is actually 'Bell' which is a really ancient hangover from early computer systems.

But the BIG surprise was the palette. The addition of the routines to manage the missing VSYNC signal had an additional affect. The palette selection all now works exactly as it should. Previously, changing the colours on the screen did not actually make any difference. The only way to change the colours was to alter the 'fallback' colours in the source code. The control panel on Torch Unix just did not work.

It does now. :)