• Please review our updated Terms and Rules here

PDP-8 OS handlers

>>> Well, I found the bug!

Well done.

The leading '0' for Octal in C/C++ is horrendous. I generally do the following:

#define OCTAL( n ) 0##n

I can then write things like:

int x = OCTAL(1234) and it (a) works and (b) 'reads' sensibly - if being a little long-winded. However, I prefer to do this rather than obfuscate things...

By the way, nice of you to describe the ".-." construct. I was wondering what that was myself. It is obvious now you have explained it (as most things are).

Dave
 
The leading '0' for Octal in C/C++ is horrendous. I generally do the following:

#define OCTAL( n ) 0##n

I can then write things like:

int x = OCTAL(1234) and it (a) works and (b) 'reads' sensibly - if being a little long-winded. However, I prefer to do this rather than obfuscate things...

By the way, nice of you to describe the ".-." construct. I was wondering what that was myself. It is obvious now you have explained it (as most things are).
I will have to think about going through the code and making this change to OCTAL. This seems like an excellent idea,


In general, self modifying code is evil. It is unfortunate that on the Family of 8 there are things you "practically" cannot do any other way. I always wanted to highlight self modifying code in blinking red letters. Shame I was never able to invent blinking ink. Another possibility would be to have ominous music play in your head when your eyes cross over self modifying code.

Last night I added in the code to write the memory image of the disk back out to the file when F1 is pressed to exit the server. No changes are made before that. But I can tell already I should put in a mode to do immediate writes. That does not need to happen right now so it goes on the enhancement list.

Today I am going to remove some of the debugging code because it is so verbose when debug is enabled as to be difficult to use. It is ok if it is clumsy to use when debug is on. I also plan to get support for the second RK05 device working. This requires finding 2 words in the handler. There is one free now eaten by a ZBLOCK at the end and I think I can get another by moving the WKUP constant so it can be executed as a harmless AND instruction replacing a NOP following an ISZ.

