• Please review our updated Terms and Rules here

PDP-8 OS handlers

Apple uses the F-keys for a lot of things. When having this switched off, I get:
SERVER: Unassigned function key pressed key=1021
when pressed SH_F12! Should be 1023 like with Linux.
So I changed this in tty.c and now it sends. But it does still on Linux. OK, no matter.
 
gnupublic said:
Doug,
at the moment I'm not quite sure if the "shift F12" problem sits before or behind the keyboard. I will find out.

I hopefully will play with BUILD later tonight.
Click to expand...
The function key mappings are strictly dependent on the terminal emulation stuff. You don't have to look at it for very long to discover that it was designed by evoloution, not some committee in a dark room. I chose that key because it worked on three different setups and it was difficult to hit by accident. None of the ones I tried it on involved any kind of fruit from Cupertino.

Good luck with BUILD. Make backups early and often when playing with it because it is easy to generate an unbootable image.
 
Tested the support for DECtape images. Seems to work. I was able to make a blank DECtape image using the following steps.

Before running the server you need to create a zero length tc0X.img file. I am assuming you don't have anything valuable in tc0X.img.
  1. rm tc0x.img
  2. touch tc0X.img
  3. ./csd
The server should be running in terminal mode. You can boot the PDP-8 if it isn't already running. If OS/8 is already running hit return to get a dot prompt. If it is not running and you have non-volatile memory you can often just restart OS/8 with a 07605 Load address and then Start or Clear Continue. The OS/ 8 dot prompt should appear. Now run PIP and enter

DTA:/Z<=1

This zeros the directory on device DTA: and leaves 1 extra word in the directory for the date field. When you exit out of the server by pressing F1 the image will be written out. This should work to create blank csd images as well.

I am still going over the documentation and will upload a new tarball soon.
 
DougIngraham said:
Good luck with BUILD. Make backups early and often when playing with it because it is easy to generate an unbootable image.
Click to expand...
That was straight forward.
I often use putr in DOSBOX to copy files in DEC media. So I copyed the ID01.PA and VM01.PA in an empty rk05 image formated by putr. I put this rk05 image in the server directory and could read it with csd.
In BUILD it was only a load and insert, then boot. Worked as expected.
 
I don't know how important it is, but I tried to run the toggle-test that does iac-output, to see if I could debug I/O at high baud rates. The CSD server seemed to go nuts trying to do I/O for me. I eventually went back to using gtty to test I/O speeds.

