• Please review our updated Terms and Rules here

PDP-8 OS handlers

DougIngraham

Veteran Member
Joined
Oct 2, 2019
Messages
647
Location
Rapid City, SD USA
I had an idea about combining console and serial disk operations over a single serial port. I wrote some code and posted it in the What did I do to my PDP-8 today thread. It was proposed we spin off a new thread for this topic so here it is. Have at it!

To start it off I will present how multiple entry points for multiple drives or devices have been done and a new approach I thought of to save some code.

This is a paraphrase of the entry decoding in the TCO8:
Code:
DTA0,    VER
DTA1,   ISZ DTANO
DTA2,   ISZ DTANO
DTA3,   ISZ DTANO
DTA4,   ISZ DTANO
DTA5,   ISZ DTANO
DTA6,   ISZ DTANO
DTA7,   ISZ DTANO
D400,   400             /EXECUTES AS A HARMLESS AND
        CLA CLL
        TAD DTANO
        CMA
        TAD DTATAD      /GENERATE "TAD DTAN" WHERE DTAN IS THE ONE THAT
        DCA DTANO       /WAS CALLED.
        CLA CLL CML RTR /AC <- 2000
        TAD DTANO       /ALSO GENERATE "DCA DTAN" SO WE CAN RESTORE IT
        DCA DTADCA
DTANO,  0               /GET CALLING ADDRESS.
        DCA DTA         /SAVE IT
        TAD DTAISZ
DTADCA, 0               /RETRORE ENTRY POINT
DTAISZ, ISZ DTANO       /BUMP DTANO FOR VARIOUS GROOVY REASONS
                        /WHICH WILL BE APPARENT LATER


DTATAD, TAD D400
All of that is just to figure out which entry point was used so it can be mapped to a device. And while self modifying code is a time honored staple of the PDP-8, it generally does not lend clarity to the code. Here is my innovation which I hope to use in the next version of serial disk:
Code:
UNCALC, -DTA0           /TAD THIS WITH VALUE AT START TO GET THE UNIT NUMBER
DTA0,   VER
DTA1,   JMS START
DTA2,   JMS START
DTA3,   JMS START
DTA4,   JMS START
DTA5,   JMS START
DTA6,   JMS START
DTA7,   JMS START
FIXUP,  JMS START
START,  .-.             /SUBTRACT THE ADDRESS OF DTA0 FROM THIS TO GET THE UNIT NUMBER
        CLA CMA CLL     /AC AND LINK ARE IN UNKNOWN STATE UPON ENTRY.  WE NEED -1
        TAD START       /GET ADDRESS OF CALLERS ARGUMENT LIST
        DCA ENTADR      /SO WE CAN GET THE ARGUMENTS AND REPLACE THE JMS START
        CDF 00          /NOW WE CAN INDIRECT TO THIS FIELD
        TAD I ENTADR    /GET POINTER TO ARGUMENT LIST
        DCA ARGADR      /SAVE POINTER TO CALLERS ARGUMENTS
        TAD FIXUP       /PUT THE JMS START BACK IN THE TABLE
        DCA I ENTADR

/CODE TO FETCH THE ARGUMENTS GOES HERE

ENTADR, .-.             /POINTER TO CALLED ENTRY POINT
ARGADR, .-.             /POINTER TO THE CALLERS ARGUMENTS
While mine is only a few words shorter, even 1 word difference in a handler is a huge difference. I like to think it is easier to understand as well although I might be biased in this regard. When used with a smart server all you need to do is an RDF to get the callers field and pass that and the value at start to the server. The server can read memory to get the address and put the JMS START instruction back. Although it would be better if the handler code could put the JMS START back in the table as the time spent doing this over a 9600 baud link would be nearly 8 milliseconds. The server would know immediately from the address what that entry point is for. It does not have to be a virtual disk, it could be any kind of device.

I would like to learn more about the DMS handlers. I have always suspected that the OS/8 system handler concept was mostly copied from DMS. Can you suggest a document I can look at?
 
Splash :)...

I am upstairs at the moment resurrecting my Cromemco Z2. It lives! Just added the DPU (Z80 and 68000 CPU card). Got it running in Z80 mode at the moment.

When I go downstairs I will post a link to the DMS documents I have. The documentation was very (very) poor and I had to read it at least 20 times before the light bulb started to come on!

Dave
 
Turns out I have physical copies of the first two of those. I have never gotten around to reading them because I never needed to use that product.

The third one is the gold that let you figure it out.

I look forward to reading through your handler.
 
Doug, I commend your efforts for unifying SerialDisk with the main console serial port! This is something I wanted to do for a while.