I was going to include the handler listing here but the forum has a 10000 character limit on a message and the handler listing is 21k. Instead here is the handler header portion of the listing which shows the code that overlays the running code in the previous posting. And you thought self modifying code was dangerous!
Code:
      / SERIAL DISK OVER THE CONSOLE PORT                                 Page 1


    1              / SERIAL DISK OVER THE CONSOLE PORT
    2              /
    3              / 20220213 DPI
    4              /       STARTED CODING SINGLE SYS ENTRY POINT.
    5
    6              / 20220218 DPI
    7              /       FLESHED IT ALL OUT.  JUST EXACTLY FITS WITHOUT ANY TRICKS.
    8
    9              / 20220330 DPI
   10              /       MOVED SOME VARIABLES TO THE DATA BREAK LOCATIONS AND NOW HAVE
   11              /       FOUR WORDS FREE.
   12
   13              / 20220427 DPI
   14              /       ADDED THE 20220330 COMMENT.  ADDED THE BOOT CODE WHICH ISN"T REALLY
   15              /       USED BUT IS WHAT ENDS UP IN MEMORY.  MADE CHANGES IN THE BOOT CODE
   16              /       AFTER REVISITING THE BOOT PROCESS.  MOVED BOOT2 SUCH THAT IT STARTS
   17              /       AT 0037 AND ENDS AT 0046 WHICH IS THE LAST LOCATION THE TRADITIONAL
   18              /       STYLE OS/8 BOOTS USE IN THE BOOT SECTOR.
   19
   20              / 20220428 DPI
   21              /       DECIDED TO MAKE THE BOOT MORE LIKE ALL THE OTHER HANDLERS.  THE
   22              /       BOOT PROCESS CONSISTS OF STARTING THE BOOT1 CODE, TELLING THE
   23              /       SERVER TO GO INTO BOOT MODE WHERE IT SENDS THE HELP VERSION OF
   24              /       BOOT2 AND THEN SENDS THE BOOT BLOCK.  BOOT2 READS THE BOOT BLOCK
   25              /       AT 0 AND THEN MOVED THE PIECES INTO THEIR LOCATIONS AND THEN
   26              /       JMPS TO 7605 TO START OS/8.
   27
   28              / 20220501 DPI
   29              /       ADDED A RELOC JUST BEFORE THE $ AT THE END FIR SYMMETRY.
   30
   31              / 20220503 DPI
   32              /       FIXED A COMMENT AND ADDED BACK IN THE NOPS AFTER THE ISZ WHICH SHOULD
   33              /       GET SKIPPED ONLY WHEN TRANSFERING THE LAST WORD OF A FIELD.
   34
   35              / 20220507 DPI
   36              /       CHANGED THE DEVICE NAME TO MATCH THE RK05 NAMES FOR THE INITIAL
   37              /       INSTALL ATTEMPT.  IF THERE ARE ISSUES WITH JUST FORCING THIS
   38              /       HANDLER INTO MEMORY DURING BOOT, THIS MIGHT HELP.
   39              /       ALSO ADDED A SECOND DUMMY ENTRY POINT TO MATHC THE RK8E.
   40
   41              / 20220707 DPI
   42              /       FOUND A BUG IN GET12 WHERE IF THE LINK WAS SET THEN THE VALUE
   43              /       WOULD HAVE 010 ADDED TO IT.  ALSO CLEARED THE LINK IN SEND12
   44              /       ALTHOUGH I DON'T THINK IT WOULD MATTER THERE.
   45
   46              /20220708 DPI
   47              /       CHANGED THE NAMES OF THE READ AND WRITE ROUTINES TO MATCH THEIR
   48              /       FUNCTIONS RELATIVE TO THE SERVER SINCE IT IS THE ONE GIVING THE
   49              /       ORDERS.
   50



      / SERIAL DISK OVER THE CONSOLE PORT                                 Page 2


   51              /20220718 DPI
   52              /       MOVED SOME CODE AROUND SO SETUP IS AT THE SECOND HANDLER ENTRY
   53              /       POINT.  IF THE SERVER DOES NOT SEE 7611 (7607+2) AS THE INITIAL
   54              /       CALLED ADDRESS, IT KNOWS THE SECOND ENTRY POINT WAS CALLED.
   55
   56        0001          VERS="A&77      /VERSION DISPLAYED BY RESORC
   57
   58        0003          DEVCNT=3        /SYS ENTRY,  RKA0 AND RKB0 DEVICES FOR NOW
   59                      DECIMAL
   60        6260          DEVSIZ=3248     /SAME AS RK05 AND PREVIOUS SERIAL DISK VERSIONS
   61                      OCTAL
   62
   63
   64        0000          *0
   65 00000  7775          -DEVCNT         /NUMBER OF ENTRIES
   66
   67              / IN REALITY WE SHOULD LOOK LIKE THIS
   68              /       DEVICE CSDO; DEVICE SYS; 4401; 2007; 0; DEVSIZ
   69              /       DEVICE CSDO; DEVICE CDA0; 4401; 1007; 0; DEVSIZ
   70              /       DEVICE CSDO; DEVICE CDB0; 4401; 1040; 0; DEVSIZ
   71
   72              / BUT WE NEED TO TRICK OS/8 INTO WORKING WITH US SO WE DO THIS FOR THE
   73              / INITIAL INSTALL.
   74 00001  2213          DEVICE RK8E; DEVICE  SYS; 4231; 2007; 0; DEVSIZ
      00002  7005
      00003  2331
      00004  2300
      00005  4231
      00006  2007
      00007  0000
      00010  6260
   75 00011  2213          DEVICE RK8E; DEVICE RKA0; 4231; 1007; 0; DEVSIZ
      00012  7005
      00013  2213
      00014  0160
      00015  4231
      00016  1007
      00017  0000
      00020  6260
   76 00021  2213          DEVICE RK8E; DEVICE RKB0; 4231; 1021; 0; DEVSIZ
      00022  7005
      00023  2213
      00024  0260
      00025  4231
      00026  1021
      00027  0000
      00030  6260
   77
   78
   79              /BOOT CODE



      / SERIAL DISK OVER THE CONSOLE PORT                                 Page 3


   80
   81 00031  7731          BTWC-BLAST      /TWO'S COMP OF LENGTH OF BOOT CODE FOR BUILD
   82
   83                      RELOC 0
   84 00000* 7400  BTWC,   -0400           /WORD COUNT TO TRANSFER
   85 00001* 0001  BTCA,   0001            /CURRENT ADDRESS TO STORE WORD.
   86 00002* 0000  BTTMP,  .-.             /THIS IS AN INITIAL DONT CARE VALUE.
   87
   88              / THE NEXT FOUR WORDS REPLACE THE PATCH CODE IN THE BOOT2 HELP LOADER
   89 00003* 7605  OS8GO,  7605            /OS8 ENTRY POINT
   90 00004* 0047  BTSRC,  0047
   91 00005* 7647  BTDST1, 7647
   92 00006* 7600  BTDST2, 7600
   93
   94 00007* 6031  BOOT2,  KSF             /GET A CHARACTER FROM SERIAL DISK SERVER
   95 00010* 5007          JMP .-1
   96 00011* 6036          KRB
   97 00012* 7006          RTL             /LEFT SHIFT 4 BITS TO BUILD UPPER HALF
   98 00013* 7006          RTL
   99 00014* 3002          DCA BTTMP       /SAVE FOR COMBINE
  100 00015* 6031          KSF             /GET LOWER 6 BITS
  101 00016* 5015          JMP .-1
  102 00017* 6036          KRB
  103 00020* 1002          TAD BTTMP
  104 00021* 3401          DCA I BTCA      /STORE THE WORD IN MEMORY
  105 00022* 2001          ISZ BTCA        /POINT AT NEXT ADDRESS
  106 00023* 2000          ISZ BTWC        /SKIP IF DONE
  107 00024* 5007          JMP BOOT2       /GO DO THE NEXT WORD
  108
  109              / WHEN WE GET HERE THE BOOT BLOCK IS LOADED IN MEM PAGES 0 AND 1
  110              / WE NOW NEED TO COPY THEM INTO PLACE.
  111
  112              / FIRST DO THE FIELD 1 PIECE
  113 00025* 1404  BTCPY1, TAD I BTSRC     /LOAD
  114 00026* 6211          CDF 10          /SWITCH TO FIELD 1
  115 00027* 3405          DCA I BTDST1    /STORE
  116 00030* 6201          CDF 00          /SWITCH TO FIELD 0
  117 00031* 2004          ISZ BTSRC       /BUMP SRC ADDRESS WILL NEVER SKIP
  118 00032* 2005          ISZ BTDST1      /BUMP DST ADDRESS AND SKIP IF DONE
  119 00033* 5025          JMP BTCPY1
  120
  121              / NEXT DO THE FIELD 0 PIECE
  122 00034* 1404  BTCPY2, TAD I BTSRC     /LOAD
  123 00035* 3406          DCA I BTDST2    /STORE
  124 00036* 2004          ISZ BTSRC       /BUMP SRC ADDRESS WILL NEVER SKIP
  125 00037* 2006          ISZ BTDST2      /BUMP DST ADDRESS AND SKIP IF DONE
  126 00040* 5034          JMP BTCPY2
  127
  128 00041* 5403          JMP I OS8GO     /AND GO START OS8
  129



      / SERIAL DISK OVER THE CONSOLE PORT                                 Page 4


  130 00042* 0000          ZBLOCK 047-.    /PAD TO FILL THE SECTION
      00043* 0000
      00044* 0000
      00045* 0000
      00046* 0000
  131
  132              BLAST,  RELOC
  133
  134              /////// END OF BOOT
