Apple IIe as a VT100 terminal for PiDP-11

[Benoit Maag]

Hi,

I am setting up my apple IIe as a VT100 terminal for my PiDP-11 (and PiDP-8 later).

Is there a link to explain how to do this? I asked Copilot and its answers are completely wrong - can't even get the serial switches functions right...

Thank you,

[John Hudak]

On the Apple 2E you need to have a serial card and terminal emulation software for a VT 100. The product pro term version 3.1 is widely regarded as a very good VT 100 emulator. I believe nowadays it is freely available. The best option for a serial card is the Apple super serial card. These are easily found on eBay.

For the PIDP 11 there are instructions on how to add the serial line chips to the prototyping area on the PIDP 11 circuit board. Once those are in place, you can use a serial cable to connect the PIDP 11 

to the Apple 2E.

Hth

J

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/1b03db81-9ceb-4cdf-82fb-bf69f1826650n%40googlegroups.com.

[Anton L.]

> how to add the serial line chips to the prototyping area on the PIDP 11 circuit board

There are better (IMO) options now available that do not require to solder anything in the prototype area, such as TTL<->RS232 DB9 connectors or

USB to RS232 adapters -- incorporating the level-shifting functionality of MAX232 (that was supposed to be done in the proto area).

For example (I'm not associated with any of these products):

https://www.amazon.com/gp/product/B07LBDZ9WG

https://www.amazon.com/gp/product/B00LZVEQEY

HTH and good luck!

A

[Adam Thornton]

I did basically this...uh, OK, it was 35 years ago.  But yeah, what you need is a serial interface and a terminal emulator.  I think I used ASCII Express, and a Super Serial card.  I don't remember if AE actually interpreted VT100 control codes correctly, or if what I had was a glass tty.  But it is definitely possible to use an Apple II as a serial terminal.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/a3fb4ba3-ebb3-4f90-834b-e2058fe28a99n%40googlegroups.com.

[Benoit Maag]

Thank you All !

I have an Apple Super Serial Card, a USB-A to DB-9 cable with FTDI, a DB-9 to DB-25 adapter.

The USB-Serial cable is not null-modem and the SSC setup is 'Terminal' - is that correct?

Tried ProTerm but the download I have seems corrupted since it crashes my Apple IIe - will check further.

[Adam Thornton]

I think Terminal is correct; the rest of the cabling sounds correct.  You might just want to try it as a serial connection and make sure you can send and receive plain old ASCII before worrying about terminal emulation.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/af3fc376-4295-4705-a30d-780447da9c88n%40googlegroups.com.

[Clem Cole]

Below.  If you read the document I sent you, much of this is covered in more detail.   See below for answers to your specific questions. 

Sent from a handheld expect more typos than usual

On Tue, Aug 11, 2026 at 8:10 PM Benoit Maag <benoit...@gmail.com> wrote:

Thank you All !

I have an Apple Super Serial Card, a USB-A to DB-9 cable with FTDI,

A cable with this chip is the best of breed and yes it should be a ‘DTE - a terminal’ with IBM PC/AT style pinning (which became grandfathered as TIA/EIA-232-F in Oct 1997).  

The only  issue with FTCI chipset is not being able to support 10 or 15 cps for ASR 33s and IBM 2700 series. 30 cps is as slow as it supports.  But it does hardware flow control on the RPi side, which extremely useful on emulated hosts as software flow is handled by the hosted OS and due to side effects of the emulation, many characters can be sent before the hosted OS actually sees “please stop sending” characters (DEC OS’s this  XOFF but HP’s OS as well as some others have a different protocol).  

a DB-9 to DB-25 adapter.

This should reroute the IBM 9pin DTE pinning to create traditional Aug 1969 RS-232-C 25pin DTE pinning.  

The USB-Serial cable is not null-modem

Correct it is a DTE - host or terminal, not a DCE (modem). 

and the SSC setup is 'Terminal' - is that correct?

It should also be a DTE since the Apple II is a “host” and it should be terminated with a standard 25 pin male (plug) connector, pinned per the RS-232-C spec. 

Thus to connect these two you need a traditional “null modem” cable which will have 25 pin female (sockets) on each end, and turn the opposite ends to look as thought it is a DCE - a.k.a. A modem.  Specifically the cable will cross xmit and rcv (2-3), cross rts and cts (4-5), short dsr to dcd and cross to dtr (6 shorted to 8 crossed to 20), and sgnd (pin 7) will be common - signal ground is the wire all of the other signals voltage levels are referenced against [remember RS-232C has two values: +3 to + 30 vdc and -3 to -30 vdc signal with any voltage between is said to be metastable or “undefined”]. The  frame gnd (pin 1) should technically be open one side and attached to any shield in a jacketed cable on that side, but often the molded null modem adapters, pass frame ground across, and sometimes will even connect one or both sides with signal ground. This not really a great idea, if you are making your own don’t, but in practice usually works. [see John McNamara’ classic text “Technical Aspects of Data Communication” ISBN 978-1555580070 you want more details like his speed vs cable length tables and the issues/pit falls like shorting frame and signal ground. There is a reason why the standard had two different pins].

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/af3fc376-4295-4705-a30d-780447da9c88n%40googlegroups.com.

[Benoit Maag]

Clem,

Thank you very much for all the information.

I just ordered a null modem connector - it should be here Saturday - will let you know.

[Clem Cole]

You are most welcome and good luck

Sent from a handheld expect more typos than usual

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/0208309b-46b8-4642-8d6a-f7ad0ba50b91n%40googlegroups.com.

[Benoit Maag]

Thank you Clem.

I finally got it to work (it took a while) ! When I have time I will summarize the process for the forum.

So far, I am using the old Apple Access v 1.0 software, but it does not have VT100 emulation, so not great for vi editor…

I tried ProTerm but the .dsk file is protected and I could not get it to work so far.

[Clem Cole]

Interesting Google turns up this article (below) that says Apple Access does support both VT-100 and VT-52.  If it does the later, try configuring Apple Access for the later and  “export TERM=vt52” to the Unix shell, and try again.  It’s not as sexy as a vt-100 but it needs less support and vi will work quite well with it. 

https://savagetaylor.com/til/TIL07887.pdf

Sent from a handheld expect more typos than usual

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/f2389d9b-764a-4b7a-b687-80f1aab6dee4n%40googlegroups.com.

[Benoit Maag]

Thank you Clem - I did not realize that ANSI meant vt100

Just set it up and added the terminal definition and it works perfectly !

Thank you !

[Clem Cole]

below...

On Tue, Aug 18, 2026 at 1:20 AM Benoit Maag <benoit...@gmail.com> wrote:

Thank you Clem - I did not realize that ANSI meant vt100

Just to be clear VT-100 != ANSI; i.e. export TERM=vt100 and export TERM=ansi (and for that matter, export TERM=vt52) will have different behaviors, which, if you look in the /etc/termcap or /usr/share/terminfo databases, you will see. Unfortunately, lots of people think the original VT-100 is fully ANSI X3.64 compliant.   They were not.  DEC released it before the standard was ratified.  The DEC engineers used the core X3.64 sequences and many of its definitions for the new terminal they were developing, but they left out two important functions that make inserting and deleting lines easiest for a host-side application programmer: 

Line Insertion and Deletion

• IL (Insert Line): ESC [ Pn L — Inserts one or more blank lines at the cursor position, pushing lower lines down.
• DL (Delete Line): ESC [ Pn M — Deletes one or more lines at the cursor position, pulling lower lines up.

Character Insertion and Deletion

• ICH (Insert Character): ESC [ Pn @ — Inserts one or more blank spaces at the cursor position, shifting existing characters to the right.
• DCH (Delete Character): ESC [ Pn P — Deletes one or more characters at the cursor position, shifting remaining characters to the left.
• IRM (Insert/Replace Mode): ESC [ 4 h (Set) and ESC [ 4 l (Reset) — A standard ANSI mode toggle. When set to Insert Mode, typing any regular character pushes existing text to the right instead of overwriting it.

 They created a DEC private scheme often called "scrolling regions:" 

• DECSTBM (Set Top and Bottom Margins): ESC [ pt; pb r

Later, the DEC engineers added the missing ANSI functionality with the VT-220 IIRC, and by the time xterm(1) was written (by a couple of DEC engineers working at MIT on the X-windows project), the pure ANSI and the DEC scrolling regions were both supported in the xterm(1) screen control definition.

FWIW: The VT-100s and their clones were very popular, so many, many programs emulated them or expected them, particularly on non-UNIX systems (i.e., without termcap or terminfo).  Thus lots of application programs were written assuming they were talking to a DEC VT-100, not an ANSI one.   While UNIX could use just about anything, thanks to termcap/terminfo, most screen-based programs developed on UNIX did (just look at the database; you will see how many terminals it knew about). But not being fully ANSI X3.64 conformant was one reason the UNIX community at the time (and MIT's ITS folk for that matter) liked the Health H19, Wyse 60, and later the Ann Arbor Ambassador over the VT-100s.   Those programs tended to work better on full ANSI, not the VT-100 subset.

As I said, the  VT-52 (and the Lear Siegler ADM3A) are really simple; one nifty thing the VT-100 could do was let you set it up to mimic a VT-52.  For "dumb terminals," there is much more processing on the host side and often more screen refreshes, but you will find places where programs like vi(1) or emacs(1) get confused between what you actually have on your screen and what they believe is on it.   If you don't ensure the TERM variable is set to exactly what you are using.  When I have had to use a VT-100 emulator that supports VT-52 mode, I have often used the much simpler mode with early versions of UNIX, such as the Sixth or Seventh Editions, that have very early vi/termcap implementations from the 1BSD and 2BSD tapes.  There are usually fewer issues, at the cost of more screen repaints.   Actually, particularly when vi(1) is running on what it thinks is a slow line (120 cps or slower), the screen on a VT-100 will get very ugly, as the program deletes characters on the screen but does not collapse adjacent lines because it doesn't want to be forced to repaint.  That is a "feature" left over from the dial-in lines we had in our apartments when we all were UCB grad students in the late 1970s and 80s.

 

Just set it up and added the terminal definition and it works perfectly !

Glad to hear it.

 

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/206d041b-9121-4c02-b41f-91b41addf54cn%40googlegroups.com.

[Paul Koning]

On Aug 18, 2026, at 5:16 PM, Clem Cole <cl...@ccc.com> wrote:

below...

...

Later, the DEC engineers added the missing ANSI functionality with the VT-220 IIRC, and by the time xterm(1) was written (by a couple of DEC engineers working at MIT on the X-windows project), the pure ANSI and the DEC scrolling regions were both supported in the xterm(1) screen control definition.

When the VT2xx series of terminals were created, DEC also created a very thorough internal standard for terminals, DEC Std. 070 (preserved on Bitsavers).  As was done with many DEC standards, it is precise enough that you can simply implement what it says and end up with a compliant and interoperable ANSI terminal.  I did exactly that when I created the Pro terminal code for (unreleased) RSTS.

Note that, apart from the draft standard issue around ANSI and the VT100, there is also the extension DEC added (in all its terminals) to switch to VT52 mode and then support the entirely different VT52 escape sequences.  (I sometimes wonder why they did not also include a VT05 mode...)

paul

[Clem Cole]

On Thu, Aug 20, 2026 at 12:20 PM Paul Koning <pa0...@gmail.com> wrote:

On Aug 18, 2026, at 5:16 PM, Clem Cole <cl...@ccc.com> wrote:

below...

...

Later, the DEC engineers added the missing ANSI functionality with the VT-220 IIRC, and by the time xterm(1) was written (by a couple of DEC engineers working at MIT on the X-windows project), the pure ANSI and the DEC scrolling regions were both supported in the xterm(1) screen control definition.

When the VT2xx series of terminals were created, DEC also created a very thorough internal standard for terminals, DEC Std. 070 (preserved on Bitsavers).

Thanks, I was pretty sure it was the VT-2xx timeframe when they added it to the spec.  Somewhere in a filing cabinet, I may still have a lineprinter listing of what was then called EL-00070-00 that was kicking around Project Athena in the mid-1980s, IIRC.  The one Al has is a PDF:DEC STD 070 Video Systems Manual DOCUMENT IDENTIFIER: A-MN-ELSM070-00-0000 Rev H. 03-Dec-1991 [https://bitsavers.trailing-edge.com/pdf/dec/standards/EL-SM070-00_DEC_STD_070_Video_Systems_Reference_Manual_Dec91.pdf]

 

 As was done with many DEC standards, it is precise enough that you can simply implement what it says and end up with a compliant and interoperable ANSI terminal.

Indeed.  The outlier is the VT-100, which so many people outside of DEC cloned, thinking that if you used VT-100 commands, you were ANSI-compliant (you weren't).  But in practice, for a lot of people, that was all you needed.  Many end-user applications were built on systems that didn't have termcap/terminfo (i.e., outside the core UNIX community); particularly applications targeting VMS users.

  I did exactly that when I created the Pro terminal code for (unreleased) RSTS.

Cool.

 

Note that, apart from the draft standard issue around ANSI and the VT100, there is also the extension DEC added (in all its terminals) to switch to VT52 mode and then support the entirely different VT52 escape sequences.  

Yep, and you could set it up to power up in either mode, and then switch under program control.   But I never saw anyone do that in practice; but I bet it was done.

Switching from VT-100 (semi-ANSI) Mode to VT-52 Mode

• Mnemonic Name: DECANM (with the Reset Mode parameter)
• Control Sequence: ESC [ ? 2 l        {which was defined as ESC (ASCII 27 / 0x1B)    [ (Control Sequence Introducer)  ? (a DEC private mode) 2 (The parameter ID for ANSI/VT-52 selection)  l (Lowercase 'L', which stands for Reset Mode, resetting the terminal back to VT-52 compatibility)}

Switching from VT-52 Mode back to VT-100 (semi-ANSI) Mode

• Mnemonic Name: Enter VT-100 Mode / Exit VT-52 Mode
• Control Sequence: ESC <        {which was defined as ESC (ASCII 27 / 0x1B)    < (Less-than sign) }

 

(I sometimes wonder why they did not also include a VT05 mode...)

As I understood it from my friend Tom Kent, who was part of the VT-100 team, even though the VT05 started selling in Nov 1970 and was replaced in Sep 1975 with the VT-52, DEC sold only a few thousand of them, mostly to institutional/high-end customers.  IIRC, it couldn't go faster than 300 baud, and it was Uppercase.   It really was a "glass tty."   Under "Simple Economics Always Beats Sophisticated Technology/Engineer, I'll make a wager that there were that many end-user apps that had been written for the VT05.  Whereas the latter model sold tens of thousands, even with Lear Siegler bringing out the ADM3A for $955 as a kit and $1,045 assembled.†  Tom suggested there was no demand for the VT05, while breaking application compatibility with the VT52 would have been bad when the VT-100 rolled out.

Frankly, until BSD created termcap, my experience with almost all other systems in the 1970s from TOPS, IBM, and the like, was that the terminal control sequences were screwed down into each app.  Even UNIX didn't get smart for a while.  One of my hacking jobs in the late 1970s was getting the Cornell "friendly ed" - a.k.a. fred, which ran on Sixth Edition, to talk to the PE Foxes.  I don't even remember how we figured out which type of terminal was on each serial port, since Ken's ENVIRONMENT variables were a Seventh Edition idea.  I think we must have had a file in /etc called something like "terminals" that mapped them to the devices, and you had to do an fstat(2) on the controlling terminal's fd to get the device major/minor and find it in /dev.

Clem

†  By the time the VT-100 showed up in 1978, the ADM3A had captured much of the entry-level terminal market.  I remember a room full of VT52s, ADM3As, and ASR33s at CMU, connected to the 20s, the IBM 360, and an RSTS system the Humanities folks used for BASIC.

[Paul Koning]

On Aug 20, 2026, at 4:01 PM, Clem Cole <cl...@ccc.com> wrote:

...

(I sometimes wonder why they did not also include a VT05 mode...)

As I understood it from my friend Tom Kent, who was part of the VT-100 team, even though the VT05 started selling in Nov 1970 and was replaced in Sep 1975 with the VT-52, DEC sold only a few thousand of them, mostly to institutional/high-end customers.  IIRC, it couldn't go faster than 300 baud, and it was Uppercase.   It really was a "glass tty."   Under "Simple Economics Always Beats Sophisticated Technology/Engineer, I'll make a wager that there were that many end-user apps that had been written for the VT05.  Whereas the latter model sold tens of thousands, even with Lear Siegler bringing out the ADM3A for $955 as a kit and $1,045 assembled.†  Tom suggested there was no demand for the VT05, while breaking application compatibility with the VT52 would have been bad when the VT-100 rolled out.

The VT05 could do at least 1200 baud, I think also 2400.  Yes, upper case only (VT50 was UC only as well).  20 lines at 72 characters.  I suspect its sales were modest because it was quite a complex beast, some vague memory says core memory for the refresh memory, that may be wrong but it certainly was a lot harder then.

I did my first work for DEC on one of those, visiting in 1976 trying to get a summer intern job.  Didn't, but Anton Chernoff pushed me into writing the first version of PIP.SAV for RSTS, for V5B to use during SYSGEN.  Took one week to get it functioning and about 100x faster than its predecessor, I'm still rather proud of that.  :-)

The VT05 case, though I'm not sure about any of its innards, was reused for the VT20 typesetting terminal.  There are some photos of it on Bitsavers, but no other data.  It was in effect a predecessor of the VT71, but controlled by a PDP-11/05 that ran two of the displays (vs. the VT71 with an LSI-11 inside controlling just that one display).  Nice devices, full file editing inside the terminal, download the file to start editing and upload it when finished.

paul

[Johnny Billquist]

VT05 runs at up to 2400 bps, and memory is semiconductor.

I used to play with one at a computer club many years ago. No idea if
they have been scrapped, or still exists somewhere. I would actually
find it slightly amusing to have one again.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> F890333D-1EE8-4936-9498-4BFC17B6A721%40gmail.com <https://
> groups.google.com/d/msgid/pidp-11/
> F890333D-1EE8-4936-9498-4BFC17B6A721%40gmail.com?
> utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Clem Cole]

thanks Paul,   below

On Fri, Aug 21, 2026 at 9:50 AM Paul Koning <pa0...@gmail.com> wrote:

On Aug 20, 2026, at 4:01 PM, Clem Cole <cl...@ccc.com> wrote:

...

(I sometimes wonder why they did not also include a VT05 mode...)

As I understood it from my friend Tom Kent, who was part of the VT-100 team, even though the VT05 started selling in Nov 1970 and was replaced in Sep 1975 with the VT-52, DEC sold only a few thousand of them, mostly to institutional/high-end customers.  IIRC, it couldn't go faster than 300 baud, and it was Uppercase.   It really was a "glass tty."   Under "Simple Economics Always Beats Sophisticated Technology/Engineer, I'll make a wager that there were that many end-user apps that had been written for the VT05.  Whereas the latter model sold tens of thousands, even with Lear Siegler bringing out the ADM3A for $955 as a kit and $1,045 assembled.†  Tom suggested there was no demand for the VT05, while breaking application compatibility with the VT52 would have been bad when the VT-100 rolled out.

The VT05 could do at least 1200 baud, I think also 2400.

I should have been clearer.  But I was pleased to see my memory wasn't off when I checked the manual. The original VT-05 (later designated the VT-05A) stopped at 300 Baud; the VT-05B could go to 2400.  There was a rotary switch that set the speed, and I thought I remembered that it only went to 300.   https://vt100.net/docs/vt05-rm/chapter3.html#T3-2     I only saw one in action at 300 baud on a PDP-8 running TSS/8.    BTW: According to the manual, the B version (which supported higher speeds) needed Filler characters at the higher speeds for some of the functions (LF, Cursor Up or Down, HOME, Cursor Y Address, and Erase screen.  I'm actually not surprised, since the terminal was all random SSI TTL logic.   

 

 Yes, upper case only (VT50 was UC only as well).  20 lines at 72 characters.  I suspect its sales were modest because it was quite a complex beast, some vague memory says core memory for the refresh memory, that may be wrong but it certainly was a lot harder then.

For storage, the VT05 used what Intel called a "Dynamic Shift Register," which is a 1024-bit DRAM-like device arranged as 256 bits by 4 (Intel i1402 chip). Because it is a dynamic storage register, it requires a continuous clock signal to keep shifting and preserve stored data, like a traditional DRAM.  I understand that Intel announced the chip sometime in 1970 and ramped up production quickly, and DEC announced the VT05 in November of 1970, but it didn't start shipping until sometime in 1971.  So the VT05 must have been one of the first products that used it.   FWIW: Page 20 of the VT05 schematics, chip E20, shows it used a WD1402A UART (the first single-chip UART), but if you look in the title block for that page, it claims it is for the VT05A.  I'm scratching my head a little, because Western Digital didn't announce the WD1402A until July 71 and start shipping in volume until 72.   So I'm not sure how that worked.  I've seen stuff in one of the IEEE pubs that said Digital was involved with the WD1402A design (it was Gordon's patent on the UART).  And DEC would standardize on that chip (a.k.a. DEC1UART on a lot of schematics) for many other products that needed a UART.

I did my first work for DEC on one of those, visiting in 1976 trying to get a summer intern job.  Didn't, but Anton Chernoff pushed me into writing the first version of PIP.SAV for RSTS, for V5B to use during SYSGEN.  Took one week to get it functioning and about 100x faster than its predecessor, I'm still rather proud of that.  :-)

Very cool. 

The VT05 case, though I'm not sure about any of its innards, was reused for the VT20 typesetting terminal.  There are some photos of it on Bitsavers, but no other data.  It was in effect a predecessor of the VT71, but controlled by a PDP-11/05 that ran two of the displays (vs. the VT71 with an LSI-11 inside controlling just that one display).  Nice devices, full file editing inside the terminal, download the file to start editing and upload it when finished.

Clem