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-boun...@trailing-edge.com] *On Behalf Of
> *Timothe Litt
> *Sent:* Sunday, January 22, 2017 21:13
> *To:* simh@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
