Page tree
Skip to end of metadata
Go to start of metadata

Come back soon for videos

In addition to the notes and instructions below, in-depth videos and images detailing how to set up and use this board will be posted here soon. Please stay tuned.

Overlapping documentation

Much of the information here was originally posted here after the first run of boards was manufactured by Eric Volpe, the actual genius behind the design of these boards. This documentation was created in an effort to expand the existing knowledge and help others gain further understanding of the board and to support the folks who ordered boards through me.

Introduction



One of the later iterations of this board, professionally manufactured in bulkA couple of prototype iterations of this board

Originally created by Eric Volpe in 2016, this design is relatively simple yet extremely versatile. It's also very inexpensive. The interface allows for any computer equipped with a USB port to act like another teletype on the loop. The computer sees the device as a simple serial interface, which can easily be manipulated by very simple text-based programs.

The device has a high voltage side where the current loop passes through by way of a couple of terminal block pairs. A pair of optoisolators handle RX and TX-- one is triggered by the current loop and is read by the microcontroller, and one keys the loop being controlled by the microcontroller. This allows for two way communication via the interface.

The device is based on the Atmel Atmega 16u2/32u2 chip, where all the logic happens.

Capabilities


  • On-board conversion of ASCII text from the computer to ITA2 (Baudot-Murray) on the current loop and vice versa (for 5-bit machines)
    • This can be disabled if your software passes ITA2 encoded text to the serial interface; if disabled, the board does no translation of encoding
  • Pass-through of ASCII encoding for 7/8-bit machines
  • Other character encodings – customizable translation tables can be configured to enable other encodings outside of ITA2 and ASCII
  • 45 and 110 baud rates have been tested the most, but other common rates (and probably all uncommon rates for that matter) used in teletypery should work without problems
  • 20ma and 60ma current loops supported (current levels both lower and higher are safe depending on the exact optoisolators used, though it would be unusual to see other currents in use)
  • All typical loop voltages supported-- in theory voltages as low as ~5VDC or as high as ~200VDC are possible depending on the optoisolator used in your particular iteration of the board

