• Please review our updated Terms and Rules here

PDP-8 OS handlers

Are there any operational pdp-5's out there? Sorry to be ignorant.
I don't know. The only one I have been able to inspect is at the System Source Museum. I would like to think that that one will be returned to operation at some time in the future. I didn't think that the machine was in too bad of condition, but the PDP-5 uses the older DEC system modules instead of FlipChips and I am not familiar with them. This makes it more difficult to know what the common problems with the machine might be.

I certainly hope there is one running somewhere! But running or not is no excuse for me to not take it into account when writing Family of 8 software.
 
There's one in Atlanta at CMoA, but I fear the chances of it running are approximately 1 in 1E17.
 
but the PDP-5 uses the older DEC system modules instead of FlipChips and I am not familiar with them. This makes it more difficult to know what the common problems with the machine might be.
IIRC the system modules are the only place I ever found actual germanium parts used in DEC gear. Other than that, they seem quite similar to the later R/B/S modules. I have no physical experience with any gear built from system modules, though.
 
Finally got around to debugging the new boot loader.

OS/8 came up first try but PIP would crash before its prompt came up. It was waiting for TSF to come true. As it turned out the piece of code in the boot loader was measuring the time it took between the TLS and the TSF flag coming true as just a few microseconds. I was clearly measuring this wrong. What I had forgotten was the M8655 has a UART with a one character transmitter buffer. The first character goes into the buffer and then into the transmit shift register. Then it reports that it can accept another character. I had to change my test to:
Code:
        TLS             /SEND A NUL
        TSF             /WAIT FOR IT TO COMPLETE
        JMP .-1
        TLS             /SEND A SECOND NUL WHICH GETS TIMED
/ TIME HOW LONG IT TAKES FOR THE TSF TO COME TRUE
Sending the second character allowed CSD to know how long to wait when a system call is made so that it can save the state of the console. I had tried to break it and found that the earlier version did the right thing. I never tried to see if anything common would break if I messed it up. But today I accidently did and found that PIP would make a system call and CSD would wrongly clear the TSF bit when it returned because it thought that was the way it was on entry. PIP would wait forever for the flag to come true.

All better now!

I think I need to add some actual functionality before I tar up a new version.

I think I could easily add a mode I call paranoia which doesn't trust the PDP-8 and does extra stuff to verify that the transfer worked. For example, when a program requests a disk read what will actually happen is the disk read will take place but then the server will have the handler send the data it just wrote to memory back to the server for a verification check. On disk write operations the server could transfer the data twice and make certain it got the same thing.

And while that would be fun, I should probably just buckle down and add the ctrl C check stuff that is supposed to be in there.
 
IIRC the system modules are the only place I ever found actual germanium parts used in DEC gear. Other than that, they seem quite similar to the later R/B/S modules. I have no physical experience with any gear built from system modules, though.
Them using Germanium makes sense. It was in the early 1960's that Silicon became cheaper and so everyone started using it. If I remember correctly the migration across the PN junction takes place at about twice the rate as in Silicon. That means they would be ageing out in half the time. And the Silicon transistors in my Straight 8 are ageing out. I've never looked for Germanium transistors, but I imagine that they would be more difficult to find.
 
At Vince's for a couple of days, Kyle has been here for 5 days and they have gotten quite a lot accomplished. Yesterday, Kyle decided to try to get CSD running on simh. I helped debug what was going wrong with his socat connection between the two programs and eventually we found that simh was not receiving the 0377 code when CSD sent one. He figured out it was some setting involving telnet and now we appear to have CSD running on simh. I will need to add the commands he used to the documentation at some point.

While Kyle was messing with socat I added the code to the CSD server to handle control C. This had the side effect of flushing the keyboard buffer. This makes the behavior more like when using a real Teletype directly connected as a console. This along with the new boot loader will be in version 1.2 when I am satisfied with it. I am really proud of the Version 1.2 boot loader. The code flows well and is easy to read and understand. A step up from the boot loader in V1.1 and earlier. The hand toggle in code is still 8 instructions but it moved from 025 down to 020 and a couple of the instructions changed due to the move.
 
