• Please review our updated Terms and Rules here

PDP-12 #435 at the University of Minnesota Duluth

@Zach or I can do that tomorrow.

Our 12 has the KW12 option... does that generate periodic interrupts all the time? We don't really know how it works and I think it's the one thing that Warren & Dawson didn't do much with.
Found manual here
http://users.rcn.com/crfriend/museum/doco/PDP-12/UG-Chap5s4.html#5.4.4

I think this should check if its the source
100 6131
101 5101
102 7402

If it halts its the clock. It doesn't say if enables are cleared by default to disable interrupts. I would hope they are cleared by the main reset.

Console port skips are. You can replace the 6131 with these.
6041
6031

Are you running your serialdisk on the console port?

Not sure if skip last digit has to be 1 for skip if flag but common. You could try all 6##1 to see which skips.
6131 doesn't do anything while it's in this state.

fwiw I've tried all of the IOT skip instructions that are noted in the pocket handbook thingy (6131, 6031, 6041, 6011, 6021, 6612, 6621, 6622, 6623, 6745, 6747, 6651, and 6661) and none appeared to trigger a skip.
I tested them by entering them into the left switches, hitting the "DO" switch, then checking the skip light on the console.
 
fwiw I've tried all of the IOT skip instructions that are noted in the pocket handbook thingy (6131, 6031, 6041, 6011, 6021, 6612, 6621, 6622, 6623, 6745, 6747, 6651, and 6661) and none appeared to trigger a skip.
I suspect you will find that 6401 or more likely 6411 will skip. Those are the default addresses for SerialDisk, and also for the PDP-12 data communications (second serial) port.
 
Your SerialDisk drivers appear to be version "G". Version G. That's from Jan 2021. Addording to the logs, version "G" was Charles Lasner's version. The current version is "I", and has my attempt at a general Family of Eight solution for the FRTS problem.
Ahh.... I did not realize that we needed to update our disk images in addition to the server software itself. In retrospect, this should have been obvious.

To be explicit, we built an updated version of server using the current sources on the os8serialdisk github, but we did not do anything to update the RK05 image from which we boot... it sounds like that is the source of the issue you are identifying, is that right? This makes sense, I suppose, that the handlers installed are the ones who need to handle interrupts correctly, and the server software can't really do anything about those parts of the system. But I wasn't thinking deeply about the interrupt problem and simply thought "update server == apply fix".

We will try to follow the instructions to update our images and let you know what happens.

Incidentally, is there a reason that there is a binary for server in the source tree? This confused us, but @ZachyCatGames did rebuild a new binary from the current sources.

I suspect you will find that 6401 or more likely 6411 will skip. Those are the default addresses for SerialDisk, and also for the PDP-12 data communications (second serial) port.

I will let @ZachyCatGames try this and report back... he is still in "newbie jail" and needs to make a few more posts to get out on good behavior.
 
The FRTS knows how to handle some of the standard interrupts. It does not know what to do with a serial interface configured the way serial disk originally used it. I have a chapter in my book that I added after we (hopefully) resolved the issue in Serial Disk. To summarize the problem:

OS/8 does not utilize interrupts. It does not care if the flags are set. When ION is executed in the FRTS an interrupt will occur if a flag is set. The ISR (Interrupt Service Routine) tests for set flags for the devices it knows about, does something to clear the flag and then returns. If it doesn't know about a device then it can't clear the flag if set and as soon as it returns another interrupt will occur. Zero progress at this point since 100% of the CPU will be used processing an interrupt that never gets cleared.

The solution CJL used to resolve this issue was specific to the Omnibus machines which are capable of disconnecting the flags from causing an interrupt. This won't work on any of the earlier Family of 8 machines since that hardware implementation is not present.

The solution used in the version Vince mentioned is to not leave the flag set.

A typical send a char routine might look like this:

