Creating a Bootable OS8 Tape on the PDP-12
17 views
Skip to first unread message
Peter Peterson
Mar 22, 2018, 11:16:57 PM3/22/18
to Kyle Owen, Dawson Rosell, Maury Pepper, Michael Thompson, PDP-12 Restoration Project, Charles Lasner
After reading the previous lengthy thread, I believe I understand the issue, which was restated a few times in the thread but neatly summarized by Charles towards the end (Thanks, Charles!)
--
Department of Computer Science
University of Minnesota Duluth
That is: FRTS and the "virtual disk" by Kyle/Bob/et. al is fundamentally incompatible on the PDP-12 (and other machines of its vintage) because of an incompatible interrupt-related issue. It might be (is?) possible to modify FRTS so as to avoid this problem, but no one is especially eager to do that (understandably).
The solution proposed by Charles (and others), and that Dawson has been pursuing, is to make a bootable OS8 LINCtape on our one working (and it seems, reliable) tape drive. We would put a complete Fortran IV environment on it (by copying it over from the serialdisk) and then by using the tape only, we should be able to run and use the current FRTS in all its interrupty glory.
We haven't been able to make this work, and my sense is that we lack clarity about what we might be doing wrong. This makes it hard to fix the problem.
Is there a step-by-step instruction for creating a bootable OS8 LINCtape that any of you are aware of?
If not, I think it would be useful if we could use this thread to create a step-by-step process for creating a bootable OS8 LINCtape that we could then run FRTS from. My office is across the hall from the PDP-12, so I should be able to test our procedure until we are happy with the result.
Once we are happy with the procedure, I can write it up and blog about it for posterity, and then (with our recent discovery about multiple compilation in F4) I think Dawson can make progress on his project.
Thoughts?
Thanks again for your time and generosity.
Best,
Peter
Peter A. H. Peterson, Ph.D.
Assistant ProfessorDepartment of Computer Science
clasystems
May 14, 2019, 7:45:24 PM5/14/19
to PDP-12 Restoration Project, kyle...@gmail.com, rose...@d.umn.edu, mpe...@ieee.org, michael.9...@gmail.com, clasy...@gmail.com
Just to update anyone who is not completely up to date.
1) I modified what Bob Adamson modified so the code will run on ANY "family of 8" machine. Bob added in support for four RK05 drives over the original two.
The handler cannot fix what the hardware prevents, but I made the use of that "feature" innocuous so it works fine on all machines, but only if it is an 8/E or newer does it solve the interrupt problem. But other than FRTS it works fine and is being used by the RICM for their PDP-12. There is no point in running the quite obsolete original separate program by Kyle because it is now built-into the handler, only actually useful if on an 8/E, etc.
2) I haven't pursued a patch for FRTS to vanquish the problem, but I am sure it CAN be remedied with a custom patch. Why/ Because the stock FRTS turns off interrupts when there are active TD8E handlers present. The TD8E cannot be interrupted, it would be fatal because of the critical timing. [The TD8E itself has no interrupt structure!]
In P?S/8 I have room to insert code to "protect" the TD8E handler internally. The 8/E and up support the SKON instruction. Skip if interrupt is on and also turn it off. I use that to construct an IOF or ION at the exit of the handler. During the handler, interrupts are off. But in OS/8 they had no way to do that, so in this odd case, it was fortuitous!
Thus, it would appear all that has to be searched for is the special-purpose code that MUST EXIST to check to see if TD8E handlers are being called, then before the call, FRTS will do an IOF and after the call an ION. Just modify this with a patch so the ersatz "RK8E" logical device number instead of the same for the TD8E wakes up the existing code, etc.
3) Michael once asked me about P?S/8 for the ersatz server so it can run in 4K to be analogous.
There are problems, but I have a solution, at least in theory:
a) All of this has to be written in compatible C so it can compile either gcc or microsoft studio. I think the bulk of the code already conforms, but changes are needed.
b) Currently, the RK05 image file is reckoned to the nearest 256 words, and will "cheat" and abandon responsibility for the second 128 words because OS/8 MAY do that, it's part of the spec [and why the REAL RK8E had to be modified to do that, else OS/8 would NOT RUN on the real RK8E!]
What P?S/8 needs is to reckon this file to the nearest logical 128 words. This is NOT hardware, it is a FILE, so there is nothing conceptual demanding 256 word organization. I will always provide a starting block number between 00000 and 31277 to access the entire drive.
c) The server needs to be modified to handle EIGHT drives, which is no big deal. OS/8 will need two separate non-system handlers to access some subset of this larger storage, but P?S/8 can get to ALL EIGHT from a single handler.
1) I modified what Bob Adamson modified so the code will run on ANY "family of 8" machine. Bob added in support for four RK05 drives over the original two.
The handler cannot fix what the hardware prevents, but I made the use of that "feature" innocuous so it works fine on all machines, but only if it is an 8/E or newer does it solve the interrupt problem. But other than FRTS it works fine and is being used by the RICM for their PDP-12. There is no point in running the quite obsolete original separate program by Kyle because it is now built-into the handler, only actually useful if on an 8/E, etc.
2) I haven't pursued a patch for FRTS to vanquish the problem, but I am sure it CAN be remedied with a custom patch. Why/ Because the stock FRTS turns off interrupts when there are active TD8E handlers present. The TD8E cannot be interrupted, it would be fatal because of the critical timing. [The TD8E itself has no interrupt structure!]
In P?S/8 I have room to insert code to "protect" the TD8E handler internally. The 8/E and up support the SKON instruction. Skip if interrupt is on and also turn it off. I use that to construct an IOF or ION at the exit of the handler. During the handler, interrupts are off. But in OS/8 they had no way to do that, so in this odd case, it was fortuitous!
Thus, it would appear all that has to be searched for is the special-purpose code that MUST EXIST to check to see if TD8E handlers are being called, then before the call, FRTS will do an IOF and after the call an ION. Just modify this with a patch so the ersatz "RK8E" logical device number instead of the same for the TD8E wakes up the existing code, etc.
3) Michael once asked me about P?S/8 for the ersatz server so it can run in 4K to be analogous.
There are problems, but I have a solution, at least in theory:
a) All of this has to be written in compatible C so it can compile either gcc or microsoft studio. I think the bulk of the code already conforms, but changes are needed.
b) Currently, the RK05 image file is reckoned to the nearest 256 words, and will "cheat" and abandon responsibility for the second 128 words because OS/8 MAY do that, it's part of the spec [and why the REAL RK8E had to be modified to do that, else OS/8 would NOT RUN on the real RK8E!]
What P?S/8 needs is to reckon this file to the nearest logical 128 words. This is NOT hardware, it is a FILE, so there is nothing conceptual demanding 256 word organization. I will always provide a starting block number between 00000 and 31277 to access the entire drive.
c) The server needs to be modified to handle EIGHT drives, which is no big deal. OS/8 will need two separate non-system handlers to access some subset of this larger storage, but P?S/8 can get to ALL EIGHT from a single handler.
d) To make a universal server, the 8 drives will be redundantly accessible by eight additional initiator codes. Thus, the protocol will be inherent by the code utilized, the first 8 are as present [8 not 4] and the last 8 to use the 15-bit addressing method to access the entire drive as a unit. This way both systems get full benefit of the server data base(s).
Obviously, I can do all the PDP-8 side of all of this, but I need someone versed in C to do what I spec, although I suspect it really isn't all that much coding changes.
I cannot work on P?S/8 for the PDP-12 unless the RICM machine LINCtapes work. SIMH doesn't support it. It would be dicey sending an image and asking for a lot of critical steps be done cold by the uninitiated, etc. [Which is why in part I asked about the status of the RICM PDP-12 now moved to a new home near the old one.]
My goal of course, everyone gets everything to run as much as possible, and be efficient as possible at it.
I had someone in mind to do the C work, but he is deathly ill [really!] and not available. However, he added a few comments to the existing code from Github which I have all of, etc.
Obviously, I can do all the PDP-8 side of all of this, but I need someone versed in C to do what I spec, although I suspect it really isn't all that much coding changes.
I cannot work on P?S/8 for the PDP-12 unless the RICM machine LINCtapes work. SIMH doesn't support it. It would be dicey sending an image and asking for a lot of critical steps be done cold by the uninitiated, etc. [Which is why in part I asked about the status of the RICM PDP-12 now moved to a new home near the old one.]
My goal of course, everyone gets everything to run as much as possible, and be efficient as possible at it.
I had someone in mind to do the C work, but he is deathly ill [really!] and not available. However, he added a few comments to the existing code from Github which I have all of, etc.
cjl
On Thursday, March 22, 2018 at 11:16:57 PM UTC-4, Peter Peterson wrote:
After reading the previous lengthy thread, I believe I understand the issue, which was restated a few times in the thread but nea
That is: FRTS and the "virtual disk" by Kyle/Bob/et. al is fundamentally incompatible on the PDP-12 (and other machines of its vintage) because of an incompatible interrupt-related issue. It might be (is?) possible to modify FRTS so as to avoid this problem, but no one is especially eager to do that (understandably).
tly summarized by Charles towards the end (Thanks, Charles!)h
Reply all
Reply to author
Forward
0 new messages