All:
I was playing around with the KEGS emulator and I wanted to get
GS/OS working on an emulated hard disk partition. I can't seem to get the
emulator to recognize the 32mb container file which is supposed to be the
hard drive. Has anyone tackled this before and can give me a few pointers?
Thanks.
Rich
Rich Cini
Collector of classic computers
Lead engineer, Altair32 Emulator
Web site: <http://highgate.comm.sfu.ca/~rcini/classiccmp/>
http://highgate.comm.sfu.ca/~rcini/classiccmp/
Web site: http://www.altair32.com/
/***************************************************/
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
Hi,
This a belated cross-post from Ottawa Freecycle.
I have a Tektronix 4107 colour graphics terminal, complete with manual
and keyboard. Free to good home, but you have to come and get it.
Jeff
>
>Subject: Re: Paper tape and 8th bit?
> From: woodelf <bfranchuk at jetnet.ab.ca>
> Date: Sat, 26 Aug 2006 16:48:38 -0600
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>Chuck Guzis wrote:
>
>>
>> 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.
PT and many of the 8080 micros didn't use the punch/reader (ASR33 usually)
in the same way as the PDP-8 and onter Minis. So conventions existed but
didn't always get applied the same.
It's not a bin tape, the manual has the source listing. Its a program "LIST"
of a PT 5k basic program that loads a long list of DATA nnn,nnn into memory
at an address and also pokes the output code of the program to point to VDM1
or Nominal IO depending of sense switch 8 (IN FF; ANI 80; JZ xxxx). Works on
IMSAI or Altair front pannal systems,useless for NS* (no sense sw at FFh).
I still have and use a VDM-1 in a Netronics Explorer 8085. I havent used PT
software since '76ish as I wrote a more compact minimal VT52 screen
emulation for it.
Allison
--- Jules Richardson <julesrichardsonuk at yahoo.co.uk
> wrote:
> aliensrcooluk at yahoo.co.uk wrote:
> > That means there are 5 different floppy disk
> > sizes that I now know of:
> >
> > 3"
> > 3.5"
> > 5"
> > 8"
>
> Add 2" to that - someone handed us a box of them t
he
> other week. I've got a
> feeling that 2.5" existed, too (and presumably by
5"
> you mean what's commonly
> called 5.25"?)
>
hmmm, now you have me slightly confused. After sendi
ng the message I did remember the 5.25" disks (as us
ed on BBC's etc.), but I assumed that 5" and 5.25" w
ere different sizes.
what's with 2" and 2.5", wouldn't they be too
fiddly and/or store too small amount of data
to make them worthwhile?
> > 12" (used on a special Sony Laservision machine)
>
> Hmm, Philips certainly had laservision players (go
t
> one here), but they're
> optical laserdisk players, not floppy (as in
> magnetic media) at all. I'd be
> surprised if a rival company could use the same na
me
> for a totally different
> technology! I've heard rumours of a 12" IBM format
> for one of their early
> mainframes, but I don't know if that's just urban
> legend or not.
>
No legend... give me a while and I'll find a link
to a pic of a 12" disk... Robert Bernardo
(Amiga enthusiast) has been pictured with one
at a retro event fairly recently.
> cheers
>
> Jules
>
>
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
>
>Subject: Re: Paper tape and 8th bit?
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Date: Sat, 26 Aug 2006 23:40:58 +0100 (BST)
> To: cctalk at classiccmp.org
>
>>
>> Hi Guys,
>>
>> I'm attempting to recover some software from paper-tape.
>>
>> Never actually had a PT reader in my "altair days", I fooled around
>> with magnetic tape systems (audio and 9-track), and later went to
>> the NorthStar disk system... Did a bit of paper-tape stuff with the
>> university systems, but I don't recall any real details.
>>
>> Anyway - I'm using an OP-80A which is a very simple manual feed
>> reader - you position a light over the unit and pull the tape through
>> wire guides over an optical sensor and it provides parallel data.
>>
>> This all appears to work OK.
>>
>> The tape I've been testing with is a Processor Technology "BASIC
>> VDM DRIVER" - it contains driver software for the PT VDM-1 video
>> board.
>>
>> My question - Does anyone know what they are using the 8th bit
>> for? - I get nicely readable ASCII BASIC source out of it, except
>
>Well, AFAIK few punches [1] or readers ever did anything with the 8th bit
>other than just transfer it to/from the system. So what it means depends
>on the device that punched that tape.
>
>[1] I say 'few', not none because the serial adapter board for the 4070
>can be set up to make this a locally-generated parity bit. In other words
>you can send it 7 bit characters (or 8 bit with the top bit ignored) and
>it will punch them with the 8th level an even parity bit. All
>link-selectable.
The punch and reader "dumb" devices though some did parity local that
was more exception than general practice.
>
>> that the 8th bit seems to be somewhat randomly set on certain
>> characters. If I strip the 8th bit I get what appears to be legit BASIC
>> code.
>>
>> I thought it might be parity, however this does not appear to be
In PT systems that may have been used as a "page" (VT or FF) marker.
I have the VDM-1 and the basic driver is ascii and the resulting program
load the binary driver.
>That would have been my first guess too. Normally even parity, since then
>totally blank and all holes are valid characters (the latter can be used
>to overpunch any other character, and was origianlly simply ignored by
>the system).
>
>Of course on a binary tape (true binary, not Intel-Hex or something),
>it's just anothe bit.
It's an Ascii punch of the PT basic "LIST: command. The 8th hole may
well be random trash or a particular character in memory that had the
high bit set.
>> the case - the codes 0A (00001010) and 0D (00001101) both
>> appear with the 8th bit clear - If the 8th bit were parity, one or
>> the other should have it set. Other characters always have it set,
>> for example 'T' (54) seems to always appears as (D4).
>
>Doe any character exist in both forms (with the top bit both clear and
>set)? If so, could it be something like a 'start of statement' marker or
>'start of keyword' or soemthing like that?
Easier, what is the punch pattern on the tape that corrosponds to the 8th
bit?
My tape is deeply burried since I stopped using back in '76. I know the
box it's in far enough down the stack to not warrent looking.
Allison
--- Jules Richardson <julesrichardsonuk at yahoo.co.uk
> wrote:
> aliensrcooluk at yahoo.co.uk wrote:
> > That means there are 5 different floppy disk
> > sizes that I now know of:
> >
> > 3"
> > 3.5"
> > 5"
> > 8"
>
> Add 2" to that - someone handed us a box of them t
he
> other week. I've got a
> feeling that 2.5" existed, too (and presumably by
5"
> you mean what's commonly
> called 5.25"?)
>
> > 12" (used on a special Sony Laservision machine)
>
> Hmm, Philips certainly had laservision players (go
t
> one here), but they're
> optical laserdisk players, not floppy (as in
> magnetic media) at all. I'd be
> surprised if a rival company could use the same na
me
> for a totally different
> technology! I've heard rumours of a 12" IBM format
> for one of their early
> mainframes, but I don't know if that's just urban
> legend or not.
>
> cheers
>
> Jules
>
Well here's the link to the pic:
http://www.dickestel.com/vintage2005.htm
It's picture 7, taken at the Vintage Computer Festiv
al 2005. I'm not entirely sure that is Robert holdin
g the disk, but he may have taken the picture instea
d?
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
Ray wrote:
> The Alpha chips were coded with EV - as in
>Electro Vlassic. :-)
That is one of those things, like VME, where the "real meaning" is
kept secret. There are several hypotheses, the other one that makes sense
is that it stands for Extended VAX (which, when you trace it out, means
Extended Virtual Address Extension [of the PDP-11], so there's still a little bit of PDP
in HP/DEC (until October...)
AXP however is known to mean nothing.
(could be a place shifting of something, e.g. VAX -> (v)AX[p]
> "I see where you're coming from - but I also know that writing a TIFF
> decoder is pretty straightforward; I wouldn't fancy doing the same
for > either JPEG or PDF (not sure about PNG, but I get the impression
that > it's pretty simple in nature)."
Noooooo!!!!!
Don't do it. The problem with writing your own decoder is that you may
not have your own set of reference images, so testing it would be
'interesting'. This is the major cause of security issues in software
at the moment. All it takes is one case where you mis-handle input, and
you have introduced a vulnerability into your application.
Unfortunately, you can't work on the basis that image data is not
hostile any more.
That's what application libraries are for. Yes, they are larger that
rolling your own, but they are also more robust.