17 Jul
2014
17 Jul
'14
7:43 p.m.
I recently bought a few punched paper tapes from an eBay seller. They were said to have
been from an IMSAI system, and I found BASIC source code on them.
Except for the leaders at both ends consisting of NULs, the rest of the bytes on each tape
have the most significant bit set. As I understand it, Teletype model 33 ASR units are
conventionally configured with MARK parity keyboards when used with PDP-8 systems, and I
gather that it's conventional to encode PDP-8 source code tapes with MARK parity.
I'm guessing that the same convention was used on the IMSAI, or at least was used by
the original creator of these tapes.
I just received a GNT model 4604 tape punch/reader yesterday, and today I got it working
after making a few repairs. Then, I set to work reading in these tapes and converting the
raw binary images (which I saved separately) to plain ASCII text by clearing the MSBs, and
dropping any NUL and DEL characters. One tape included a splice which the creator marked
with red ink. Each line was terminated by the sequence CR-LF-DEL-DEL.
I presume that the two DELs after each line were there to give a 33 ASR (or similarly slow
printer) time to return the carriage before the next line starts printing.
Here is my question: Is it conventional and/or important to include the two DELs after
each line when creating a source tape which is to be read in to a BASIC interpreter, or is
that just an artifact of how the tapes were created (i.e., by printing source code out to
a 33 ASR printer)? I ask because I want to know if I should include the DELs if I ever
create new tapes from the extracted text files.
The tapes were marked with 1976 dates, and were named:
STRTRK
DIET
BLUFF
I'll share their contents on my web site soon, and I'll also try running them in a
BASIC interpreter sometime.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
17 Jul
17 Jul
8:56 p.m.
On 07/17/2014 07:43 PM, Mark J. Blair wrote:
Here is my question: Is it conventional and/or
important to include
the two DELs after each line when creating a source tape which is to
be read in to a BASIC interpreter, or is that just an artifact of how
the tapes were created (i.e., by printing source code out to a 33 ASR
printer)? I ask because I want to know if I should include the DELs
if I ever create new tapes from the extracted text files.
The DELs/Rubouts were included to allow time for the carriage
return-linefeed at the end of line on TTYs. Usually, one rubout would
do, but two was safe.
It doesn't matter to modern electronic equipment--the rubouts are
non-printing.
Life at 10cps.
--Chuck
9:22 p.m.
On 07/17/2014 08:56 PM, Chuck Guzis wrote:
The DELs/Rubouts were included to allow time for the
carriage
return-linefeed at the end of line on TTYs. Usually, one rubout would
do, but two was safe.
Oh, I'll add that another popular end-of-line sequence when talking to a
remote host was CR-LF-XOFF-DEL-DEL. Same idea, but it would also halt
the paper tape reader. The remote host could then send X-ON to read the
next line.
Thanks for the memories!
--Chuck
10:01 p.m.
On Jul 17, 2014, at 20:56 , Chuck Guzis <cclist at sydex.com> wrote:
The DELs/Rubouts were included to allow time for the
carriage return-linefeed at the end of line on TTYs. Usually, one rubout would do, but
two was safe.
It doesn't matter to modern electronic equipment--the rubouts are non-printing.
Do paper tape BASIC interpreters pay any attention to the DELs when they're loading a
program, or are they just there so that the tape can be printed legibly on teletype-style
console?
Can other nonprinting characters be used in place of the DEL, like a NUL or a 0x80 (NUL
after the MSB is stripped off)? I notice that the DELs weaken those 38-year-old tapes
quite a bit.
I'm asking about these little trivialities because I'll probably write a little
utility for archiving and punching tapes, and I want to get the details right. I've
added some preliminary stuff to my silly paper tape renderer package at
https://github.com/NF6X/papertape but I'll probably write a standalone python script
later, with built-in features to strip or add mark parity, add/remove leaders, punch a
human-readable title at the beginning of a tape, etc.
That GNT 4604 reader really zips through the tape quickly. I put a box in front of it to
catch the tape as it belches out of the reader, but it's still time-consuming to
rewind the tape after reading it. The machine orients the tape the opposite way from my 33
ASR, so the "top" markings on the tape are wrong when swapping a tape punched on
one machine to the other one's reader. Let's see, according to the ECMA standard,
the GNT 4604 is "right" and the 33 ASR is "wrong".
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
10:53 p.m.
On 07/17/2014 10:01 PM, Mark J. Blair wrote:
Do paper tape BASIC interpreters pay any attention to
the DELs when
they're loading a program, or are they just there so that the tape
can be printed legibly on teletype-style console?
Can other nonprinting characters be used in place of the DEL, like a
NUL or a 0x80 (NUL after the MSB is stripped off)? I notice that the
DELs weaken those 38-year-old tapes quite a bit.
DEL/Rubout had a well-accepted meaning in old-school ASCII/USASCII
code--and that was "delete" or "idle". If you were punching tape,
and
made a mistake, the routine was to backspace over the erroneous
characters and overpunch them with DEL/Rubout characters (all holes
punched) and then continue with the correct characters.
Ask any retired TWX or Telex operator.
In fact, ECMA-35 (1994) calls out the matter quite explicitly:
6.2.1
Fixed coded characters
Character DELETE
Name: DELETE
Acronym: DEL Coded representation: 07/15
DEL was originally used to erase or obliterate an erroneous or unwanted
character in punched tape. DEL may be used for media-fill or time-fill.
DEL characters may be inserted into, or removed from, a CC-data-element
without affecting its information content, but such action may affect
the information layout and/or the control of equipment.
So there you go--DELs are to be ignored. Whether or not everyone does
is, of course, a different matter.
--Chuck
18 Jul
18 Jul
2:27 a.m.
Do paper tape
BASIC interpreters pay any attention to the DELs when
they're loading a program, or are they just there so that the tape
can be printed legibly on teletype-style console?
Can other nonprinting characters be used in place of the DEL, like a
NUL or a 0x80 (NUL after the MSB is stripped off)? I notice that the
DELs weaken those 38-year-old tapes quite a bit.
DEL/Rubout had a well-accepted meaning in old-school ASCII/USASCII
code--and that was "delete" or "idle". If you were punching tape,
and
made a mistake, the routine was to backspace over the erroneous
characters and overpunch them with DEL/Rubout characters (all holes
punched) and then continue with the correct characters.
8:12 a.m.
I guess I should do some experimenting in SIMH to see what the paper-tape BASIC
interpreters like to digest; assuming I can find the appropriate interpreter images, that
is. I'll include at least an option to include DELs after each line in my envisioned
future tape puncher/reader utility.
On Jul 18, 2014, at 02:27 , Philip Belben <philip at axeside.co.uk> wrote:
Incidentally, when I had an ASR33 as my only printing
device (bit banging over the PET user port), I never sent any non-printing characters
after CRLF. If I'd used LFCR (as many systems do), that would have been a different
matter...
You must have had a 33 ASR that returned its carriage within one character time plus
whatever overhead your PET's bit-banging routines had. I think that could vary from
machine to machine based on the strength of the carriage spring, how gunky the carriage
rails and rollers are, the dashpot setting, the ambient temperature, and so forth. Three
character periods (LF-DEL-DEL) would probably work for all but the most grungy machines.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
9 a.m.
On 07/18/2014 02:27 AM, Philip Belben wrote:
When the IMSAI (or whatever machine) reads these tapes
in to run them in
BASIC,
Does it need to see two characters there?
Do they have to be DEL?
I thought that I was pretty clear about that--DEL, AFAIK, is the only
character *by definition* is supposed to be ignored--and that goes all
the way back to ECMA-1 (1963) when 6-bit codes were used by data
processing equipment (FWIW, ESCape was defined as 62 decimal/76 octal,
but that was later changed).
Does the IMSAI expect the DELs? I doubt it, since they convey no
information and DELs can appear anywhere in the data stream. If you're
using something other than an ASR33 (e.g., a "glass TTY") in
half-duplex, I doubt that they're necessary.
What's actually done is another matter, since the IMSAI is a hobbyist
computer and very often, standards were not observed in such software.
--Chuck
10:12 a.m.
From: Chuck Guzis: Friday, July 18, 2014 9:00 AM
On 07/18/2014 02:27 AM, Philip Belben wrote:
One possibility that I haven't seen discussed, is that the DELs are
there to provide a delay for the IMSAI. It's conceivable that the
BASIC interpreter ponders it's navel for a short time after a
line is received. Adding a couple of frames of "ignore me"
would give the interpreter two character times to catch up.
If the interpreter was sometimes/often ready early, then
"ignore me" was the harmless thing to send.
Vince
When the IMSAI (or whatever machine) reads these
tapes in to run them in
BASIC,
Does it need to see two characters there?
Do they have to be DEL?
I thought that I was pretty clear about that--DEL, AFAIK, is the only
character *by definition* is supposed to be ignored--and that goes all
the way back to ECMA-1 (1963) when 6-bit codes were used by data
processing equipment (FWIW, ESCape was defined as 62 decimal/76 octal,
but that was later changed).
Does the IMSAI expect the DELs? I doubt it, since they convey no
information and DELs can appear anywhere in the data stream. If you're
using something other than an ASR33 (e.g., a "glass TTY") in
half-duplex, I doubt that they're necessary.
11:13 a.m.
On 07/18/2014 10:12 AM, Vincent Slyngstad wrote:
One possibility that I haven't seen discussed, is
that the DELs are
there to provide a delay for the IMSAI. It's conceivable that the BASIC
interpreter ponders it's navel for a short time after a
line is received. Adding a couple of frames of "ignore me" would give
the interpreter two character times to catch up.
If the interpreter was sometimes/often ready early, then "ignore me" was
the harmless thing to send.
I think I mentioned that at least one of the old timesharing BASIC-like
systems demanded that paper tape input lines end with CR-X-OFF-DEL-DEL.
Given that many systems of the time were half-duplex, the idea was to
have the X-OFF stop the reader until the host was ready to accept
another line, whereupon the host would send LF X-ON.
--Chuck
10:19 a.m.
The answer to:-
Chuck, loads of interesting stuff, but it doesn't answer Mark's question.
What Mark needs to know is:
When the IMSAI (or whatever machine) reads these tapes in to run them in
BASIC,
Does it need to see two characters there?
Do they have to be DEL?
There are three possibilities that I can see:
1. No, the machine just reads the tapes and ignores DEL.
2. Yes, they can be anything, the machine ignores the first two characters
after a CRLF.
3. Yes, they have to be DEL, the machine checks this.
I think the first is the most likely, since the machine is supposed to
ignore DEL anyway, and this doesn't require any extra code. The machine
should accept the input from the tape reader just as if you were typing it
at the keyboard - if your terminal is an ASR33, the machine can't actually
tell, after all!
But you never know. It may even be different on different machines /
versions of the system.
Incidentally, when I had an ASR33 as my only printing device (bit banging
over the PET user port), I never sent any non-printing characters after
CRLF. If I'd used LFCR (as many systems do), that would have been a
different matter...
Philip.
Does it need to see two characters there?
Do they have to be DEL?
Is almost certainly "NO", but I would preserve them, as removing them
destroys the historical integrity of the images....
Dave
G4UGM
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Philip Belben
Sent: 18 July 2014 10:28
To: General Discussion: On-Topic Posts Only
Subject: Re: Encoding of BASIC source code on punched tape
Do paper tape
BASIC interpreters pay any attention to the DELs when
they're loading a program, or are they just there so that the tape
can be printed legibly on teletype-style console?
Can other nonprinting characters be used in place of the DEL, like a
NUL or a 0x80 (NUL after the MSB is stripped off)? I notice that the
DELs weaken those 38-year-old tapes quite a bit.
DEL/Rubout had a well-accepted meaning in old-school ASCII/USASCII
code--and that was "delete" or "idle". If you were punching tape,
and
made a mistake, the routine was to backspace over the erroneous
characters and overpunch them with DEL/Rubout characters (all holes
punched) and then continue with the correct characters.
10:49 a.m.
On Jul 18, 2014, at 10:19 , Dave G4UGM <dave.g4ugm at gmail.com> wrote:
The answer to:-
I will certainly preserve the original images "as-read", even including strings
of NULs where the tape creator made a tape splice, for historical purposes. I want to make
sure that my probable future tape-manipulation utility will have the right feature set for
new tape creation, so I'd like to learn about any conventions, as well as any must-do
and must-not-do rules for various systems.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
Does it need to see two characters there?
Do they have to be DEL?
Is almost certainly "NO", but I would preserve them, as removing them
destroys the historical integrity of the images....
12:33 a.m.
Wasn't all-punched used as an ignore character originally so if you made a
mistake typing to punch you could backspace, punch all holes, and then
carry on...
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Mark J. Blair
Sent: 18 July 2014 06:01
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Encoding of BASIC source code on punched tape
On Jul 17, 2014, at 20:56 , Chuck Guzis <cclist at sydex.com> wrote:
The DELs/Rubouts were included to allow time for the
carriage
return-linefeed at the end of line on TTYs. Usually, one rubout would do,
but two was safe.
It doesn't matter to modern electronic equipment--the rubouts are
non-printing.
Do paper tape BASIC interpreters pay any attention to the DELs when they're
loading a program, or are they just there so that the tape can be printed
legibly on teletype-style console?
Can other nonprinting characters be used in place of the DEL, like a NUL or
a 0x80 (NUL after the MSB is stripped off)? I notice that the DELs weaken
those 38-year-old tapes quite a bit.
I'm asking about these little trivialities because I'll probably write a
little utility for archiving and punching tapes, and I want to get the
details right. I've added some preliminary stuff to my silly paper tape
renderer package at https://github.com/NF6X/papertape but I'll probably
write a standalone python script later, with built-in features to strip or
add mark parity, add/remove leaders, punch a human-readable title at the
beginning of a tape, etc.
That GNT 4604 reader really zips through the tape quickly. I put a box in
front of it to catch the tape as it belches out of the reader, but it's
still time-consuming to rewind the tape after reading it. The machine
orients the tape the opposite way from my 33 ASR, so the "top" markings on
the tape are wrong when swapping a tape punched on one machine to the other
one's reader. Let's see, according to the ECMA standard, the GNT 4604 is
"right" and the 33 ASR is "wrong".
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
3809
days inactive
3809
days old
12 comments
5 participants
participants (5)
-
cclist＠sydex.com -
dave.g4ugm＠gmail.com -
nf6x＠nf6x.net -
philip＠axeside.co.uk -
vrs＠msn.com