• Please review our updated Terms and Rules here

PDP-8 OS handlers

I can see uses for such a thing, but I also think it's extremely handy to have all those RK05 images useable, and I can't see how you'd do both. Maybe a command line flag or the like, with the default partition sizes like the RK05?

It's also imaginable to do "images" with more than two devices/partitions. (Maybe RL02-like?)
I think what I am going to do is make SYS: the native CSD image which is a maximum size OS/8 image. This eliminates all the confusion about modified RK05 system images. The SYS handler will have two devices, CSD0: and CSD1:

The non system handler will have a couple more CSD devices and RKA0:, RKB0: so an RK05 image can be mounted but not booted from directly. I will at some point add other devices to the non-sys handler, like an RX01, RX02, and DECtape device. But that is for a future release.

I would make it an option. But I don't really like disk images which do not work on a real rk05. The disk images for Kyle's disk server also needed to be edited for the disk server. Within time people might confuse these images with real images. I have had problems with online papertape which were corrupt as well.

Ideally a disk emulator would work with original disk images. And images created with an emulator should work on real hardware. Otherwise there will be two pdp8 worlds I think....
Yes, the idea that I have broken an RK05 image is what was making me uncomfortable. When I started thinking about it the reason I did that was it was an expedient way to bootstrap into a running system on a machine with no working mass storage. Now that I have it working I should be able to work around it pretty easily.
 
Yes, I think we need a 'maximum size OS/8 partition' storage device. If you don't code it, I'm confident someone else will soon do it. If it's useable at 9600 baud, I'm looking forward to hearing how well it performs with a USB serial I/O interface.
Usable might be too strong a word. Barely tolerable would be a more apt phrase. Better than feeding paper tapes through the ASR33 paper tape reader/punch though.

