This is
supposed to be loaded under Altair BASIC somehow (I'll have to
dig out the Altair BASIC manuals and if it sheds any light) - I thought that
perhaps this in an internal representation, and that AB sets the high bit
on the last character of reserved words ... except that 'INPUT' does not
have the high bit set on it's last character...
It seems consistent that 'INPUT' wouldn't have the high bit set there. The
pattern seems to be that
the high bit is set on the last character of every BASIC keyword. In the context in
which 'INPUT'
appears in this code fragment, it's part of a quoted string, not a keyword.
Also note that the '=' in line 14 (A$="(HEX....) has the high bit set as
well (thus appearing as BD
instead of 3D). = is also likely being treated as a BASIC keyword in this context.
Right you are - to be honest, I just noticed that the high bit was set at the end of REM
and PRINT
after I included the dump in the message, and then I noticed INPUT, but did not notice
that it was
in a a quoted string. I'm going to process the remainder of the code and see if this
rule stays true,
in which case it's something to do with the Altair BASIC and not the format of the
paper-tape
(which remains a simple 8-bit binary channel).
I think you are right about the '=' as well - funny that they would
"tokenize" in this manner - I've
written several BASICs over the years - some which operated on pure plain text (no
tokenization
at all), but most replaced all keywords with a single easily recognizable token - I
don't see what
advantage this type of tokenization could have done as it saves no space, and you still
have to
parse the whole word.
I've got a few versions of the VDM software on paper tape, and I'm supposed to be
getting in
more soon including the dazzler software, spacewar tapes and more - I'm trying to
figure out
the best way to make certain that I archive error free reads - I was hoping for some sort
of
error detection scheme built into the tape layout, however it doesn't look that way -
Now I'm
thinking to perform multiple reads of each tape, and confirm that I get identical data
streams.
I don't know if errors during paper-tape read tend to repeat at the same spot on the
tape or
not... Anyone have a better suggestion?
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools:
www.dunfield.com
com Collector of vintage computing equipment:
http://www.classiccmp.org/dunfield/index.html
