[Simh] Semi-OT: 7-bit binaries

[Rich Alderson]

CC'd to the SimH mailing list so that everyone sees that there is an answer to
the question, not just a complaint from an old fart.

> From: Cory Smelosky <b4 at gewt.net>
> Date: Tue, 4 Oct 2016 11:34:50 -0700

> On Oct 4, 2016, at 10:57, Rich Alderson <simh at alderson.users.panix.com> wrote:

>>> Date: Mon, 3 Oct 2016 19:05:19 -0700 (PDT)
>>> From: Cory Smelosky <b4 at gewt.net>

>>> This is somewhat OT, but you people are honestly the best people to ask.

>> Why bother the SimH community, most of whom seem to be interested in Vaxen or
>> PDP-11s these days, when alt.sys.pdp10 is readily available?  They're hardly
>> the best to ask about non-8-bit architectures.

> I vaguely recalled a simh-related tool for binary format conversion.

I don't think I've ever seen any such thing, in 15+ years with simh, but that's
irrelevant.  I was wondering why you wouldn't ask the 36-bit experts.

>>> I have a 7-bit-clean binary (from the SC-40), using klh10's wfconv (input
>>> of 7, output of h - high density) gets me a readable file...containing
>>> errors.

>> What does that mean????

> It appears to be in an a 7-bit ANSI tape record format. Unsure if due to a
> dump to take or on-disk.

If it's a tape (image) generated on a PDP-10, it will have a particular layout
which you have scrambled.

I had a look at wfconv.c, so I think I know what you did.  You used a command
similar to

	wfconv -7h <tape.image >garbled.file

What you really needed to say was

	wfconv -cd <tape.image >octal.dump

to get data to analyze.

>> SC-40 binary files contain 36-bit words.  Ain't no such thing as "7-bit-clean
>> binary" in an SC-40 context.  What are you really saying?  Or asking?

> Sorry - this is for the SPARC FE.

Was it generated on a Sparc running Unix?  Then there is no need for any file
conversion using wfconv at all.  Was it generated (or stored) on an SC-40?
Then you have to take cognizance of the 36-bit nature of the architecture.

>> A 7-bit binary implies a 7-bit architecture, which I doubt anyone ever
>> built.  Smallest non-8-bit architectures I've ever encountered are 12-bit
>> systems; smallest non-even word size I've ever encountered is 23 bits on the
>> Bendix G-15.

> It seems to have been for tape or similar.

I don't understand what you mean, here.  Tapes are generated for specific
systems, and take their architectures into account.

>>> I am getting:

>>>> Memoby mtst be inhtialize firs

>>> which should be:

>>>> Memory must be initialized first

>>> What step am I missing in conversion? `file` finally knows what it is,
>>> however.

>> It would seem to me that you aren't missing a step, you're missing a point
>> completely.  It looks as if you have stripped bits from a text file (which
>> is 7-bit ASCII packed 5 per word, left justified ).  What did you think you
>> were converting?  Why did you think you needed to convert anything at all?
>> What tool did you use?  What are you really trying to accomplish?

> wfconv from KLH10, a.out for the FE, with no readable data coming out unless
> converted from something that packed it in to 7 bits.

ARRRGGGHHHHHHHH!

OK, here's what you probably need, but do some analysis on the output of the
command I gave you above first:

	wfconv -ch <input.tape >9octets.in.2words.bin

>>> converted/a.out: SPARC executable not stripped

I would exted the same result on the output of that most recent command.

>> What does a SPARC executable have to do with an SC-40?  What (why) do you
>> expect a Unix utility (the file program) to know anything at all about the
>> internal format of a PDP-10 file, whether text or binary????

> Front end processor.

OK.

>>> Thanks - non-8-bit text was never my strongest skill ;)

And none of this is text, or non-8-bit.

>> So you're expecting text, and have done something inappropriate to it.  To
>> what end?  Again, what are you really trying to accomplish?

> Get a disassembly of the FE binary.

OK.  I think I've got you where you wanted to go.

Here's the thing that you need to remember about the PDP-10 family.  Except in
very particular circumstances, data in bytes smaller than the 36 bit word are
always left justified in the word.  7-bit ASCII text is packed 5 per word, with
the rightmost bit (35) unused.  8-bit data from any source (PDP-11, VAX, Alpha,
Itanium, IBM 360/370/..., HP 21xx, etc. etc. usw. k.t.l.) are packed 4 per
word, with the rightmost *4* bits (32-35) unused, *EXCEPT* on very late tape
drives which could use so-called high-density mode and then 9 8-bit bytes are
stored as 4 x 8, bits 32-35 <<4 OR'd with bits 0-3 of the next word, and 4 x 8,
thus 72 bits in 9 8-bit tape frames.

NOW.  On 9-track tape, in the default mode for all PDP-10 operating systems,
referred to as core-dump mode, 36 bit words are stored into 5 8-bit frames
(with logical parity) as follows:

bits 0-7    x x x x x x x x P
bits 8-15   x x x x x x x x P
bits 16-23  x x x x x x x x P
bits 24-31  x x x x x x x x P
bits 32-35  0 0 0 0 x x x x P

The description of ANSI-ASCII mode in wfconv is completely incorrect, by the
way.  On PDP-10 9-track tapes, that means writing out bits 0-31 of the word in
4 8-bit frames, and ignoring the contents of bits 32-35 completely.  No tape
ever was written as wfconv describes; it's not mechanically possible on any
tape drive attached to a PDP-10.

                                                                Rich