Code:
SNDCHR, 0               /SEND CHARACTER SUBROUTINE
        TLS             /SEND THE CHARACTER IN THE AC TO THE CONSOLE
        TSF             /WAIT FOR CHARACTER TO BE SENT
        JMP .-1
        JMP I SNDCHR    /RETURN
This code is simple and short which is why it is extremely common but it has the problem of leaving the transmit flag set and it does not utilize the hardware very will because there is no reason to wait for the character to finish being sent in this way. Here is a better although longer routine:
Code:
/SEND A CHARACTER TO A SERIAL PORT WITH OVERLAP
SNDCHR, 0               /TRANSMIT THE CHARACTER IN THE AC
        ISZ SNDING      /SKIP IF SENDING
        JMP NOTSND      /WE DON’T NEED TO WAIT FOR PREVIOUS TO FINISH
        TSF             /SKIP IF PREVIOUS TRANSMIT IS COMPLETE
        JMP .-1         /WAIT
NOTSND, TLS             /SEND IT
        CLA CMA         /INDICATE WE ARE SENDING
        DCA SNDING      /BY SETTING TO -1
        JMP I SNDCHR    /RETURN
SNDING, 0               /NOT SENDING
The above code allows the CPU to execute while the character is being transmitted. It does not by itself solve the flag set issue. For that you need some code to be executed before the handler exits.
Code:
/BEFORE WE RETURN TO THE CALLER WE MIGHT NEED TO WAIT
        ISZ SNDING      /SKIP IF SENDING
        JMP SNDEXI      /WE DON’T NEED TO DO ANYTHING
        TSF             /SKIP IF TRANSMIT IS COMPLETE
        JMP .-1         /WAIT FOR IT
        TCF             /CLEAR THE FLAG
SNDEXI, CLA             /CLEAR THE SENDING FLAG
        DCA SNDING
This allows nearly 100% overlap of the sending of characters so that the CPU is not sitting there spinning its wheels waiting. The sharp eyed reader will probably point out that in most situations there is no reason to clear the SNDING flag. To fail the exit code would need to be executed 4095 times without sending any characters.

There are similar issues with receiving characters.
 
Hey, we're trying to follow the instructions here to update the serial disk driver: https://github.com/drovak/os8diskserver/blob/master/SerialDisk/docs/how-to.md

We were able to use `handler_installer` seemingly just fine during the `INSTALLING THE SYSTEM HANDLER` step:
Code:
./handler_installer ../handler/sdsksy.bin ../disks/Mike_PDP-12-2024.rk05
Read 454 bytes of disk
Read 812 bytes of handler
Position after leader: 0357
Number of devices: 3
Position of bootloader: 0445
Boot length is 38 (0046)
Position of handler: 0601

and the system boots up just fine and `RES/E` now shows:
Code:
.RES/E                                                                                           
                                                                                                
130 FILES IN 2480 BLOCKS USING 4 SEGMENTS                                                       
712 FREE BLOCKS (3 EMPTIES)                                                                     

#  NAME TYPE MODE SIZ BLK KIND U V ENT USER                                                     
01 SYS   64  RWF      SYS      0 I  07                                                           
02 DSK   64  RWF      SYS      0 I  07                                                           
03 TTY  TTY  RW       16+ KL8E   E 176                                                           
04 RXA0 RX8E RWF  494 17         E  30                                                           
05 RXA1 RX8E RWF  494 17         E  34                                                           
06 LTA0 LINC RWF  737 20       0 A  10                                                           
07 LTA1 LINC RWF  737 20       1 A  11                                                           
10 TV   VR12 W        21+        A  13                                                           
11 PTR  PTR  R        22  KS33   A 110                                                           
12 RKA0 RK8E RWF 3248 23  RK05 0 A  20                                                           
13 RKB0 RK8E RWF 3248 23  RK05 0 A  21                                                           
14 T4    64  RWF      24         G  53                                                           
15 TDA0  64  RWF      24         G  52
16 T5    64  RWF      24         G  51                                                           
17 TDA1  64  RWF      24         G  50

