Anyone Know The Encoding For The Old 'Nickel' OS/8 Files?

[bobaboba]

I'm referring to the old 'nickel' files which can be found at http://www.dbit.com/pub/pdp8/nickel/

If you go down to e.g. http://www.dbit.com/pub/pdp8/nickel/langs/lisp/ there is an os/8 directory. However all of the files in this and similar paths are encoded. Does anyone recollect/know/deduce what encoding is used for these? There is a parallel ascii path but it contains only (naturally enough) ascii files and I'm interested in the binaries/images also.

Thanks.

 

[jackrubin]

You can reach John Wilson, Mr. Dbit himself, at info@dbit.com.

 

[bobaboba]

Yes, I've done that too, but I was under the impression that the files didn't originate there. Maybe wrong of course. (Old Sunsite?)

 

[vrs42]

I'm referring to the old 'nickel' files which can be found at http://www.dbit.com/pub/pdp8/nickel/

If you go down to e.g. http://www.dbit.com/pub/pdp8/nickel/langs/lisp/ there is an os/8 directory. However all of the files in this and similar paths are encoded. Does anyone recollect/know/deduce what encoding is used for these? There is a parallel ascii path but it contains only (naturally enough) ascii files and I'm interested in the binaries/images also.

Thanks.

The short answer is yes. For example, lisp.bn is encoded as 16 bit shorts, each of which contains
a 12 bit word. Each pair of such words encodes three 8 bit characters in the usual OS/8 way.

So 004200 000200 decodes to 200 200, followed by the top 4 bits of each word to form
another 200, which are the first three leader bytes of the BIN format file.

Be advised that the files have cruft after the last byte. For instance, near the end
of lisp.bn is 04600 005200, which decodes as 200 200 232. After the ^Z, which
marks the end of the OS/8 file, the rest of the block should be ignored. (In fact,
IMHO, the ^Z isn't part of a proper BIN format file, either.)

If you need further help, let me know. Basically once you've got how the words
are encoded, the rest is straight out of the OS/8 manuals for the file type under
consideration.

Vince

 

[bobaboba]

Thanks Vince. I'd noted the similarity to OS/8 packing in the text files but I was a bit thrown by the regular zero nibbles (hardware guy really so a bit dull when it comes to software ).

Anyway, I realised belatedly that of course Dbit is the home of PUTR and the files are simply the DOS output of a PUTR copy. So all that needs done is to copy them back into a convenient OS/8 image and there you are!

You don't need to worry about the trailing garbage, I think (not checked) that this just pads up to the next whole block which OS/8 would do naturally. (According to the manual ^Z is the terminator for a binary file).

 

[vrs42]

You don't need to worry about the trailing garbage, I think (not checked) that this just pads up to the next whole block which OS/8 would do naturally. (According to the manual ^Z is the terminator for a binary file).

Right. OS/8 should be fine with it. Where the cruft becomes an issue is when converting the files,
for instance to load them into SIMH or the like. Especially if you want to concatenate a couple and
mount them on the the paper tape reader emulation.

Even if you're just punching them, sometimes you have to cut that stuff off (though not so much
for BIN format, as that should HLT before reading it in).

Worse are the web-sites that read in and store paper tape images with cruft on *both* ends.

Vince

 

[bobaboba]

So as a little trial, I copied the Algol stuff onto a TU56 OS/8 image, booted it in Simh and managed to compile and run a short Algol program. This is Rogalgol - the best Algol variant I know of for the pdp-8 - which I used to use at work back in the early to mid-70s. I've been hunting it for years. It's not a friendly system (!!) and a little buggy, but it's quite competitive against FIV for speed and compactness and it was tailor-made for some of the algorithmic work I needed to do back then.