Small collection of files for you.

10 views
Skip to first unread message

clasystems

unread,
Feb 15, 2018, 12:25:59 PM2/15/18
to PDP-12 Restoration Project
Michael hasn't confirmed by direct testing, but I believe these latest versions should work.  The disk contains the source, binary and listing files for the serial disk system device handler and non-system device handler as I recently updated.

I also included the CMPR30.SV program so you can confirm binary files as you test out the reliability of LTA0: in terms of writing then reading the data back, etc.

Here is a an extract of a session log illustrating how to use it.  [Note: You should copy CMPR30.SV to SYS:.  If not, you have to use the RUN <the device it's on> CMPR30 alternative [which is also more overhead].


.DATE 15-FEB-90

.DATE
THURSDAY FEBRUARY 15, 1990

.R CMPR30

CMPARE 30
*RKA3:SDSKSY.BN,RKB3:SDSKSY.BN

EOF M
*^C

.R CMPR30

CMPARE 30
*RKA3:SDSKSY.BN,RKB3:SDSKSY.BN

EOF M
*RKA3:SDSKNS.BN,RKB3:SDSKNS.BN

EOF M
*RKA3:SDSKNS.BN,RKB3:SDSKSY.BN


BLK  0205 0107 (0000)
005/ 1200 0200
006/ 0000 1400
007/ 0100 6477
010/ 0477 0423
011/ 1470 1404
...

371/ 7460 0000
372/ 0075 0000
375/ 7400 0000
376/ 4022 0000
377/ 0200 0000
EOF B
*^C

Notes:

1) I choose the year arbitrarily to be 1990.  That way, the same day as the week as the real 2018 date.  [P?S/8 doesn't have this problem; date support will last longer than all of us]

2) The third example was chosen deliberately to show an impossible case; thus many non-matching cases.  The CMPR30 output will only output the non-matching words of the first non-matching OS/8 record.  Many words were elided; it only shows the first and last five mismatches.  Ironically, some words did match!

In general it's nice that you can perform multiple compares without having to run it again; press Control-C to exit when done comparing everything, etc.

The disk has the same files on the RKA side as on the RKB side.

In ye olden days, we called things like this "CARE packages" :-)  Of course, back then they were usually food; this one is of course food for thought!

cjl

cjl021518.rk05

Dawson Rosell

unread,
Feb 15, 2018, 1:04:24 PM2/15/18
to clasystems, PDP-12 Restoration Project
Thanks Charles! I will give this, and the suggestions in your last email, a shot when I am up in the lab next... It's midterm time for me so PDP-12 time is getting to be scarce. 

This is a wonderful "care package". Thank you!

Peter Peterson

unread,
Feb 15, 2018, 1:11:04 PM2/15/18
to Dawson Rosell, clasystems, PDP-12 Restoration Project
Yes, and while old ones might have normally contained food, this food for thought is wonderfully low calorie. :)
--
Peter A. H. Peterson, Ph.D.
Assistant Professor
Department of Computer Science
University of Minnesota Duluth

CLASystems

unread,
Feb 15, 2018, 3:04:23 PM2/15/18
to Peter Peterson, Dawson Rosell, PDP-12 Restoration Project
Don't forget to send a salami to your boy in the army :-).

cjl

Virus-free. www.avast.com
--
"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992

Dawson Rosell

unread,
Feb 22, 2018, 9:59:25 PM2/22/18
to clasystems, Peter Peterson, PDP-12 Restoration Project
Hi all!

I had a little free time tonight since I got my Digital Systems lab done faster than I anticipated, so I went up to the lab to work for a little bit.

I tried running CMPR30.SV on the PDP-12 a couple different ways.

First I did RUN SDA1: CMPR30.SV. The program started and gave me the prompt. I gave it SDA1:SDSKSY.BN,SDB1:SDSKSY.BN and it gave me ILLEGAL SYNTAX.

