What did I do to my PDP-8 today.

[bqt]

BASIC.UF is an optional file that contains any user written/defined functions that you want to be able to access from your BASIC program.
It don't even need to exist.

I wonder - this serial disk thing... Do people know/understand how things work in OS/8 enough to add a new device properly? Does the serial disk appear to look like an exsting device (like the RK05)? Does it then also have all the signatures of that driver, so that other programs like PIP understands it? PIP have a list of all known devices, along with the size of each one, so that a zero of the device creates a proper directory mapping all of the disk. RESORC is another program that actually knows more about devices, and also picks through the device driver to figure out what device it is.
There might be a few more, I can't really remember. But it's not enough to just write a device driver if it is for a device that is supposed to have a file structure on it.
OS/8 is a little primitive in that way. Not enough information is kept around in some common place. Instead various programs that needs extra information have it in themselves...

[DougIngraham]

I wonder - this serial disk thing... Do people know/understand how things work in OS/8 enough to add a new device properly?

Kyle figured most of it out when he wrote it. I wrote a handler in 1976 and it was a major pain because I didn't have enough of the documentation and I had no sources to look at. I had to reverse engineer the handlers we used. It is for this reason that I have been working on a book that details OS/8 ( and of course PS/8 ) handlers. I will be getting back to that soon.

Does the serial disk appear to look like an existing device (like the RK05)?

Kyle chose to use the RK05 geometry so that disk images could be directly mounted. For SYS the device type name is SDSK with three entry points supported. SYS of course and SDA0 and SDB0. There is a table of device codes that RESORC uses. The codes from 000 to 037 are allocated to DEC devices and the range of codes from 040 to 077 are for user defined devices. Kyle chose to use 64. I don't know why but it really doesn't matter. The other critical thing in a block structured handler is the entry point word. For DEC devices there are specific places where the entry points need to be for that device. For user defined handlers this is not important except that all handler entry points in a system must be unique. The best reason I could find for this is that the USR caches the last directory entry read from a device and it keeps track of this using the entry point somehow. If two entry points in different handlers have the same relative offset then the USR could use the other devices directory and chaos will ensue. Kyle also wrote boot code which build will place on an image and allow you to boot. I believe Roland's boot board has the boot0 code but you could toggle it in if you wanted to. I punched it in once on my 8/a.
For the Non-sys handler it is also called SDSK with four devices supported. SDA0, SDA1, SDB0 and SDB1. I have a version of serial disk that Charles Lasner massaged which allows for 8 entry points but I don't think anyone has ever tried it. To do so would require changes to the server. I started making changes but it was not an easy change to make on the existing code so I decided to write it over from scratch with 8 devices in mind.

Does it then also have all the signatures of that driver, so that other programs like PIP understands it? PIP have a list of all known devices, along with the size of each one, so that a zero of the device creates a proper directory mapping all of the disk. RESORC is another program that actually knows more about devices, and also picks through the device driver to figure out what device it is.

No. PIP would need to be patched in order to understand how to zero this device correctly. There are instructions about this in one of the DEC documents. I will need to put this info in my book.

My temptation would be to reuse the RK05 device names and handler entry points so that PIP would not need to be patched. This fails spectacularly if you also want to have a real RK05 on your machine at the same time. That is not an issue with the chosen naming scheme.

If you are interested the serial disk sources are on github.

Here is a link to the google doc of my book as it currently stands. OS/8 handler info
I have not inserted many of the example handlers as I am still working on and testing them. Comments and criticism are welcome!

[vrs42]

Wasn't someone asking somewhere recently about 101 BASIC Computer Games?

Since I had become aware of it and now it became feasible for me to do it reasonably, I have reconstructed
DECUS-BASIC8-55. Which is to say, you can find the games here:
http://svn.so-much-stuff.com/svn/tru...ecus/basic8-55
You can also get there from http://so-much-stuff.com/pdp8/softwa...decus-basic8-1 by scrolling down a bit.

Some of the source documents were mangled, so I had to do some repairs. Only zoop is completely reconstructed (from the OCR) though, so I think all or almost all of it is in good shape now. They came from OS/8 media, so I think they should run there.

I used the manual to determine which were missing, so there are programs there not listed in the abstract. Mostly alternate versions -- salvo and salvo1, etc., where they seem to have lost the alternate from the abstract.

Vince

[djg]

The palbart suite comes with a script to fire up SIMH and extract the binary produced by PAL8, and it comes with "correct" binaries allegedly produced this way. I'm not sure all the binaries actually come from the script, as even in the "good" directory, some of those reference binaries are "off" in subtle ways that I wouldn't have expected from PAL8. Then there's another script to run palbart and see if they get the same answer, and if so, the case goes in the "good" directory, otherwise it goes in the "bad" directory.

Vince

I checked. I get identical binaries rerunning my scripts. I did find a couple listing were from edited version of the .pa file where the edits changed the listing but not the binary. Files updated. I wouldn't expect the problem to be simh. Could be what version of pal is used.

http://www.pdp8online.com/ftp/software/palbart/

[bobaboba]

