[TUHS] Re: Compatibility question

[TUHS] Re: Compatibility question

[David Arnold]


> On 17 Dec 2023, at 13:02, KenUnix <ken.unix.guy@gmail.com> wrote:

-8<—

> I have tried vt100, vt100-am, vt100-nam and none
> work as expected.

I have a long-ago recollection that using vt100 had rendering issues with emacs, but vt102 was fine.  Maybe worth a shot?



d

[TUHS] Re: Compatibility question

[segaloco via TUHS]

> > I have tried vt100, vt100-am, vt100-nam and none
> > work as expected.
> >
> > -Ken
> 
> 
> I have a long-ago recollection that using vt100 had rendering issues with emacs, but vt102 was fine. Maybe worth a shot?
> 
> 
> 
> d

I'll hopefully be able to offer up hardware confirmation in a week...secured a VT100 for a reasonable price due to missing keyboard...and I happen to have one such keyboard.  Ken your images run fine on my install of SimH VAX-11/780 so I'll try and serial that machine straight out to the VT100 once I've got it setup.  Fwiw I hopped in vi a few times to build a few sample programs and didn't run into any issues, this is with TERM=vt100, and the enclosing xterm is not 80x24 currently, half a screen in dwm (although naturally the vi window in SimH is the right size.)

- Matt G.

[TUHS] Re: Compatibility question

[James Frew]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf 
mode")? AFAIK none of the emulators (or "VT100-compatible" iron, for 
that matter) ever bothered to replicate this (for which hackers prone to 
motion sickness remain grateful 🤢)

/Frew

P.S.: Fond memories of the USENIX where Rob Pike, in a talk describing 
the Blit, announced "and [pause] it is NOT VT-100 compatible", to 
thunderous applause. A lot of termcap tweakers in that audience...

On 2023-12-17 00:08, segaloco via TUHS wrote:
> secured a VT100 for a reasonable price