Doug,

Let me know when you are all done and I will see what I can do to add it to Roland's boot board code.

Mike
 
Let me know when you are all done and I will see what I can do to add it to Roland's boot board code.

The V1.2 release should be the last time I change it. I would be delighted if someone added it to Roland's project.

I am hoping to someday get a "Real M847" and program the diode matrix to do this boot. For the time being it doesn't take too long to enter it by hand. Less than a minute. And most of the time you can just start CSD up and do a Load 7605 in field 0, Start and are good to go.

But during development I have entered the boot hundreds of times.
 
I did a little more work on V1.2 of Console Serial Disk. I have been planning on adding some virtual Character handlers, specifically, TTY:, PTP:, PTR:, and LPT: devices. Right now I have seven entry points in the non system handler and I don't know how many there can be. The most found in any of the DEC handlers is 8 so I know that should work. The entry points in CONNON.PA are CSD0: through CSD3:, RKA:, RKB:, and DTA:. RKA: and RKB: are how you reference the two halves of a virtual RK05 or Kyle's serial disk image and DTA: is how you reference a DECtape image. I don't know why but if I try to use the real names such as DTA0: then BUILD refuses to insert them. No error, it just silently does nothing. This was probably a blessing in disguise because it forced me to change the names and this eliminates the possibility of a conflict if you have a real RK05 or DECtape device on the machine.

The next step is to add LPT to the handler and see what BUILD thinks.

I am going to have to look into BUILD and probably write my own version of RESORC to see if I can fix the issues.
 
Doug,

I will be adding your boot to my boot board soon.

Also, I do have an M847 that I might be willing to trade.

Mike
 
I will be adding your boot to my boot board soon.
Ok The new boot for V1.2 and probably forever forward is:

Code:
0020    6031    BOOT1,  KSF
0021    5020            JMP BOOT1
0022    6036            KRB
0023    7012            RTR
0024    7010            RAR
0025    3003            DCA 0003
0026    2025            ISZ .-1
0027    5020            JMP BOOT1

It is short enough that I have it memorized at this point. Self modifying code, Ya gotta love it!
Also, I do have an M847 that I might be willing to trade.
You are talking about a DEC M847 hardware bootstrap loader card right? It would be so retro to put the CSD boot loader in one of those.

I guess I need to inventory some cards I would trade for that if that was what you had in mind. I know I have several extra M8350 posibus boards if something like that would interest you.
 
I did some more work on ver 1.2 of Console Serial Disk (CSD) over the last few days.

I had previously changed the non system handler to use the baud rate timer constant in the system handler since it is in a known location. The BDTIME constant is measured at the very end of the boot loader code which then patches the value into the SYS handler. I have since realized that there will be people who will not use CSD as the system device and that makes this a poor choice. So I added the code to the non-sys handler to calculate the BDTIME constant on its first call. That measuring code then becomes dead and a few locations will get reused as variable storage. I don't like this solution much but it is what it is for now. Originally I had the user run a program to measure this and then you corrected the value in CONNON.PA. I may go back to this because in the situation where you are not using CSD as your system device you are going to have to BUILD a system that includes it which means you will need to have some clue (i.e. not clueless).

I am also adding a HSR: and HSP: devices which are the virtual equivalents of the High Speed Reader (PTR:) and High Speed Punch (PTP:) devices. These as virtual devices are useful for getting 8 bit binary data into and out of a machine. OS/8 handler for the PTR and PTP is called PT8E.PA and is the same for pre-Omnibus high speed paper tape devices like the PC01 on the Straight 8.

