Looks like it marks the last (or only) byte of a BASIC keyword all right;
I think the "Input" is part of the text, not a keyword.
mike
------------Original messsage:
Message: 32
Date: Sat, 26 Aug 2006 19:33:49 -0500
From: "Dave Dunfield" <dave06a at dunfield.com>
Subject: Re: Paper tape and 8th bit?
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <200608262337.k7QNbHXI004269 at hosting.monisys.ca>
If you look at the preceding character, is there any
correlation to the 8th
bit of the next one? The 8th bit just might be garbage left over and not
masked out.
None that I can tell - Also, the 8th bit is punched on the tape with the
character - It seems unlikely that PT would have punched a tape in error
that way (with garbage left over from the previous character in the
8th bit) - although stranger things HAVE happened...
It could be binary.The driver is loaded in the top of
memory, and
seems to patch over a TTY driver. I don't have manual handy
but it does have a bootstrap loader @ 80H I think, the first
256 bytes to load in a hex loader.
I have the manuals as well - this is the BASIC VDM driver, which I
don't believe has a loader.
Here is a HEX dump of the first 256 bytes retrieved from the tape
(after the string of 00s occuring in the leader).
0000 0D 0A 00 00 0D 0A 00 00 30 20 52 45 CD 0D 0A 00 ........0 RE....
0010 00 32 20 52 45 CD 20 20 3C 3C 3C 20 20 42 41 53 .2 RE. <<< BAS
0020 49 43 20 54 4F 20 56 44 4D 2D 31 20 4C 49 4E 4B IC TO VDM-1 LINK
0030 20 50 52 4F 47 52 41 4D 20 20 3E 3E 3E 0D 0A 00 PROGRAM >>>...
0040 00 34 20 52 45 CD 0D 0A 00 00 36 20 52 45 CD 20 .4 RE.....6 RE.
0050 20 20 20 20 20 20 50 52 4F 43 45 53 53 4F 52 20 PROCESSOR
0060 54 45 43 48 4E 4F 4C 4F 47 59 20 43 4F 52 50 2E TECHNOLOGY CORP.
0070 0D 0A 00 00 38 20 52 45 CD 20 20 20 20 20 20 20 ....8 RE.
0080 36 32 30 30 20 48 4F 4C 4C 49 53 20 53 54 52 45 6200 HOLLIS STRE
0090 45 54 0D 0A 00 00 31 30 20 52 45 CD 20 20 20 20 ET....10 RE.
00A0 20 20 45 4D 45 52 59 56 49 4C 4C 45 2C 20 43 41 EMERYVILLE, CA
00B0 4C 49 46 4F 52 4E 49 41 20 20 20 39 34 36 30 38 LIFORNIA 94608
00C0 0D 0A 00 00 31 32 20 50 52 49 4E D4 0D 0A 00 00 ....12 PRIN.....
00D0 31 34 20 41 24 BD 22 28 48 45 58 29 20 49 53 20 14 A$."(HEX) IS
00E0 59 4F 55 52 20 4C 41 53 54 20 41 44 44 52 45 53 YOUR LAST ADDRES
00F0 53 2C 20 49 4E 50 55 54 3A 22 0D 0A 00 00 31 36 S, INPUT:"....16
I have visually verified that the tape contains the binary values for the first
16 bytes as punched dots - (ie, it starts with 0D 0A 00 00 twice), then
20 20 54 45 CD 0D 0A 00
This is the line '0 REM', however the 'M' has the eight bit set, which
makes
the code CD instead of 4D. You can see this in the remaining comments
which are visible as well. However the 'M' in 'EMERYVILLE' appears with
the high bit clear.
You can also see that the 'T' in 'PRINT' has the high bit set.
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...
I have the machine code driver as well, and I will try reading that and
see if the code disassembles into something that makes sense.
Ultimately I will read these and other tapes and archive the code as a
raw binary dump of the tape content, however I'm trying to understand
what is recorded on the tapes so that I can verify my setup.
Regards,
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