Think of 9600 baud this way: To do a backup of a full RK05 3248 block image will take around 29 minutes for the CSD side and theoretically only 8 seconds for the RK05 side (this is copying from a real RK05 to a CSD mounted image.
 
I wasn't able to find exact replacements for the dip switches in my stash of parts but I did get them replaced and the new ones do work.

When I got the old dip switches out it was clear that someone had sprayed something into them in the past.

If I put a Peltier cooler on the UART, will work at 38400?
 
Oh, and before you post back a comment about spraying deoxit into the switch and working the contacts, I tried that. It isn't just that one switch, only two of the contacts on that switch close.
I had a DSD floppy with a DIP switch like that. It got stuck in "format a new floppy" mode and erased my boot disk (grumble). (Alas, I replaced the DIP switch a few years down the road, but now it has bit-rot in the control ROM and won't pass self-diagnostics.)

Vince
 
I wasn't able to find exact replacements for the dip switches in my stash of parts but I did get them replaced and the new ones do work.

When I got the old dip switches out it was clear that someone had sprayed something into them in the past.

If I put a Peltier cooler on the UART, will work at 38400?
I had two M8655 serial boards with bad DIP switches. After replacing the switches I pulled two of the old switches apart to investigate the cause. It turned out that the guts of the switches were coated in limestone. Clearly somebody in the past had washed the boards in hard water. After the water evaporated the switch internals were coated with the mineral residue. This should be a warning to all those who think it is a good idea to wash boards in tap water or even worse drop them into the dish washer.
 
I coded up a non-sys handler for CSD0-CSD3 (4095 OS/8 block disks), and added in entry points for one virtual RK05 (RKA0 &RKB0) and a virtual DECtape (DTA0). Used PAL8 to assemble it and then BUILD to install it. I patched PIP so it would know the sizes of CSD0-3: and then rebooted to complete the process and it wouldn't boot. I figured I had done something to blow my boot image but that is not it because it won't boot yesterdays image either. It gets partway through the boot and hangs in a KSF; JMP .-1 waiting for the next character from the server. Looks like the M8655 is dropping characters. It was a hot day and my basement shop was warming up not to mention the 8/e had been running for several hours. We will see sometime today if it is behaving now that it has cooled off.

I was re-reading the OS/8 handler reference stuff and found something I didn't remember reading before. A handler can have at most 16 entry points. This is most likely a limitation in BUILD. This is not a terrible limitation when you consider that OS/8 can only have 15 active handler entry points total and there must be a SYS:, DSK:, TTY:, and LPT: handler. And while DSK: can point at the SYS: device it still takes up one of the 15 slots. I edited this new to me info into my handler book.

It felt like I got a lot done kind of day but the hardware failure (probably) left me feeling a little down.
 
I coded up a non-sys handler for CSD0-CSD3 (4095 OS/8 block disks), and added in entry points for one virtual RK05 (RKA0 &RKB0) and a virtual DECtape (DTA0). Used PAL8 to assemble it and then BUILD to install it. I patched PIP so it would know the sizes of CSD0-3: and then rebooted to complete the process and it wouldn't boot. I figured I had done something to blow my boot image but that is not it because it won't boot yesterdays image either. It gets partway through the boot and hangs in a KSF; JMP .-1 waiting for the next character from the server. Looks like the M8655 is dropping characters. It was a hot day and my basement shop was warming up not to mention the 8/e had been running for several hours. We will see sometime today if it is behaving now that it has cooled off.

I was re-reading the OS/8 handler reference stuff and found something I didn't remember reading before. A handler can have at most 16 entry points. This is most likely a limitation in BUILD. This is not a terrible limitation when you consider that OS/8 can only have 15 active handler entry points total and there must be a SYS:, DSK:, TTY:, and LPT: handler. And while DSK: can point at the SYS: device it still takes up one of the 15 slots. I edited this new to me info into my handler book.

It felt like I got a lot done kind of day but the hardware failure (probably) left me feeling a little down.
In message #95 you wrote that you changed the M8655 jumper to 19200 bps. I wonder if that is the cause of the dropped characters.
I read somewhere that the M8655 only works at 19200 bps reliably when a "special" versions of the LSI UART chip is fitted. I think these were the newer plastic as opposed to the ceramic versions of the IC.
I would try again at 9600 bps to see if you can get it to work reliably at that speed.
Other than the LSI UART you might have some software timing issue which shows up at the higher serial speeds.
 
The change to 19200 could be a contributing factor but I had been running for several hours this way without noticing any problems. I have another M8655 still configured for 9600 baud that I can swap in. The one I am using at 19200 baud has the black plastic chip. The other one has the white ceramic chip with the gold cap.

I say "noticing" because there is no way to do any kind of error checking in a 93 word system handler. The server side uses the 4 bit overlap when it receives a word from the 8 which I do check for a mismatch but that is only one way. There is room in the non-sys handler so I will add in that as an error check there. But it isn't a very good error check. If there was programmatic control of the number of bits and parity on the 8 side I would probably switch to 6 bits with parity checking as the easiest way to find a bit error.

If someone is curious about the 4 bit overlap just ask and I will elaborate.
 
Found a few minutes to try to boot and with everything cold it boots fine. When it happens again I will put the M8655 on a riser and scope stuff out. Hopefully the issue will be on the M8655 and not something in the CPU as that is more difficult to fix due to the top blocks connecting the cards.

Time to add the CSD0-CSD3 support to the server. Sometime this afternoon or evening.
 
Booted OS/8 on Vince's 8/a. Measured BDTIME on that machine and my predicted value matched exactly.

Briefly messed with getting CSD to run on a Vista powered laptop running ancient Cygwin. This combo is pretty broken and I am not going to spend anymore time on it as the ioctl's don't do what they are supposed to.

I need to spend a few more hours and I will release it in an initial configuration so people can try it. I have drawn the line on development until I get more testers.
 
Spent several hours yesterday trying to use BUILD to make the new max size OS/8 boot image. It turns out that they (DEC) did something that is kind of clever and it is causing me issues. When you enter the BOOTSTRAP command in BUILD it checks to see if your new SYS device is the same as the old SYS device. If they are different then it needs to copy the operating system to the new SYS device. Now the tricky part is that you never tell BUILD the name of the new device because it is going to be SYS. And the only way it knows to talk to the new device is using the SYS handler that you just marked as active. SYS is a special handler that always resides on field 0 between 7607 and 7743 so in order to always work correctly it must be loaded there. What BUILD appears to do when copying the system blocks from running SYS to new SYS is to swap the two SYS handlers. The copy operation looks like this:
  1. Read a block from running SYS.
  2. Save the running SYS handler from the last page in field 0 in a temporary place in memory.
  3. Install the new SYS handler on the last page of field 0.
  4. Write the block from step 1 to the new SYS device.
  5. Save the new SYS handler from the last page in field 0 to its temporary place in memory.
  6. Restore the running SYS handler.
  7. Repeat until every block is copied.
Swapping the handlers is not that expensive of an operation since a SYS handler is only 93 words long at most. All of that works splendidly except for my case. The reason it doesn't work for me in this case is I am using essentially the same handler for both. The server recognizes the device that OS/8 is talking to by the handler entry point which is passed by the handler. In both cases the handler entry point is 7607 which the server knows is the SYS device. Which means that in using this trick DEC causes the server to write on the same device as it is reading from even though the SYS handler is different. This is an edge case and I know how to fix it for version 2 but I don't want to change that much code before I release it since in the normal case what I am doing now works fine.

I think I can shoehorn the boot block which includes the handler and OS/8 resident code into this new image. I have already used PIP to copy everything from the RK05 image I am currently booting from to the new max sized image. I didn't time it but I think it took about a half an hour for PIP to copy everything on the RK05 system image to the new image at 19200 baud. I was going to figure out some way to verify this copy using the 8 but have not yet done so. This would be a good idea since there is no real error checking anywhere.

Later!
 
It has been a while. I worked on the Readme this evening and I think that is ready. Here is the Readme that will go up on Github separate from the tarball.
Code:
This file is a project overview and quick config guide.

It is expected that you know something about Unix or Posix compliant
operating systems of which Linix is an example.

The CSD (Console Serial Disk) project is intended to allow an upgraded
PDP-8 console serial port to be used for both the console and as the
interface to a general purpose OS/8 device handler.  By upgraded I mean
a higher baud rate (9600 or greater) and RS-232 (not current loop).  The
reason for this is that while extra serial ports are still plentiful for
Omnibus based PDP-8's, extra serial ports on the earlier machines (Negi
and Posibus) are virtually non-existent and quite a bit more difficult to
make.  An extra serial port is a prerequisite for Kyle Owen's Serial Disk
program.

In its most basic use case all you need is:

1) A PDP-8 with a 9600 baud or greater RS-232 console port.
2) A Raspberry Pi or any Posix compatible Unix server with an RS-232
   port.