I have been frustrated by the code I put in to let the user feed a text file in via the console. I put this feature on F6 and a file is then sent a character at a time waiting for the sent character to be echoed. The UNIX newline code is sent as a CR and a CR/LF pair is the expected ECHO. Non UNIX line ending files would get sent as CR CR LF. That has not yet been an issue for me but I can probably do something to detect that case and do mostly the right thing. The problem I am having occurs when a line of text in the file is longer than 71 characters. When a character is sent at column 71 which is the right margin of a Teletype 33 the Super TTY handler sends a CR/LF pair which causes the send function in the server to see the wrong character echoed and it dumps out with an error. I am going to try to accept a CR/LF and ignore them if the character that follows is the one I expected. There may be a way to turn off this behavior in the Super TTY handler but I have not investigated that and the user should not be expected to do so in any case. I think this will work because the CR/LF that the Super TTY handler echoes is cosmetic and not inserted into the text file. At least I don't think it is. And the whole reason for this is because the RDR RUN signal cannot be used for flow control except on a teletype. The UART chips take a couple of characters to stop transmitting and there is at most a 1 character buffer which is probably already full on the PDP-8 console port.

Oh, Happy New Year everyone!
 
Added the code to the NONSYS handler to do the two 12 bit words to three 8 bit bytes transfer in the PDP-8 memory read to server write direction. I did this one first because it takes less code. This results in a 25% increase in transfer speed in the "Disk Write" direction. It is unclear if there is enough space in the handler to do the other direction. Currently there are 2 words free so I have a lot of work to do to make the "Disk Read" direction work as well. The "Disk Read" direction would be more useful because in the real world we do lots more reading than writing. The implemented direction would make sense from the standpoint of archiving physical media.
Of course I still have to test it.
 
After more thought I concluded that there are two main use cases for CONsole Serial Disk.
  1. Someone has no system boot device, just a console serial port on their Family of 8 machine.
  2. Someone has a system device and wants to move data around for archival purposes or to run on simh.
Foe case 1 I want the most convenience for the user which means I do all the work in advance. I have tied CONNON.PA to CONSYS.PA such that changes made to CONSYS will require changes to CONNON.PA because CONNON.PA uses subroutines and variable values found in CONSYS. This in essence makes it a two page handler but uses the space and coding practices of a one page handler. But all the user has to do is boot the CSD disk image and they have a usable OS/8 system and it looks like a Family of 8 machine with a lot of peripherals.

After making the above changes I now have 34 words free in CONNON to add the memory write "Disk Read" direction for the 2 word to 3 byte compression. That should be plenty of space. Probably add that later today.

For case 2 I am going to make a stand alone handler called CONSAL for CONsole Stand ALone which will be installed by the user on their working system device using BUILD. This will most likely end up as a two page handler but at least it isn't a two page SYS handler.
 
do I unserstand you in the right manner that 2. is more or less the usecase of os8diskserver?
Kyle's Serial disk must have a second serial port to act as the disk device. I have eliminated the requirement for the second serial port because everything goes through the console serial port. But I would say that the use cases are similar for both. I've just made it a lot more general purpose. And with this release it will be about 25% faster than Kyle's serial disk because I make use of all 8 bits in each character instead of only 6 bits. Years ago I tried to do this to Kyle's handler and was only able to fit in one direction or the other due to handler length issues. I had IFDEFs so I could conditionally build it several ways.

Use case 2 would perhaps be best served using a file transfer program with error checking. Something like Kermit or XYZmodem if someone ported those over. And while they would be ever so slightly slower than this new version of CSD, the error checking would be a big plus. I would add some error checking if I had enough room.

I did code up the other transfer direction last night and I now have two words free in the non system handler. The non sys handler supports the following virtual devices:
  • CSD0 through CSD3 which are 4095 block size devices, the largest OS/8 supports.
  • RKA and RKB which is an RK05 simh or Kyle's serial disk image. (3248 blocks each)
  • DTA which is a simh DECtape image. (737 blocks)
  • VLPT which is a virtual line printer.
  • VPTP which is a virtual paper tape punch.
  • VPTR which is a virtual paper tape reader.
That is 10 devices supported by one handler. I have not yet tested this so it is possible that there will be some issues with BUILD not liking more than 8 devices in a handler. I will be adding support for RX01 and RL01 images at some point, probably not in release 1.2. It only takes one word in the handler to add support for another virtual device so there is room to support those additional devices assuming bug fixes don't eat that extra space.

I guess it is time to turn on the 8/e and see if BUILD behaves itself.
 
Back
Top