(230.4Kbaud output seems to be fine, but input isn't working for some reason.)
 
vrs42 said:
I don't know how important it is, but I tried to run the toggle-test that does iac-output, to see if I could debug I/O at high baud rates. The CSD server seemed to go nuts trying to do I/O for me. I eventually went back to using gtty to test I/O speeds.

(230.4Kbaud output seems to be fine, but input isn't working for some reason.)
Click to expand...
The CSD server won't respond well to a sending all characters test. It will switch into server mode when it sees the 020 through 027 control characters come in. I supplied a program called recvtst.c . The comments at the front tell what it does.

There is also a possibility that at 230.4 k baud the input interrupt routine and all the overhead involved in Linux is overwhelmed and the server cannot keep up when unbuffered. 230.4 k baud would be about 21000 cps or about 50 us per character. I would hope that a fairly modern processor could keep up but there is lots of bad code out there. There is a point where polling will no longer work and I will need to fork off read and write processes and block on input each way. But today is not that day.
 
gnupublic said:
That was straight forward.
I often use putr in DOSBOX to copy files in DEC media. So I copyed the ID01.PA and VM01.PA in an empty rk05 image formated by putr. I put this rk05 image in the server directory and could read it with csd.
In BUILD it was only a load and insert, then boot. Worked as expected.
Click to expand...
This is most excellent! On your particular setup I would think about installing the CSD handler on the normal boot device. It is probably easier to boot that way. It will at some point be 25% faster when I put in the 2 words to 3 bytes mapping over the serial link. That cannot be done in the SYS handler due to code size constraints. Plenty of room in the non sys handler.
 
DougIngraham said:
The CSD server won't respond well to a sending all characters test.
Click to expand...
If it was important, I suppose the server could look for a two-character command sequence instead of a single character, but that would also slow requests down a tiny bit, and possibly burn a word (or less likely two) in the SYS handler. (Unless it actually helped SYS to always send and receive words.)
 
vrs42 said:
If it was important, I suppose the server could look for a two-character command sequence instead of a single character, but that would also slow requests down a tiny bit, and possibly burn a word (or less likely two) in the SYS handler. (Unless it actually helped SYS to always send and receive words.)
Click to expand...
It isn't that I didn't want to do a little more secure server startup sequence it is that there is simply no room in the code to do so. If I get rid of the support for CSD1: entry point there would be 2 words. In the minimal case that just isn't enough. There would need to be a constant and I looked at using an instruction as the constant and couldn't come up with anything I wanted to use.

The good side of all this is that unless you send binary data not to a known device there is little chance of triggering the server. You can do it on purpose but not by accident. This is because for the most part nobody sends those unused control codes to the console.
 
DougIngraham said:
I just uploaded a new tarball to github for V1.1
Click to expand...
That was fast!

And it also works. Maybe you may add a small comment in tty.c:

#define KEY_SH_F12 1023 /* Apple Sends 1021 instead of this */

Feature request:
Do you think it would be possible csd forks or redirect the console to a second tty on the computer? That would make it possible to use an old (real) terminal as console. If the console could be redirected with socat, this would even go over the network. Socat would buffer different baud rates. So you could even use an ASR-33 with it.

Have fun,
Volker
 
gnupublic said:
That was fast!

And it also works. Maybe you may add a small comment in tty.c:

#define KEY_SH_F12 1023 /* Apple Sends 1021 instead of this */

Feature request:
Do you think it would be possible csd forks or redirect the console to a second tty on the computer? That would make it possible to use an old (real) terminal as console. If the console could be redirected with socat, this would even go over the network. Socat would buffer different baud rates. So you could even use an ASR-33 with it.

Have fun,
Volker
Click to expand...
I put the comment in. The question then becomes what does Apple send for Shift F10? Perhaps I should change the boot function key to what is Shift F10 on a PC and then Shift F12 would still work on the Apple? This is appealing to me because on the Pi 400 US keyboard layout the F12 key is a Fn key so I have to press Shift Fn and F2 to get shift F12. The F2 key is labeled F12 in maroon so it is clear but still confusing to write about.

The idea of a second serial port to talk to the original console hardware is mentioned in my Upgrades document. It is in the plan. I don't have a teletype model 33 or 35. It was an oversite when I bought my Straight 8 to not take the Model 35. I do have a Teletype model 43 but those have a problem with ribbons. I have one in a sealed bag but I am sure it is dry as a bone. I guess I better look at what socat is. I have never heard of it.
 
Thanks! And now I looked at your doc. There are a lot of other interesting things!

With socat you can bring serial ports together:

example on one host:
socat ‍-d ‍-d ‍-d ‍/dev/ttyUSB0,raw,echo=0 ‍/dev/ttyUSB1,raw,echo=0

example with 2 hosts:
host1: ‍‍ ‍socat ‍-d ‍-d ‍-d ‍/dev/ttyUSB0,echo=0,raw ‍tcp4-listen:4711
host2: ‍‍ ‍socat ‍-d ‍-d ‍-d ‍/dev/ttyUSB0,raw,echo=0 ‍tcp4-connect:host1:4711

the -d-d-d makes it very verbose. I use it to bring my minis and my terminals together in my basement. So I have my gear plugged local and can combine any connection without moving a cable. Different speeds are possible, because socat buffers. I use an ASR-33 (110 baud current loop to RS232 adapter) with my lab8 connected at 9k6. I'm not sure if this works in all circumstances and all programs, but I had no problems yet.
 
Spent the morning trying to add the code to time the baud rate delay in the boot loader code. I only managed to save 2 or 3 words and I am still short by 3 words. OS/8 only allows 047 octal words for the boot code which is not a lot. What I think I will do is have the PDP-8 caretaker (you can read that as SYSOP if you like) run a program on their 8 which will measure this constant and then have you put that in as a configuration value in the server. This value is currently based on you using a KK8E CPU and running at 9600 baud. This is normally the fastest CPU and the slowest recommended baud rate. It will add a little extra latency on every csd disk read or write but is a reasonable value as a default. It would not be a good value to use on an 8/S or the other extreme, a very fast FPGA implementation of an 8.

I suppose I could have the server load code to do the measurement during boot and then set it. I have considered a server option that would do a boot time self test. Sort of like a POST. But it is a lot of work to get this something like this right. Maybe in version 2.
 
DougIngraham said:
Spent the morning trying to add the code to time the baud rate delay in the boot loader code. I only managed to save 2 or 3 words and I am still short by 3 words.
Click to expand...
I had a look at the boot code and I think I've managed to squeeze a few words, which with the three from before makes eight. It requires corresponding changes in the stage 2 help stuff and is obviously completely untested, so I could well be talking out of my hat.

I'll send an email with my mangled code.

Vince
 
An update on the boot code. Vince had some good ideas and I was able to get closer due to them but I was still short of space. Strangely, I had an idea that went in a completely different direction. If you don't have enough space, is there a way to make more space? And the answer in this case is yes. I know I have explained this in my book but I am not sure I have done so here.

The OS/8 boot block is 256 words long and is the first sector of the system device except for RX01 and RX02. On the floppies they left track 0 unused probably because IBM did. The boot block has three sections.

  1. The boot code which is words 0 through 046.
  2. The field 1 OS/8 resident code which is words 047 through 0177 and gets written to 017647 through 017777.
  3. The field 0 OS/8 resident code which is words 0200 through 0377 and gets written to 07600 through 07777. This portion mostly consists of the SYS: handler.
Based on this it looks like you have 047 (39 decimal) words of code to use for the OS/8 bootstrap. And that is pretty much true for every boot device except for Serial Disk and Console Serial Disk. What makes those drives special is that the virtual drives are a lot more capable than the PDP-8 they are talking to. When booting you toggle in a short program called the help loader. You run that and then in the case of CSD you tell the server to send the boot code. In the case of Serial Disk the help loader triggers the boot. The help loader is somewhat limited in what it accepts, turning an 8 bit byte into a 12 bit instruction pattern. The server will send a series of 8 bit bytes which make up a less limited boot than the help loader. This in turn then accepts the contents of the boot sector and the separate pieces of that are placed into memory and finally it jumps to 07605 to start OS/8 running. Instructions generated by the help loader can only address memory locations 0 through 037. But it can install code up to 0177 (page 0) and if run on page 1 could install code there as well. The limitations on the instructions are strict enough that effectively your program must run at the bottom of page 0.

The trick to making more than 047 words of boot code is in the help loader code. While limited in what instructions and data can be loaded with it, it is still code. And as long as that code can be used by the unlimited instructions found in that first section of the boot block you get more than 047 words. I was not thinking about it this way because one of my goals was to make this "example code" that could be easily understood. I wanted it to look like and behave like other devices as much as possible. It should be possible to make the boot code as long as the 32 words of help loader plus the 39 words found in the boot block or 71 total words. In practice it will never be quite that much.

Now I have to go code up a new boot loader! More later!
 
I coded up the new boot loader for CSD which times a transmitted character and then patches the handler that it just installed. Testing comes tomorrow. The program flow is good. At least as good as any code that overwrites itself while running can be. But it is compiled into a handler so there are constraints and not all of it appears in one place. Once I get it running I will try to put all of it into the handler using NOPUNCH and ENPUNCH to prevent BUILD from throwing a fit when it sees code that should not be there. I hope I can make that work. It is kind of UGLY to read as is. And my trick mentioned in the previous post gave me a lot of extra space. I only used 032 (octal) of the 047 words available.

Also, this should now run on the PDP-5 although as near as I can tell the PDP-5 would crash when OS/8 loads its transient portion over the top of the program counter.
 
After letting the new boot loader perk in my brain for a couple of days I found all sorts of ways to make it easier to understand. I like it when stuff goes that way. And it got a tiny bit shorter in the process.

One downside of changing this stuff is that the toggle in part changed its address. It used to be at 025 and now it is at 020. Would it be wrong of me to consider placing it for minimum number of switch actuations? Yeah, it probably would give someone an excuse to accuse me of OCD.

And it should now run on a PDP-5. Although OS/8 wont run on a 5 I am going to add some way to use the server to allow the running of code directly from the server sans any OS other than the handler. Would allow for saving most of memory and running diags from the 8 instruction toggled in loader.

I will put out a ver 1.2 once I am reasonably certain I haven't added any new bugs.
 
Last edited:
You must log in or register to reply here.
Back
Top