26 Feb
2013
26 Feb
'13
2:47 p.m.
Also posted this question in the Vintage Computer Forums.
OK, I'm stumped. I'd like to use a real VT100 as a terminal with an
emulated PDP-11 running RT11.
When the VT100 is connected to a real PDP-11, it works fine. When connected
to the emulated PDP-11, garbage characters begin to appear on the screen
when, say, doing a DIR command.
The garbage always starts in exactly the same place in the DIR listing.
After that, garbage characters (grey squares) become interspersed with the
good text.
I have tried this with SIMH under Linux, connecting the VT100 to the serial
console port of the Linux machine. I've also tried it under E11, using that
program's built-in serial terminal capacity. Same exact error in both cases.
I've looked at the RT11 SET command for TT: to see if there are any
applicable parameters. Can't find any. I've set the SIMH TTO device to all
its possible settings: 7B, 7P, 8B, and UC. Same stuff in all cases. I've
looked at the serial settings on the VT100 to ensure 8 bits, no parity, and
correct baud rate. All good.
The VT100 works fine with the Linux box doing Linux-ey things. No character
corruption when doing a big "ls" listing, OK with vi, etc. The SIMH and E11
emulators work fine in their virtual consoles, with no character corruption
when doing a DIR, etc.
Any ideas? I'd really like to, for instance, get my Raspberry Pi to be a
mini PDP-11 system, but I can't get past this character garbage when using
the real VT100. Help appreciated! And thanks for reading!
- Earl
26 Feb
26 Feb
4:01 p.m.
On 26-feb-2013 23:47, Earl Evans wrote:
OK, I'm stumped. I'd like to use a real VT100
as a terminal with an
emulated PDP-11 running RT11.
When the VT100 is connected to a real PDP-11, it works fine. When connected
to the emulated PDP-11, garbage characters begin to appear on the screen
when, say, doing a DIR command.
The garbage always starts in exactly the same place in the DIR listing.
After that, garbage characters (grey squares) become interspersed with the
good text.
Sounds like it may be related to (software/hardware) flow control. I
only have a VT220 here, so I'm not totally sure how the VT100 exactly
functions, but I assume it's the 'standard' 9600 bauds, 8 data bits
and 1 stop bit? (When you're working with actual hardware.)
- MG
5:35 p.m.
On Wed, Feb 27, 2013 at 01:01:23AM +0100, MG wrote:
On 26-feb-2013 23:47, Earl Evans wrote:
The VT100 could not keep up with full speed 9600 baud. The back of
the VT100 manual has a table of how many nul chars you need per baud rate.
OK, I'm stumped. I'd like to use a real
VT100 as a terminal with an
emulated PDP-11 running RT11.
When the VT100 is connected to a real PDP-11, it works fine. When connected
to the emulated PDP-11, garbage characters begin to appear on the screen
when, say, doing a DIR command.
The garbage always starts in exactly the same place in the DIR listing.
After that, garbage characters (grey squares) become interspersed with the
good text.
Sounds like it may be related to (software/hardware) flow control. I
only have a VT220 here, so I'm not totally sure how the VT100 exactly
functions, but I assume it's the 'standard' 9600 bauds, 8 data bits
and 1 stop bit? (When you're working with actual hardware.)
- MG
-Diane
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
27 Feb
27 Feb
3:37 a.m.
On 27-feb-2013 2:35, Diane Bruce wrote:
The VT100 could not keep up with full speed 9600 baud.
The back of
the VT100 manual has a table of how many nul chars you need per baud rate.
Well, I have never owned or used a (real) PDP-series system. (I was
also born long after their heyday.)
- MG
6:33 a.m.
On Wed, Feb 27, 2013 at 12:37:19PM +0100, MG wrote:
On 27-feb-2013 2:35, Diane Bruce wrote:
*laugh* The important thing here is to solve the problem, not worry
about age differences. ;) I do have a copy of a VT-100 manual downstairs
somewhere, and I do recall it stating number of nuls per baud rate to insert
or suggesting the use of flow control. I am sure a copy of the manual is
online if anyone is really curious.
I do remember being very disapointed at the time I first read this
some time (*cough*) ago, as the framebuffers of a modern PC were still
a few years away. We all treasured serial speed, as that was the way
things were done. Having a terminal claiming it could run 9.6K was nice
but disapointing it could not actually keep up.
Heh the wikipedia article shows it was running an 8080
http://en.wikipedia.org/wiki/DEC_VT102
I owned one working Volker-Craig terminal and several more parts ones.
http://vt100.net/volker-craig/
I gave them all to a member of this list.
It seemed to run a tad faster than the real VT100. I seem to recall
spotting a Z-80 on that board.
The VT100 could not keep up with full speed 9600
baud. The back of
the VT100 manual has a table of how many nul chars you need per baud rate.
Well, I have never owned or used a (real) PDP-series system. (I was
also born long after their heyday.)
- MG
- Diane
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
4:30 p.m.
On 02/27/2013 09:33 AM, Diane Bruce wrote:
On Wed, Feb 27, 2013 at 12:37:19PM +0100, MG wrote:
One way to seriously slow the terminal down was to enable smooth scroll
as that took a fair amount of cpu cycles to implement.
The fastest was jump scroll and set to VT52 mode. Data setups with
8bits and stick parity with 2 stop bits were better than 7bits. reason
that added two bit times per character (slows the overall character rate).
When the host is DEC and local (less than 50ft cable) I used to run
19.2k on my Vt102 (smooth scroll and Vt100 mode, xon/off) and it
was great when editing.
On 27-feb-2013 2:35, Diane Bruce wrote:
*laugh* The important thing here is to solve
the problem, not worry
about age differences. ;) I do have a copy of a VT-100 manual downstairs
somewhere, and I do recall it stating number of nuls per baud rate to insert
or suggesting the use of flow control. I am sure a copy of the manual is
online if anyone is really curious.
I do remember being very disapointed at the time I first read this
some time (*cough*) ago, as the framebuffers of a modern PC were still
a few years away. We all treasured serial speed, as that was the way
things were done. Having a terminal claiming it could run 9.6K was nice
but disapointing it could not actually keep up. The VT100 could not keep up with full speed 9600
baud. The back of
the VT100 manual has a table of how many nul chars you need per baud rate.
Well, I
have never owned or used a (real) PDP-series system. (I was
also born long after their heyday.) Heh the wikipedia article shows it was running an
8080
http://en.wikipedia.org/wiki/DEC_VT102
I owned one working Volker-Craig terminal and several more parts ones.
http://vt100.net/volker-craig/
I gave them all to a member of this list.
It seemed to run a tad faster than the real VT100. I seem to recall
spotting a Z-80 on that board.
The H19 used a Z80. The vt100 was top of the line
for its time to be
replaced with the VT220. In the between there were varients like the 102
that were actually a little better.
Oddly enough there were a lot of oddities of the Vt100 that didn't make it
to many of the look alikes. Some even broke VT100 emulation enough
to not work at all right for some of the more extreme tests.
Generally if there is trash on the screen slow down, 2400 is usually enough.
Allison
11:21 a.m.
On 27-feb-2013 2:35, Diane Bruce wrote:
The VT100 could not keep up with full speed 9600 baud.
The back of
the VT100 manual has a table of how many nul chars you need per baud rate.
My mistake; I didn't realize the VT100 also had fill character
requirements, but you're right.
<http://manx.classiccmp.org/mirror/vt100.net/docs/vt100-ug/appendixc.html#TC-1>
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
26 Feb
26 Feb
4:10 p.m.
On Tue, Feb 26, 2013 at 02:47:40PM -0800, Earl Evans wrote:
Also posted this question in the Vintage Computer
Forums.
OK, I'm stumped. I'd like to use a real VT100 as a terminal with an
emulated PDP-11 running RT11.
When the VT100 is connected to a real PDP-11, it works fine. When connected
to the emulated PDP-11, garbage characters begin to appear on the screen
when, say, doing a DIR command.
It's possible the VT-100 can't keep up to the emulated PDP-11.
The VT-100 needed a lot of padding characters or working XON/XOFF soft
flow control. It's just a guess.
- Earl
- Diane
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
6 p.m.
On 02/26/2013 05:47 PM, Earl Evans wrote:
Also posted this question in the Vintage Computer
Forums.
OK, I'm stumped. I'd like to use a real VT100 as a terminal with an
emulated PDP-11 running RT11.
When the VT100 is connected to a real PDP-11, it works fine. When connected
to the emulated PDP-11, garbage characters begin to appear on the screen
when, say, doing a DIR command.
The garbage always starts in exactly the same place in the DIR listing.
After that, garbage characters (grey squares) become interspersed with the
good text.
Too high a data rate without flow control. Either enable Xon/Xoff on
both ends or
use hardware control (most PCs do not support that correctly).
If all else fails set the baud rated to something slower till the
problem goes away.
Allison
I have tried this with SIMH under Linux, connecting the VT100 to the serial
console port of the Linux machine. I've also tried it under E11, using that
program's built-in serial terminal capacity. Same exact error in both cases.
I've looked at the RT11 SET command for TT: to see if there are any
applicable parameters. Can't find any. I've set the SIMH TTO device to all
its possible settings: 7B, 7P, 8B, and UC. Same stuff in all cases. I've
looked at the serial settings on the VT100 to ensure 8 bits, no parity, and
correct baud rate. All good.
The VT100 works fine with the Linux box doing Linux-ey things. No character
corruption when doing a big "ls" listing, OK with vi, etc. The SIMH and E11
emulators work fine in their virtual consoles, with no character corruption
when doing a DIR, etc.
Any ideas? I'd really like to, for instance, get my Raspberry Pi to be a
mini PDP-11 system, but I can't get past this character garbage when using
the real VT100. Help appreciated! And thanks for reading!
- Earl
6:45 p.m.
In article <CAMDAk4f81=gcUh_GV14mGhZoH1rGpLfZk74pQG=sjjpqJ-NS0g at mail.gmail.com>,
Earl Evans <earl at retrobits.com> writes:
The garbage always starts in exactly the same place in
the DIR listing.
After that, garbage characters (grey squares) become interspersed with the
good text.
Try setting your baud rate to 300 and see if it still happens.
If so, then you have a hardware problem.
If not, then it's as suspected elsewhere in this thread -- the
emulated machine is feeding the VT100 faster than it can accept the
data.
The VT100 doesn't need padd characters IIRC (VT05 and VT52 definitely
do), but it uses a signalling scheme to tell the host that it's
internal buffer is full. This signalling scheme can be either in the
hardware signalling (DTR/CTS) or it can be XON/XOFF (DC1/DC3) control
characters in the data stream.
Relevant manuals for VT100 are linked here:
<http://terminals.classiccmp.org/wiki/index.php/DEC_VT100>
Under Windows, the default settings of a com port are not set to use
any flow control. I was recently generating ESC sequence laden files
for my Tektronix 4205 terminal on my PC and sending them to the COM3:
port with "copy foo.dat com3:" and the Tek was losing data and
garbling commands until I configured both the terminal and the COM
port to use the same flow control signalling. Then everything worked
properly.
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
27 Feb
27 Feb
12:53 a.m.
Hi all,
Regarding the comments on baud rate and flow control - still doesn't make
sense to me why the VT100 would not exhibit the error with a real PDP-11
(at 9600 baud), but does do it with the emulated PDP-11. The info is coming
at the terminal at the same rate - why would the behavior be different?
- Earl
On Tue, Feb 26, 2013 at 6:45 PM, Richard <legalize at xmission.com> wrote:
In article <CAMDAk4f81=gcUh_GV14mGhZoH1rGpLfZk74pQG=
sjjpqJ-NS0g at mail.gmail.com>,
Earl Evans <earl at retrobits.com> writes:
The garbage always starts in exactly the same
place in the DIR listing.
After that, garbage characters (grey squares) become interspersed with
the
good text.
Try setting your baud rate to 300 and see if it still happens.
If so, then you have a hardware problem.
If not, then it's as suspected elsewhere in this thread -- the
emulated machine is feeding the VT100 faster than it can accept the
data.
The VT100 doesn't need padd characters IIRC (VT05 and VT52 definitely
do), but it uses a signalling scheme to tell the host that it's
internal buffer is full. This signalling scheme can be either in the
hardware signalling (DTR/CTS) or it can be XON/XOFF (DC1/DC3) control
characters in the data stream.
Relevant manuals for VT100 are linked here:
<http://terminals.classiccmp.org/wiki/index.php/DEC_VT100>
Under Windows, the default settings of a com port are not set to use
any flow control. I was recently generating ESC sequence laden files
for my Tektronix 4205 terminal on my PC and sending them to the COM3:
port with "copy foo.dat com3:" and the Tek was losing data and
garbling commands until I configured both the terminal and the COM
port to use the same flow control signalling. Then everything worked
properly.
--
"The Direct3D Graphics Pipeline" free book <
http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
6:35 a.m.
On Wednesday (02/27/2013 at 12:53AM -0800), Earl Evans wrote:
Hi all,
Regarding the comments on baud rate and flow control - still doesn't make
sense to me why the VT100 would not exhibit the error with a real PDP-11
(at 9600 baud), but does do it with the emulated PDP-11. The info is coming
at the terminal at the same rate - why would the behavior be different?
Although the bit rate for each character may be the same, the delay
between characters is likely to be greater on the real PDP-11 than the
(faster) emulated one. So, it is the character rate and not bit rate
that matters.
The faster character rate doesn't give the terminal enough time to unload
its receive queue and process the characters (and escape sequences)
like it has with the real PDP-11. Without flow control, you evenutally
overrun the terminal's receive queue and start dropping characters and
screwing up escape sequences.
--
Chris Elmquist
9:45 a.m.
On Feb 27, 2013, at 3:53 AM, Earl Evans <earl at retrobits.com> wrote:
Hi all,
Regarding the comments on baud rate and flow control - still doesn't make
sense to me why the VT100 would not exhibit the error with a real PDP-11
(at 9600 baud), but does do it with the emulated PDP-11. The info is coming
at the terminal at the same rate - why would the behavior be different?
That would be true if the real PDP-11 sent characters at full throttle
all the time, but in general it does not. There's generally an inter-
character delay. On a faster system, the data can come out full-blast
and swamp the receiver if it can't keep up with the byte data rate.
In other words, the serial hardware is totally capable of handling 9600
baud, but the software managing the display isn't capable of handling
960 characters per second sustained.
- Dave
11:16 a.m.
First off, thanks as usual for all the great discussion. I learn so much
from this list.
I reduced the baud rate to 300, and had no problems. Increased to 1200, and
things kept working. I'll leave it at 1200 for now and keep playing around.
Still, there's one thing doesn't make sense. When I'm using the VT100 in
Linux, connected to the same host computer at 9600 baud (just not running
SIMH), things function flawlessly. I can do large textual outputs. I can
view man pages and perform editing sessions with proper screen codes. No
corruption and no sign of the terminal struggling to keep up, even though
Linux is throwing characters at it way faster than the emulator could. But
go into SIMH, and it starts to fall apart.
Oh well, more experimentation.
- Earl
28 Feb
28 Feb
5:44 a.m.
* Earl Evans <earl at retrobits.com> [130228 02:27]:
First off, thanks as usual for all the great
discussion. I learn so much
from this list.
I reduced the baud rate to 300, and had no problems. Increased to 1200, and
things kept working. I'll leave it at 1200 for now and keep playing around.
Still, there's one thing doesn't make sense. When I'm using the VT100 in
Linux, connected to the same host computer at 9600 baud (just not running
SIMH), things function flawlessly. I can do large textual outputs. I can
view man pages and perform editing sessions with proper screen codes. No
corruption and no sign of the terminal struggling to keep up, even though
Linux is throwing characters at it way faster than the emulator could. But
go into SIMH, and it starts to fall apart.
Oh well, more experimentation.
- Earl
Your tty from Linux probably has XON/XOFF flow control enabled. You
could do an 'stty -F <terminal_device> -a' and see if ixon is set.
(And SIMH probably disables that setting.)
Todd
27 Feb
27 Feb
12:51 p.m.
In article <CAMDAk4cMo1Dbb9GPw=6L0KV07AL0yFJxf5HnraTjcxMhJUGnhQ at mail.gmail.com>,
Earl Evans <earl at retrobits.com> writes:
Regarding the comments on baud rate and flow control -
still doesn't make
sense to me why the VT100 would not exhibit the error with a real PDP-11
(at 9600 baud), but does do it with the emulated PDP-11. The info is coming
at the terminal at the same rate - why would the behavior be different?
A real PDP-11 has hardware flow control turned on in the interface.
If you're coming in over a modem, you need to make sure both ends of
the communication are either i) setup for XON/XOFF flow control, or
ii) the remote OS is setup to use fill padding based on baud rate.
Escape sequence specifications in terminfo have the ability to specify
fill characters (or delays) based on baud rate. Here is my shell's
idea of the vt100 terminfo entry:
# Reconstructed via infocmp from file: /lib/terminfo/v/vt100
vt100|vt100-am|dec vt100 (w/advanced video),
am, mc5i, msgr, xenl, xon,
cols#80, it#8, lines#24, vt#3,
acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
clear=\E[H\E[J$<50>, cr=^M, csr=\E[%i%p1%d;%p2%dr,
cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J,
cuf=\E[%p1%dC, cuf1=\E[C$<2>,
cup=\E[%i%p1%d;%p2%dH$<5>, cuu=\E[%p1%dA,
cuu1=\E[A$<2>, ed=\E[J$<50>, el=\E[K$<3>, el1=\E[1K$<3>,
enacs=\E(B\E)0, home=\E[H, ht=^I, hts=\EH, ind=^J, ka1=\EOq,
ka3=\EOs, kb2=\EOr, kbs=^H, kc1=\EOp, kc3=\EOn, kcub1=\EOD,
kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kent=\EOM, kf0=\EOy,
kf1=\EOP, kf10=\EOx, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOt,
kf6=\EOu, kf7=\EOv, kf8=\EOl, kf9=\EOw, lf1=pf1, lf2=pf2,
lf3=pf3, lf4=pf4, mc0=\E[0i, mc4=\E[4i, mc5=\E[5i, rc=\E8,
rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O, rmam=\E[?7l,
rmkx=\E[?1l\E>, rmso=\E[m$<2>, rmul=\E[m$<2>,
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,
sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t\016%e\017%;$<2>,
sgr0=\E[m\017$<2>, smacs=^N, smam=\E[?7h, smkx=\E[?1h\E=,
smso=\E[7m$<2>, smul=\E[4m$<2>, tbc=\E[3g,
Notice the entries with <2>, <3>, etc. These specify the relative
delay or padding necessary when that ESC sequence is issued. The
delays are all proportional to baud rate -- the faster you
communicate, the more delay/padding is used.
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
2:31 p.m.
A real PDP-11 has hardware flow control turned on in the interface.
Not necessarily. Most DL-11 interfaces, notably the DL11-W, had no hardware flow control
of any kind, or even modem control, and the 11w was probably the most common console
interface for unibus pdp11s. It included the line clock.
28 Feb
28 Feb
5:14 a.m.
On Feb 27, 2013, at 5:31 PM, Roe Peterson <roe at liveblockauctions.com> wrote:
I was going to say something about that; certainly the SLUs on
the KDF11-Bx don't have anything along those lines. I should
know; I had to hack together SLU cables by rewiring PC internal
serial cables, and if there was any kind of handshake line, I
would have wired it up.
- Dave
A real PDP-11 has hardware flow control turned on in the interface.
Not necessarily. Most DL-11 interfaces, notably the DL11-W, had no hardware flow control
of any kind, or even modem control, and the 11w was probably the most common console
interface for unibus pdp11s. It included the line clock. 
27 Feb
27 Feb
4 p.m.
On Wed, Feb 27, 2013 at 12:53:38AM -0800, Earl Evans wrote:
Regarding the comments on baud rate and flow control -
still doesn't make
sense to me why the VT100 would not exhibit the error with a real PDP-11
(at 9600 baud), but does do it with the emulated PDP-11. The info is coming
at the terminal at the same rate - why would the behavior be different?
My guess is buffering. The serial driver and/or host OS are likely to
provide some buffering on output so that the first N characters sent over
the emulated DL11 appear (to the PDP-11) to go out more or less instantly.
So by the time an XOFF comes back (and the PDP-11 stops sending more chars
to the DL11), lots more characters are already working their way out, so
you're going to get the SUB blocks on the screen when they arrive at the
VT100 and overflow its input buffer.
I don't know what other emulators have, but in E11 there's an ASSIGN /TXMAX:n
switch which sets the limit for transmit buffering. I think the default is
something like 16, which is OK for some devices which send XOFF when they
still have space left, but not for others like the LA120 which needs /TXMAX:1
or else BOOOOOOOOOOOOOOOP.
John Wilson
D Bit
5:30 p.m.
New subject: NASA Rope Memory Module B28
Anyone know what this is out of ? It looks a lot like
http://www.apolloartifacts.com/2008/01/rope-memory-mod.html
Usually ebay descriptions are just crazy talk but, that may be an actual
Apollo artifact.
http://www.ebay.com/itm/Raytheon-NASA-Rope-Memeory-Module-B28-/111020115489
4098
days inactive
4100
days old
20 comments
12 participants
participants (12)
-
ajp166＠verizon.net -
chrise＠pobox.com -
db＠db.net -
earl＠retrobits.com -
ethan.dicks＠gmail.com -
fraveydank＠gmail.com -
legalize＠xmission.com -
marcogb＠xs4all.nl -
mc68010＠gmail.com -
roe＠liveblockauctions.com -
tsg＠bonedaddy.net -
wilson＠dbit.com