• Please review our updated Terms and Rules here

PDP-12 #435 at the University of Minnesota Duluth

ISTR that P?S8 spent a fair bit of energy working to preserve a prior behavior, in which the loader had an amazing ability to load over itself. So even diagnostics and such that used the memory where the loader lived could be loaded. Does DIAL-MS have this ability?

If so, it may complicate the creation of compatible replacement loaders.
oh huh, how did they pull that off? I guess for data break devices you could issue a read command to overwrite yourself (the loader), but then you'd end up attempting to execute whatever was in that block.

But I'm not sure if DIAL-MS supports doing that. The main loader passes execution off to a mini-loader that's part of the final I/O routines page and is responsible for loading programs into the second half of field 1. If the loader tell the mini-loader to load the final page of field 1, overwriting itself, it will. I'm not sure if that happens in practice, but DEC's docs for the loader imply it can. If it does happen, there's no special handling and the system will just start executing whatever is loaded into that final page after it's been loader (data break devices) or stop loading mid-page after the I/O handler overwrites itself (serial disk stuff).

I was going to test what happens, but I just came in to the analog channel knobs on our machine not working (necessary for DIAL), so using DIAL is a no-go for now :/
 
I was going to test what happens, but I just came in to the analog channel knobs on our machine not working (necessary for DIAL), so using DIAL is a no-go for now :/
To elaborate on this: none of the channels can span their entire intended range (-777 to 777 iirc). On the positive end, I think the highest I saw on any channel was 147 (many stopped at ~70, though). The lowest on the negative end was -411.
IMG_4491.jpegIMG_4493.jpeg
 
