• Please review our updated Terms and Rules here

Hacking the VT100 keyboard

legalize

legalize

Experienced Member
Joined
Mar 24, 2006
Messages
391
Location
Salt Lake City, UT, USA
Has anyone hacked the VT100 keyboard to see what kind of sounds you can coax out of the speaker other than the key click (1 tick of the speaker circuit) vs the bell (200 ticks of the speaker circuit that averages out to a perceived tone)?

I'm wondering if any other pitches could be induced by changing the 200 ticks to something else.

For those that aren't intimately familiar with the VT100 keyboard connection, it's a 3-wire connection on a TRS jack with +12 V, ground and signal. The single signal line is used for bidirectional communication between the terminal and the keyboard. The keyboard is a slave device and the key click and bell noises from the keyboard's speaker are controlled by a bit in the command byte sent to the keyboard periodically.
 
Interesting idea. I suppose if you knew how/where to hack the bell routine in the ROM and burned your own set, you might even be able to play PCM samples! I've never seen a documented ROM listing though.

To me the stock key "click" on autorepeat sounds more like an AK-47 on full auto. :D

The VT100 is pretty well documented, so there is genuine hacking potential. That's more than can be said for it's Japanese sibling, the CIT-101, for which there's no service manual to be found. I have the main PCB from that thing and still haven't figured out the connectors. (Anyone have a spare CIT-101 keyboard)?

--GT
 
It depends what you mean by 'hacking' in this context of course. Do you mean an unmodified keyboard?

All the information you should require is in the technical manual and schematics on bitsavers.

There is a bit in the status register to enable/disable the tone, but the tone itself is generated by the baud clock and the UART receive data available signal.

I'll have a look a bit later when I have some free time...

Sounds an interesting thought...

Dave
 
Oh wow, hi again DaveR! :)

I didn't realise the tone is hardwired to the UART. So I guess my VT100 can't say "END OF LINE" after all... :D
I'm not about to tear down my VT100 (again), but I'm intrigued what you could do with the hardware.

--GT
 
Hi GT - how are you?

The circuitry is quite basic that drives the speaker (a flip flop, a transistor and a speaker) - although it does have an interesting CR (capacitor/resistor) timing network in there also.

The really interesting thing is how they use 1 wire to transmit a clock from the VDU to the keyboard and (simultaneously) permitting data to be transmitted from the VDU to the keyboard AND from the keyboard back to the VDU. This circuitry is ingenious...

It shouldn't take too much to wire up a bit of breadboard with the UART and circuitry of the VDU interface end and drive that from a modern micro controller to see what you can actually do. I wonder if you can come up with a musical instrument of some description? I do remember a really crude 'one bit' speech software driver in the dim and distant past...

Dave
 
The technical manual implies that a single pulse is what makes the keyclick "tick" noise and that a stream of pulses results in them averaging out (through the RC network) to a tone. I'm thinking you could probably get some other sounds by changing the number and timing (e.g. duty cycle) of the pulses that you send to the speaker. This is all under control of the ROM. Some work on disassembling and reverse engineering the ROM has been done here.
 
That's correct. By understanding the CR network, you can choose to output or not the bit to the keyboard and decide at the rate at which you send the data to the keyboard.

You may also decide that changing the CR network applies to your definition of 'hack'...

Are you thinking about keeping the VT100 VDU and keyboard together and modifying the firmware?

My take was just using the VT100 keyboard on its own and interfacing it to a micro-controller (or similar). Which goes back to the question I posed back in post #3 where I was asking what your definition of 'hack' was in this context.

Dave
 
There's a VT100<->USB interface design out there for the keyboard. You could certainly do it via a microcontroller hack there.

There's not much leftover room in the original VT100 ROM, but with the expansion ROM space in the AVO board you could easily patch the existing keyclick routines to handle more behaviors.
 
The speaker is controlled by a bit from a uart data. The rate that you could toggle is controlled how fast you can send 8 bits of data over the serial. To complicate things, the serial is a bidirectional wire, also used to send keyboard keys. You might want to check things like how the speaker is activated and how the protocol for sending data on the single wire is handled.
Check the VT-100 schematics.
Dwight
 
Dwight Elvey said:
The speaker is controlled by a bit from a uart data. The rate that you could toggle is controlled how fast you can send 8 bits of data over the serial.
Click to expand...

Agreed.

To complicate things, the serial is a bidirectional wire, also used to send keyboard keys.
Click to expand...

Yes, the VT100<->USB keyboard hack lifted the discriminating circuitry from the VT100 schematic in order to handle the communication with the keyboard.

See the External Links section on the DEC VT100 page on the terminals wiki for links to the USB hack and the blog posts describing hacking the ROMs.

I've studied the schematics and ROM for quite some time. I've been working on an annotated ROM disassembly listing. That is what gave me the idea for hacking the speaker in the first place. If I thought about it, chances are someone else might have already done it, hence this thread :).
 
What is the clock rate used by the keyboard UART? Looking at the schematic, it isn't clear. That divided by 128 or 144, depending on which of stop counts are used would be the fastest half cycle you can put out.
Dwight
 
IIRC, the clock is recovered from the signal generated by the main unit. Section 4.4.6.3 Terminal Data Encoding in the VT100 technical manual says:
The keyboard requires a clock for its operation and is provided with one by the terminal controller side of the interface. To transmit a clock independently of data on the same wire, the terminal side of the interface generates a clock signal within which data is encoded as a pulse width modulation. The terminal circuit produces a 75 percent high pulse width output for the mark state. Data transmission causes the clock output to switch between 75 and 25 percent pulse width (duty cycle).
Click to expand...

Attached is the timing diagram.

On the CPU side, I am not able to find at the moment the part in the manual where it describes how often the keyboard is issued a command over the bidirectional interface. It states in section 4.4.3 that the key address bit (that starts the key switch scanning counter in the keyboard) is set once per vertical refresh. The same section says:

The eighth bit, if sent only once, causes the keyboard speaker to click. (Keyclick is defeatable at SET-UP.) If the bit is sent approximately two hundred times in a row, for about a quarter second, it sounds a bell.
Click to expand...

This implies that the command byte is sent approximately 800 times per second.

clock-diag.jpg
 
Hi all, back here again after a long time. VT100 still here too. ;^)

A quacking VT is an interesting prospect! Is the DUCK.TXT file mentioned in the git thread available anywhere? Otherwise it's just a sequence of 0x7f 0xff 07f 0xff... ? Might post a video if the effect lives up to expectations...
 
GanjaTron said:
A quacking VT is an interesting prospect! Is the DUCK.TXT file mentioned in the git thread available anywhere? Otherwise it's just a sequence of 0x7f 0xff 07f 0xff... ? Might post a video if the effect lives up to expectations...
Click to expand...
Sorry, there's no DUCK.TXT file available as far as I know.
 
Correction: the sequence should be BEL-FF = 0x07 0x0c.
Haven't gotten round to it yet...
 
Last edited:
Well, I couldn't get the VT to quack. :^(
Then again, I have a fairly late revision, so I think the newer firmware might have "fixed" this artefact...
 
You must log in or register to reply here.
Back
Top