This has not yet been fed into BUILD but all the stuff is there so it should work.
 
Spent the morning writing a configuration document. It turns out this is not just a plug and play setup. In addition to telling the server the baud rate and device name of the serial port you will probably want to patch a timer constant that is in the handler. I call this constant BDTIME for BauD rate TIMEr. This constant can be set to zero (the maximum) which should always work but is slower than tuning it. I should probably default it to zero and if you want to tune it you can. It also will need to be patched in the server because the server has a copy of the handler that it uses to patch RK05 images so they can be booted directly. It could add at least 25 ms to each handler call if not tuned. It would be a LOT worse on an 8/s. Probably close to half a second per OS/8 handler call if not tuned (on an 8/s).

At the moment I am assuming some familiarity with system administration of Linux which is the most likely place the server will end up. I am currently running it on a raspberry pi 3 but it should run on any reasonably Posix compliant system. My straight 8 and 8/a are connected to a FreeBSD server and I will try it there as well.
 
A lesson I learn over and over again.

I have a thing that works. But I am the only one who can make it work in its current state. There is a lot to do so that others can use it.

Documentation...

I am trying to get something wrapped up in good enough shape for a beta release.
 
Today was much cooler and this afternoon and evening I played with it and did a little more documentation and code cleanup.

But it is time to let someone else play with it.

I created a tarball of consd 0.1 (Beta) and emailed it to Kyle and Vince. I hope they can find time to look at it.

If you have played with Kyle's serial disk at 9600 baud you know how slow it is. This should be the same speed
and it takes about 20 seconds to do a DIR. It only takes about 2 seconds to boot so with that as a benchmark
it is faster than Windoze at booting.
 
