• Please review our updated Terms and Rules here

PDP-8 OS handlers

My main unspoken concerns were really about the migration path, as there are a bunch of existing SerialDisk implementations, not all of which will get properly re-worked with the latest code. I feared that the next bootloader/server would not be "upward compatible" in the sense that the new server could be used with the older drivers and bootloaders.
I thought we did a pretty good job of allowing the "new" serial disk server be compatible with the old handlers. Because of the way we did it the old boot still works.
Wrt your OCD, I think of it as an "EE" thing. Unlike "proper engineering", my background is software, where the assumption is that "anything useable today is far better than something better tomorrow, let alone something perfect next year". There are pros and cons to each approach.

The standards for engineering are different. When a bridge or a building falls down, that's (rightly) a scandal. In software a "self driving feature" that kills a few riders is somehow par for the course.
There's something hard and cynical in there about how easy it is to blame the users for believing the hype, too. But that's all way off subject.
There is some of that in the OCD thing I suppose. It is kind of obvious when looking at DEC power supplies that they probably put the new guy on them and then suffered with power supply issues for years.

With software there used to be quality assurance departments who had final say on product ship. The big company I did some software work with was Wang Labs and if QA didn't sign off on it then it didn't ship. QA was a constant issue for the programmers there. After the internet and easy software updates those QA departments seem to have lost their power because we can ship it now and easily fix it later. My problem with this is that they never seem to get around to fixing it. Serious problems sure, they get attention but little things almost never. My Tesla Model S is 9 years old this month and there are still software bugs that have been there the whole time. The one that annoys me almost every day is the charge port release. You press the button to release the cable lock. The lock releases and then a tenth of a second later it relocks. You press the release button again and it unlocks and stays unlocked. This should be an easy fix. I suspect that in Tesla's case Elon is the QA department and if he doesn't notice it then nobody works on it. End of off topic rant.

I think I will post all the boot pieces after I have tested them. Now back to work!
 
I thought we did a pretty good job of allowing the "new" serial disk server be compatible with the old handlers. Because of the way we did it the old boot still works.
Yep. Then you kept working on it, which re-raised the backward compatibility question. I figured we'd cross that bridge when we came to it again.

Vince
 
My take on most of this stuff is that, if you're messing with old hardware and software, you need to be (or will soon become!) proficient in rebuilding OS driver support among other things. If SerialDisk modifications are being made to support a larger audience of computers (i.e. the true Family of 8), to correct bugs, to make the boot process simpler, etc., I am all for it, even if it breaks compatibility. The beauty of software repositories is that, presumably, you can go back in time to an older version at any point of both the server and handlers as needed, if you are okay with the previous software limitations.

I am still waiting to see someone make an Omnibus and Posibus/Negibus solid state disk system that could emulate the necessary parts for an DF08, DF32, RK05, RL01/02, etc. as far as most software is concerned. I would not think there would be a need to emulate the exact controller specifications as long as handlers could be used unmodified. Even if concessions have to be made with handlers being modified, it wouldn't be the end of the world—we know how to do this now! But having a real data break device would be quite lovely.
 
Hey Kyle:

It would be fun to do a data break device sometime. But not at all necessary unless one comes up with an interrupt driven OS. In my view OS/8 gains little from DMA transfers because it would just sit there waiting for it to finish anyway. You could gain some performance that way since a single cycle data break device can transfer a word every 1.2 us on Omnibus with the KK8E CPU. This is 10 mbps memory bandwidth. About the best you can do with programmed I/O is 124k words per second and that uses loop unrolling which is probably not going to happen to that extent in a handler. 124k wps is about 1.5 mbps. When you think about it, the PDP-8/e can briefly burst up to 10 mbps ethernet speeds but it has no cpu cycles if it were to go that fast. Probably the most you would want to do would be every other cycle so the processor can get something done during transfers.

I now have my server reading in an RK05 image and it will reject it if it is not a system volume. Sometime tomorrow it should also reject it if it is not a console serial disk volume. I am looking at the boot block to determine what kind of device the image is for. I found a bug in my code that displays a directory of an OS/8 image. I had only run it on DECtape images and when the block size of an RK05 file (actually an empty block was where I saw it) exceeded 2k blocks it started reporting negative file sizes. It was a fairly easy bug to fix.
 
I am all for it, even if it breaks compatibility. The beauty of software repositories is that, presumably, you can go back in time to an older version at any point of both the server and handlers as needed, if you are okay with the previous software limitations.
The worst thing would be to replicate the problems of RX01/RX02, where it not only fails, but makes a hash of things in the process.

Vince
 
What we need is something like this for Omnibus http://retrocmp.com/projects/unibone.
I thought Doug is especially working on this code for non Omnibus machines. Just to make things possible on these beasts too.

