Quack sound

[larsbrinkhoff]

@MikeShawaluk told me this:

How accurate is your emulation? Does it include a “beep” when the BEL (0x07) ASCII code is received. And, most importantly, does the terminal “quack” if you send a BEL followed by a FF (0x0C)?

I remember accidentally discovering the “quack” sound when someone typed a binary file to the screen that had those characters in it. (I seem to recall that the quacking sound only occurred if smooth scrolling was not enabled). One of us made a file called DUCK.TXT which included several BEL / FF pairs, followed by an ASCII art rendition of a duck.

[larsbrinkhoff]

I'm trying to form a theory on how the VT100 could emit a quack.

A key click and a beep is signaled the same way by the VT100: by sending a data character to the keyboard containing the "bell bit". If it's just a single bell, it's a short pulse through the speaker. If there are several bell bits in a row, the sound circuit will oscillate. Since the VT100-to-keyboard transfer rate is 785 characters per second, the beep is a 785 Hz tone.

The firmware keyboard service is part of the main loop which round robin rotates between the keyboard, input processing, and output processing. So maybe if a form feed character or other time consuming input delays the main loop, the bell bits will be sent at a lower rate?

[MikeShawaluk]

Hello, I'm the person who sourced the original "quack" comment. These are very old memories, so my recollection isn't perfect, but this is what I remember from that time. When the VT100 received a FF character, it would do a scroll of several linefeeds at once (I don't remember the exact number). My theory was that the multi-line scroll was somehow interrupting the "beep" sound, causing it to distort and make a quacking sound. I realize this is a bit fuzzy sounding and a bit of guesswork, but I didn't have access to VT100 schematics to know exactly how the "beep" sound was being created.

[larsbrinkhoff]

Thank you @MikeShawaluk, I really appreciate your comments and any recollections you may offer.

I tried sending a BEL and an FF, but I didn't see any special effect so far. I will investigate more deeply. Do you think anyone else might remember this? Any copy of that duck.txt file?

[LegalizeAdulthood]

Actually, now that you mention it, a stuck "beep" sounds familiar with the VT100 was doing a batch scroll.

[larsbrinkhoff]

@hisdeedsaredust, see here for vague information about a VT100 bug (or hidden feature). It's supposedly able to emit a "quack" sound under some particular circumstances.

[hisdeedsaredust]

I'm not quite there yet, but there's certainly a possibility of scrolling disrupting a bell, so I'll explain what I know so far.

Firstly, regarding the ancient memories of the mechanism: a single FF never produces more than one line of scrolling. Internally, LF, VT, FF and IND all run exactly the same routine. So I'd have thought you'd need to send a BEL and then multiple FF to really disrupt anything. A jump scroll will always complete during the next vertical blank interrupt, which is only ever 16.7ms or 20ms away.

Now, skip a bit and look at the other end of the chain, the communication with the keyboard. Although the CPU sets up what bits are to be sent to the keyboard ("do a scan", "click", LED status, etc.), the actual update to the keyboard at the rate Lars mentioned is out of the CPU's hands - the status is sent to the keyboard UART and that is entirely responsible for the fast update to the keyboard itself. That fast update is controlled by one of clocks from the DC011 video timer: LBA 4. I can't see a way of disrupting that (it's not dependent on screen width or AC power rate), so the actual comms to the keyboard is always, I believe, constant.

That leaves us with the CPU's hand in the bell generation. Executing the C0 control BEL, or hitting the right margin, simply increases a value in scratch RAM that I call bell_duration. It does nothing else. (I think this means that sending several BELs gets you a long continuous bell rather than several bells with silence between.)

The vertical blank interrupt routine handles all the rest, which is to toggle the speaker click bit in the keyboard status every 8 cycles through the interrupt routine, while decrementing bell_duration.

So, here we have a possibility. The vertical blank interrupt also handles the completion of scrolling, so as not to produce tearing on the screen. Whether you're smooth or jump scrolling, the final adjustments to video RAM are done during video blank. You can read this up in the Technical Manual; it's called shuffling. However, it's a constant-time operation: all the calculations are performed in advance, and then two end-of-line DMA pointers are updated during the interrupt. If a shuffle is required, it is done before the bell cycling.

Therefore, the time taken between toggles of the "speaker click" bit varies (minutely, but I haven't measured it) depending on whether a scroll will occur this time or not. Incidentally, I imagine the jump scroll versus smooth scroll difference is simply because a smooth scroll will only perform the shuffle once every 10 interrupts, as the DC012 video control chip is responsible for the scan-line-by-scan-line adjustments.

Phew. I think someone needs to see how the time between CPU updates to the keyboard port varies when scrolling is in progress. The good news is that you're looking at slight variations on a 50 Hz or 60 Hz cycle, rather than variations on a 785 Hz cycle.

I can't see any bugs in this area, i.e. something that would cause CPU to miss toggling the speaker click bit for a while.

[larsbrinkhoff]

Thank you @hisdeedsaredust for the detailed analysis!

Maybe I will try to repeat this experiment: "I remember accidentally discovering the “quack” sound when someone typed a binary file to the screen"