[Simh] Looking for a RIM10B paper-tape image

[Timothe Litt]

I don't have tape images, but I do have information.

There seems to be some confusion here.

  * RIM10B is a purely software construct; no hardware understands it.
    (And few humans understand the code, though the data format is
    simple enough.)
  * RIM10 is used by hardware READIN mode this is the simple IOWD n,
    addr, data, where the last data word is XCT'd.
  * RIM is a PDP-6 software construct that was replaced by RIM10B - it's
    horribly inefficient.


See
https://ia801605.us.archive.org/18/items/bitsavers_decpdp10TOguageHandbook021973AsmRefmacro_5710828/02_1973AsmRef_macro_text.pdf
P. 288  (6.2.2) thru p. 292 for details.

Readin mode for the PTR (KA10/KI10) sets the reader to (hardware) binary
mode, reads one IOWD,  does a BLKI until exahusted, and XCTs the last
word loaded.  Typically, that loads the RIM10B loader into the ACs, and
executes the JRST in location 16 of RIM10B.

It is certainly possible that ITS has a different loader (with its own
format), but the hardware is fixed.  It would be challenging to do
better than Dave Gross's loader...

The real KS console has no support for booting from paper tape.

I can't say what MIDAS produces, but the hardware is simple - if
asymmetric and not entirely obvious.

The PDP-10 PTR/PTP has two modes: The bootstrap uses binary mode.
In binary mode, channel 8 must be punched, channel 7 is ignored, and
channels 6-1 are data.  6 frames are read (MS first) to form a 36-bit word.

In alphanumeric mode, all 8 channels are used, but only 1 byte is read
per word (right justified).

The punch wants one frame per word (again, right justified) in any
mode.  Binary mode always punches channel 8, never punches channel 7 and
punches the low 6 bits.  AN mode punches all 8 as given.

TOPS-10 turned those 2 hardware modes into 5 data modes visible to the
(UUO) user - PIP has switches for them.  Bits stored on disk can be in
modes with the same name - but packed differently.  By default, PIP uses
the file mode from disk to write to the punch.  So if you have a disk
file, you need to look at it's mode for a clue.  [Galaxy would spool
these devices, but that's more-or-less transparent - if you ignore the
human-readable block letters used to identify user/file names...]

Reader:
ASCII - ignores NUL, DEL & 0200 (channel 8 is not punched)
ASCII Line - buffers end with LF/FF/VT
Image - 8 bit bytes
Image binary - Frames w/o Channel 8 ignored, otherwise, sixbit characters
Binary - Checksummed binary: 32 word (max) blocks
    checksum,,#words
    data
    Checksum = arithmetic (2's comp) sum of data;
    checksum = 1's comp sum of Checksum<0:11> + <12:23> + <24:35>
Punch:
ASCII  - 7 bit + even parity
ASCII Line - blank frame after FF. DE: after VT & HT; NUL skipped
Image - 8 bit bytes
Image Binary - sixbit chars punched - Channel 8 is always punched.
Binary - each buffer sent as described for reader.  Blank frames between
blocks.

Note that Binary isn't RIM10B. RIM10B would be punched as Image Binary,
from a file with the loader and checksummed blocks in 36-bit words.

I wrote TOPS-10 drivers for a PC11 on the KS10, which should implement
the user mode versions of this; however, the PC11 vanished before I had
a chance to verify them.  I believe they shipped in later versions of
TOPS-10, so you ought to be able to build a monitor that works with
them.  I never got a bug report - so either they worked perfectly, or
they were never used.  [They were intended for a KS10 that I used to
support all flavors of PDP-10, but as it turned out the strategy
changed; I changed jobs & the hardware was reclaimed.]

DTBOOT could be loaded from paper tape (in RIM10B format), and the CTL
file that assembles it should show how the tape is created.



On 22-Jan-17 13:33, Lars Brinkhoff wrote:
> Bob Supnik wrote:
>> I've fixed it, but I have been unable to test it, for lack of a
>> suitable paper-tape image. It's possible to assemble a test program in
>> Macro using the RIM10B pseudo-op, but the KS10 simulator doesn't have
>> a paper-tape punch for exporting the file in the proper format.
> The ITS RIM10 samples I sent you were made from the binary file
> generated by MIDAS.  I saved them to tape, and then in Unix converted
> the raw binaries to the format expected by LOAD, and presumably, a paper
> tape reader.
>
> So there was no paper tape punch involved.  I certainly hope this
> doesn't invalidate the contents of the samples.
>
> My binary-to-paper tape converter is called its2rim, and can be found in
> my http://github.com/larsbrinkhoff/pdp10-its-disassembler repository.
> The expected input is a binary in ITS evacuate format.
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170122/ee5f17c7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20170122/ee5f17c7/attachment.bin>