The PDP-8 console port baud rate does not have to be set to something
really fast, but you will quickly wish that it was.  9600 baud is just
barely tolerable to me.  It could be run at 110 baud and after thinking
about it I am pretty sure that would be an overall improvement over
papertape using the teletype paper tape reader/punch.

The most difficult part of using this is getting the serial port on the
server configured to match the PDP-8 and configuring the csd (console
serial disk) server to talk to that port.

I have included several csd image files in the tarball so you can just
boot up.  You can also mount a simh RK05 image or one of Kyle's Serial
Disk images and access those although you can't boot from them.

Unpacking the tarball:

I suggest you create a user account on the server specifically for this
but it can be run from anywhere as long as the server can read and write
the serial port devices.  For this you can place that user in the same
group as the serial device, or change the ownership of the serial device
to the user the server is running under.  I suppose you could also run
the server as superuser although this is not recommended.  Once you have
decided where to place the code you can unpack the tarball with the
command:

tar xzf consd.tgz

This will create a subdirectory consd in that subdirectory.  If you have
never used tar the x means extract, the z means use compression, and the
f means the tarfile is the filename that follows the f.

You will find that there are several files and subdirectories in the
consd directory.  There is a copy of this Readme and a file named Config
which has more instructions on how to configure everything if necessary.


Building the server:

The server sources are found in the subdir consd/server.  You can get
there by changing to it with cd consd/server command.

There are two lines in the csd.c file that may need to be changed to
match your installation.  They specify the serial port device and baud
rate on the Unix server.  By default they are set to

#define PDP_SP          "/dev/ttyUSB0"
#define PDP_BAUD        B9600

After correcting those just type make all.  No reason to install this in
a bin directory but you can if you want to.  To run it type

./csd -D

and it should start running in terminal mode emulating a really dumb ASR
33 or 35 Teletype.  The -D signals Debug mode and it will report what it
is doing.  Each debug line is prefixed by "csd:"

Booting:

The boot process is straight forward.  First you toggle the boot loader
into the PDP-8:

0025    Load
6031    Dep
5025    Dep
6036    Dep
7012    Dep
7010    Dep
3001    Dep
2032    Dep
5025    Dep

I suggest you then verify that it is correct before you run it.  The
reason for this is it self modifies and the OS/8 boot process overwrites
the bottom 1k of field zero.  When it is correct you start it with:

0025    Load
Start or Clear and Continue depending on the machine.

Now the PDP-8 is sitting there waiting for the csd server to send it the
boot codes.  You do this one of two ways.  You can start csd with the -B
option or start csd and once it announces it is in terminal mode you can
press shift F12.  If everything is working you will get an OS/8 dot
prompt after a couple of seconds.  OS/8 is now up and running.

In this version of csd the boot image is the file csd0.img which is
provided.  The disk images attached to csd will only be updated when you
leave the server by pressing the F1 key.  This means that all the work
you did in OS/8 has not been saved until you exit.  This was a decision
I made to prevent premature failure of the Micro SD card on the PI.  At
some point I will add an option to allow for immediate updates.