FREE DEVICE SLOTS: NONE,  FREE BLOCK SLOTS: 01
OS/8 V3T

however when we try to send sdskns.pal over during the `REBUILDING OS/8` step something is causing the system to exit the `EDIT` tool near the end of the transfer:
1719422276247.png

The page suggests using character/line delays, to be safe we used a fairly extreme delay of 80ms/line & 12ms/char, this made no apparent difference.
 
Just to add some extra information, we tried the recommended delays and increased to 80ms/12ms after the more sensible delays made no difference.

It always seems to "fall out" of EDIT around the same place; the source code dumped to the tty is always the same, so it doesn't seem like it's an intermittent issue. (We even got this behavior with no character delays.)
 
Hey, we're trying to follow the instructions here to update the serial disk driver: https://github.com/drovak/os8diskserver/blob/master/SerialDisk/docs/how-to.md
Per README.md:
Code:
There are two "installers" here.

The 'handler_installer' does a bare bones kludge to allow booting with the
new handler for SYS:.

That seems to be what you've done (successfully). Note that the other SerialDisk handlers besides SYS: are still at version G. Hence your efforts to send the non-system handler with presumable the intent to install it with BUILD.

If you want to continue with this path but skip trying to paste source code, try:
Code:
../tools/os8xplode ../disks/Mike_PDP-12-2024.rk05
../tools/pal sdskns.pal
../tools/bin2bn sdskns.bin >../disks/Mike_PDP-12-2024.rk05.0/.
../tools/os8implode ../disks/Mike_PDP-12-2024.rk05
../tools/mkdsk ../disks/Mike_PDP-12-2024.rk05.xml+
cp ../disks/Mike_PDP-12-2024.rk05.new ../disks/Mike_PDP-12-2024.rk05 #(...or just boot rk05.new)

That should get SDSKNS.BN onto the image so you can proceed.

You could also give Mike's getos8diskserver and makeos8diskserver at the top level a try. (Once you've got the right packages installed you can also play with the "sdsk/runbuild" stuff.)
 
Thanks! We hope to get to run this a little later and will report back!
Today, Zach and I got ADVENT to run on the PDP-12! We realized that our os8diskserver versions were not actually up to date, so we cloned and used makeos8diskserver, which worked perfectly. Then we used @djg's instructions for setting up ADVENT with different disk names, which worked perfectly. You were right that it takes a long time to get things set up!

Zach and I noticed that the newer versions of os8diskserver (or perhaps the handlers) make much less "noise" on the PDP-12. It was a little odd to hear a completely different set of sounds from the machine, but it all worked perfectly. Attached is proof that we got it up and running.

Huge thanks to everyone who has been so helpful and supportive, including @vrs42 , @djg, @m_thompson , @DougIngraham , @antiquekid3 and others. Playing ADVENT on the PDP-12 has been a dream since nearly the beginning!
 

Attachments

  • advent.jpg
    advent.jpg
    258.2 KB · Views: 15
Today, Zach and I got ADVENT to run on the PDP-12!

I spent so much time after work in a team playing Adventure on a Honeywell mainframe. We made huge maps that described the tunnels and hazards. We made script files containing known good plays that we could replay to get to where we left off the prior night. Then I found a tool to edit the database and added even more tunnels.
 
In other news, one of the fans cooling the flip chips is starting to make grindey noises. It is still spinning, but visibly slower. It's one of these Boxer 115mm AC fans. It is a testament to their engineering that we haven't had to replace fans before. It looks like I can find similar (15cm, 115V, 2 amp, 50/60hz) replacements online. Do you folks try to get original replacements? On the one hand that seems aesthetically pleasing... on the other hand it feels a little foolish. Alternatively, is there any maintenance I could perform on this fan? Thanks.
 

Attachments

  • 15mm_boxer.jpg
    15mm_boxer.jpg
    194.2 KB · Views: 3