@DougIngram “For the Non-sys handler it is also called SDSK with four devices supported. SDA0, SDA1, SDB0 and SDB1. I have a version of serial disk that Charles Lasner massaged which allows for 8 entry points but I don't think anyone has ever tried it. To do so would require changes to the server. I started making changes but it was not an easy change to make on the existing code so I decided to write it over from scratch with 8 devices in mind.”

In fact I did the 8 entry point non-sys handler which Charles subsequently modified to run on a non-omnibus machine (which I tried to do by simply replacing the BSWs with rotates but it needed more expertise). More or less a hack of the standard DEC multiple-entry-servicing code. I also modded the sys handler to have 4 entries (equivalent to 2xRK05) which for most purposes minimises the number of handlers that need to be in memory simultaneously. The changes to the server side were minimal I thought - only really a matter of replicating the code which recognises which ID the handler has requested and associated file pointers. I use it as standard - works fine.

[DougIngraham]

@DougIngram “For the Non-sys handler it is also called SDSK with four devices supported. SDA0, SDA1, SDB0 and SDB1. I have a version of serial disk that Charles Lasner massaged which allows for 8 entry points but I don't think anyone has ever tried it. To do so would require changes to the server. I started making changes but it was not an easy change to make on the existing code so I decided to write it over from scratch with 8 devices in mind.”

In fact I did the 8 entry point non-sys handler which Charles subsequently modified to run on a non-omnibus machine (which I tried to do by simply replacing the BSWs with rotates but it needed more expertise). More or less a hack of the standard DEC multiple-entry-servicing code. I also modded the sys handler to have 4 entries (equivalent to 2xRK05) which for most purposes minimises the number of handlers that need to be in memory simultaneously. The changes to the server side were minimal I thought - only really a matter of replicating the code which recognises which ID the handler has requested and associated file pointers. I use it as standard - works fine.

This means you must be Bob Adamson per the Charles comments. Thanks for setting me straight. The version found on Github is still the 4 device one from Dec 24 of 2015. Is there another repository with your updates?

I just went back and re-read Charles revisions history. He mentions that you did the update to 4 devices but nowhere is the 8 device support mentioned. I just assumed that Charles did that. Sorry about that.

At some point I will be uploading my modified version and I would hate to leave out your contributions. My version does 3 byte to 2 word mapping over the serial port making it 25% faster. But it has not been tested because this requires the more significant changes to the server side. It was this more than the increase to 8 devices which prompted the rewrite. To clarify, in some places you need to still do the current dual six bit transfers and during the large block transfers the server has to do the two words to three byte packing and three byte to two word unpacking. Unfortunately, the SYS handler has to be quite a bit shorter and there simply isn't enough room to add the packing and unpacking operations. A one page non sys handler is 128 words while the sys handler loses 7 words from the front (down to 121) and 28 words from the end making it have to fit in 93 words. A sys handler can use the data break addresses (7750-7755) for non-persistent temporary storage. What this means to the server is that it has to treat SYS and NON-SYS requests differently. And boot would need to be treated the dual 6 bit way until the transition to the boot2 code loaded from the server. And I wanted the new server to be compatible with the old handlers. So it would need to recognize different wake up codes to identify the handler.

Best Wishes!

[bobaboba]

Thanks Doug, yes that’s me. I don’t have a GitHub account so my hacks emerged first to Michael Thompson to try on the 8/i when he’d failed to get SerialDisk to work on it, and thence to CJL when they didn’t work. If you’re intending to cope with pre-omnibus machines, which would be good, you need to follow CJL’s stuff as (I believe) the TTY I/O stuff needed consideration as well as simply avoiding BSWs.

As an aside I also rewrote a version to operate with the 8/a parallel port which is very quick, but I’ve since sold my 8/a on so that one’s been discontinued as it was model specific. I’ve had intermittent errors trying to run the serial interface (perhaps too) fast although the Raspberry Pi I serve from is only a foot or so from the M8650. I’ve put an extra command (Q) in the server code to allow the pdp8 to shut the pi down cleanly.

Lastly I notice your comments on ^C handling in your write up. I tried for a while to handle it in SerialDisk but had to give up in the end because the handshaking requires both ends to agree that they’re aborting which was just too awkward. I feel it’s untidy to need to rely on the front panel to escape from a software hang.

Bob

[m_thompson]

I don’t have a GitHub account so my hacks emerged first to Michael Thompson to try on the 8/i when he’d failed to get SerialDisk to work on it, and thence to CJL when they didn’t work.

We have been using the non-Omnibus serialdisk on a PDP-12 for quite a while on a 9600 baud serial interface. Works just fine.

[vrs42]

We have been using the non-Omnibus serialdisk on a PDP-12 for quite a while on a 9600 baud serial interface. Works just fine.

Am I being extra thick today, or is there some other repository than Kyle's in which these changes can be found? (I don't see them in Kyle's github.)

Vince

[vrs42]

is there some other repository than Kyle's in which these changes can be found? (I don't see them in Kyle's github.)

I had a conversation with Kyle, and found a copy of both revisions that Michael had sent me some months ago. I'm thinking I should just coordinate with Kyle to make them gnerally available?

Bob, are you OK with that?

Michael, are you still having the interrupt interaction with Fortran on your 8/I? According to my reading of the code you would be.

Vince