Not sure why I forgot this but I never mapped a modern keyboard key to the RUBOUT (0377) code. The RUBOUT code was used when creating paper tapes offline as the correcting code. You would backup the paper tape punch to the code you wanted to RUBOUT and when you hit RUBOUT every punch in that position was punched. Programs would ignore 0377 codes (mostly). The RUBOUT key is used by the keyboard monitor on the PDP-8 as the delete the previous character key. Since a Teletype cannot backspace the keyboard monitor would print a / and then the character that was rubbed out. Additional RUBOUTs would display additional characters that were deleted and when a non RUBOUT was received another / was printed followed by the new character to indicate the end of the correction.

This morning I became annoyed that it didn't work so I mapped the DEL key to RUBOUT.
 
Doug, a little question... Is your code portable so someone could also use it on a Windows PC or an old MS-dos machine? I've been playing with the code from Kyles disk server on a MS-Dos machine. I forgot about that project when I gave the machine to another collector. So my work was gone... But I would love to use some sort of vintage machine for the disk server...

Regards, Roland
 
Doug, a little question... Is your code portable so someone could also use it on a Windows PC or an old MS-dos machine? I've been playing with the code from Kyles disk server on a MS-Dos machine. I forgot about that project when I gave the machine to another collector. So my work was gone... But I would love to use some sort of vintage machine for the disk server...
At the moment it needs a posix compliant os to run on. But the subroutines that would need to be modified are all pretty small and it would be straightforward to modify them. So it would not be out of the question to make it work on old hardware although one of my design decisions sort of requires the ability to store an image of the disk in an array in memory. A little over 3 mb of ram for that array. But even that could be changed to do the reads and writes from the disk of 256 words.
 
I am taking a break from a weird bug. I am not even sure it is in my code. If I boot OS/8 and immediately try to R PIP then PIP hangs. If I R PAL8 and then control C out of it and R PIP then PIP is fine. The next thing to do is grab another RK05 image and try that..
 
Found the bug and it was in my code. There is a flag TSFSET that remembers the state of the console TSF flag when the handler is entered so it can be set the same way when the handler returns to the caller. I was setting this the opposite of what it was supposed to be. Now this seems like it would cause no end of difficulties but suppose you send characters with:
Code:
        TLS             /BLINDLY SEND THE CHARACTER IN THE AC
        TSF             /SKIP IF DONE SENDING
        JMP .-1         /WAIT UNTIL IT IS FINISHED BEING SENT
That code is immune to an initial flag being set or not. However it is not an efficient way to send characters because the CPU is waiting instead of
working. If you reverse it and test first:
Code:
        TSF             /WAIT FOR PREVIOUS CHARACTER TO COMPLETE
        JMP .-1
        TLS             /NOW SEND THE CHARACTER
You get all the overlap time to do something else. In the failure case a character was send and then the handler was called. When the handler returned it cleared the flag and the TSF loop hangs.

I fixed it by moving two instructions. And I am fresh out of known bugs. I am going to wrap this up and send it off to Kyle and Vince and see if I can finish adding an important item on my upgrade list before I turn this loose.
 
Added a somewhat clumsy way to send text files to the 8. At the moment when you press F6 it sends a file named textfile to the PDP-8. The characters are massaged with toupper(ch)|0200 to make them 8 compatible. It expects you have PIP running and have typed FILNAM.EX<TTY: at the PIP * prompt. It sends a character and waits for the echo. When it sends a RETURN it expects a CR LF pair. I found out that if a line is longer than 72 characters the TTY: handler sends a 015 code. This should technically be a 0215. My program logs an error and stops when it sees this. If it didn't it would probably also see a 012 code. Time to go look at the TTY: handler. When EOF is reached on the textfile a control Z is sent which signals the TTY: handler that end of file has been reached and it returns to PIP and PIP closes the file. What is there all seems to work

I have found that I am taking advantage of CORE. I start the server and then walk over to the 8/e, turn the power key, enter 7605 then press load address, clear, continue and OS/8 pops up without needing a reboot.
 
This afternoon I fired up BUILD and built a SYS image the correct way rather than having the server patch at boot. I had zero issues doing this. I was going to change the baud rate on the M8655 to 19200 but didn't get to that. I even assembled the handler from source on the 8/e using the console serial disk as the disk. It took around a minute to assemble and generate a listing which was faster than I expected. The source file is 19 blocks and the listing file is 46 or 48 blocks.

I will probably try it on my 8/a soon. I need to look that machine over and make sure it is in a state where I can safely plug it in.

