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:[email protected]] *On Behalf Of > *Timothe Litt > *Sent:* Sunday, January 22, 2017 21:13 > *To:* [email protected] > *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 > [email protected] <mailto:[email protected]> > http://mailman.trailing-edge.com/mailman/listinfo/simh > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