@vrs42 and @m_thompson (or anyone else with a PDP-12): do either of you have PDP-12-specific RK05 images that you like to use for booting your PDP-12s? If so, what kinds of things are on it, or how is it configured? We were thinking it might be nice to have a couple of standard Swiss Army knife disk images with necessary handlers, helpful utilities, etc. and then we can use other disk images when we want to run various things. But we're not really even sure what should be on a "PDP-12 specific system disk."

Or, if you don't have something like this, how do you prefer to work? Thanks again!
 
Hey, we're trying to follow the instructions here to update the serial disk driver: https://github.com/drovak/os8diskserver/blob/master/SerialDisk/docs/how-to.md

We were able to use `handler_installer` seemingly just fine during the `INSTALLING THE SYSTEM HANDLER` step:
Code:
./handler_installer ../handler/sdsksy.bin ../disks/Mike_PDP-12-2024.rk05
Read 454 bytes of disk
Read 812 bytes of handler
Position after leader: 0357
Number of devices: 3
Position of bootloader: 0445
Boot length is 38 (0046)
Position of handler: 0601

and the system boots up just fine and `RES/E` now shows:
Code:
.RES/E                                                                                         
                                                                                              
130 FILES IN 2480 BLOCKS USING 4 SEGMENTS                                                     
712 FREE BLOCKS (3 EMPTIES)                                                                   

#  NAME TYPE MODE SIZ BLK KIND U V ENT USER                                                   
01 SYS   64  RWF      SYS      0 I  07                                                         
02 DSK   64  RWF      SYS      0 I  07                                                         
03 TTY  TTY  RW       16+ KL8E   E 176                                                         
04 RXA0 RX8E RWF  494 17         E  30                                                         
05 RXA1 RX8E RWF  494 17         E  34                                                         
06 LTA0 LINC RWF  737 20       0 A  10                                                         
07 LTA1 LINC RWF  737 20       1 A  11                                                         
10 TV   VR12 W        21+        A  13                                                         
11 PTR  PTR  R        22  KS33   A 110                                                         
12 RKA0 RK8E RWF 3248 23  RK05 0 A  20                                                         
13 RKB0 RK8E RWF 3248 23  RK05 0 A  21                                                         
14 T4    64  RWF      24         G  53                                                         
15 TDA0  64  RWF      24         G  52
16 T5    64  RWF      24         G  51                                                         
17 TDA1  64  RWF      24         G  50

FREE DEVICE SLOTS: NONE,  FREE BLOCK SLOTS: 01
OS/8 V3T

however when we try to send sdskns.pal over during the `REBUILDING OS/8` step something is causing the system to exit the `EDIT` tool near the end of the transfer:
View attachment 1282090

The page suggests using character/line delays, to be safe we used a fairly extreme delay of 80ms/line & 12ms/char, this made no apparent difference.
Hey, I've been reading the OS/8 manual and playing around a bit, I don't think EDIT works great for this. Our issue here was being caused by EDIT hitting form feed characters in the sent pal files, which cause EDIT to switch back to command mode. Once back in command mode EDIT treated the rest of the sent text as commands until an exit command was hit (minicom wasn't showing this when sending the pal files through minicom for some reason), then the remaining text would get dumped on the main command line (which is what's seen here). Without the form feed characters the pal files hit EDIT's 5600 character buffer limit, which leads to similar breakages (EDIT switches back to command mode once the limit is reached).

We could split the pal into chunks and append->save them individually through EDIT, but I noticed the PIP tool seems to work great for this, unless I'm missing something?
 
n other news, one of the fans cooling the flip chips is starting to make grindey noises.
Alternatively, is there any maintenance I could perform on this fan?
You can get at the bearing but you have to cut/remove the label. If its made it to grindey I have found lubrication doesn't last since the bearing has been damaged. Most are sleeve bearing but some ball. If its ball you can replace the bearings. Most people just replace fan. You can always save fan to repair and replace if originality is ever worth the trouble. Never tried matching NOS part to see if they age sitting. Does IMC boxer still exist? Online search seems like no based on who selling them.
 
Back
Top