I then tried to copy it over to SYS. I ran R PIP/I and then CMPR30.SV<SDA1:CMPR30.SV. It transfered, but was only 1 block in size (and didn't run, as expected.)

Could this be a deeper problem than just how OS/8 is set up? Maybe it's time to run diagnostics again...



I have spring break the week after next, and as I can't take the PDP-12 with me to Florida, I will have some time to go back to the simh side of things. Does anyone here know why subroutine calls wouldn't work correctly in Fortran IV on simh? It crashes at the ISN for the subroutine call and says its a USER ERROR. I will post on VCFED as well and see if anyone there has any ideas.

CLASystems

unread,
Feb 22, 2018, 10:50:24 PM2/22/18
to Dawson Rosell, Peter Peterson, PDP-12 Restoration Project
On Thu, Feb 22, 2018 at 9:57 PM, Dawson Rosell <rose...@d.umn.edu> wrote:
Hi all!

I had a little free time tonight since I got my Digital Systems lab done faster than I anticipated, so I went up to the lab to work for a little bit.

​OK

I tried running CMPR30.SV on the PDP-12 a couple different ways.

First I did RUN SDA1: CMPR30.SV. The program started and gave me the prompt. I gave it
​​
SDA1:SDSKSY.BN,SDB1:SDSKSY.BN and it gave me ILLEGAL SYNTAX.

​Not sure; this is a user-written program and perhaps MUST be run from SYS: with the R command.  You haven't tried that [I address that below].

I then tried to copy it over to SYS. I ran R PIP/I and then CMPR30.SV<SDA1:CMPR30.SV. It transfered, but was only 1 block in size (and didn't run, as expected.)

​It did what you want, not what you meant.

R program-name does not take command-line switches.  [In P?S/8 it would!].

OS/8 works quite differently from what you understand.  Basically there are two forms:

.R or RUN DEV program-name with .SV assumed if left out.

This does NOT take command-line options!

That loads the command-decoder; you have to apply the options on that secondary line.

OR

CCL form where the illusion is that​ it works the way you tried [with regard to the /I on the command line, but you didn't use the CCL form!].  I say illusion because software fakes out software so reality is all the overhead of th first command actually happens, but the command typed is selectively parsed so it does ACCOMPLISH what it says, but not in a straight-forward manner.  Note:  The overhead is so bad that DEC's official position was that on tape-oriented systems, they recommendd CCL be disabled!  [Works, but palpably slow.]

I say thus not as an unrelated factoid, but if you probably going to be running things while booted to a LINCtape-based system, learning the lower overhead methods is important, etc.

Thus, put the /I on the command-decoder line, not the main line executing the program.


Could this be a deeper problem than just how OS/8 is set up? Maybe it's time to run diagnostics again...

​No, it's an education problem :-).

Us old-timers predate CCL so we never had to unlearn the overhead-ridden way of using it.

Moreover, P?S/8 uses a concise command variant,.  It resembles all the bells and whistles of CCL but it is the only [and low-overhead] way to execute a core-image program  [Note: P?S/8 pre-dates OS/8.  DEC was interested in it, but only the programmers.  The indifferent [and worse] managers refused to take it seriously.

As such, I sold a limited license of P?S/8 to the Intersil Corporation to run it on their IM6100 PDP-8 on a chip machine, that is best described as a noticeably better​ VT78 [with superficially a similar configuration].  Ironically, due to poor design, OS/8 runs thirteen times as slow as it does on all the other models, while P?S/8 runs at the same speed on all RX-type systems it can support, etc.

The point here for the moment is that you are attempting to use intuition on the commands.  But OS/8 is NOT intuitive, while P?S/8 is.  OS/8 had CCL hacked on top of it as a poorly written internal overlay.  Your intuition would make sense in P?S/8; it shouldn't matter regarding command-line options [but it does!]

Also, OS/8 is strictly output  < input file flow in all cases.

P?S/8 is always YOUR CHOICE of output < input OR

input > output.  The angle bracket points the way, either way, etc.

This makes it more intuitive regardless of what you were exposed to in the past, and worse, at the time, other DEC systems also went the second way [well, some of them did].  P?S/8 is command-oirder "neutral" etc.

Anyway, if you use the COPY command, it does NOT use PIP at all!  It uses the FOTP program which always does image-oriented transfers and has no options.  One of my friends wrote FOTP. He was too lazy to mess with the PIP code, etc.

But PIP with the /I on the secondary command line should work.

Then you will be able to use R CMPR30

The rest of what you used ought to work.




I have spring break the week after next, and as I can't take the PDP-12 with me to Florida, I will have some time to go back to the simh side of things. Does anyone here know why subroutine calls wouldn't work correctly in Fortran IV on simh? It crashes at the ISN for the subroutine call and says its a USER ERROR. I will post on VCFED as well and see if anyone there has any ideas.

​I make no claims regarding Fortran IV, never used it.​

cjl
Reply all
Reply to author
Forward
0 new messages