[-- Attachment #2: Type: text/html, Size: 1087 bytes --]

[TUHS] Re: Compatibility question

[Lars Brinkhoff]

James Frew wrote:
> Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf mode")?
> AFAIK none of the emulators (or "VT100-compatible" iron, for that matter)
> ever bothered to replicate this (for which hackers prone to motion sickness
> remain grateful 🤢)

I made one which simulates the VT100 hardware and runs the original ROM.
There are two more emulators like that.

[TUHS] Re: Compatibility question

[Brad Spencer]

Lars Brinkhoff <lars@nocrew.org> writes:

> James Frew wrote:
>> Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf mode")?
>> AFAIK none of the emulators (or "VT100-compatible" iron, for that matter)
>> ever bothered to replicate this (for which hackers prone to motion sickness
>> remain grateful 🤢)
>
> I made one which simulates the VT100 hardware and runs the original ROM.
> There are two more emulators like that.


That is really very neat and honestly not something I would have thought
of.



-- 
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

[TUHS] Re: Compatibility question

[Paul Winalski]

One problem that the VT100 emulators may have is that they behave
according to the published VT100 specifications rather than the actual
hardware behavior.

The VT100 had notoriously buggy firmware.  Alan Kotok, one of DEC's
early engineers, encountered some of these and was annoyed enough
about it that he wrote a program to generate a complete list of escape
sequences--legal and illegal--which he fed to his VT100 terminal.  The
results were highly entertaining.  Some perfectly valid escape
sequences were mishandled by the firmware and had behavior that didn't
match the documentation.  Even worse, some illegal escape sequences
caused catastrophic behavior, such as the terminal freezing with the
alarm continuously on--the only way out was to power-cycle the
terminal.  One particularly nasty escape sequence caused corruption of
the EPROM such that the terminal crashed on power-up or restart,
resulting in an infinite crash-and-restart loop that could only be
fixed by sending the terminal in for a factory reset.

Kotok published his results within DEC engineering and shortly
thereafter "email bombs" containing escape sequences that triggered
some of the milder of the bugs started circulating.  The VAX/VMS mail
utility had to be changed to filter out escape sequences by default.

-Paul W.

[TUHS] Re: Compatibility question

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

On Sun, Dec 17, 2023 at 11:48 AM Paul Winalski <paul.winalski@gmail.com>
wrote:

> One problem that the VT100 emulators may have is that they behave
> according to the published VT100 specifications rather than the actual
> hardware behavior.
>

They behave like the author of the emulator thinks the documentation
describes.
But often, ambiguity in descriptions lead to bad decisions here,
especially when
you go to the far right of the screen, the bottom right corner, etc.
There's several
quirks of VT100 behavior that just aren't clearly documented. They aren't
bugs,
per se, but people depend on that behavior.


> The VT100 had notoriously buggy firmware.  Alan Kotok, one of DEC's
> early engineers, encountered some of these and was annoyed enough
> about it that he wrote a program to generate a complete list of escape
> sequences--legal and illegal--which he fed to his VT100 terminal.  The
> results were highly entertaining.  Some perfectly valid escape
> sequences were mishandled by the firmware and had behavior that didn't
> match the documentation.  Even worse, some illegal escape sequences
> caused catastrophic behavior, such as the terminal freezing with the
> alarm continuously on--the only way out was to power-cycle the
> terminal.  One particularly nasty escape sequence caused corruption of
> the EPROM such that the terminal crashed on power-up or restart,
> resulting in an infinite crash-and-restart loop that could only be
> fixed by sending the terminal in for a factory reset.
>
> Kotok published his results within DEC engineering and shortly
> thereafter "email bombs" containing escape sequences that triggered
> some of the milder of the bugs started circulating.  The VAX/VMS mail
> utility had to be changed to filter out escape sequences by default.
>

Yea... Those are fun...  I wonder how many got fixed in later versions?

I'd also read somewhere that VT220 development was slowed by
having to behave exactly the same way as the VT100s (the above
example was one given)...  But at least they had the benefit of being
able to look at the old firmware code... At least I'd suppose that was
a benefit...

Warner

[-- Attachment #2: Type: text/html, Size: 2893 bytes --]

[TUHS] Re: Compatibility question

[Dave Horsfall]

On Sun, 17 Dec 2023, Paul Winalski wrote:

> One problem that the VT100 emulators may have is that they behave 
> according to the published VT100 specifications rather than the actual 
> hardware behavior.

DEC did pretty much the same thing with the Unibus to keep out 3rd-party 
boards; the published specs didn't match the implementation, so your 
non-DEC board would have subtle timing issues.

DEC of course just shrugged and said "Our boards work just fine, so yours 
must be faulty"...

-- Dave

[TUHS] Re: Compatibility question

[Dan Cross]

On Sun, Dec 17, 2023 at 1:13 PM James Frew <frew@ucsb.edu> wrote:
> Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf mode")? AFAIK none of the emulators (or "VT100-compatible" iron, for that matter) ever bothered to replicate this (for which hackers prone to motion sickness remain grateful 🤢)

HDS terminals could do that. I rather liked it, honestly. I don't
recall it ever making me feel sick, but it definitely led to character
overruns. :-/

        - Dan C.

>
> /Frew
>
> P.S.: Fond memories of the USENIX where Rob Pike, in a talk describing the Blit, announced "and [pause] it is NOT VT-100 compatible", to thunderous applause. A lot of termcap tweakers in that audience...
>
> On 2023-12-17 00:08, segaloco via TUHS wrote:
>
> secured a VT100 for a reasonable price

[TUHS] Re: Compatibility question

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

On Sun, Dec 17, 2023, 12:26 PM Dan Cross <crossd@gmail.com> wrote:

> On Sun, Dec 17, 2023 at 1:13 PM James Frew <frew@ucsb.edu> wrote:
> > Wow, an actual VT-100! Have you tried "smooth scrolling" (aka "barf
> mode")? AFAIK none of the emulators (or "VT100-compatible" iron, for that
> matter) ever bothered to replicate this (for which hackers prone to motion
> sickness remain grateful 🤢)
>
> HDS terminals could do that. I rather liked it, honestly. I don't
> recall it ever making me feel sick, but it definitely led to character
> overruns. :-/
>


Smooth scroll was good for 1 application I had. There was a 30 line message
with instructions and info about a group. You then hit a hit to fill out a
form for more info. The smooth scroll prevented burnin... though the
terminal was only active a few months...

Every other time, though, I disabled it post haste.

Warner

        - Dan C.
>
> >
> > /Frew
> >
> > P.S.: Fond memories of the USENIX where Rob Pike, in a talk describing
> the Blit, announced "and [pause] it is NOT VT-100 compatible", to
> thunderous applause. A lot of termcap tweakers in that audience...
> >
> > On 2023-12-17 00:08, segaloco via TUHS wrote:
> >
> > secured a VT100 for a reasonable price
>

[-- Attachment #2: Type: text/html, Size: 2054 bytes --]

[TUHS] Re: Compatibility question

[Brad Spencer]

David Arnold <davida@pobox.com> writes:

> 
>> On 17 Dec 2023, at 13:02, KenUnix <ken.unix.guy@gmail.com> wrote:
>
> -8<—
>
>> I have tried vt100, vt100-am, vt100-nam and none
>> work as expected.
>
> I have a long-ago recollection that using vt100 had rendering issues with emacs, but vt102 was fine.  Maybe worth a shot?
>
>
>
> d



Unless you are actually using a real VT100 physical serial terminal
there is very much a non-zero chance that the terminal emulator that you
are using is not really vt100, vt102, or any such thing, but some
subset, superset or variant that isn't quite like a real physical VT100,
close but not exact.  You may try 'ansi' or 'xterm', if either of those
are available in the Unix you are using.  If not, try a different
terminal emulator.

Example..  a long time ago in a university far away, there was Data
General systems mostly and lots of DG211 terminals.  The DG211 have a
ansi mode that is very close to vt100, but not quite.  Along comes
various Unix systems, in particular, a RS6000.  Wanting to play Moria
(successor to rogue), I found that the ansi mode didn't quite cut it and
ended up hacking up a TERMCAP / TERMINFO entry to deal with the issue as
best as it was possible.  I could never come up with a native DG211
entry that worked any better than my hacks. If I recall, the terminal
*MAY* have supported VT52 as well (or that might have been the MV10000
that did some sort of DG211 to VT52 translation) I know I ended up
writing a VT52 terminal emulator (for some reason or other... it was a
long time ago) and I know I used it on the Unix systems that started to
appear around the university as time went on.  VT52 was pretty simple
and it tended to work pretty well.









-- 
Brad Spencer - brad@anduin.eldar.org

[TUHS] Re: Compatibility question

[Arrigo Triulzi via TUHS]

On 17 Dec 2023, at 15:08, Brad Spencer <brad@anduin.eldar.org> wrote:
> ansi mode that is very close to vt100, but not quite.  Along comes
> various Unix systems, in particular, a RS6000.  Wanting to play Moria
> (successor to rogue), I found that the ansi mode didn't quite cut it and
> ended up hacking up a TERMCAP / TERMINFO entry to deal with the issue as
> best as it was possible. 

The number of times I have heard “I couldn’t run {nethack, rogue, Moria} so I tweaked the termcap / terminfo for the terminal”… I had a similar issue with a WY-180 fixed by the local termcap wizard (not me, I abandoned all hope quite rapidly).

Definitely agree that trying “close” terminals is a viable route.

Arrigo 

[TUHS] Compatibility question

[KenUnix]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

I have been working with a VAX780 sim running
Unix System V r2 VAX780 and am having strange
issues.

TERM is defined at vt100

When firing up vi at times the cursor is positioned
in the wrong place or when inserting text it over
writes areas on the screen.

I have tried vt100, vt100-am, vt100-nam and none
work as expected.

Any ideas? Thanks

-Ken

Happy holidays

-- 
WWL 📚

[-- Attachment #2: Type: text/html, Size: 837 bytes --]

[TUHS] Re: Compatibility question

[Seth Morabito]

On 12/16/23 6:01 PM, KenUnix wrote:
> I have been working with a VAX780 sim running
> Unix System V r2 VAX780 and am having strange
> issues.
>
> TERM is defined at vt100
>
> When firing up vi at times the cursor is positioned
> in the wrong place or when inserting text it over
> writes areas on the screen.

I have most often encountered this when my terminal window size was 
larger than exactly 80x24.

If you're using Xterm or Gnome-terminal or a Windows terminal, for 
example, make sure that the window is exactly 80 columns wide by 24 
lines tall, or the VT100 termcap inside the emulator will be very confused.

-Seth

[TUHS] Re: Compatibility question

[segaloco via TUHS]

> On 12/16/23 6:01 PM, KenUnix wrote:
> 
> > I have been working with a VAX780 sim running
> > Unix System V r2 VAX780 and am having strange
> > issues.
> > 
> > TERM is defined at vt100
> > 
> > When firing up vi at times the cursor is positioned
> > in the wrong place or when inserting text it over
> > writes areas on the screen.
> 
> 
> I have most often encountered this when my terminal window size was
> larger than exactly 80x24.
> 
> If you're using Xterm or Gnome-terminal or a Windows terminal, for
> example, make sure that the window is exactly 80 columns wide by 24
> lines tall, or the VT100 termcap inside the emulator will be very confused.
> 
> -Seth

I'm not so sure on that one, I ran this on an arbitrarily sized xterm (I use a tiling WM) and it sized the vi session correctly and didn't seem to exhibit cursor anomalies.  This encapsulating terminal is a recent (past year) build of xterm using I believe the xterm256 or whatever its named TERM, in which I then launched your script using my local copy of vax780.  Tried just now in Linux fbcon with a TERM of "linux" and likewise the vi session still seems to size to 80x24 appropriately and doesn't have any cursor positioning issues.  Note in both cases the TERM variable I describe is the *host* terminal, TERM in the emulated session is vt100.

- Matt G.

[TUHS] Re: Compatibility question

[Mary Ann Horton]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

The concept of a resizable window didn't appear until GUI interfaces. 
Originally the hardware terminal had one specific size and vi depended 
on the screen being that exact size. I suspect that SVr2 was in that 
category, as the Sun merger of SVr4 would have been the reason to 
incorporate it. So try a 24x80 window and see if it behaves.

Try "stty -a" and see if it mentions rows and columns. If not, what 
terminfo says (try "infocmp") is what vi will believe.

It might also matter how you option your vt100 emulator, and even the 
native vt100 had setup options, such as wraparound (terminfo calls this 
auto_right_margin or just am). Vi depends on knowing what the cursor 
does when it types in the rightmost column.

Thanks,

/Mary Ann Horton/ (she/her/ma'am)
maryannhorton.com <https://maryannhorton.com>



On 12/17/23 10:23, segaloco via TUHS wrote:
>> On 12/16/23 6:01 PM, KenUnix wrote:
>>
>>> I have been working with a VAX780 sim running
>>> Unix System V r2 VAX780 and am having strange
>>> issues.
>>>
>>> TERM is defined at vt100
>>>
>>> When firing up vi at times the cursor is positioned
>>> in the wrong place or when inserting text it over
>>> writes areas on the screen.
>>
>> I have most often encountered this when my terminal window size was
>> larger than exactly 80x24.
>>
>> If you're using Xterm or Gnome-terminal or a Windows terminal, for
>> example, make sure that the window is exactly 80 columns wide by 24
>> lines tall, or the VT100 termcap inside the emulator will be very confused.
>>
>> -Seth
> I'm not so sure on that one, I ran this on an arbitrarily sized xterm (I use a tiling WM) and it sized the vi session correctly and didn't seem to exhibit cursor anomalies.  This encapsulating terminal is a recent (past year) build of xterm using I believe the xterm256 or whatever its named TERM, in which I then launched your script using my local copy of vax780.  Tried just now in Linux fbcon with a TERM of "linux" and likewise the vi session still seems to size to 80x24 appropriately and doesn't have any cursor positioning issues.  Note in both cases the TERM variable I describe is the *host* terminal, TERM in the emulated session is vt100.
>
> - Matt G.

[-- Attachment #2: Type: text/html, Size: 3420 bytes --]

[TUHS] Re: Compatibility question

[Ron Natalie]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

That’s not entirely true.   The VT100 could switch modes from 80x24 to 
132x14 (the latter was pretty ugly) or with the AVO 132x24.


------ Original Message ------
From "Mary Ann Horton" <mah@mhorton.net>
To tuhs@tuhs.org
Date 12/17/23, 5:51:00 PM
Subject [TUHS] Re: Compatibility question

>The concept of a resizable window didn't appear until GUI interfaces. 
>Originally the hardware terminal had one specific size and vi depended 
>on the screen being that exact size. I suspect that SVr2 was in that 
>category, as the Sun merger of SVr4 would have been the reason to 
>incorporate it. So try a 24x80 window and see if it behaves.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2024 bytes --]

[TUHS] Re: Compatibility question

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

On Sun, Dec 17, 2023, 4:00 PM Ron Natalie <ron@ronnatalie.com> wrote:

> That’s not entirely true.   The VT100 could switch modes from 80x24 to
> 132x14 (the latter was pretty ugly) or with the AVO 132x24.
>

I recall some VMS programs in v3.2 misbehaving when run in 132x24 mode...

Warner

------ Original Message ------
> From "Mary Ann Horton" <mah@mhorton.net>
> To tuhs@tuhs.org
> Date 12/17/23, 5:51:00 PM
> Subject [TUHS] Re: Compatibility question
>
> The concept of a resizable window didn't appear until GUI interfaces.
> Originally the hardware terminal had one specific size and vi depended on
> the screen being that exact size. I suspect that SVr2 was in that category,
> as the Sun merger of SVr4 would have been the reason to incorporate it. So
> try a 24x80 window and see if it behaves.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1996 bytes --]

[TUHS] Re: Compatibility question

[KenUnix]

[-- Attachment #1.1: Type: text/plain, Size: 1808 bytes --]

Here is what I ended up doing. Creating a putty session with locked size.
Aso
using the vi as designed it works well. I have included the putty.defs,
putty.notes
and vi.notes.

Now everything is fine. Thanks for your help.

See attachments

Getting System-V-r2-VAX780:

For those running Arch the tar file is here. Simply download, untar
cd to it , type in ./unix

https://drive.google.com/file/d/1XToKXIxZvs9LKNerkVbTNspMik7OnLrs/view?usp=drive_link

For other 64 bit Unix's use this image

https://drive.google.com/file/d/1L-M8dGXogDpKutR0fpSkOkaEfNNH-1SZ/view?usp=drive_link

Getting System-V-r3-3b2-700 64bit:

https://drive.google.com/file/d/16zJrq3USLFAVnoGtbh4GCIj685o_UQER/view?usp=drive_link

The above packages do not require any special software. It is all self
contained.

-ken


On Sun, Dec 17, 2023 at 6:08 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Sun, Dec 17, 2023, 4:00 PM Ron Natalie <ron@ronnatalie.com> wrote:
>
>> That’s not entirely true.   The VT100 could switch modes from 80x24 to
>> 132x14 (the latter was pretty ugly) or with the AVO 132x24.
>>
>
> I recall some VMS programs in v3.2 misbehaving when run in 132x24 mode...
>
> Warner
>
> ------ Original Message ------
>> From "Mary Ann Horton" <mah@mhorton.net>
>> To tuhs@tuhs.org
>> Date 12/17/23, 5:51:00 PM
>> Subject [TUHS] Re: Compatibility question
>>
>> The concept of a resizable window didn't appear until GUI interfaces.
>> Originally the hardware terminal had one specific size and vi depended on
>> the screen being that exact size. I suspect that SVr2 was in that category,
>> as the Sun merger of SVr4 would have been the reason to incorporate it. So
>> try a 24x80 window and see if it behaves.
>>
>>
>>

-- 
End of line
JOB TERMINATED

[-- Attachment #1.2: Type: text/html, Size: 3963 bytes --]

[-- Attachment #2: vi.notes --]
[-- Type: application/octet-stream, Size: 616 bytes --]

12-17-2023 KenUnix Old School

In vi under Unix use the following most common keys:

a  = Ad text
dd = Delete current line. Example to delete 3 lines you would enter 3dd
i  = Insert text at cursor position
j  = Join lines at the cursor
p  = paste yanked lines at current line position
q  = Quit vi
q! = Quit vi without saving
r  = Read file , append
s  = Substitute text. Example :s/old/new/ for current line
       or :s 1,$ /old/new/ for entire file
u  = Undo the lest operation
w  = Write file
x  = Erase character under cursor
yy = Yank line
:  = Issue command. Example :w to write file
esc= Go to command mode


[-- Attachment #3: putty.notes --]
[-- Type: application/octet-stream, Size: 507 bytes --]

12-17-2023 KenUnix

If putty is not installed under Arch do: sudo pacman -S putty

Under most other Linux's do: sudo apt-get install putty

File putty.defs contains the setup for running putty under Linux port 2323.

Put putty.defs into ~/.putty/sessions/telnet2323
This will give you a pre-configured vt-100 setup with 20 points font.

Then when firing up putty load telnet2323. Then click open
after a few seconds you should get a Unix login screen.

When done right click on the window and click close.


[-- Attachment #4: putty.defs --]
[-- Type: application/octet-stream, Size: 4779 bytes --]

Present=1
HostName=localhost
LogFileName=putty.log
LogType=0
LogFileClash=-1
LogFlush=1
LogHeader=1
SSHLogOmitPasswords=1
SSHLogOmitData=0
Protocol=telnet
PortNumber=2323
CloseOnExit=0
WarnOnClose=1
PingInterval=0
PingIntervalSecs=0
TCPNoDelay=1
TCPKeepalives=0
TerminalType=xterm
TerminalSpeed=38400,38400
TerminalModes=CS7=A,CS8=A,DISCARD=A,DSUSP=A,ECHO=A,ECHOCTL=A,ECHOE=A,ECHOK=A,ECHOKE=A,ECHONL=A,EOF=A,EOL=A,EOL2=A,ERASE=A,FLUSH=A,ICANON=A,ICRNL=A,IEXTEN=A,IGNCR=A,IGNPAR=A,IMAXBEL=A,INLCR=A,INPCK=A,INTR=A,ISIG=A,ISTRIP=A,IUCLC=A,IUTF8=A,IXANY=A,IXOFF=A,IXON=A,KILL=A,LNEXT=A,NOFLSH=A,OCRNL=A,OLCUC=A,ONLCR=A,ONLRET=A,ONOCR=A,OPOST=A,PARENB=A,PARMRK=A,PARODD=A,PENDIN=A,QUIT=A,REPRINT=A,START=A,STATUS=A,STOP=A,SUSP=A,SWTCH=A,TOSTOP=A,WERASE=A,XCASE=A
AddressFamily=0
ProxyExcludeList=
ProxyDNS=1
ProxyLocalhost=0
ProxyMethod=0
ProxyHost=proxy
ProxyPort=80
ProxyUsername=
ProxyPassword=
ProxyTelnetCommand=connect %host %port\n
ProxyLogToTerm=1
Environment=
UserName=
UserNameFromEnvironment=0
LocalUserName=
NoPTY=0
Compression=0
TryAgent=1
AgentFwd=0
GssapiFwd=0
ChangeUsername=0
Cipher=aes,chacha20,aesgcm,3des,WARN,des,blowfish,arcfour
KEX=ntru-curve25519,ecdh,dh-gex-sha1,dh-group18-sha512,dh-group17-sha512,dh-group16-sha512,dh-group15-sha512,dh-group14-sha1,rsa,WARN,dh-group1-sha1
HostKey=ed448,ed25519,ecdsa,rsa,dsa,WARN
PreferKnownHostKeys=1
RekeyTime=60
GssapiRekey=2
RekeyBytes=1G
SshNoAuth=0
SshNoTrivialAuth=0
SshBanner=1
AuthTIS=0
AuthKI=1
AuthGSSAPI=1
AuthGSSAPIKEX=1
GSSLibs=libgssapi,libgssapi_krb5,libgss,custom
GSSCustom=
SshNoShell=0
SshProt=3
LogHost=
SSH2DES=0
PublicKeyFile=
DetachedCertificate=
AuthPlugin=
RemoteCommand=
RFCEnviron=0
PassiveTelnet=0
BackspaceIsDelete=0
RXVTHomeEnd=0
LinuxFunctionKeys=0
ShiftedArrowKeys=0
NoApplicationKeys=0
NoApplicationCursors=0
NoMouseReporting=0
NoRemoteResize=1
NoAltScreen=1
NoRemoteWinTitle=1
NoRemoteClearScroll=0
RemoteQTitleAction=1
NoDBackspace=0
NoRemoteCharset=0
ApplicationCursorKeys=0
ApplicationKeypad=0
NetHackKeypad=0
AltF4=1
AltSpace=0
AltOnly=0
ComposeKey=0
CtrlAltKeys=1
TelnetKey=0
TelnetRet=1
LocalEcho=2
LocalEdit=2
Answerback=PuTTY
AlwaysOnTop=0
FullScreenOnAltEnter=0
HideMousePtr=0
SunkenEdge=0
WindowBorder=1
CurType=0
BlinkCur=0
Beep=1
BeepInd=0
BellWaveFile=
BellOverload=1
BellOverloadN=5
BellOverloadT=2000000
BellOverloadS=5000000
ScrollbackLines=2000
DECOriginMode=0
AutoWrapMode=1
LFImpliesCR=0
CRImpliesLF=0
DisableArabicShaping=0
DisableBidi=0
WinNameAlways=0
WinTitle=Arch Linux
TermWidth=80
TermHeight=24
FontName=client:Monospace 20
FontQuality=0
FontVTMode=4
UseSystemColours=0
TryPalette=0
ANSIColour=1
Xterm256Colour=1
TrueColour=1
BoldAsColour=1
Colour0=187,187,187
Colour1=255,255,255
Colour2=0,0,0
Colour3=85,85,85
Colour4=0,0,0
Colour5=0,255,0
Colour6=0,0,0
Colour7=85,85,85
Colour8=187,0,0
Colour9=255,85,85
Colour10=0,187,0
Colour11=85,255,85
Colour12=187,187,0
Colour13=255,255,85
Colour14=0,0,187
Colour15=85,85,255
Colour16=187,0,187
Colour17=255,85,255
Colour18=0,187,187
Colour19=85,255,255
Colour20=187,187,187
Colour21=255,255,255
RawCNP=0
UTF8linedraw=0
PasteRTF=0
MouseIsXterm=0
RectSelect=0
PasteControls=0
MouseOverride=1
Wordness0=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
Wordness32=0,1,2,1,1,1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1,1
Wordness64=1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,2
Wordness96=1,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,1,1,1,1
Wordness128=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
Wordness160=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
Wordness192=2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,2,2,2,2,2,2,2,2
Wordness224=2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,1,2,2,2,2,2,2,2,2
MouseAutocopy=0
MousePaste=implicit
CtrlShiftIns=implicit
CtrlShiftCV=none
LineCodePage=UTF-8
CJKAmbigWide=0
UTF8Override=1
Printer=
CapsLockCyr=0
ScrollBar=1
ScrollBarFullScreen=0
ScrollOnKey=0
ScrollOnDisp=1
EraseToScrollback=1
LockSize=0
BCE=1
BlinkText=0
X11Forward=0
X11Display=
X11AuthType=1
X11AuthFile=
LocalPortAcceptAll=0
RemotePortAcceptAll=0
PortForwardings=
BugIgnore1=0
BugPlainPW1=0
BugRSA1=0
BugIgnore2=0
BugHMAC2=0
BugDeriveKey2=0
BugRSAPad2=0
BugPKSessID2=0
BugRekey2=0
BugMaxPkt2=0
BugOldGex2=0
BugWinadj=0
BugChanReq=0
BugRSASHA2CertUserauth=0
BugDropStart=1
BugFilterKexinit=1
StampUtmp=1
LoginShell=1
ScrollbarOnLeft=0
BoldFontName=
WideFontName=
WideBoldFontName=
ShadowBold=0
ShadowBoldOffset=1
SerialLine=/dev/ttyS0
SerialSpeed=9600
SerialDataBits=8
SerialStopHalfbits=2
SerialParity=0
SerialFlowControl=1
WindowClass=
ConnectionSharing=0
ConnectionSharingUpstream=1
ConnectionSharingDownstream=1
SSHManualHostKeys=
SUPDUPLocation=The Internet
SUPDUPCharset=0
SUPDUPMoreProcessing=0
SUPDUPScrolling=0

[TUHS] Re: Compatibility question

[segaloco via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2984 bytes --]

For the record Ken's scripting appears to work with my copy of SimH vax780 albeit with some non-fatal errors, probably different configure flags vs. the static copy in this archive. I'm on aarch64 so can't use the vax780 binary in there but after boot the images seem to run fine for me. Dunno what distros do, my copy is upstream.

Typing "unix" at the double "$" prompt starts the bootstrap. Running uname(1) returns the expected properties for SVR2 for the VAX-11/780.

- Matt G.

P.S. SVR2 is post-1983 so a little touchier, so just some caution on distribution. Not sure if there's any IP ownership differences concerning materials that said "Western Electric" and/or "Bell Laboratories" in their licenses vs materials that said "AT&T". Some clarity from the interested parties would be helpful but I have no clue what the likelihood of a second round of free-to-study licensing of later SysV codebases looks like. I would have to wonder if the licensing of illumos has some technicality where all code SVR4 and back (that being the split point) is technically covered under their license. I'm no lawyer so *shrug*
On Sunday, December 17th, 2023 at 4:35 PM, KenUnix <ken.unix.guy@gmail.com> wrote:

> Here is what I ended up doing. Creating a putty session with locked size. Aso
> using the vi as designed it works well. I have included the putty.defs, putty.notes
> and vi.notes.
>
> Now everything is fine. Thanks for your help.
>
> See attachments
>
> Getting System-V-r2-VAX780:
>
> For those running Arch the tar file is here. Simply download, untar
> cd to it , type in ./unix
>
> https://drive.google.com/file/d/1XToKXIxZvs9LKNerkVbTNspMik7OnLrs/view?usp=drive_link
>
> For other 64 bit Unix's use this image
>
> https://drive.google.com/file/d/1L-M8dGXogDpKutR0fpSkOkaEfNNH-1SZ/view?usp=drive_link
>
> Getting System-V-r3-3b2-700 64bit:
>
> https://drive.google.com/file/d/16zJrq3USLFAVnoGtbh4GCIj685o_UQER/view?usp=drive_link
>
> The above packages do not require any special software. It is all self contained.
>
> -ken
>
> On Sun, Dec 17, 2023 at 6:08 PM Warner Losh <imp@bsdimp.com> wrote:
>
>> On Sun, Dec 17, 2023, 4:00 PM Ron Natalie <ron@ronnatalie.com> wrote:
>>
>>> That’s not entirely true. The VT100 could switch modes from 80x24 to 132x14 (the latter was pretty ugly) or with the AVO 132x24.
>>
>> I recall some VMS programs in v3.2 misbehaving when run in 132x24 mode...
>>
>> Warner
>>
>>> ------ Original Message ------
>>> From "Mary Ann Horton" <mah@mhorton.net>
>>> To tuhs@tuhs.org
>>> Date 12/17/23, 5:51:00 PM
>>> Subject [TUHS] Re: Compatibility question
>>>
>>>> The concept of a resizable window didn't appear until GUI interfaces. Originally the hardware terminal had one specific size and vi depended on the screen being that exact size. I suspect that SVr2 was in that category, as the Sun merger of SVr4 would have been the reason to incorporate it. So try a 24x80 window and see if it behaves.
>
> --
>
> End of line
> JOB TERMINATED

[-- Attachment #2: Type: text/html, Size: 6363 bytes --]

[TUHS] Re: Compatibility question

[Paul Winalski]

On 12/17/23, Ron Natalie <ron@ronnatalie.com> wrote:
> That’s not entirely true.   The VT100 could switch modes from 80x24 to
> 132x14 (the latter was pretty ugly) or with the AVO 132x24.

The 132-character screen width was for displaying files originally
formatted to be printed on a line printer.  Compiler listings and
linker maps, for example.

-Paul W.

[TUHS] Re: Compatibility question

[Jon Forrest]

Speaking of how VMS handled escape sequences, in the 1980s I
swung both ways (e.g. VMS and Unix). When DEC announced TERMTABLE,
a termcap-like library for VMS, I thought it would be fun to
write a termcap to TERMTABLE conversion program, so I did.
I thought this would let me run VMS TUI programs on non-DEC
compatible terminals.

This turned out to be a bad idea because none (?) of the DEC-written
programs actually used TERMTABLE. They were all hard-wired to use
VT100 (and VT52?) escape sequences. As I recall, I couldn't find any
programs that used TERMTABLE in non-trivial ways so I gave up.

Jon Forrest
UCB (ret.)

[TUHS] Re: Compatibility question

[Dave Horsfall]

On Mon, 18 Dec 2023, Paul Winalski wrote:

> The 132-character screen width was for displaying files originally 
> formatted to be printed on a line printer.  Compiler listings and linker 
> maps, for example.

Such as the mighty 1403 :-)

Hint: never leave your cup of coffee on top of it, as the lid will open 
automatically when it runs out of paper...

-- Dave

[TUHS] Re: Compatibility question

[Harald Arnesen]

Dave Horsfall [19/12/2023 02.46]:

> Such as the mighty 1403 :-) Hint: never leave your cup of coffee on top 
> of it, as the lid will open automatically when it runs out of paper...

Haven't heard of anyone doing that, but a stack of punched cards, 
though, before the diagonal line was drawn along the edge of the stack.
-- 
Hilsen Harald

[TUHS] Re: Compatibility question

[Paul Winalski]

On 12/18/23, Dave Horsfall <dave@horsfall.org> wrote:
> On Mon, 18 Dec 2023, Paul Winalski wrote:
>
>> The 132-character screen width was for displaying files originally
>> formatted to be printed on a line printer.  Compiler listings and linker
>> maps, for example.
>
> Such as the mighty 1403 :-)
>
> Hint: never leave your cup of coffee on top of it, as the lid will open
> automatically when it runs out of paper...

The 1403 was the best line printer ever made.  It was originally the
printer for the IBM 1400 second-generation (discrete transistor-based)
computer.  It continued to be the line printer for S/360.  The deluxe
model, the IBM 1403 N1, had a power cover that could be operated under
computer control.  The OS/360 operating system would raise the
printer's cover if an error condition occurred, such as out of paper
or a paper jam.  This was a very useful feature in large data centers
where there were several line printers, to indicate which printer had
a problem.

The cover of a 1403 N1 also provided a convenient and attractive flat
surface on which to place things.  But a dangerous one.  Many a card
deck magtape reel, coffee cup, or pizza box has been unceremoniously
dumped on the floor.

When our shop upgraded from a S/360 model 25 to a S/370 model 125, our
1403 was replaced by a 3203 line printer.  It was not as good as the
1401 had been.

There was a business in Massachusetts in the 1980s that bought and
sold old IBM computer gear.  A company asked them for a quote on their
IBM 1400 system (1401 processor, 1402 card read/punch, 1403 printer).
They were offered $18,000 for the whole system, or $15,000 for the
1403 printer alone.  That's how valued those printers were.

To bring this closer on-topic, was there Unix support for the IBM 1403?

-Paul W.

[TUHS] Re: Compatibility question

[Tom Lyon]

[-- Attachment #1.1: Type: text/plain, Size: 2108 bytes --]

Yes, Amdahl UTS supported the 1403 from earliest days.
There even seem to be some mods to 'tbl' to support it.

On Tue, Dec 19, 2023 at 9:40 AM Paul Winalski <paul.winalski@gmail.com>
wrote:

> On 12/18/23, Dave Horsfall <dave@horsfall.org> wrote:
> > On Mon, 18 Dec 2023, Paul Winalski wrote:
> >
> >> The 132-character screen width was for displaying files originally
> >> formatted to be printed on a line printer.  Compiler listings and linker
> >> maps, for example.
> >
> > Such as the mighty 1403 :-)
> >
> > Hint: never leave your cup of coffee on top of it, as the lid will open
> > automatically when it runs out of paper...
>
> The 1403 was the best line printer ever made.  It was originally the
> printer for the IBM 1400 second-generation (discrete transistor-based)
> computer.  It continued to be the line printer for S/360.  The deluxe
> model, the IBM 1403 N1, had a power cover that could be operated under
> computer control.  The OS/360 operating system would raise the
> printer's cover if an error condition occurred, such as out of paper
> or a paper jam.  This was a very useful feature in large data centers
> where there were several line printers, to indicate which printer had
> a problem.
>
> The cover of a 1403 N1 also provided a convenient and attractive flat
> surface on which to place things.  But a dangerous one.  Many a card
> deck magtape reel, coffee cup, or pizza box has been unceremoniously
> dumped on the floor.
>
> When our shop upgraded from a S/360 model 25 to a S/370 model 125, our
> 1403 was replaced by a 3203 line printer.  It was not as good as the
> 1401 had been.
>
> There was a business in Massachusetts in the 1980s that bought and
> sold old IBM computer gear.  A company asked them for a quote on their
> IBM 1400 system (1401 processor, 1402 card read/punch, 1403 printer).
> They were offered $18,000 for the whole system, or $15,000 for the
> 1403 printer alone.  That's how valued those printers were.
>
> To bring this closer on-topic, was there Unix support for the IBM 1403?
>
> -Paul W.
>

[-- Attachment #1.2: Type: text/html, Size: 2605 bytes --]

[-- Attachment #2: Screenshot from 2023-12-19 09-57-38.png --]
[-- Type: image/png, Size: 12565 bytes --]

[TUHS] Re: Compatibility question

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 3187 bytes --]

Tom smiled while reading that man page: "It is assumed that the TN print
train is being used."
I have to wonder how many younger programmers know what a print train is,
much less what it looked like (or how heavy they were when you
changed them).  Also, with the loss of the use of real lineprinters, you
have to wonder if those same folks understand why the asa(1) program that
POSIX.2 requires is there (although IIRC later *.2 revisions moved it to
the "FORTRAN Runtime Utilities" as an option POSX2_FORT_RUN - but we had it
there in the original draft).

Paul -- you left out the other "feature" -- the noise, which was still
deafening even with a model N1 and its cover.

I equate four sounds to my early computing days: the ASR33 printing, a 1403
printing, a 1402 reading card, and finally, the constant fan noise in the
machine room, plus the smell of light machine oil [definitely in a terminal
room of ASR33s].
ᐧ
ᐧ

On Tue, Dec 19, 2023 at 1:07 PM Tom Lyon <pugs78@gmail.com> wrote:

> Yes, Amdahl UTS supported the 1403 from earliest days.
> There even seem to be some mods to 'tbl' to support it.
>
> On Tue, Dec 19, 2023 at 9:40 AM Paul Winalski <paul.winalski@gmail.com>
> wrote:
>
>> On 12/18/23, Dave Horsfall <dave@horsfall.org> wrote:
>> > On Mon, 18 Dec 2023, Paul Winalski wrote:
>> >
>> >> The 132-character screen width was for displaying files originally
>> >> formatted to be printed on a line printer.  Compiler listings and
>> linker
>> >> maps, for example.
>> >
>> > Such as the mighty 1403 :-)
>> >
>> > Hint: never leave your cup of coffee on top of it, as the lid will open
>> > automatically when it runs out of paper...
>>
>> The 1403 was the best line printer ever made.  It was originally the
>> printer for the IBM 1400 second-generation (discrete transistor-based)
>> computer.  It continued to be the line printer for S/360.  The deluxe
>> model, the IBM 1403 N1, had a power cover that could be operated under
>> computer control.  The OS/360 operating system would raise the
>> printer's cover if an error condition occurred, such as out of paper
>> or a paper jam.  This was a very useful feature in large data centers
>> where there were several line printers, to indicate which printer had
>> a problem.
>>
>> The cover of a 1403 N1 also provided a convenient and attractive flat
>> surface on which to place things.  But a dangerous one.  Many a card
>> deck magtape reel, coffee cup, or pizza box has been unceremoniously
>> dumped on the floor.
>>
>> When our shop upgraded from a S/360 model 25 to a S/370 model 125, our
>> 1403 was replaced by a 3203 line printer.  It was not as good as the
>> 1401 had been.
>>
>> There was a business in Massachusetts in the 1980s that bought and
>> sold old IBM computer gear.  A company asked them for a quote on their
>> IBM 1400 system (1401 processor, 1402 card read/punch, 1403 printer).
>> They were offered $18,000 for the whole system, or $15,000 for the
>> 1403 printer alone.  That's how valued those printers were.
>>
>> To bring this closer on-topic, was there Unix support for the IBM 1403?
>>
>> -Paul W.
>>
>

[-- Attachment #2: Type: text/html, Size: 5346 bytes --]

[TUHS] Re: Compatibility question

[Paul Winalski]

On 12/19/23, Clem Cole <clemc@ccc.com> wrote:
> Tom smiled while reading that man page: "It is assumed that the TN print
> train is being used."
> I have to wonder how many younger programmers know what a print train is,

For the edification of those who don't know, the 1403 line printer and
its brothers worked like this.  There was a (removable and switchable)
horizontal cartridge that sat midway in the printer, laid out
horizontally across the paper, behind an ink-soaked cloth band located
between the print train and the paper.  Behind the paper was a series
of 132 hammers (one per column of print).  The cartridge contained a
single chain of type that was spun at high speed.  Whenever the
position of a desired character passed in front of its desired colu,
that column's hammer struck the back of the paper and thus printed the
character.

There were several print trains available, just as there were several
typeballs for the IBM Selectric typewriter.  One of these used a space
character '  ' both for the space and for the underscore '_'.  This
was the origin of using underscores to represent spaces in program
identifiers.

The other way to do line printing is to have a rotating drum with the
full character set for each column.  This is the way the DEC line
printers worked.  Of course there were minor inaccuracies in the
timing of the hammers, and with the drum-based printers this resulted
in wavy lines.  There were inaccuracies in the print train-style
printers, too, but waviness in the columns is not as noticeable to the
eye as waviness in the lines.  Coming from the IBM world, I considered
the DEC printers total junk.

> Paul -- you left out the other "feature" -- the noise, which was still
> deafening even with a model N1 and its cover.

Yes, the 1403 was very loud.  The pitch of the noise varied with the
sequence of characters being printed.  Some IBM hacker (yes, they
existed) came up with a deck of cards that, when printed, played
"Anchors Aweigh" on the 1403.  IBM field service wasn't very keen on
this hack because it put a lot of wear-and-tear on the print train.

-Paul W.

[TUHS] Re: Compatibility question

[Bakul Shah]

On Dec 19, 2023, at 1:31 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> Yes, the 1403 was very loud.  The pitch of the noise varied with the
> sequence of characters being printed.  Some IBM hacker (yes, they
> existed) came up with a deck of cards that, when printed, played
> "Anchors Aweigh" on the 1403.  IBM field service wasn't very keen on
> this hack because it put a lot of wear-and-tear on the print train.

I couldn't find "Anchors Aweigh" but I did find "La Marseillaise":

https://www.youtube.com/watch?v=Oe0MGO17K10

[For the curious & easily distracted among us....]

[TUHS] Re: Compatibility question

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On Tuesday, 19 December 2023 at 15:52:39 -0800, Bakul Shah wrote:
> On Dec 19, 2023, at 1:31 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
>>
>> Yes, the 1403 was very loud.  The pitch of the noise varied with the
>> sequence of characters being printed.  Some IBM hacker (yes, they
>> existed) came up with a deck of cards that, when printed, played
>> "Anchors Aweigh" on the 1403.  IBM field service wasn't very keen on
>> this hack because it put a lot of wear-and-tear on the print train.
>
> I couldn't find "Anchors Aweigh" but I did find "La Marseillaise":
>
> https://www.youtube.com/watch?v=Oe0MGO17K10

"This video isn't available anymore"

Does anybody have a copy?

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: Compatibility question

[Bakul Shah]

On Dec 19, 2023, at 4:05 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
> 
> On Tuesday, 19 December 2023 at 15:52:39 -0800, Bakul Shah wrote:
>> On Dec 19, 2023, at 1:31 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
>>> 
>>> Yes, the 1403 was very loud.  The pitch of the noise varied with the
>>> sequence of characters being printed.  Some IBM hacker (yes, they
>>> existed) came up with a deck of cards that, when printed, played
>>> "Anchors Aweigh" on the 1403.  IBM field service wasn't very keen on
>>> this hack because it put a lot of wear-and-tear on the print train.
>> 
>> I couldn't find "Anchors Aweigh" but I did find "La Marseillaise":
>> 
>> https://www.youtube.com/watch?v=Oe0MGO17K10
> 
> "This video isn't available anymore"
> 
> Does anybody have a copy?

The above link does work for me... I thought I'd direct you to
archive.org but there it says attempts to archive this video failed.
Strange! May be try another browser?

[TUHS] Re: Compatibility question

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

On Tuesday, 19 December 2023 at 17:03:03 -0800, Bakul Shah wrote:
> On Dec 19, 2023, at 4:05 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
>>
>> On Tuesday, 19 December 2023 at 15:52:39 -0800, Bakul Shah wrote:
>>> I couldn't find "Anchors Aweigh" but I did find "La Marseillaise":
>>>
>>> https://www.youtube.com/watch?v=Oe0MGO17K10
>>
>> "This video isn't available anymore"
>>
>> Does anybody have a copy?
>
> The above link does work for me... I thought I'd direct you to
> archive.org but there it says attempts to archive this video failed.
> Strange! May be try another browser?

Yes, thanks.  "Another browser" seems to have helped.

A hollow voice croaks "interoperability".

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: Compatibility question

[Wesley Parish]

I've just heard it on Firefox, on Fedora.

Wesley Parish

On 20/12/23 14:32, Greg 'groggy' Lehey wrote:
> On Tuesday, 19 December 2023 at 17:03:03 -0800, Bakul Shah wrote:
>> On Dec 19, 2023, at 4:05 PM, Greg 'groggy' Lehey <grog@lemis.com> wrote:
>>> On Tuesday, 19 December 2023 at 15:52:39 -0800, Bakul Shah wrote:
>>>> I couldn't find "Anchors Aweigh" but I did find "La Marseillaise":
>>>>
>>>> https://www.youtube.com/watch?v=Oe0MGO17K10
>>> "This video isn't available anymore"
>>>
>>> Does anybody have a copy?
>> The above link does work for me... I thought I'd direct you to
>> archive.org but there it says attempts to archive this video failed.
>> Strange! May be try another browser?
> Yes, thanks.  "Another browser" seems to have helped.
>
> A hollow voice croaks "interoperability".
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog@lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA.php

[TUHS] Re: Compatibility question

[Mary Ann Horton]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Thank you for this, I never knew how this worked. My experience as an 
IBM 360 (USC-ECL) operator was brief and I never got into the nuts and 
bolts.

I vaguely recall, as a teen, taking a tour of a DEC-10 shop in about 
1970 in Portland. Their printer played "Anchors Aweigh" and I never knew 
how. But now I wonder - does this mean they had an IBM 1403 connected to 
a DEC 10 somehow?

Thanks,

/Mary Ann Horton/ (she/her/ma'am)
maryannhorton.com <https://maryannhorton.com>



On 12/19/23 15:52, Bakul Shah wrote:
> On Dec 19, 2023, at 1:31 PM, Paul Winalski<paul.winalski@gmail.com>  wrote:
>> Yes, the 1403 was very loud.  The pitch of the noise varied with the
>> sequence of characters being printed.  Some IBM hacker (yes, they
>> existed) came up with a deck of cards that, when printed, played
>> "Anchors Aweigh" on the 1403.  IBM field service wasn't very keen on
>> this hack because it put a lot of wear-and-tear on the print train.
> I couldn't find "Anchors Aweigh" but I did find "La Marseillaise":
>
> https://www.youtube.com/watch?v=Oe0MGO17K10
>
> [For the curious & easily distracted among us....]
>

[-- Attachment #2: Type: text/html, Size: 2304 bytes --]

[TUHS] Re: Compatibility question

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On Tue, Dec 19, 2023 at 11:14 PM Mary Ann Horton <mah@mhorton.net> wrote:

> I vaguely recall, as a teen, taking a tour of a DEC-10 shop in about 1970
> in Portland. Their printer played "Anchors Aweigh" and I never knew how.
> But now I wonder - does this mean they had an IBM 1403 connected to a DEC
> 10 somehow?
>

It certainly means they had some kind of chain or train printer, but any
place big enough to have a PDP-10 would probably have had the budget for a
serious printer as well.  I don't know if DEC made a competing printer (I
think they were very early with dot matrix printing?) or not (or who other
than IBM made big lineprinters),  but once you know the trick is possible,
the rest is a relatively simple matter of having someone with a good ear to
tune the printer output so it sounds right.

For a modern and delightful analogue to this, have a look at the
Floppotron.  https://www.youtube.com/@PaweZadrozniak

[-- Attachment #2: Type: text/html, Size: 1365 bytes --]

[TUHS] Re: Compatibility question

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

Until the DECwriter series and the VT04, DEC sold OEM printers and
terminals were made by other manufacturers.   Paul is speaking of the
traditional LP01, which Centronix made (I think) IIRC [Datapoint maybe -- I
forget], and it was ordered with either an upper case only drum [faster -
as it had two copies of the A-Z set] or an upper and lower case drum -
which included some special characters.  The 8-bit parallel interface was
defined by Centronix, which was the standard printer interface for Minis
and later PCs.  The difference with the latter is that IBM used a common
ground wire so they could put it in a DB25S connector. With the PC, IBM
designed the interface using a bi-directional Intel parallel I/O chip so
you could read it - which was not true of the earlier interfaces for
PDP-8/10/11.

As for the LP01 drum, it was possible to replace in the field but a PITA
[we did when we got a used one from Tektronix's Finance shop that was
running RSTS Cobol and moved it to the Teklab's 11/70 - V7++ UNIX system].

FWIW: when the Printronix was released in the late 1970s, it became the
standard lineprinter for UNIX sites until the rise of laser printers.

As for putting a 1403 on a PDP-10, I suspect it was possible, but it
probably took some custom interfacing.
ᐧ
ᐧ
ᐧ
ᐧ

On Wed, Dec 20, 2023 at 11:08 AM Adam Thornton <athornton@gmail.com> wrote:

> On Tue, Dec 19, 2023 at 11:14 PM Mary Ann Horton <mah@mhorton.net> wrote:
>
>> I vaguely recall, as a teen, taking a tour of a DEC-10 shop in about 1970
>> in Portland. Their printer played "Anchors Aweigh" and I never knew how.
>> But now I wonder - does this mean they had an IBM 1403 connected to a DEC
>> 10 somehow?
>>
>
> It certainly means they had some kind of chain or train printer, but any
> place big enough to have a PDP-10 would probably have had the budget for a
> serious printer as well.  I don't know if DEC made a competing printer (I
> think they were very early with dot matrix printing?) or not (or who other
> than IBM made big lineprinters),  but once you know the trick is possible,
> the rest is a relatively simple matter of having someone with a good ear to
> tune the printer output so it sounds right.
>
> For a modern and delightful analogue to this, have a look at the
> Floppotron.  https://www.youtube.com/@PaweZadrozniak
>

[-- Attachment #2: Type: text/html, Size: 4830 bytes --]

[TUHS] Re: Compatibility question

[Alan D. Salewski]

On Wed, Dec 20, 2023, at 11:07, Adam Thornton wrote:
> For a modern and delightful analogue to this, have a look at the
> Floppotron.  https://www.youtube.com/@PaweZadrozniak

Wow, the Floppotron takes things to a whole other level -- thanks
for sharing!

-- 
a l a n   d.   s a l e w s k i
ads@salewski.email
salewski@att.net
https://github.com/salewski

[TUHS] Re: Compatibility question

[Paul Winalski]

On 12/19/23, Mary Ann Horton <mah@mhorton.net> wrote:
>
> I vaguely recall, as a teen, taking a tour of a DEC-10 shop in about
> 1970 in Portland. Their printer played "Anchors Aweigh" and I never knew
> how. But now I wonder - does this mean they had an IBM 1403 connected to
> a DEC 10 somehow?

They very well might have had an IBM 1403 printer on their PDP-10
system.  DEC marketed the PDP-10 as their commercial raised-floor data
center computing solution.  They OEMed a lot of the high-end
peripheral gear for the DEC-10/20 from third-party vendors in the IBM
world.  The high-end disk of the time was an OEM version of the IBM
3330 with an IBM block multiplexer channel-to-DEC MASSBUS adapter.
DEC was notoriously bad at producing 9-track magtape drives.  But they
were smart enough to OEM high-end tape drives from Storage Technology
Corporation, which made the gold standard of tape drives in the IBM
data center world.

So DEC did have the capability to attach IBM gear to the PDP-10.  They
would certainly have an incentive to use 1403 printers in this market.
Nobody familiar with IBM line printers would consider the standard DEC
line printers acceptable.  The 1403 was typically connected to the
S/360/370's byte multiplexer channel (transmits one byte at a time to
each device; intended for slow peripherals such as card readers, line
printers, card punches).  I know DEC had IBM channel adapters for
disks and tapes usually attached by selector or block multiplexer
channels.  They may have had a byte multiplexer channel adapter, too.

-Paul W.

[TUHS] Re: Compatibility question

[Jon Forrest]

On 12/20/2023 8:34 AM, Paul Winalski wrote:

> DEC was notoriously bad at producing 9-track magtape drives. 

Sad but true. Does anybody remember the redoubted TS-11, aka
"Tape Stretcher 11"?

Jon Forrest
UCB (ret.)

[TUHS] Re: Compatibility question

[Steffen Nurpmeso]

Bakul Shah wrote in
 <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org>:
 |On Dec 19, 2023, at 1:31 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
 |> 
 |> Yes, the 1403 was very loud.  The pitch of the noise varied with the
 |> sequence of characters being printed.  Some IBM hacker (yes, they
 |> existed) came up with a deck of cards that, when printed, played
 |> "Anchors Aweigh" on the 1403.  IBM field service wasn't very keen on
 |> this hack because it put a lot of wear-and-tear on the print train.
 |
 |I couldn't find "Anchors Aweigh" but I did find "La Marseillaise":
 |
 |https://www.youtube.com/watch?v=Oe0MGO17K10

My aunt, who once was married with a --Transi-- Pennsylvanian for
decades (and lived there), would surely proclaim "OH, [BIG] BOOOY".

 |[For the curious & easily distracted among us....]

As i am not french i does not matter that it seems not super right.

Thought: if by that time AI would have been a thing, would it have
recomposed it to the Beatles' "Help!", and played it as the boss
went passing along?  (Or, rather, the more empathic "a hard day's
night".)

 --End of <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|
| Only in December: lightful Dubai COP28 Narendra Modi quote:
|  A small part of humanity has ruthlessly exploited nature.
|  But the entire humanity is bearing the cost of it,
|  especially the inhabitants of the Global South.
|  The selfishness of a few will lead the world into darkness,
|  not just for themselves but for the entire world.
|  [Christians might think of Revelation 11:18
|    The nations were angry, and your wrath has come[.]
|    [.]for destroying those who destroy the earth.
|   But i find the above more kind, and much friendlier]

[TUHS] Re: Compatibility question

[Tom Lyon]

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]

I guess the 1403 was the original multimedia output device.
See also Sam Harbison's line printer art:
http://q7.neurotica.com/Oldtech/ASCII/

On Tue, Dec 19, 2023 at 5:11 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> Bakul Shah wrote in
>  <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org>:
>  |On Dec 19, 2023, at 1:31 PM, Paul Winalski <paul.winalski@gmail.com>
> wrote:
>  |>
>  |> Yes, the 1403 was very loud.  The pitch of the noise varied with the
>  |> sequence of characters being printed.  Some IBM hacker (yes, they
>  |> existed) came up with a deck of cards that, when printed, played
>  |> "Anchors Aweigh" on the 1403.  IBM field service wasn't very keen on
>  |> this hack because it put a lot of wear-and-tear on the print train.
>  |
>  |I couldn't find "Anchors Aweigh" but I did find "La Marseillaise":
>  |
>  |https://www.youtube.com/watch?v=Oe0MGO17K10
>
> My aunt, who once was married with a --Transi-- Pennsylvanian for
> decades (and lived there), would surely proclaim "OH, [BIG] BOOOY".
>
>  |[For the curious & easily distracted among us....]
>
> As i am not french i does not matter that it seems not super right.
>
> Thought: if by that time AI would have been a thing, would it have
> recomposed it to the Beatles' "Help!", and played it as the boss
> went passing along?  (Or, rather, the more empathic "a hard day's
> night".)
>
>  --End of <7DEABFE1-9015-461E-82EF-FF8E00516DBD@iitbombay.org>
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> |
> | Only in December: lightful Dubai COP28 Narendra Modi quote:
> |  A small part of humanity has ruthlessly exploited nature.
> |  But the entire humanity is bearing the cost of it,
> |  especially the inhabitants of the Global South.
> |  The selfishness of a few will lead the world into darkness,
> |  not just for themselves but for the entire world.
> |  [Christians might think of Revelation 11:18
> |    The nations were angry, and your wrath has come[.]
> |    [.]for destroying those who destroy the earth.
> |   But i find the above more kind, and much friendlier]
>

[-- Attachment #2: Type: text/html, Size: 3202 bytes --]

[TUHS] Re: Compatibility question

[Rod Bartlett via TUHS]

> On Dec 19, 2023, at 4:31 PM, Paul Winalski <paul.winalski@gmail.com> wrote:
> 
> 
> Yes, the 1403 was very loud.  The pitch of the noise varied with the
> sequence of characters being printed.  Some IBM hacker (yes, they
> existed) came up with a deck of cards that, when printed, played
> "Anchors Aweigh" on the 1403.  IBM field service wasn't very keen on
> this hack because it put a lot of wear-and-tear on the print train.

The holidays always seemed to feature people running programs which played festive songs by punching fully laced cards or printing patterns on the line printers.  Whenever I noticed something, I'd ask the operators to kill those programs because they could cause equipment failures.  A fully laced punch card is much more flexible and likely to jam.  Printing all columns on a printer, especially doing so without a line feed, tends to moisten the paper which tended to gum up the print trains.

Those line printers were definitely noisy.  I've got tinnitus thanks to working around them.

 - Rod

[TUHS] Re: Compatibility question

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 3603 bytes --]

The night operator for the High Speed Job Stream at the University of
Toronto would nap on top of the 1401. He would be woken by the lid lifting
him up when the printer ran out of paper, an effective alarm clock set to
the computer's cycle.

-rob


On Wed, Dec 20, 2023 at 7:34 AM Clem Cole <clemc@ccc.com> wrote:

> Tom smiled while reading that man page: "It is assumed that the TN print
> train is being used."
> I have to wonder how many younger programmers know what a print train is,
> much less what it looked like (or how heavy they were when you
> changed them).  Also, with the loss of the use of real lineprinters, you
> have to wonder if those same folks understand why the asa(1) program that
> POSIX.2 requires is there (although IIRC later *.2 revisions moved it to
> the "FORTRAN Runtime Utilities" as an option POSX2_FORT_RUN - but we had
> it there in the original draft).
>
> Paul -- you left out the other "feature" -- the noise, which was still
> deafening even with a model N1 and its cover.
>
> I equate four sounds to my early computing days: the ASR33 printing, a
> 1403 printing, a 1402 reading card, and finally, the constant fan noise in
> the machine room, plus the smell of light machine oil [definitely in a
> terminal room of ASR33s].
> ᐧ
> ᐧ
>
> On Tue, Dec 19, 2023 at 1:07 PM Tom Lyon <pugs78@gmail.com> wrote:
>
>> Yes, Amdahl UTS supported the 1403 from earliest days.
>> There even seem to be some mods to 'tbl' to support it.
>>
>> On Tue, Dec 19, 2023 at 9:40 AM Paul Winalski <paul.winalski@gmail.com>
>> wrote:
>>
>>> On 12/18/23, Dave Horsfall <dave@horsfall.org> wrote:
>>> > On Mon, 18 Dec 2023, Paul Winalski wrote:
>>> >
>>> >> The 132-character screen width was for displaying files originally
>>> >> formatted to be printed on a line printer.  Compiler listings and
>>> linker
>>> >> maps, for example.
>>> >
>>> > Such as the mighty 1403 :-)
>>> >
>>> > Hint: never leave your cup of coffee on top of it, as the lid will open
>>> > automatically when it runs out of paper...
>>>
>>> The 1403 was the best line printer ever made.  It was originally the
>>> printer for the IBM 1400 second-generation (discrete transistor-based)
>>> computer.  It continued to be the line printer for S/360.  The deluxe
>>> model, the IBM 1403 N1, had a power cover that could be operated under
>>> computer control.  The OS/360 operating system would raise the
>>> printer's cover if an error condition occurred, such as out of paper
>>> or a paper jam.  This was a very useful feature in large data centers
>>> where there were several line printers, to indicate which printer had
>>> a problem.
>>>
>>> The cover of a 1403 N1 also provided a convenient and attractive flat
>>> surface on which to place things.  But a dangerous one.  Many a card
>>> deck magtape reel, coffee cup, or pizza box has been unceremoniously
>>> dumped on the floor.
>>>
>>> When our shop upgraded from a S/360 model 25 to a S/370 model 125, our
>>> 1403 was replaced by a 3203 line printer.  It was not as good as the
>>> 1401 had been.
>>>
>>> There was a business in Massachusetts in the 1980s that bought and
>>> sold old IBM computer gear.  A company asked them for a quote on their
>>> IBM 1400 system (1401 processor, 1402 card read/punch, 1403 printer).
>>> They were offered $18,000 for the whole system, or $15,000 for the
>>> 1403 printer alone.  That's how valued those printers were.
>>>
>>> To bring this closer on-topic, was there Unix support for the IBM 1403?
>>>
>>> -Paul W.
>>>
>>

[-- Attachment #2: Type: text/html, Size: 6237 bytes --]