An OmniBone would be nice, but it will be a different beast with all the timing generation signals on the OmniBus. The only place for an OmniBone on the bus, is at the position of the EAE boards. Otherwise you can not emulate the EAE properly. There are some clone boards available for these OmniBus machines... Vince his memory board, the OmbiUSB etc... But for the non OmniBus machines there is not much available. And what to do for the PDP8/A with its hex boards? Maybe something for another topic...?
 
I thought Doug is especially working on this code for non Omnibus machines. Just to make things possible on these beasts too.
The thinking is that there are no sources of extra serial ports for Negi or Posi bus machines. And Omnibus serial ports in the M865, M8650, M8655 while not yet what I would call rare are becoming increasingly expensive and may be considered rare at some point in the not too distant future. Vince has a solution for the 8/i (and probably 8/l and PDP-12) to increase the baud rate of the console. I did it for my straight 8 but so long ago now that it would need to be redone. If you are patient you could run this at 110 baud although I would do that only if the paper tape on your teletype is your only storage peripheral.

Update for this morning:

I added testing to the system image to make certain that it is the correct one for this version of SDCON. It reads the boot block and generates a checksum of the handler area. I think I am also going to verify the boot section from 0000 through 0046 as well. As a parlor trick it currently identifies an Image as being an RK05. I found two variants of RK05 handler in my images. One is marked version 3 (probably "C" in the source) and the other is version 6 (which would be version "F".) I think the version number is the only difference.

Next I get to fire up simh and make a theoretically bootable image. It is either simh or I spend the effort to get my RK05 running. I think we know what is the most expedient option.
 
I fired up simh this morning with the intention of building a boot image. I decided it would be a good idea to use real PAL8 to assemble the handler code. You know, just to be sure I am not using some odd palbartism.

PAL gives a PH 0200 error. What? This is supposed to be caused when you conditional out code and don't have matching <> around the code. Well I dont have any conditionals in this. I grabbed the RK8ESY.PA and put it on the image and it does the same thing. This was an RK05 image from the PiDP distro and I was pretty sure it was good but to be sure I switched to one I had been using before and it did the same thing. What finally worked was:
.R PIP
*CONSYS.PA<TTY:

And paste the code into the TTY buffer with a right mouse click and then hit ^Z. That would assemble. When it wasn't working I was feeding the file in using the paper tape file name in simh. It looked fine when I did

.TYPE CONSYS.PA

But it clearly had something that PAL really didn't like. In retrospect it is probably because I am feeding it text with LF instead of just CR for line endings and the MSB is set to 0 instead of 1. And simh is doing too much stuff and hiding this issue where if you copied it to a real teletype it would look all wrong.

Now after all that I made all my changes in BUILD and entered the BOOTSTRAP command to write out the changes and right after I hit enter I realized that I can't use build to make a system that way. You see the BOOTSTRAP command writes the new system to the system device that is selected in its tables. And that system device is the console serial disk sys handler. Yeah, it printed a couple of characters on the screen and hung waiting for the server to talk to it. What is interesting is that apparently the BOOTSTRAP command installs your handler at 7600 and then calls it to write the new boot block out. When done it puts the original back but in this case it never got done so it hung.

It is a catch 22 situation. If you have a working console serial disk then BUILD can build one. If you don't then you can't.

How do I deal with this? I am not going to go down the rabbit hole of trying to attach the console port in simh to a serial port on my windows laptop. It seems like it should be possible but also that there are simply too many programs touching the data to expect it to pass un corrupted.

Ok, new plan! I can bring up old serial disk on a second serial port and boot from that. My back won't hurt from hauling heavy mass storage devices around that I don't even know work. The other way to deal with it is to do what BUILD does. The problem with this is I don't know everything that BUILD does. But I might know enough to trick it. I think I will try the serial disk route first.

I think I have had enough frustration today. Time to do something else.
 
I don't know offhand if SIMH will let you redirect the console to a pseudo-tty. If so, the usual SerialDisk hacks (which are normally for devices 40/41) should work.

Vince
 
Ah. I get "Unit not attachable". It may still be possible to use "expect" in a fashion similar to runbuild to set up the pseudo-terminal the way you want it.

Vince
 
Last edited:
But it clearly had something that PAL really didn't like. In retrospect it is probably because I am feeding it text with LF instead of just CR for line endings and the MSB is set to 0 instead of 1.
I do :set fileformat=dos in vi and then
PIP
FILE.PA<PTR:/I
and it then works for me.
 
I am not going to bother with simh at this point. I have real hardware so that is what I will use.

I spent the morning investigating just manually installing the handler in the boot block. It is easy if that is all that needed to be done. But it looks like there are other things that would need massaging as well so I have decided to just do it the way DEC would have done it. And because of that I get to debug it at the same time as I build the first boot image. Should be interesting.

