[Simh] Looking for a RIM10B paper-tape image --> papertape reader/punch drivers on KS10
Timothe Litt
litt at ieee.org
Mon Jan 23 08:31:07 EST 2017
I'm not surprised about your findings on prsser/ppsser. As I wrote, the
requirement (and the hardware) disappeared before I debugged them. Yes,
they were cloned from PTRSER/PTPSER - besides the IO instructions, I
believe there were some changes to deal with the hardware differences;
the binary modes in the hardware in particular.
There were changes to system initialization in 703/704, where almost
everything moved to autcon. I didn't do that work, and I didn't look at
PxSSER after they were done. The hardware was long gone. The original
work was c.a. 7.01/7.02.
I can't look at this now (I'm swamped with other issues), but if you're
still having problems when I do, I'm willing to help.
RX2SER definitely does work with real hardware. I had hardware for
quite some time; I used it to create RSX20F floppies. I don't think the
code for Files-11 survived - but someday I'll look. Somewhere I have
code that reads and writes RT11 file systems; I think I implemented
everything useful. I also wrote code that reads WPS-8 floppies and does
a rough translation into Digital Standard Runoff. It was imperfect, but
made porting some documentation a lot easier.
On 22-Jan-17 15:42, R. Voorhorst wrote:
>
> Ls,
>
>
>
> about the drivers for the KS10 Tops10 paper tape reader and punch the
> following:
>
>
>
> They appeared to be cloned from PTRSER and PTPSER and some KL10
> IO/interrupt instructions replaced with equivalent KS10 instructions;
>
> both were shipped as unsupported (rightly so, because immature) but
> apparently not debugged.
>
>
>
> PRSSER.MAC for the paper tape reader lacked necessary preamble code an
> some init code, but was relatively easy to make workable; it looks
> like it works now (Ascii file import from a file through the Tops10
> PTR succeeds) but the other paper tape formats needs some testing for
> which the availability of the punch driver is desirable.
>
>
>
> PPSSER.MAC for the punch lacked the same preamble, but is also not
> working due to operational differences between the KL10 interrupt
> system and the KS10 one, it behaves incompatible with the unmodified
> inherited way of interrupt processing from PTPSER.MAC
>
> Eventually it will be made workable after some reconstruction of the
> driver code to make up for the differences; up to now it is (still)
> plagued with a hung device.
>
>
>
> On another note, concerning the other drivers for the Unibus
> peripherals on the KS10, the also unsupported floppy disk driver
> RX2SER.MAC is confirmed working with the somewhat functionally limited
> utility RTFLX from the Grenoble integration tapes from the mid 80’s;
> one can exchange RT-11 format data with OpenVMS and other systems.
>
>
>
>
>
> Best regards,
>
>
>
> R. Voorhorst
>
>
>
> *From:*Simh [mailto:simh-bounces at trailing-edge.com] *On Behalf Of
> *Timothe Litt
> *Sent:* Sunday, January 22, 2017 21:13
> *To:* simh at trailing-edge.com
> *Subject:* Re: [Simh] Looking for a RIM10B paper-tape image
>
>
>
> 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 <mailto: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/20170123/96d98e08/attachment-0001.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/20170123/96d98e08/attachment-0001.bin>
More information about the Simh
mailing list