I figured an appropriate solution would be to send "+++" rather slowly and deliberately to initiate a SerialDisk transfer. I thought that would be a sure way to prevent any other serial stream from getting interpreted as a command to the disk server. Yes, this would slow things down for an already slow process...

I suppose some other very uncommon sequence could be selected that doesn't need a delay between characters, but I'm not sure how I would go about picking it given the propensity for binary transfers.

Kyle
 
Turns out I have physical copies of the first two of those. I have never gotten around to reading them because I never needed to use that product.

The third one is the gold that let you figure it out.

I look forward to reading through your handler.
I'll start perusing those too. I have never worked with DMS, but being a pdp-8 fan maybe I can help somehow.
 
Doug, I commend your efforts for unifying SerialDisk with the main console serial port! This is something I wanted to do for a while.

I figured an appropriate solution would be to send "+++" rather slowly and deliberately to initiate a SerialDisk transfer. I thought that would be a sure way to prevent any other serial stream from getting interpreted as a command to the disk server. Yes, this would slow things down for an already slow process...

I suppose some other very uncommon sequence could be selected that doesn't need a delay between characters, but I'm not sure how I would go about picking it given the propensity for binary transfers.
We talked about this very briefly years ago. I think what happened to me was I decided that it needed to be done for the pre-omnibus machines. I have two machines and Vince has at least 5 and I think you have an 8/i making it 8. It just isn't practical to add a serial port to those machines. Possible yes, practical not really. A lot easier on Posibus but still not what I would call fun.

Doing a timed escape sequence would be safest but I don't think it is necessary. In the general use case the 8 does not send unusual control characters. The operator has to do something to cause binary data to be sent to the console. If you are going to send binary data on purpose you can put the server into a mode where it will ignore it. Besides, we don't have room to put anything like a timed escape sequence in the sys handler. It is going to be very tight as it is. Assuming no more bugs, there are 6 words free when I move the transient variables to the data break addresses at 7750 through 7755. And I would like to support 8 virtual disks with the sys handler. Looks like I might have to settle for 4.

Consider this. What will happen is that the handler will send a wakeup character between 020 and 027. And then a 12 bit pointer to one of several addresses in the handler. These addresses must be 7607 and up to 7 more very specific addresses in the handler. If the server sees something other than what it expects it can send a control C or if it gets a legit handler call it can force a jump to 07600 and go back to the command prompt while reporting what it just did to the operator.

But we will see how this all comes out. It may be that I am overlooking something critical.
 
One option would be to create a special packet format that would make it easy to discern serial disk and console packets. The SerialDisk server, based on the packet type, would either echo the data to the "console" or handle a serial disk request.

For example:

SOH
Packet Type (for example 0x00 for console and 0x01 for serialdisk)
Data (either console data or serial disk data depending on the packet type)
EOT

The SOH & EOT would have to be escaped (substituted) to allow for binary data.

That way you could add additional data types for printer, reader/punch, etc,
 
How would you ensure normal PDP-8 applications packetize the data for console operations? That seems like a lot of work and would break lots of applications, unless I'm missing something.
 
One option would be to create a special packet format that would make it easy to discern serial disk and console packets. The SerialDisk server, based on the packet type, would either echo the data to the "console" or handle a serial disk request.
This can't be done without re-writing everything that talks to the console. It would be a good idea assuming programs made an OS call in order to write something to the console but they don't.

What I have decided on is for the serial disk console handler to switch to disk mode when any 020 through 027 codes are sent. These should not be sent by anything that isn't printing binary data to the teletype punch. For everything except punching tape the 8th bit is supposed to be set. A normal program that wants to send one of those codes for some reason should send them as 0220 through 0227 which are CTRL P through CTRL W. I just know that someone is going to ask about CTRL S and CTRL Q which are traditionally used for software flow control. And the answer is that those codes are only required in the other direction. I think the Super TTY handler responds to those when sent from the console keyboard. The teletype has no idea what to do with them and if you sent them would just wiggle the type cylinder.

The only thing that should send the 020 through 027 codes is the combined Serial Disk handler. I suppose if you want to you could send these codes and get the SD server to do something. But it would be easier to just call the handler.
 
The packetizing and de-packetizing of the data would be done by the TTY and Serial Disk drivers in OS/8 making it transparent to any OS/8 applications.

On the serial disk server side the packet type would determine whether the data is sent to the serial disk data code or what ever is added to serial disk for terminal emulation.

Does that answer your question?
 
I can see what you are both saying.

If all programs that are run under OS/8 uses the OS/8 TTY driver - then a modification can be made to the OS/8 TTY driver to 'packetise' the output character.

However, if this is not the case (for example, loading and running CHEKMO-II or one of the MAINDEC-08s via OS/8), then this will fail - as the program(s) directly manipulate the console serial port once executed.

I suspect Doug is looking for a solution that will work in both stand-alone and OS/8 mode?