FAQ


  • Will this board work with model X teleprinter? If it uses a current loop, then most likely. Pretty much any ITA2 or ASCII, 45+ baud, 20ma or 60ma current loop machine should work with this board. Even if you have an unusual type of loop, baud rate, or 5-bit encoding, chances are the board can still be made to work with your oddball machine.
  • Will this board work with X computer or X operating system? Almost certainly-- it shows up as a simple serial interface as far as the computer's concerned, so almost anything remotely modern should be able to drive it. It has been most extensively tested on a few flavors of Linux, MacOS, and Windows, however. The computer must also support USB, of course.
  • Does this board require an external loop power supply? Yes. This board does not provide any power to the loop.
  • Does the polarity of the loop matter? Nope. There is a bridge rectifier added to the RX_LOOP circuit, which allows for the loop to be wired in either polarity.
  • Does this support full duplex or half-duplex? Yes. <This should probably move to be its own section down below>
    • The most common mode is probably half-duplex, meaning you have a single current loop to which your teletype keyboard and printer are wired in series (or just the printer if it's an RO unit). This is achieved by bridging the TX and RX terminals with a bit of hookup wire between the center terminals <image to come to better illustrate this>. Then the single loop must be wired to the outermost terminals.
    • Full duplex involves two electrically isolated current loops-- one for your keyboard (RX on the board), and one for your printer (TX on the board). Full-duplex can be achieved by removing the jumper between the TX and RX terminals and simply wiring the two loops to the two pairs of terminals <image to come to better illustrate this>.
  • Are there any recommended loop power supplies? There is a great selection of tried and true supplies outlined here <link to be added later>.

Procure one Ready-Made


This board has been manufactured in bulk at least three times and probably will be again at some point in the future. If we know about any future manufacturing runs, we'll include details here:

Date of ManufactureProcuratorDistinctive MarkingsUniquismsAvailability
03/2016Eric VolpeGreen PCB, "r1 03/2019" mark on back
None
02/2019Eric BinghamPurple PCB, same "r1 03/2016" mark
None
04/2019Jordan Cunningham

Black PCB, "r2 04/2019" mark on back

under original "r1" mark

See hereLimited - contact

Build Your Own


One of the great things about this board is that all of its components have through-hole counterparts, so a somewhat solder-savvy person can procure parts and assemble boards by hand. Those with the skills and equipment for SMT can, of course, stick with the SMD components, or a run could be manufactured at any reputable fab house.

Schematics, BOM, &c.

more to come

Tips for Assembling Through-Hole

same here

How to Use - Setup & Normal Use


Check your USB cable

If your board doesn't seem to appear in the OS after plugging it in, please check your USB cable. The board may light up and appear to be functional, but the USB cable could be bad.

It's happened many times to me and wasted hours of my life I'll never get back. It's so simple you don't really think about it until you've exhausted every other possible issue.

Familiarity with Unix Conventions

The Linux and MacOS sections assume you have basic familiarity with the terminal, entering commands, and probably SSH. If you don't, try the below first:

First - Wire the Board to the Current Loop

To begin, you will need to wire up the board in series to your current loop, just as you would another teletype. Also ensure there IS another teletype on the current loop, or this exercise will be pointless. 

If your teletype's keyboard and printer are both wired up to the same current loop so that whatever you type on the keyboard is also instantly printed on the same machine's printer, then you will want to wire up your board in half duplex, single loop mode (this is most common). To do this, simply put a small bit of hookup wire between the innermost TX and RX terminals, as depicted below (TO ADD IMAGE).

If your teletype's keyboard and printer are wired up to separate current loops so that anything you type on the keyboard is NOT printed on the same machine's printer but is rather meant to only be printed at a remote machine's printer, then you will want to wire up the RX and TX terminals to the two separate current loops. This is full duplex mode. This is a less common setup but is not entirely uncommon.

Once this is done, plug the board into the computer and turn on the current loop power supply and any machines on the loop you wish to test with.

DANGER - high voltage

The voltages passing through the loop side of the board can be dangerous to man and machine alike (60ma at 120VDC is typical). Be very careful dealing with this board with a live loop. Don't make contact with the board, and don't let anything else (stray wire, USB plug, metal enclosure, etc) contact it either. Use standoffs to mount the board, and otherwise use prudent electrical common sense.

Second - Set Up the Board for First Use

On Linux

 Click here to expand...

This board should work very easily out of the box on most if not all *nix systems. Using a Raspberry Pi as a controller is highly recommended due to its small size and ability to integrate; this typically runs a distribution of Debian called Raspbian. The following should be similar on most Linux systems.

Figure out what device path has been assigned

Once the board is connected to the computer, it will show up as a new device under /dev/tty[something]. It will probably show up as /dev/ttyACM0 (or ACM1, ACM2, &c. depending on whether you have plugged in other USB serial devices before this point). 


After plugging in, you can confirm the device path for sure by running the command dmesg and look for some of the latest output to verify which path the device was assigned. According to the below (see the last line), the device path is verified to be /dev/ttyACM0.

teletype@ttynode:~$ dmesg
[    0.000000] Booting Linux on physical CPU 0x0

<...lots of log output here...>

[  106.305973] usb 1-1.2: USB disconnect, device number 4
[  108.141105] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
[  108.285479] usb 1-1.2: New USB device found, idVendor=1209, idProduct=4545
[  108.285490] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[  108.285499] usb 1-1.2: Product: Teletype Interface
[  108.285507] usb 1-1.2: Manufacturer: Slothco Enterprises
[  108.285514] usb 1-1.2: SerialNumber: 95735343533351916120
[  108.286784] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

Pro tip

Note that the assigned device path can change if multiple boards are plugged in, removed, and then plugged in again in a different order. You can specify a device path that is permanently assigned to the board and have your software always use that device path instead.

To do this, take note of the SerialNumber in your dmesg output (second to last line in the above example). Then use your favorite text editor to create /etc/udev/rules.d/99-teletype.rules and enter the following for each interface:

SUBSYSTEM=="tty", ATTRS{serial}=="SERIALNUMBER", SYMLINK+="tty-int1"

...where SERIALNUMBER is the SerialNumber pulled from the dmesg output, and tty-int1 is the permanent device name you wish to utilize. The above setting, for example, would create a permanent device path of /dev/tty-int1, which is simply a symlink of whatever path Linux assigns to the device when first plugged in:

teletype@ttynode:~# ls -l /dev/tty-int1
lrwxrwxrwx 1 root root 7 Sep  6 22:59 /dev/tty-int1 -> ttyACM0

Add your user(s) to dialout group

By default non-root users don't have access to ACM serial interfaces. To rectify this, add your user to the dialout group (note that teletype is the user in this instance):

teletype@ttynode:~# usermod -a -G dialout teletype

Run some test transmissions

Testing is simple. There are some basic Bash commands you can run to test that the board is working:

  • screen /dev/ttyACM0 – this opens up an interactive serial session with your board. Try typing some test phrases from your computer and from your teletype. You should see the text you type on one machine print on the other.
    • Note that if the board is in half duplex mode (single loop for TX and RX), you will see the text you type into the computer terminal appear in that terminal's screen session, just as you will see the text you type on the teletype print on that teletype. This is because the signals are echoing back from TX to the RX part of the board as they're both on the same loop.
    • However, if the board is in full duplex mode (a separate loop for both TX and RX), or if the current loop is turned off, you WON'T see the text you type into the computer terminal appear in that terminal, just as you WON'T see the text you type on the teletype keyboard print on that machine. You WILL see that text appear on the OTHER machine whose RX (printer) is wired up to the same loop as your TX (keyboard).
  • echo "Text here" > /dev/ttyACM0 - this sends text from the board to the current loop-- the quoted text should print out on the teletype. Output only-- cannot read input from the loop.
  • printf "Text here\n" > /dev/ttyACM0 - more or less the same as the above-- echo automagically adds a CRLF, while printf does not. printf has a lot of other tricks up its sleeve, too, and is a very handy little program to use when manipulating a current loop.
  • read INPUT < /dev/ttyACM0 && echo "${INPUT}" - this will read input text from the current loop and put it into the INPUT variable, which is then echoed out on the local terminal for your viewing pleasure. This command will keep running and accepting text until a CR and LF are detected.

On MacOS

 Click here to expand...

As MacOS is a Unix-based system, its setup and use is very similar to that of Linux. It's very easy to use out of the box. The following would probably be similar in other BSD-like systems.

Figure out what device path has been assigned

Once the board is connected to the computer, it will show up as a new device under /dev/tty.usbmodemXXXX, where X is a series of numbers. You can find the exact one by running the following command:

js-macOS:~ js$ ls -l /dev/cu.usbmodem*
crw-rw-rw-  1 root  wheel   18,  10 Sep  6 23:52 /dev/cu.usbmodem14501

In this instance, the path assigned to this board on this Mac is /dev/cu.usbmodem14501. Note that MacOS seems to automagically keep track of the individual boards and will reassign the same device path consistently between times the board is attached/detached to the system.

Don't confuse the paths

Another sister device path will appear, for example /dev/tty.usbmodem14501 (instead of cu.usbmodem14501). Don't get confused and use that tty path-- it will only end in misery (i.e. freeze up your terminal).

Run some test transmissions

Testing is simple. There are some basic Bash commands you can run to test that the board is working:

  • screen /dev/cu.usbmodem14501 – this opens up an interactive serial session with your board. Try typing some test phrases from your computer and from your teletype. You should see the text you type on one machine print on the other.
    • Note that if the board is in half duplex mode (single loop for TX and RX), you will see the text you type into the computer terminal appear in that terminal's screen session, just as you will see the text you type on the teletype print on that teletype. This is because the signals are echoing back from TX to the RX part of the board as they're both on the same loop.
    • However, if the board is in full duplex mode (a separate loop for both TX and RX), or if the current loop is turned off, you WON'T see the text you type into the computer terminal appear in that terminal, just as you WON'T see the text you type on the teletype keyboard print on that machine. You WILL see that text appear on the OTHER machine whose RX (printer) is wired up to the same loop as your TX (keyboard).
  • echo "Text here" > /dev/cu.usbmodem14501 - this sends text from the board to the current loop-- the quoted text should print out on the teletype. Output only-- cannot read input from the loop.
  • printf "Text here\n" > /dev/cu.usbmodem14501 - more or less the same as the above-- echo automagically adds a CRLF, while printf does not. printf has a lot of other tricks up its sleeve, too, and is a very handy little program to use when manipulating a current loop.
  • read INPUT < /dev/cu.usbmodem14501 && echo "${INPUT}" - this will read input text from the current loop and put it into the INPUT variable, which is then echoed out on the local terminal for your viewing pleasure. This command will keep running and accepting text until a CR and LF are detected.

On Windows

 Click here to expand...

Windows details to be added soon including screenshots, videos, and instructions. 

For now, the basic instructions for initial setup can be sourced from Eric, the designer of the board, from the original instruction sheet here, quoted below:

Windows may require an information (INF) file to use the device. With the device disconnected, download this file from http://teletweety.com/usbtty.inf, save it to a file, and install it by right clicking the icon and selecting “Install.” Confirm any dialog asking if you’re sure. Then connect the board. It will appear as a “COM:” device; you can look in the Device Manager for “Teletype Adapter” under “Ports (COM & LPT)” to see which COM number it was assigned.


Third - Get some software and have fun

Now it's time to put your teletypes to good use. Most teleprinter software available should work with this interface since it's exposed as just a simple serial device. Check the Software section of this site for details. Also don't forget to check the configuration section down below to get to know your board better.

You can also roll your own software. You can string together a few series of functions using your favorite programming or scripting language to manipulate the serial interface to your heart's content. Since the board shows up as a simple serial input/output device, it's fairly easy to send/receive text. See the setup section for further ideas.

How to Use - Special ASCII Control Codes


A later version of the firmware enables the use of special control character codes to control the board from the computer in a few useful ways:

Programmatically enter board configuration mode

Useless with ASCII translation disabled

If ASCII translation (translate) is disabled, this functionality becomes useless. You can also easily just send the normal ITA2 characters for FIGS and LTRS (0x1B and 0x1F, respectively).

This enables you to enter the board's configuration mode and programmatically execute configuration commands rather than having to manually press SW1 on the physical board. The main advantage to this is that custom software could make configuration changes on the fly depending on what the program was currently trying to do. For example, the ttyBash program leverages this functionality to temporarily disable crlf when printing ASCII/ITA2/RTTY art.

Different firmwares might have different customizations here, and you could customize the firmware yourself to set your own control character, but the known main two standards for this are:

  • % - percent character - easy to echo to board, but could cause conflicts for ASCII machines
  • 0x16 - SYN, Synchronous Idle - requires echoing the raw bytes to the board (e.g. printf "\x16" > /dev/ttyACM0), and should minimize conflicts with ASCII machines

If you're unsure which your firmware uses, simply try sending the characters to your board to see which, if either, your firmware utilizes.

Issue FIGS from computer

To be honest, this control character is rarely used, but if you ever find the need to send a FIGS to

Different firmwares might have different customizations here, and you could customize the firmware yourself to set your own control character, but the known main two standards for this are:

  • { - left brace - easy to echo to board, but could cause conflicts with ASCII machines
  • 0x1E - RS, Record Separator - requires echoing the raw bytes to the board (e.g. printf "\x1E" > /dev/ttyACM0), and should minimize conflicts with ASCII machines except in relatively rare circumstances when emulating old computers that actually used the Record Separator control character

Issue LTRS from computer

This is mainly used to ensure the teletype's shift is in sync with the board's since the teletype may have been left in FIGS when the current loop was turned off/board shut down. When the board powers on, it's by default in FIGS. To ensure they are in sync, this LTRS control character could be sent before printing anything else.

Different firmwares might have different customizations here, and you could customize the firmware yourself to set your own control character, but the known main two standards for this are:

  • } - right brace - easy to echo to board, but could cause conflicts with ASCII machines
  • 0x1F - US, Unit Separator - requires echoing the raw bytes to the board (e.g. printf "\x1F" > /dev/ttyACM0), and should minimize conflicts with ASCII machines except in relatively rare circumstances when emulating old computers that actually used the Unit Separator control character

Note on why these control characters were chosen

The SYN, RS, and US control characters were chosen because they are presumed to be used relatively rarely even for ASCII machines. They are not in modern use, and it would be unusual (though not unheard of) to actually require the use of these characters when connecting an ASCII teletype to this USB interface board. Still, if they are required, other characters could be programmed into the firmware instead. Unfortunately this functionality does not yet exist as a configuration option-- the firmware would need to be customized and recompiled.

The percent, left bracket, and right bracket characters were chosen because they are nonexistent in the ITA2 encoding and thus would be universally acceptable for all Baudot machines.


How to Use - Configuration


The Volpe board has custom firmware installed that does some of the heavy lifting (Baudot to ASCII translation, &c). There are several functionalities that can be configured on the board itself.

To put the board into configuration mode, open up a screen session to the device, and then press the "SW1" button on the board. This suspends transmissions and instead opens up a command line interface on the serial port. You should see output like the following:

Commands available:
help, baud, table, [no]translate, [no]usos, [no]autocr, [no]showbreak, [no]8bit,
[no]autoprint, automsg, save, load, show, exit

CLI Commands

Print Current/Saved Configurations - show

cmd> show
Settings:                                  Cur     Saved
[no]translate   Translate ASCII/Baudot:    Y      Y
[no]crlf        CR or LF --> CR+LF:        Y      Y
[no]autocr      Send CRLF at end of line:  N      N
[no]usos        Unshift on space:          N      N
[no]showbreak   Display received breaks:   N      N
[no]8bit        8bit mode:                 N      N
table N         Translation table number:  0      0
baud N          Baud rate:                 45     45

Entering show will describe each available configuration and its current/saved setting. If the configuration has been set but not saved, the "Cur" and "Saved" columns will show a disparity. Setting the config without saving and then exiting will preserve the configuration until power is lost to the board (i.e. the computer shuts down or the board is disconnected).

Save Configurations - save

save simply saves any modified configurations. Remember-- if you exit without saving, changes will be lost the next time the board loses power.

Reload Saved Configs - load

Use load to reset the board to saved configurations. Alternatively, you could disconnect and reconnect the board to clear unsaved configs.

Exit CLI - exit

Enter exit to exit the configuration command line and go back to normal TX/RX operation.

Reset to Factory Defaults - eewipe

eewipe will revert ALL configurations back to factory defaults on the next restart (disconnect and reconnect the board). Like the *nix rm command, there is no confirmation prompt before actually executing, so only enter the command if you really mean to use it.

Configuration Options

Enable/Disable ITA2 ↔ ASCII Translation - translate

cmd> translate
Set to ASCII/Baudot translate mode.

cmd> notranslate
Set to passthru mode.

Default: translate

Enter translate to enable the board to automagically convert ASCII (8-bit encoding) received from the computer to ITA2 (5-bit encoding) on the current loop and vice versa.

Use notranslate to disable the board from converting ASCII/ITA2 to/from the loop. This should be used if either of the following are true:

  • The software you intend to use on the computer already encodes for ITA2 and expects ITA2 encoding
  • The machines on your current loop expect ASCII encoding

The translate functionality relies on lookup tables explained more in table and eewrite.

Enable/Disable Full CR/LF - crlf

cmd> crlf
CR or LF --> CRLF.

cmd> nocrlf
CR & LF independent.

Default: crlf

Use crlf to have the board automagically issue BOTH a carriage return and line feed to the loop when either one is received from the computer.

Use nocrlf to have no such functionality.

Enabling or disabling this functionality mostly depends on what your software expects. Modern operating systems handle CR/LF differently (for example, Windows sends both CR and LF automatically for a newline while *nix systems usually just send LF and Mac OS 9 and earlier used CR). On the other hand, some software written explicitly for teletypes may work the same way as a standard teletype-- that is, not send both a CR and LF automatically.

Worst case scenario is you keep auto crlf enabled, but your software already sends both automatically. The result would be that your physical teletypes would always add an extra space between lines. If this happens, simply run nocrlf.

Note that nocrlf is required for overstrike ASCII/ITA2/RTTY art (otherwise you'll get an LF and CR when you only wanted a CR).

Enable/Disable Auto CR/LF at EOL - autocr

cmd> autocr
Auto-CRLF at end of line.

cmd> noautocr
No Auto-CRLF at end of line.

Default: noautocr

Set autocr so that the board counts printable characters on a given line and automagically issues a carriage return and line feed to the loop once 70 characters are counted. 

Set noautocr so that the above functionality is disabled.

This can and will split words-- it does not intelligently break at the first space before the newline like the Bash command fold -s does. 

This must see at least one CR in order to work-- it starts counting after each CR.

Enable/Disable Auto LTRS on Space - usos

cmd> usos
Unshift-on-space enabled.

cmd> nousos
Unshift-on-space disabled.

Default: nousos

Use usos to cause a LTRS to be sent to the loop whenever a space is received.

Set nousos to have no such functionality.

This functionality automagically unshifts from FIGS to LTRS whenever a space is received, even if the teletype is not currently in FIGS. This can help keep shifts in sync. For example, if a teletype is turned off while still in FIGS, the board won't be aware of that the next time it's turned on and may print out FIGS characters when LTRS characters should be printing.

Enable/Disable BREAK Indicator - showbreak

cmd> showbreak
Show break indicator.

cmd> noshowbreak
Do not show break indicator.

Default: noshowbreak

Enter showbreak to have the text \[BREAK]\ echoed to the computer whenever there is a break in the loop circuit (i.e. the circuit is opened for longer than a few hundred milliseconds, or the time it takes to send a character or two).

Enter noshowbreak to disable this functionality.

You'd see this happen, for example, whenever the BREAK button is engaged on any teletype on the circuit or the loop power is turned off. This coincides with the green LED on the board going dark rather than being lit or blinking.

Set Loop Baud Rate - baud

cmd> baud 110
Baud rate set to 110 (divisor 757)

Default: 45.45

Enter baud <rate> where <rate> is the baud rate you wish to use on the current loop.

This configuration supports anything between 1 baud and 1200 baud. Attempting to set anything higher will result in error.

Note that several standard baud rates (45.45, 50, 75, 110) are programmed explicitly in the firmware using timings measured with a scope by this board's designer; anything outside the standards is calculated on the fly but should work fine. Actual maximum baud rate depends on various factors including current and inductance. The optoisolators on the board should be capable of achieving well above the 1200 baud firmware maximum.

This command accepts integers but will assume the common rates when entered. For example, entering baud 45 will set the rate to 45.45 in the background.

Enable/Disable ASCII on Loop - 8bit (experimental)

cmd> 8bit
8 bit mode for ascii machines.

cmd> no8bit
normal mode for 5-level machines.

Default: no8bit

Select 8bit to put the board into ASCII passthrough mode to work with ASCII teletypes such as the Model 33.

Use no8bit to set the board back into regular 5-bit mode for ITA2/Baudot-Murray machines.

As I have not used this functionality myself, I will simply quote Eric, the designer of these boards (original document here):

To try to use the board to talk to an ASCII machine like a Model 33, enter config mode and set “8bit” and “baud 110” - this

will also change various other options for you in order to hopefully make it compatible with 110 baud ASCII machines and

old computers. Since as far as I know most such application are full-duplex, you may need to remove the jumper between

the TX and RX terminal blocks and connect each block to its own loop. In this mode there is no character translation, and

the transmit and receive systems are switched to 8 bit instead of 5 bit. Also, since again as far as I know most ASCII

machines run on a 20mA rather than 60mA loop, you will be operating near the lower end of the range that the receiving

circuit can sense reliably, though it did work OK for me in testing. If you have problems receiving, slightly increasing the

loop current may help. If it falls below 15 mA it will almost certainly not work.

Note that later iterations of the board used an optoisolator that could sense much lower currents-- some as low as around 5mA.

Enable/Disable Autoprinted Message after BREAK - autoprint/automsg (experimental)

Autoprint disabled on 16u2-based boards

Due to memory constraints, the autoprint/automsg functionality is disabled on 16u2-based boards. It is still functional on 32u2-based boards, however.

Default: noautoprint

This functionality enables you to have a short message (512 characters including non-printables) print out automatically whenever a BREAK is received (whenever the current loop is open for more than a few hundred milliseconds). This can even be done without a host computer connected (i.e. the board is simply connected to a phone charger for power only). This would be a handy feature to use when doing a minor demonstration where a host computer is not available or if you for some reason wanted to print out a specific message whenever a BREAK is received or the current loop turns back on after any period of being off.

Note that the functionality is finicky and should be disabled unless it's absolutely required.

  1. To use, start by executing the command automsg in CLI mode; enter in the desired message:

    cmd> automsg
    enter up to 512 bytes. EOF at beginning of line to finish.
    > What hath God wrought?
    > EOF
    end of message.
  2. Next enable showbreak:

    cmd> showbreak
    Show break indicator.
  3. Finally, enable autoprint:

    cmd> autoprint
    Print saved text on break.

To disable, simply enter noautoprint and noshowbreak:

cmd> noautoprint
Do not print saved text on break.
cmd> noshowbreak
Do not show break indicator.

Configure Non-standard Character Encodings - table, eedump, eewrite

Default table selected: 0 (ITA2); tables 1 - 5 are blank by default

This functionality may be helpful for enabling the use of unusual encodings or doing something crazy such as modifying your ITA2 machine to a custom encoding for your own purposes. Yes, I called you crazy.

Select which translation table to use by entering table n, where n is the table number, 0 - 5.

See the hex contents of board nonvolatile memory (including tables) by executing eedump (note that the board does not support scrolling back, so you

Use eewrite to modify the board's nonvolatile memory in hex-- you must modify only the tables' portion of memory.

As I have not used this functionality myself, I will give further details by simply quoting Eric, the board's creator, from his original instruction document here:

The default translation between ASCII and ITA-2 / Baudot is probably sufficient for most uses. The tables are read from

nonvolatile storage in real time as characters are sent and received. It is possible to modify the provided tables or to add up

to 5 additional tables, which can be selected using the “table” command. The default table is 0; additional user-added tables

start at 1. To add a new table, you will need to use the “eewrite” command to update values stored in nonvolatile memory at

the correct addresses.


Each table consists of 64 bytes; 32 bytes for LTRS followed by 32 bytes for FIGS. The same tables are used for both

“sending and receiving. When a character is received from the loop, that character’s offset is looked up in either the LTRS

or FIGS table, and the corresponding value found at that address is sent to the host as ASCII. So for instance if the shift state

is LTRS and the device receives 01010 (hex 0A, decimal 10), it will look at offset +10 from the beginning of the current

LTRS table, find the value 0x52, and send it to the host, which will see it as ASCII ‘R’. If the host sends the ASCII letter

‘Y’, the current LTRS table will be sequentially searched for a location whose value is 0x59 (‘Y’) and that location’s offset

(21) will be sent to the loop as 10101, where it will print as ‘Y’. The default table (0) begins in eeprom at offset 0x0080 for

LTRS and 0x00A0 for FIGS; table 1, if present, should start at 0x00C0 for LTRS and 0x00E0 for FIGS. When the “table”

configuration setting is set to something other than 0, the value is multipled by 64 and used as an offset from the beginning

of the first table. There’s no bounds checking so setting nonsense values is likely to produce nonsense data.


To create or modify a table, use “eewrite XXXX AA BB CC DD EE ….” XXXX is the start address, and must be exactly

four hex digits, padded with leading zeros. Subsequent arguments must be exactly two hex digits each, separated by exactly

one space, and will be written to eeprom locations starting at XXXX and increasing one at a time. Since the commandline

input buffer is small, you can only write 16 values at a time. The format is exactly the same as the output of “eedump”.


Note also that the “eewrite” command has no bounds or format checking and will allow you to corrupt all parts of

nonvolatile memory, including the baud rate and option settings starting at location 0. It can not, however, modify program

memory, so there is no risk of irrevocably damaging the device (see Factory Reset below.)


If you don’t like messing with hex, send me an email indicating what you want to change in the translation tables, and I’ll

send you lines of text you can cut and paste to the board in config mode.

Troubleshooting


Common problems and how to resolve them to be added here soon.

Firmware


Details about firmware, how to update it, and links to firmware for download will be added here soon.





  • No labels