• Please review our updated Terms and Rules here

OS/8 questions

thunter0512

Veteran Member
Joined
Sep 27, 2020
Messages
859
Location
Perth in Western Australia
I have been puzzled for a while about the delay of about 1 - 2 seconds in the output of the OS/8 DIR command for larger directories.
This delay is very pronounced when your serial speed is 9600 bps or faster.

Interestingly on my PDP-8/E with AC selected for display you also see some distinct pattern of lights during this delay.
During the delay all AC bits are clear and all address bits are on.

While running from RX01 floppys I never questioned this because I assumed the system was simply reading more directory sectors.
Now I am running OS/8 from an RK05 and the delay still exists.

The hard-sectored RK05 has no interleave, so reading consecutive sectors will have the penalty of about 40 ms (for a full rotational delay).
Of course I wouldn't notice the 40 ms which is insignificant compared to the 1 - 2 seconds delay in the DIR output.

I also noted that the read light on the RK05 is off during this 1 - 2 second delay.

This delay exists when running OS/8 on SIMH (PiDP-8/i), the SBC6120 and a real PDP-8/e.

Does anyone have an explanation for this little mystery?

Thanks
Tom
 
If you get SerialDisk running on your system, you can watch all of the transactions taking place in real time on the server side. I don't have a running system in front of me to show that at the moment, unfortunately.
 
I have been puzzled for a while about the delay of about 1 - 2 seconds in the output of the OS/8 DIR command for larger directories.
I'd guess there is some processing/sorting/formatting being done by DIRECT.SV that takes longer when there's more file names. What / options (if any) are you using? What's the maximum number of file names allowed on an OS/8 file system?
 
I am intrigued by this question. I have not played with a machine with a fast disk since the late 70's. And at that time I was using a teletype as the console so you tended to avoid doing things like listings when you could. So I don't remember the delay. But I do see a delay when using console serial disk as the disk at 19200 baud. Like Kyle's Serial Disk I can put CSD in debug mode and watch all the disk activity. The directory is found in blocks 1 through 6 where each block is 256 words. I am not at home so I can't just go try stuff. Typically an extra word is specified ti hold the date field and this makes the maximum possible number of files 240 per device. There are a maximum of 40 per block. I expect you are seeing the delay every 40 files being displayed. Reading 256 words at 9600 baud should be around half a second. And it does take longer than that.

Yeah, what the heck is it doing?
 
I'm seeing a much shorter delay. With an 8/M and RX02 emulator. Have two Putty windows running, one is the OS/8 console connected to the M8650 and the other connected to the RX02 emulator where I can see a log of the controller-to-disk commands. When I enter DIR<enter> there's a stream of reads on the RX02 log followed by a delay that's I think about 0.3 seconds before the directory listing appears. It's too fast for me to catch the state of the address lights.

However, related to this:
"During the delay all AC bits are clear and address bits show 7575 but there is activity in address lights 175 as those are dimmer then the 7400 lights."

