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.

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.

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.

On Saturday 26 August 2006 09:23 pm, Dave Dunfield wrote:

> 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.

Is there any chance that there are more than one keyword that share the same first few characters?

This reminds me of wordstar "document" format, too...

-- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

I think so, but on one of my old CP/M disks, I came across this table. Does this look like the MS keyword table? I remember writing a converter from MS BASIC80 to another dialect of BASIC, but don't know if this is related to the project.

"DEFSTR" 173 "DEFINT" 174 "DEFSNG" 175 "DEFDBL" 176 "DEF" 152

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... 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

I've gotten the OP-80A to work quite reliably - I have it mounted in a little

bracket that hangs it off the edge of my desk so that I can unfold/refold the paper-tape in piles on the floor as I draw it through. The OP-80A instructions tell you to use a 40w or 60w bulb as the light source and to lower it until you get the right light level to read the holes in the tape. I'm using a "luxo lamp", and find that even a 40w bulb is too bright - I can't move the lamp high enough to keep it from seeing through the tape, so I am using a variac which gives me very good control over the intensity. With this setup I can adjust it to read very reliably and consistantly.

from the sensors on the sprocket track. OK, there are some adjustments on