Last edited:
To elaborate on this: none of the channels can span their entire intended range (-777 to 777 iirc). On the positive end, I think the highest I saw on any channel was 147 (many stopped at ~70, though). The lowest on the negative end was -411.
View attachment 1303988View attachment 1303989
The culprit seems to be the A131 multiplexor in slot D32.
After this post, I messed with the external analog channels and found that giving input to channel 11 causes every other channel to fluctuate a bunch.
The D32 card is responsible for multiplexing the external channels (10 to 17) and the D33 card for multiplexing the knob/pot channels (0 to 7).
Swapping the cards (they're both A131s) moves the funky fluctuating behavior from channel 11 to channel 1.
Removing the suspect card altogether and leaving the good one in either slot yields typical behavior in either the external or knob/pot channels, depending on the slot the card is left in.
 
oh huh, how did they pull that off? I guess for data break devices you could issue a read command to overwrite yourself (the loader), but then you'd end up attempting to execute whatever was in that block.
I went and looked at the code. I think the main innovation was some gamesmanship with
the DMA mechanism, which means no actual buffer is required. Instead, a single word is repeatedly hammered with successive words from the DECtape, and interpreted to set location counters, field settings and data words.

The claim to fame seems to be that the loader was small enough to fit in a single page with the BIN and RIM loaders, as well as the DECtape reboot code. Which means any "user" code can be loaded.

There was also an alternative called the "virtual loader", similar to what OS/8 does where it assembles a partial memory image on scratch blocks, then loads that over itself. (Apparently that was considered stupid because it involved moving the DECtape a lot to get to the scratch area and back.)
 
@ZachyCatGames and I cleaned up our A131, because it was quite dusty, but that did not magically solve our problems. I've attached some pictures of the flip chip.

Zach checked the resistors and capacitors and they seemed to be OK.

Our plan right now is to test the NAND ICs by providing power and input from the card edge connector and then testing the outputs from the output pin on the appropriate IC.

If anyone has any suggestions, please let us know!
 

Attachments

  • A131-bottom.jpg
    A131-bottom.jpg
    1 MB · Views: 10
  • A131-top.jpg
    A131-top.jpg
    1.1 MB · Views: 10
If anyone has any suggestions, please let us know!
I would check the diodes forward voltage drop if you haven't. Those look like D664's that are highest failure rate component in R series logic.

Then whichever is easier for you testing out of circuit or putting it on extender and seeing what is going wrong with signal.
 
I would check the diodes forward voltage drop if you haven't. Those look like D664's that are highest failure rate component in R series logic.

Then whichever is easier for you testing out of circuit or putting it on extender and seeing what is going wrong with signal.
They are indeed D664. They all read 0.59V +- 0.006V, which sounds about right from other threads.
 
Well, today our M401H decided to go on vacation again. We put in the M401L from @gnupublic and it came right back. Let's hear it for spares! (And thank you, @gnupublic !)

Also, as you may know, we have an ASR-33 we are fixing up, but I put in for a navy teletype (part of the 46 won in an auction) so hopefully we will have a teletype for the '12 soon.
 
Last edited:
OK... I think this is reaching the point of being in an OK state.

I wrote a small bootloader for booting DIAL-MS without LINCtape and was also able to implement my idea for rebooting DIAL-MS without LINCtape or the need to re-load the bootloader. I think at this point I have DIAL-MS working without any LINCtape dependency. I haven't extensively tested everything, but I can boot into the editor, type code in the editor, assemble it, etc. Software compatibility is likely messy, but I can't do much about that.

In the process, I wrote a script (well, multiple scripts) for creating and customizing DIAL-MS images from a base DIAL-MS LINCtape image: https://github.com/ZachyCatGames/dial-ms-media-builder
It can build LINCtape, RK08, and Serial Disk images with their respective device handlers. That repo also includes my bootloaders, currently I have ones for RK08 and Serial Disk. I just pulled the DIAL-MS handlers and used them to read in the I/O routines so I could use the restart routine there, so both bootloaders can definitely be condensed.

I've attached a set of Serial Disk and RK08 images and their bootloaders. I haven't been able to test the RK08 image or bootloader because we don't have RK08 hardware, but the Serial Disk stuff definitely works. The LINCtape images in both packs are setup to boot from Serial Disk or RK08, they can can be written to a tape and used to quickly boot DIAL-MS from disk, or they can be ignored if you're using a bootloader. Both disk types use units 010 to 015 in DIAL-MS, have a restart location of 017757(field 1 location 07757), and are in DSK/disk format. Both bootloaders are loaded using the RIM loader and can be started at either location 020 or 0200, after the disk is up and running of course.

For Serial Disk, my fork of os8diskserver is required and the `-d` cmd flag must to be given, it otherwise functions the same as normal os8diskserver.

(will write more explicit usage instructions shortly)
 

Attachments

Quick guide for DIAL-MS serial disk:

This assumes that you have a C development environment installed in some *nix-like environment, already have a setup capable of using os8diskserver (and have some familiarity with os8diskserver), and already have some means of sending paper tape images/files.

On the modern system:
1) Download my fork of os8diskserver (os8diskserver-dial): https://github.com/ZachyCatGames/os8diskserver-dial
1a) `git clone https://github.com/ZachyCatGames/os8diskserver-dial` or
1b) download a source zip from github and extract it: https://github.com/ZachyCatGames/os8diskserver-dial/archive/refs/heads/master.zip
2) Build the server under 'os8diskserver-dial/SerialDisk/server'.
2a) `cd os8diskserver-dial/SerialDisk/server` (filling in for the actual location you saved os8diskserver-dial at)
2b) `make`
3) Configure the serial disk server's serial config in `os8diskserver-dial/SerialDisk/server/disk.cfg` according to your setup.
4) Download and extract my sdsk.zip archive from my previous post, put `test.sdsk` in `os8diskserver-dial/SerialDisk/server` and `sdsk-bootloader.rim` wherever (doesn't matter where).
5) Start the disk serial disk server in DIAL mode and using my disk image as the first disk: `./server -d -1 test.sdsk`

On the PDP-12 (if using the bootloader, without LINCtape, to boot DIAL-MS; see the next section if you wish to use LINCtape to boot):
1) Enter and start the RIM loader.
2) Send the `sdsk-bootloader.rim` paper tape image from earlier to the PDP-12 via the TTY/PTR using your preferred method.
3) Stop the rim loader after the bootloader has been fully sent.
4) Make sure `MODE` on the main console is set to `8`.
5) Depress `I/O PRESET`.
6) Make sure the VR12 display is turned on (not strictly required, but DIAL-MS uses the display heavily)
7) Depress `START 20`.
- The bootloader also supports being started at location 0200
8) After a short wait the DIAL-MS editor should show up on PDP-12's display

On the PDP-12 (if using LINCtape to boot DIAL-MS; if using the bootloader to boot DIAL-MS, see the previous section):
1) Write the LINCtape boot image (test.linc) using your preferred method to a 256 word-per-block tape that has at least 512 blocks.
2) Mount the on a LINCtape transport designated unit 0, making sure that transport is the only one set as unit 0.
3) Set `REMOTE` and `WRITE ENABLE` on unit 0.
4) Make sure `MODE` on the main console is set to `LINC`.
5) Set `LEFT SWITCHES` to 0701 and `RIGHT SWITCHES` to 7300.
6) Depress `DO`, LINCtape transport unit 0 should begin moving.
7) Once unit 0 stops moving, depress `I/O PRESET`.
8) Make sure the VR12 display is turned on (not strictly required, but DIAL-MS uses the display heavily)
9) Depress `START 20`.
- The bootloader also supports being started at location 0200
10) After a short wait the DIAL-MS editor should show up on PDP-12's display
 
