• Please review our updated Terms and Rules here

PDP-8 OS handlers

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
464
Location
Rapid City, SD USA
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.
 

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
464
Location
Rapid City, SD USA
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.
 

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
464
Location
Rapid City, SD USA
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?
 

vrs42

Veteran Member
Joined
Nov 24, 2009
Messages
655
Location
Beaverton, Oregon
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
 

thunter0512

Experienced Member
Joined
Sep 27, 2020
Messages
418
Location
Perth in Western Australia
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.
 

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
464
Location
Rapid City, SD USA
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.
 

thunter0512

Experienced Member
Joined
Sep 27, 2020
Messages
418
Location
Perth in Western Australia
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.
 

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
464
Location
Rapid City, SD USA
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.
 

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
464
Location
Rapid City, SD USA
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.
 

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
464
Location
Rapid City, SD USA
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.
 

DougIngraham

Experienced Member
Joined
Oct 2, 2019
Messages
464
Location
Rapid City, SD USA
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!
 
Top