Supported Devices:

The file csd0.img is mapped to SYS: and CSD0: while the file csd1.img is
mapped to CSD1: and DSK: is pointed at that.
The server will also look for csd2.img and csd3.img and if found will be
available as devices CSD2: and CSD3: respectfully.  The file rk0.img if
found is mapped to RKA0: and RKB0: and must be a simh RK05 or one of
Kyle's Serial Disk images.

The csd images are maximum size OS/8 file systems.  They are 4095 blocks
long which on a non system platter gives a usable space of 4088 blocks.
This is 1046528 words or 1569752 bytes when packed 3 bytes every 2 words.
With extra code OS/8 could have mapped a device size of 0 as 4096 blocks
but this would have added extra complexity for little gain so I don't
fault the developers for making this decision.

Known to work on:

The server is known to work on a Raspberry Pi 3B running the Raspberry
Pi Linux 5.15.32. That is what I used to develop it.  I expect pretty
much any Linux distro will work.

It is expected that it will work under most of the BSD Unix variants and
it should be possible to run it under Version 7 Unix with just a little
work.  I believe it will also work under Minux version 3.

The handler has been run on a PDP-8/e with an M8655 console port running
at both 9600 and 19200 baud.
The handler has been run on a PDP-8/a with an M8315 CPU card and the
console port on the M8316 Option 1 card at 9600 baud.

It is expected that the handler will run on any of the Family of 8
machines except for the PDP-5.  More on that later.

The server is known to not work on a very old version of Cygwin running
under Windows Vista (who would have guessed?)  The termios don't let
you put it into raw mode.


Known Issues:

There is a problem with type ahead during server operations like read or
write.  If you type more than one character while the server is
processing a disk request those characters will not be sent on to the
PDP-8.  I have some ideas on how to fix this but that can wait until the
next version.  Also don't press cursor keys or any keys that don't exist
on a teletype as they can trigger this issue.  It happens because of the
way I chose to decode the function key escape sequences.

Control C is not yet decoded during handler operations.  Yes, this will
get added although it does not seem to be an issue that causes any
problems.

It won't work on a PDP-5.  I do plan to fix that but I really don't
expect anyone to ever try it on one.  I do however hope someone does and
for that reason I am going to make changes to the boot loader so it will
work there.  This seems like it should be a trivial change but it is not.
I've already spent a couple of hours looking at it.  It is not clear to
me that OS/8 will run on a PDP-5 as the non resident portion overwrites
the PC memory location when it loads.  I could fix that by preventing
the server from writing location 0 in field 0 but if that location is
actually used by OS/8 then OS/8 would need to be fixed.

Performance:

At 9600 baud a DIR takes about 20 seconds of activity before it starts
displaying.  At 19200 it takes about 10 seconds.

There is a timer constant in the handler that should be tuned for your
machine and baud rate combination called BDTIME.  By default it is set
to 7530 which is for the 8/e at 9600 baud.  Since the 8/e is the fastest
processor and this is the slowest recommended baud rate this should work
on most setups.  But it is not optimum and would be terrible on an 8/s.
I am hoping to make this a value that the boot loader can measure and
patch.  But there is no room and I need a few more words.  Probably
happen at the same time as I fix it to work with the PDP-5.

If you find any problems or just have questions or comments you can
email me.

Doug Ingraham
October 24, 2022

doug.ingraham@gmail.com

I am pretty close to finishing up this first public release. If you see something hideous in the Readme above let me know.
 
That's a very impressive and worthwhile contribution. I'm interested in learning how well CSD performs at 115K baud or with one of the USB KL8E interfaces.
 
I'm interested in learning how well CSD performs at 115K baud or with one of the USB KL8E interfaces.
It is essentially the same speed as Kyle's serial disk as far as performance goes. A DIR should take around 1.5 seconds at 115200 baud. This is for a directory with around 100 files and is the delay between you hitting return and first entry display. Kind of a weird benchmark actually.

There is no room for it in the SYS handler but I am going to do a 2 word to 3 byte compression across the data link in the non sys handler at some point. which should speed it up by 25% (except for SYS:).
 
I have been working on a document called Cables which discusses RS-232 cabling and the interfaces on the different models of PDP-8.

My concern is that most of the PDP-8 console interfaces are configured to talk to a Teletype model 33 or 35 at 110 baud over a 20 ma current loop. What we need is RS-232 at 9600 or faster baud rate. Many years ago I built a board for my Straight 8 that lets me do 38400 although it is not reliable at that rate. It works at 9600 baud fine. But this cannot be replicated exactly as the parts that I used are no longer available.

