[Simh] Looking for a RIM10B paper-tape image --> papertape reader/punch drivers on KS10
khandy21yo
khandy21yo at gmail.com
Mon Jan 23 09:35:34 EST 2017
Fwiw I did a wps8 to wordperfect converter many years ago. Had a lot of wps8 disks and they wanted to switch. Had to decode the wps8 format by trial and error. Still have the code.
Sent from my Galaxy Tab® A
-------- Original message --------From: Timothe Litt <litt at ieee.org> Date: 1/23/17 6:31 AM (GMT-07:00) To: "R. Voorhorst" <R.Voorhorst at swabhawat.com>, simh at trailing-edge.com Subject: Re: [Simh] Looking for a RIM10B paper-tape image --> papertape reader/punch drivers on KS10
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:
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:173499327;
mso-list-template-ids:-386250240;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
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
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/26d4ba6b/attachment-0001.html>
More information about the Simh
mailing list