DougIngraham
Veteran Member
Correct Dave.
The only time there can be an issue is if the application talking to the console sends the wakeup command which is unlikely. The handler puts the console port back the way it was when it was called so the console looks the same after as it was before.
There isn't even a delay if the TSF flag set when the handler was called. And I wait a second character time before I check the keyboard to make sure I catch that after the serial disk server should have switched to serial disk mode. The sequence of events is as follows.
There are programs that use interrupts. The FTRS in FORTRAN comes to mind. But they universally turn them off when they call OS/8 as this is a requirement.
I hope that is clear. Since it isn't finished I may find I need to add or can delete some of that but for the most part the above is the idea I am shooting for. I've only been thinking about this on and off for 4 or 5 years now.
The only time there can be an issue is if the application talking to the console sends the wakeup command which is unlikely. The handler puts the console port back the way it was when it was called so the console looks the same after as it was before.
There isn't even a delay if the TSF flag set when the handler was called. And I wait a second character time before I check the keyboard to make sure I catch that after the serial disk server should have switched to serial disk mode. The sequence of events is as follows.
- The handler is entered. The user program may or may not have a character in transit to the console.
- Wait for up to a character time for the TSF flag to be set. The serial disk server will process this last character if there is one in console mode. OS/8 does not use interrupts so nothing else can affect this.
- Remember the state of TSF so we can put it back when we are done.
- The handler sends the Wakeup code of 0020 through 0027. Think of this as an escape code for the disk.
- The handler sends the address of the application that called the handler.
- Read the state of the keyboard flag and the character in the input buffer and save this state. At this point the serial disk server has been in disk mode for 2 character times and will no longer send anything else from the console keyboard.
- Send the keyboard state to the server since it will have to re-send the character at the end to put the character back in the keyboard buffer. (I am not sure this is necessary.)
- Handler goes into command mode where it does what the server tells it to
- One command is Read a block of memory and send it to the server which can be thought of as a disk write.
- Another command is Write a block of memory which can be thought of as a disk read.
- The final command is to transfer control to a specific location in memory with the AC loaded with an arbitrary value. This last one will clear the TSF flag if necessary to match the state at call. The handler will then wait for the KSF flag to be set indicating that the serial disk server has resent the code that was in the buffer at call. It will clear the KSF flag if that was the state upon entry. Finally it will load the AC and perform the jump. Most of the time this will be the return to the handlers caller.
- The server at this point goes back into console mode.
There are programs that use interrupts. The FTRS in FORTRAN comes to mind. But they universally turn them off when they call OS/8 as this is a requirement.
I hope that is clear. Since it isn't finished I may find I need to add or can delete some of that but for the most part the above is the idea I am shooting for. I've only been thinking about this on and off for 4 or 5 years now.