[GreenKeys] Model 35

[Harold Hallikainen]

On Sat, July 6, 2024 12:28 pm, Jim Haynes wrote:

> Another complexity in the ASCII stew was the keyboard arrangement.
> There was considerable support for a keyboard arrangement like that of
> typewriters.  But this required assigning bit patterns to the keys
> so that a shift key cause a simple change in the bit patterns.
> An alternative was called the bit-paired, where the upper and lower
> case characters on the keys were simply related but the key tops
> were different from those on typewriters.  All this is passe now
> since it's just a matter of each key depression generating a number
> than can be looked up in a memory and translated into any character
> you wish.  But it explains why at the time ASCII was not an easy project
> and consumed a lot of time and travel by a lot of experts.  And why
> there are still conflicts and compromises.

One of my early products was a "program logging system" for automated
radio stations. It place 3.5 kHz FSK on the cue track of tape cartridges.
When the cartridge was played, the time was printed along with the AFSK
data. These used the XR2206 to generate the AFSK and the XR2211 to
demodulate. The very first design used a model 15 as the printer. Time
data came from an external clock as parallel BCD. This was converted to
Baudot with a diode matrix for each digit. The diode matrix drove a
parallel load shift register for each character to be printed. The CRLF,
time, and a space were shifted out of the long shift register. The AFSK
demodulator in this unit used an NE565 PLL. The carrier detect output from
that (lock detect) would cause the time data to be loaded and shifted out.
This was then followed by the AFSK data from the tape cartridge.

In the next design (
https://bh.hallikainen.org/index.php/HallikainenAndFriends#:~:text=LOG112%20Program%20Logging%20System
), the printer was a Teletype model 43, which is ASCII. It is VERY SIMPLE
to convert BCD to ASCII (set the 3 msb to 0x3). The 4 lsb are the BCD.
This system used a clock chip with a multiplexed BCD output. The carrier
detect output of the XR2211 would reset a counter which would then route
the digit strobes coming out of the clock chip to the strobe input of a
UART. It would capture each of the BCD digits and send them. The counter
also drove a ROM chip (MM6330-1) which set the msbs to 0x3. It also
generated the CRLF sequence. It also converted a 1 of 10 input to an
"alarm letter" that would be printed after the time before the AFSK data
would start printing.

It was REALLY NICE that it was so easy to convert from BCD to ASCII. Also,
changing one bit would change between upper and lower case. I really think
ASCII is very well thought out.

In some later projects, like
https://www.movingimagetech.com/images/products/mit-ADA-Accessibility/R000301_IRC_Manual_v23-08-01.pdf
, I got to work with UTF-8. Also very clever! ASCII is just passed
through. If the msb is set, it's the start of UTF-8 encoding of a Unicode
code point that is above 127. I converted the incoming UTF-8 to 16 bit
characters that then indexed into a table of 8x16 and 16x16 bitmaps in the
Unifont table.

So, I really appreciate ASCII, and appreciate how UTF-8 allows for more
characters while still supporting ASCII.

People have done some clever stuff!

Harold
https://w6iwi.org/rtty

-- 
Not sent from an iPhone.