I am still cleaning up comments and adding to the documentation.

I think the next thing to do while I wait for my Beta testers is to write a non system version of the handler. The non-sys will have entry points for 4 disk devices (two RK05 or serial disk images), a handler for the TTY: device and a handler for the LPT: device. I will probably also put in support for PTR: and PTP: at some future time. With the method I am using it only takes 1 word to add another character device to a handler because all the real work is done in the server.
 
Is the pdp8 bootstrap now permanent? I could add it to the M847 bootstraps...
That is a good question. I think I am going to change it one of these days so it can run on the PDP-5 in addition to all the other Family of 8 machines. I also want to try to get the boot loader to time the serial port transmitter and patch the sys handler with this constant. And while the instructions in the help loader will stay the same the location will probably move. Yes I would like the help boot in the M847 but not quite yet.
 
I am preparing a general release. I have been working on documentation and started working on the Non System handler version. Today I changed the jumper on my M8655 to select 19200 baud instead of 9600. I haven't tried it yet.

I have been thinking about making the final version support a maximum size OS/8 partition. The RK05 is 3248 blocks long where a block is 256 words. A maximum size OS/8 partition is 4096 blocks. Well, maybe only 4095, I doubt it was ever tested with 4096 and there are things that might have trouble with that last block. This is an increase in size of 26% which I consider significant. The downside is that you can't mount the image anywhere else. Any thoughts?
 
I have been thinking about making the final version support a maximum size OS/8 partition.
Yes, I think we need a 'maximum size OS/8 partition' storage device. If you don't code it, I'm confident someone else will soon do it. If it's useable at 9600 baud, I'm looking forward to hearing how well it performs with a USB serial I/O interface.
 
I have been thinking about making the final version support a maximum size OS/8 partition. The RK05 is 3248 blocks long where a block is 256 words.
I can see uses for such a thing, but I also think it's extremely handy to have all those RK05 images useable, and I can't see how you'd do both. Maybe a command line flag or the like, with the default partition sizes like the RK05?

It's also imaginable to do "images" with more than two devices/partitions. (Maybe RL02-like?)

Vince
 
I would make it an option. But I don't really like disk images which do not work on a real rk05. The disk images for Kyle's disk server also needed to be edited for the disk server. Within time people might confuse these images with real images. I have had problems with online papertape which were corrupt as well.

Ideally a disk emulator would work with original disk images. And images created with an emulator should work on real hardware. Otherwise there will be two pdp8 worlds I think....
 
At the moment...

If you feed a real RK05 image to the server, it is identified as such and the boot block is replaced with one that tricks OS/8 into thinking the handler is for RK05. You still talk to it using RKA0: and RKB0: because as far as OS/8 is concerned it is an RK05. When you exit the server, all changes made to that image are written out including the modified boot sector. The next time the server is brought up and handed this image it recognizes that it is for Console Serial Disk and it only validates the fields of the boot record. Unless you have run BUILD and changed things it still looks like an RK05 but it isn't bootable on an RK05 drive or simh. This will cause confusion and I don't like that part of it. I could pretty easily write a program to put the RK05 boot block back and that may be part of the solution. But I expect this might be even more confusing.

Once you have a running system that looks like an RK05 you should probably run build, remove the RK8E handler and install the CSD handler. After you do that, The first half of what was an RK05 image becomes CDA0: and the second half becomes CDB0: and OS/8 will no longer recognize RKA0: and RKB0: as active devices. Upon startup the server recognizes this as another variation of CSD and only validates the boot block.

For the real release I might provide an image in CSD format and eliminate ever booting from an RK05 image. I can make the non system handler version of it know about an RK05 image which would let you move stuff in and out of those images.

There are of course other approaches to this and I want to find a happy middle ground. I am not comfortable with modifying RK05 images so they are no longer bootable as RK05. This will be confusing. But this is what I am currently doing.

I need to think about this a bit more.
 
Oh, and my M8655 stopped working. Device code 04 (console transmit) isn't being recognized by the card. Turns out that on the 8 position dip switch for the transmit most of the contacts no longer close. I must have bumped the #6 switch and now it doesn't close. It is probably being decoded as device 00 which is not going to work very well. I know I have some dip switches around here somewhere.

Oh, and before you post back a comment about spraying deoxit into the switch and working the contacts, I tried that. It isn't just that one switch, only two of the contacts on that switch close. And only three of the receive switch contacts close now that I have opened them.

Its always something!
 
Back
Top