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 <b...@gewt.net> > Date: Tue, 4 Oct 2016 11:34:50 -0700 > On Oct 4, 2016, at 10:57, Rich Alderson <s...@alderson.users.panix.com> wrote: >>> Date: Mon, 3 Oct 2016 19:05:19 -0700 (PDT) >>> From: Cory Smelosky <b...@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 _______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh