24 Mar
2010
24 Mar
'10
8:44 p.m.
All this talk about the HP 64000 has got me thinking...
The HP 165xB Inverse Assembler Toolkit includes a DOS-based table
assembler that appears to be derived from something used on the HP
64000, and it spits out what the manual calls a "HP 64000 format
relocatable object file". This is what the analyser loads to run an IA.
Did HP ever publish a spec for the .R (relocatable object) file, or has
it ever been successfully reverse engineered?
This is one of those "curiosity killed the cat" type projects; I've been
wanting to use the HP LA inverse assemblers on a PC since I got my 1651B
(mainly because a PC can theoretically handle a much larger symbol table).
Writing an assembler / compiler for my own custom format and VM is
always an option, I suppose, but I'd rather like to be able to run the
HP IAs that I don't have the source code for (ISTR I've got a 68000 one
somewhere).
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
24 Mar
24 Mar
9 p.m.
Philip Pemberton wrote:
Did HP ever publish a spec for the .R (relocatable
object) file, or has
it ever been successfully reverse engineered?
Foot, meet mouth. Mouth, meet foot. *mrrrph*
The short answer is "yes, there's a spec."
It's in HP doc #64980-90933 "HP 64000 File Format Reference Manual".
Which is on the Great Oracle of the Internet, bitsavers.org:
<http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/hp/64000/software/64980-90933_Jul-1986.pdf>
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
9:51 p.m.
OK, here's an interesting one. The .R files have had a 20-byte header
tacked on... From my hex editor:
8203 4049 3830 3835 2020 2020 2020 2020 2020 004B | .. at I8085 .K
Anyone care to take a guess what this is? "I8085" is the filename of the
IA file (with the extension chopped off), but I haven't the foggiest
idea what the other bytes are for.
Everything after the 20-byte header seems to match up with what the
64000 documentation says, though. Which is nice, as it'll make writing a
loader *much* easier.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
25 Mar
25 Mar
2:32 a.m.
On Wednesday, March 24, 2010 at 21:51, Philip Pemberton wrote:
Everything after the 20-byte header seems to match up
with what the
64000 documentation says, though.
I use the HP 10391B Inverse Assembler Development Package with my 64620
state analyzer. The .R file produced by the IA is nearly compatible with
the 64000. To use it, though, I had to write a program to:
1. strip off that 20-byte header, and
2. alter the NAME record to conform to the 64000 relocatable format
Once these are done, the 64620 will accept the file produced by the IA.
My notes on item #2 say:
The Name Record differs only slightly from the HP 64000 format. The
difference is in the source filename field. The 64000 defines this
as a fixed-length field of 8 words that contains the filename, user
ID, and disc number. The IAL assembler produces a variable-length
field containing the full pathname (drive, directories, filename, and
extension) to the source file. We convert the latter by using the
base filename, which will be eight characters or less, as the IAL
assembler is a DOS program, as the filename. We set the user ID to
"IAL" and the disc number to zero. All other portions of the Name
Record are valid and are copied into the 64000 version, and a new
checksum is calculated.
-- Dave
11:10 a.m.
J. David Bryan wrote:
I use the HP 10391B Inverse Assembler Development
Package with my 64620
state analyzer. The .R file produced by the IA is nearly compatible with
the 64000. To use it, though, I had to write a program to:
1. strip off that 20-byte header, and
2. alter the NAME record to conform to the 64000 relocatable format
Yeah, I noticed that there was "something" different about the file. I
can get the checksum for the NAME record to match up perfectly, then
there's a DOUBLE record after that. The checksum for that NEVER matches
up and I can't find the criteria for making it do so. My code just hits
the 128-word limit and bails out :-/
The IAL assembler produces a variable-length
field containing the full pathname (drive, directories, filename, and
extension) to the source file. We convert the latter by using the
base filename, which will be eight characters or less, as the IAL
assembler is a DOS program, as the filename. We set the user ID to
"IAL" and the disc number to zero. All other portions of the Name
Record are valid and are copied into the 64000 version, and a new
checksum is calculated.
I'll have a look at that -- for now, all my IAL files have been
assembled in C:\IA, so the filenames are quite short ("C:\IA\I8085.S" as
an example; 13 characters plus the null).
I don't suppose you have some code (or even snippets of code) that you
could share?
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
26 Mar
26 Mar
3:01 a.m.
On Thursday, March 25, 2010 at 11:10, Philip Pemberton wrote:
I can get the checksum for the NAME record to match up
perfectly, then
there's a DOUBLE record after that. The checksum for that NEVER
matches up and I can't find the criteria for making it do so.
The relocatable files produced by the 10391 IA have a null EXTERNAL record
in between the NAME and the first DOUBLE record. The record is two words:
0004 (record ID) and 0004 (checksum). Is it possible that you're
overlooking that? I've never encountered any checksum errors with the
output of the IA.
I'll have a look at that -- for now, all my IAL
files have been
assembled in C:\IA, so the filenames are quite short ("C:\IA\I8085.S"
as an example; 13 characters plus the null).
I don't know whether the logic analyzer you're using cares or not, but the
64000 NAME format uses a length byte and blank-pads the fixed-length
filename, rather than using a null terminator.
-- Dave
25 Mar
25 Mar
4:23 a.m.
Hello,
Both the dos downloader as well as the assembler do run under DOSBOX 0.73.
The downloader uses the virtual serial ports offered by the app fine...
I am picking apart the translation the file undergoes from DOS format to
HPLIF DOS format (with the LIF header) so I can generate a file directly
that way...
Maurice
27 Mar
27 Mar
1:41 a.m.
maurice smulders wrote:
I am picking apart the translation the file undergoes
from DOS format to
HPLIF DOS format (with the LIF header) so I can generate a file directly
that way...
lif_utils (<http://www.hpcc.org/datafile/hpil/lif_utils.html>) will do
that nicely. Or at the very least it'll let you extract the contents of
a LIF file and display some information about it. Try 'lifstat',
'lifdir' and 'lifget'.
I've been playing with the .R files and I've got a mostly-working
OBJDUMP work-a-like sorted. It is one hell of a weird format, and the
InvAsm virtual machine is no less weird. I'm starting to wonder if
someone at HP Fort Collins was experimenting with illicit substances at
the time InvAsm was conceived...
Anyway, it's a pretty simple (if unusual) VM. One register (the
accumulator) and a pretty simple instruction set. Add, subtract, AND,
shift and rotate you can do, but forget multiply/divide (unless you feel
like writing them yourself).
The weird bits are (in no particular order) the segmented memory
architecture (it's a Harvard Architecture, Jim, but not as we know it),
fixed-size instructions (hey, kids, it's a 16-bit RISC-a-like), and the
weird disparity between addressable memory zones in different instructions.
Oh, and the Invasm assembler is bugged. Turns out you can make an output
format specification with some truly weird parameters -- very few of
them seem to be checked... :-o
Ah well, it wouldn't be a HP product if it wasn't at least a little bit
weird.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
8:22 p.m.
lif_utils
(<http://www.hpcc.org/datafile/hpil/lif_utils.html>) will do
that nicely. Or at the very least it'll let you extract the contents of
a LIF file and display some information about it. Try 'lifstat',
'lifdir' and 'lifget'.
And you even get a design for a microcontroller-based project (nothing at
all to do with LIF disks...)
-tony
5394
days inactive
5397
days old
8 comments
4 participants
participants (4)
-
ard＠p850ug1.demon.co.uk -
classiccmp＠philpem.me.uk -
jdbryan＠acm.org -
maurice.smulders＠gmail.com