After the directory listing appears on the OS/8 console window, there is about a 2 second delay and then the screen clears and I only see the "." prompt. I need to scroll up to see the directory listing.
I had assumed there was an escape sequence, maybe ESC [ 2 J or something, that was clearing the screen. I haven't looked with a scope or line analyzer to know for certain.
During the time between when the directory appears and before the screen clears, I can see roughly 7575 in the address lights.
Do you think it's possible that your terminal emulator is buffering the directory listing, and then displaying it when the maybe a clear-screen escape sequence is sent? It would be odd behavior, but there are some coincidences.
 
Seem to remember a TTY PAUSE setting In OS/8. Could this be it?
Thanks for the info. This is exactly the cause of the weird delay.

Here is what I found:

Code:
       .SET TTY PAUSE          - causes the terminal  to  pause  every
                                 "height" lines for ease of reading.

       .SET TTY HEIGHT 24      - tells the handler the screen  has  24
                                 lines

Unfortunately I did not find a "SET TTY UNPAUSE", but you can get close by "SET TTY HEIGHT 4095" which is the maximum the command allows.
The default height is 20.
 
Thanks for the info. This is exactly the cause of the weird delay.

Unfortunately I did not find a "SET TTY UNPAUSE", but you can get close by "SET TTY HEIGHT 4095" which is the maximum the command allows.
The default height is 20.

Doug and I also experimented with SET TTY PAUSE and found it to be causing a second or so of delay every 24 output lines or so.

SET has a "NO" modifier which can be used to unset things:
Code:
.SET TTY NO PAUSE
 
On some systems, you can type:
Code:
.HELP SET
Code:
        SET.SV
 
@CALLING COMMANDS:
.SET DEV PARAMETER(S)
.SET DEV NO PARAMETER(S)
 
@PARAMETERS:
HANDLER         CHANGE DEVICE HANDLERS WITHIN BUILD
READONLY        DECLARE DEVICE TO BE READ ONLY
FILES           DECLARE DEVICE TO BE FILE STRUCTURED
DVC             CHANGE DEVICE CODES
VERSION X       CHANGE VERSION
LOCATION N[=M]  EXAMINE OR CHANGE LOCATIONS
LV8E            DECLARE LINE PRINTER TO BE AN LV8E
LA8A            DECLARE LINE PRINTER TO BE LA180 ON DKC8-AA
LA78            SAME AS .SET LPT NO LA8A
WIDTH N         SET WIDTH OF LINE PRINTER OR TTY
LC              DECLARE LINE PRINTER OR TTY TO HAVE LOWER CASE
ECHO            RESTORE TTY CHARACTER ECHOING
PAGE            RESTORE TTY ^S AND ^Q FACILITIES
TAB             IN TTY PRINT TABS (DON'T SIMULATE WITH SPACES)
FILL            IN TTY APPEND FILL CHARACTERS AFTER TABS
FLAG            IN TTY FLAG LOWER CASE CHARACTERS
SCOPE           ERASE CHARACTER ON TTY RUBOUTS
ESC             PRINT ESC(ASCII 033) WITHOUT CONVERTING IT TO $ SIGN
ARROW           PRINT CONTROL CHARACTERS WITH UP ARROW (E.G. ^C, ^S)
HEIGHT [M]      SET TTY SCREEN HEIGHT
PAUSE [N]       SET TTY PAUSE TIME
COL N           SET DIRECT TO USE N COLUMNS (.SET TTY COL 2)
CODE N          CHANGE TTY IOTS OR CARD READER CODES
PARITY EVEN/ODD SET MAGTAPE PARITY
OS8             DECLARE SYS TO BE OS/8
OS78            DECLARE SYS TO BE OS/8
INIT XXXXX      CAUSE SYS TO EXECUTE XXXXX ON BOOTSTAPPING
(I'm pretty sure there's a typo in the OS78 line.)
 
Last edited:
I found some info about "SET" on David Gesswein's website at: https://www.pdp8online.com/os/os8/os8_general.shtml
That one I had not seen before. Like many searches it was obscured by stuff I don't care about.

Strangely I did not find the "SET" command in the OS/8 Handbook from 1974.
I think SET might be mentioned in the chapter about the CCL but it is not in the index. I looked in the index. Vince thought it was mentioned although I don't remember seeing it.

Is there a PDF of a later revision of the manual somewhere?
I hope someone has a good answer for this. It is clear that I need to add a section to my book for set and how it interacts with at the very least the TTY handler. I hope I don't get to figure it out by looking at the sources or reverse assembly for SET if the source is not available. SET appears to be able to patch the TTY handler. It isn't clear if it does both the version in memory but it certainly does the one stored in the system area.
 
I found some info about "SET" on David Gesswein's website at: https://www.pdp8online.com/os/os8/os8_general.shtml
Strangely I did not find the "SET" command in the OS/8 Handbook from 1974.
Is there a PDF of a later revision of the manual somewhere?
I think that is the exact document I copy-pasted from :).

My OS/8 Handbook doesn't mention SET either. It seems to be best documented in OS/78, which makes me wonder if SET appeared in the OS/8 extensions or something.
 
I hope someone has a good answer for this. It is clear that I need to add a section to my book for set and how it interacts with at the very least the TTY handler. I hope I don't get to figure it out by looking at the sources or reverse assembly for SET if the source is not available. SET appears to be able to patch the TTY handler. It isn't clear if it does both the version in memory but it certainly does the one stored in the system area.
We do have SET source code, for at least a couple of versions. I've looked at it a little, and it isn't too hard to follow. The worst bit is all the arcane knowledge that's in there. So you might be looking at code to set magtape parity, but the "why" of which blocks and offsets are being peeked and poked remains obscure.

I think it should suffice for SET to unload the copy in OS memory somehow before the return. Maybe it can poke the tables in field 1 for that?
 
Back
Top