The current version of the boot loader will not work on a PDP-5. I don't think I am using any of the operate combos that don't work on the 5. Should I bother to fix this? Is it at all likely anyone will ever want to run this on a 5? Are there any PDP-5's with 8k or more of memory still running? Maybe the question should be are there any 5's still running? Of those machines how many have faster console ports? I guess if someone wants to run it on a 5 I will fix it at that time.
 
I feel like I am pretty close to attempting a boot.

I did a bit more testing and found a couple of mistakes. The one I am going to present here was one of those things where if I told you convincingly enough you would believe it. I told myself this and apparently I was convincing enough. Here is the code in error.
Code:
/READ A BLOCK OF 12 BIT WORDS FROM THE SERVER INTO MEMORY
RDCMD,  JMS GET12       /GET 12 BIT WORD FROM SERVER (DSK RD)
        DCA I CA        /STORE IN USERS BUFFER
        ISZ CA          /BUMP STORE ADDRESS
/       NOP             /NOP NOT NECESSARY IF SERVER DOES NOT WRAP AROUND 7777
        ISZ WC          /ARE WE DONE YET?
        JMP RDCMD       /NOT YET
        
        JMP CMDLP       /GO GET NEXT COMMAND

The CA stands for Current Address and WC stands for Word Count. The problem here is that the NOP is not needed unless the the block transfer wraps around the end of memory or ends at 7777. If either of those is true then the ISZ WC will be skipped (if the NOP is not there) and we will wait for an extra word that will never come. The WRCMD loop has the same issue. I had to put the NOP instructions in to make it work in all cases. I don't know if anything in OS/8 would tickle this bug but I did pretty much first thing I tried. I have a dummy server that sent a RDCMD command and had it transfer from 27600 through 27777 and it didn't work. It hung waiting for the server to send an extra word.

Two steps backwards and one step forwards. I had four free words in the handler and lost two of those to this bug. But I was able to find a word. so back to three free. When (when?) I run out of space I can possibly get the space back that these NOP instructions use by placing a constant in that location. As long as it doesn't jmp or change the link when it is executed it can be tolerated. In the case of the WRCMD loop it just has to leave the AC clear. Executing a harmless constant is a fairly common tactic in handlers in this kind of situation.
 
Back to the manually installing the handler in the boot block plan. I am manually installing an interim handler and boot record in the boot block from an RK05 image. The handler headers are identical to an RK8E system handler so there really shouldn't be anything in OS/8 that will get confused. It will believe it is calling the RK8E. All sizes and entry points match. I should be able to use this interim system to run BUILD and turn it into a real image. This will be interesting because I should be able to do a direct comparison of the pre and post images and see what else BUILD touches.

I am letting the server install it in the memory image of the disk that it keeps. I have code that compares the boot portion from 0000 through 0046 and the handler portion from 0207 through 0343 to ensure that the system disk image is one that the server can talk to. For the purposes of this experiment I simply write the correct value into the memory image and then test that word to be certain it is correct. Normally it will just do the test.

I have enough code in the server to start debugging the interactions with the handler. I should be able to see the first call after boot.

I might get to try this later today or tomorrow.
 
Finally got back to this, and it sort of boots. The initial toggle in boot does its job and the server feeds it the help loader. The help loader then reads in the boot sector and puts the parts in the correct places and then jumps to 07600 which is the OS/8 entry point. What happens next is where it gets much more difficult to debug.

I've got an appt with my Ophthalmologist in about 40 minutes. I plan to continue debugging after I get back from that.
 
I finally got back to working on console serial disk a few days ago. I think I had been suffering from burnout after spending a week working on an old Straight 8 (not mine) and getting it sort of running.

One problem I had was with Unix termios and putting the console keyboard/display in raw mode. This now seems to be working (at least on Linux) and I even think I know what I am doing....

The bug I squashed last night was one of those things I probably knew 40 years ago. Here is the snippit of C code that I eventually found was failing.
C:
  if( pdp_ch&0370 == 020 ) do_server( pdp_ch&007 );
This is supposed to take the character received from the pdp8 and decide if it is the server wakeup code. The server wakeup code is 020 through 027 where the last octal digit is the callers instruction field. The do_server routine uses the field to know what field to look in to find the handler call argument list. This test was always false even when pdp_ch was set to a value of 021. Do you see what the problem is? Took me several hours of looking in the wrong place before I realized do_server was never being called. What is supposed to happen is the AND with 0370 will remove the field bits from the comparison. That is not what was happening. The C precedence rules cause the == to take place before the & so 0370 is never equal to 020 giving a result of 0 which when ANDed with anything is still 0. which means do_server was never being called.
C:
  if( (pdp_ch&0370) == 020 ) do_server( pdp_ch*007 );
Is the working business.

Now to find the next bug!
 
My view is to always put the parenthesis in whilst writing the code - they cost nothing in the execution.

Dave
 
Back
Top