Dave
 
But nearly all OS/8 applications don't use a TTY driver for console communications. That driver is completely optional in OS/8.

For console communications, I will be so bold as to say *every* application uses TLS, TSF, KSF, and KRB directly, without relying on some other driver.

The only time the TTY driver is used, at least in my experience, is for loading or printing tapes to the console teletype.
 
But nearly all OS/8 applications don't use a TTY driver for console communications. That driver is completely optional in OS/8.

For console communications, I will be so bold as to say *every* application uses TLS, TSF, KSF, and KRB directly, without relying on some other driver.

The only time the TTY driver is used, at least in my experience, is for loading or printing tapes to the console teletype.
If this is true than the virtual console idea cannot work.

The only way for this to work is to trap (capture) all of the console IOT instructions and redirect them to the virtual console code.
 
The packetizing and de-packetizing of the data would be done by the TTY and Serial Disk drivers in OS/8 making it transparent to any OS/8 applications.
This won't work for 2 reasons. The first and most important is that most programs don't use the TTY handler to send data to the console. Instead they have their own subroutine that talks directly to the hardware and looks something like this:
Code:
PUTCH,  .-.             /PUT CHAR IN AC ON THE CONSOLE.
        TLS             /SEND CHAR
        TSF             /SKIP IF CHARACTER HAS BEEN SENT
        JMP .-1         /WAIT FOR IT TO COMPLETE
        JMP I PUTCH     /RETURN
While not the most efficient way to go it is a lot easier to call than using the TTY handler. The TTY handler requires that characters be packed in a particular format. Three bytes into 2 words and some multiple of 128 words. The sequence is terminated by a CTRL Z character or the end of the 128 word buffer.

The second reason is because there is no room in the handlers to add this. A one page system handler is entered at 7607 and its last word is 7643 which is 93 words. It can use the three cycle data break addresses from 7750 through 7755 for transient variables. This is 6 words and by transient I mean you cannot store data there that needs to be maintained between handler calls. Going to a two page system handler would give you an additional 128 words which resides in the last page of Field 2. This is not a usable alternative because so few of the oldest machines have more than 8k. The one page non system handler gives you a full 128 words to work with. But that does not help unless the machine has some way to boot other than serial disk.

I hope that makes it clear why you can't packetize the console data even though it would be a good idea if you could.
 
If this is true than the virtual console idea cannot work.

The only way for this to work is to trap (capture) all of the console IOT instructions and redirect them to the virtual console code.
It is true but I think it can be made to work anyway.

On machines with an M837 card you could probably trap all the IOT instructions but I don't think you could do this in a way that would allow it to be invisible. Certainly not on an 8k machine.

Again, the way I am planning on doing this is the serial disk server starts up and it is in console mode. It will accept characters from the 8 and display them on the screen. It will take characters from the keyboard and send them to the 8. It will interpret the things that need to be interpreted like carriage return (0215) and linefeed (0212) which are really the only two control codes a teletype understands. And it will look for the 0020 through 0027 codes that the serial disk handler sends to switch to disk mode. When the disk mode commands are complete it will go back to console mode.

If I was trying to make this into a commercial product this would not be good enough. But the only people who will be using it are hobbyists and an occasional museum. We don't have any issues of internet security to be concerned with. There are no secrets to steal here. And the tech is old enough that I am pretty sure the Cylons can't take it over.
 
But nearly all OS/8 applications don't use a TTY driver for console communications. That driver is completely optional in OS/8.

For console communications, I will be so bold as to say *every* application uses TLS, TSF, KSF, and KRB directly, without relying on some other driver.

The only time the TTY driver is used, at least in my experience, is for loading or printing tapes to the console teletype.
Yeah, even PIP talks directly to the console.

I know when my Straight 8 was being used for its original purpose they would spool up the output by writing it to a file instead of the console. Then they had the option of copying it to a tape and taking it into the room next door to print on the 1000 line per minute printer or printing it on the console at night when nobody was around.

I consider it one of the largest mistakes that OS/8 didn't include a system call with a bunch of helper functions like talking to the console or reading a character from the keyboard. Stuff that every program needs.
 
Doug,

How will you trap application I/O calls if each application has it's own console input/output routines.

I think P?S/8 would be the ideal operating system for the virtual console due to it's I/O abstraction.
 
He doesn't.

As for as I can tell (Doug, please correct me if I am wrong) he lets the application program 'do its thing with the IOTs for the console' unmodified. When the application program wants to use the disk - the first thing he does is to wait for at least one character time to permit any output console character that is 'in flight' complete first - then he processes the virtual disk transfer.

The console and disk usage for the serial port never, therefore, conflict or overlap as a result.

Dave
 
Back
Top