David Gesswein has photos on his website of a board that converts the signals to RS-232 but this does not address the higher baud rate issue.

For the PDP-8/s the console is a negibus device built into the base of the Teletype. The issues are similar to the Straight 8. Warren Stearns made an RS-232 converter for the Rhode Island Computer Museum which they are still using but there is no documentation for it and I have looked through the disk image of Warren's laptop for it.

For the 8/i, 8/l, and PDP-12 Vince Slyngstad has worked out a solution although he doesn't have any boards to sell at the moment. DEC documented a way to make the 2nd serial port a high speed RS-232 interface and since the console and the second port are the same except for the device code those changes could be made to the console port if you could find the cards. And those changes should also apply to the 8/i and 8/l since those parts of the machines are the same.

For the Omnibus machines the M8655 will operate at 9600 (some will operate at 19200) and the M8650 can be configured to operate at 230.4k baud with appropriate modifications.

I think there are also a couple of homebrew solutions to the high speed serial port issue for omnibus but a web search failed to show anything relevant in the first few pages of search results.

For 8/a machines equipped with the M8316 option 1 board the console port operates at 9600 baud and works fine. The schematic shows a switch setting that gets 19200 baud but it also says not to use that setting. I have not looked into why exactly they say not to use it but probably the UART won't reliably go that fast.

If you know of a higher speed RS-232 solution for any of these machines that I can recommend, please let me know.
 
Mentioned on the what did I do to my PDP-8 today thread I tested Console Serial Disk using my shiny new Raspberry Pi 400. This works fine and is what I am recommending as the server hardware if you don't have something that will already work. I will be bringing my 8/e and the Rpi400 to demonstrate to VCF-MW.
 
My concern is that most of the PDP-8 console interfaces are configured to talk to a Teletype model 33 or 35 at 110 baud over a 20 ma current loop. What we need is RS-232 at 9600 or faster baud rate.
Loads of fun stuff to think about there. There are a few components of every PDP-8 serial interface:
The Baud Rate Clock.
The Recieve half-UART.
The Transmit half-UART.
Device Decoding and Bus interface.

The last of these problems needs to be solved for each of: Omnibus machines, Posibus machines, and Negibus machines.

I believe VT78 and DECmates have a solution of some sort already, though I haven't actually tried to use them.

I see the 8/S as mainly a packaging issue for what is essentially the straight-8 case. That said, I do think that a separate backplane is awfully resource intensive, and would suggest packaging it to plug directly into the Negibus. That way the backplane connectors at the end of the user's Negibus have something to do, and the expense of trying to re-manufacture connector blocks is avoided.

I'm working currently (again/finally) on serial solutions for Omnibus machines.

I have a new version of the baud rate generator that's going in there, and I'm pretty happy with the dynamic range of bauld rates supported -- from 230,400 on down to 110. It is quite easy to implement with either LSTTL or CPLD. It's also quite suitable for use in Posibus machines, though Negibus machines would need a level converter or two.

Similarly, the half-UART implementations are essentially good for either Positive logic case, and would need level converters to be directly compatible with Negibus machines.

There are plenty of Device Decoder solutions for Omnibus and Posibus, and a general level converter solution would make them available on Negibus too.

As mentioned, the PDP-12 has a built-in solution, essentially using the same componenets as the console interface. The exception there is that they have a better solution to the baud rate generator. I'm using a simple TTL can oscillator in mine, connected directly to the edge connector and driving the divider to run at 115200 baud.

One of the things I'll try to do between now and VCF-MW is to update the baud rate generator board and see if I can make the revision available.

The Posibus and Negibus solutions do generally have a connector card to connect to the actual terminal. I think the thing to do in the long run may be to use the opto-isolated design I have for low speed and current loop interfaces, and create an M850 (IIRC) replacement for the high speed EIA interface. Previously I had tried to use BC01V cabling to choose the interface, but I'm not sure how easy it will be to get that working properly at the higher baud rates. (The optos are currently too slow, so the high EIA speeds can't use them.)

Vince
 
So is your original solution for the 8i the W076 and the M452? I have your original you sent me long ago and the M452 is just the board itself. Is this useful in the short term if you can't get yours ready?
 
So is your original solution for the 8i the W076 and the M452? I have your original you sent me long ago and the M452 is just the board itself. Is this useful in the short term if you can't get yours ready?
Yes, those replacements are fine, for what they do. The opto-isolators top out at about 38K baud, though, so they don't go as fast as one might want for SerialDisk or the like.
 
Back
Top