Last edited:
The RICM PDP-12 has the Omnibus chassis containing an RK8F connected to an RK05. I wonder if the RK08 and RK8F are compatible so DIAL-MS would work on our machine.
 
The RICM PDP-12 has the Omnibus chassis containing an RK8F connected to an RK05. I wonder if the RK08 and RK8F are compatible so DIAL-MS would work on our machine.
Oh hm, it sounds like the RK8F closely resembles the RK8E, which isn't compatible with RK08. I see there's a RK8F version of DIAL, I wonder if that's shown up anywhere?
I guess worst case I could write a new RK8E handler and test it using simh.
 
Oh hm, it sounds like the RK8F closely resembles the RK8E, which isn't compatible with RK08. I see there's a RK8F version of DIAL, I wonder if that's shown up anywhere?
Name on this one is promising
https://www.pdp8online.com/pdp8cgi/...e-images/dial/rk8e_system_tape.linc;sort=name

Some other results look like they may be useful. Looks like search terms not part of URL so can't paste full link. Seach for rk8e dial
https://www.pdp8online.com/htdig/search.shtml
 
Name on this one is promising
https://www.pdp8online.com/pdp8cgi/...e-images/dial/rk8e_system_tape.linc;sort=name

Some other results look like they may be useful. Looks like search terms not part of URL so can't paste full link. Seach for rk8e dial
https://www.pdp8online.com/htdig/search.shtml
ah, thanks ^^. The system area in that one doesn't look particularly remarkable (it has the LINCtape and DF32 handlers with an unmodified I/O controller), but that "SYSTEM" file looks promising.
 
Last edited:
That SYSTEM file is interesting. It contains a copy of the DIAL-MS I/O controller + sorta a handler block (the second handler is weird) at 0x6C00 (looking at it in a hex editor on a modern system), so it _does_ contain at least some part(s) of DIAL.

DEC's bootstrapping instructions for RK8F DIAL imply the bootstrap is located in the first block at location 020 and is supposed to be started in 8-mode. This SYSTEM file also starts at block 0, so I started there. It _does_ contain sensible code starting at location 020, but its LINC code, not PDP8 code, and depends on multiple blocks having been read in, so it doesn't seem to be the same bootstrap described in whatever manual. But it does read several blocks from the ~end of an RK05 disk... it also sets up the KW12-A clock and does <other things> so it could be a red herring. Unsure still. I attached my current progress on reverse engineering it.
 

Attachments

I mentioned over in the "What I did to my PDP-8 today" thread that I've been working on a "HELLORLD!" program for the UMN PDP-12.

Here's a version in pure LINC code. I added some frills to auto start when run from LAP6, check for a key press, and exit back to LAP6.

Code:
        @1
        JMP 1A
        @15
        RCG
        7|300
        @20
#1A     SET i 1 [X POSITION
         240
        SET i 2 [TEXT DATA
         2A-1
        SET i 3 [TEXT LENGTH
         2A-2B
#1B     CLR     [Y POSITION
        DSC i 2
        XSK i 3
         JMP 1B
        KST
         JMP 1A
        KBD
        JMP 15  [EXIT TO LAP6
#2A     1077 [H
        7710
        0000
        5177 [E
        4151
        0000
        0177 [L
        0101
        0000
        0177 [L
        0101
        0000
        4177 [O
        7741
        0000
        4477 [R
        3146
        0000
        0177 [L
        0101
        0000
        4177 [D
        3641
#2B

Assembler output (I made my own LAP6). I sent this to the LINC guys at System Source Museum, but I'm not sure they want to toggle it all in.

Code:
0001 6020
0015 0701
0016 7300
0020 0061
0021 0240
0022 0062
0023 0035
0024 0063
0025 7750
0026 0011
0027 1762
0030 0223
0031 6026
0032 0415
0033 6020
0034 0515
0035 6015
0036 1077
0037 7710
0040 0000
0041 5177
0042 4151
0043 0000
0044 0177
0045 0101
0046 0000
0047 0177
0050 0101
0051 0000
0052 4177
0053 7741
0054 0000
0055 4477
0056 3146
0057 0000
0060 0177
0061 0101
0062 0000
0063 4177
0064 3641
0065 0000
 
Back
Top