• Please review our updated Terms and Rules here

What did I do to my PDP-8 today.

djg = David Gesswein. Added my name to profile.

If you want 57600 or above I think that works with 14.7456 MHz crystal. Won't be able to do the common lower frequencies but if dedicated for SerialDisk won't mater.

Thanks David!

The M8650 works perfectly well with the original 14.418 MHz crystal running at 115200 bps while using it as a console UART at addresses RX=3 and TX=4.

I have tried rewiring the address to RX=40 and TX=41 using the instructions on Doug Jones's website.

It didn't work with SerialDisk so I just tried the simple transmitter test and echo test on page 4-3 of DEC-8E-HMM1A-D-D_PDP-8e_Maintenance_Manual_Volume_1_Processor_Sep73.pdf (modified for addresses 40/41) .

Transmitter test:

0: 7604
6416
6411
5002
5000

Echo Test:

0:6402
6401
5001
6406
6416
6411
5005
5001

Neither of them does what I expect.

I also tried different address selection jumper settings as show at the bottom of:

https://www.pdp-9.net/configure-m8650-kl8e-for-serialdisk

These jumper settings didn't improve it either.


Both tests work fine when jumpered to addresses 3/4.

Where did I go wrong?

Thanks and best regards
Tom Hunter
 
Transmitter test:

0: 7604
6416
6411
5002
5000
This is:
Code:
STSF=6411
STLS=6416
        *0000
LP,     CLA OSR         / CLEAR AC AND LOAD TRANSMIT CODE FROM THE SWITCH REGISTER
        STLS            / TRANSMIT THE CHARACTER OUT THE SERIAL PORT
        STSF            / SKIP IF TRANSMIT COMPLETE
        JMP .-1         / WAIT FOR TRANSMIT COMPLETE
        JMP LP          / START OVER
Read the switch register and send the code forever. If you didn't manage to get the device codes changed or another device is on 41 already this will not work.
Echo Test:

0:6402
6401
5001
6406
6416
6411
5005
5001
And this one is:
Code:
SKSF=6401
SKCC=6402
SKRB=6406
STSF=6411
STLS=6416
        *0000
LP,     SKCC            / CLEAR AC AND RECEIVER FLAG
        SKSF            / SKIP IF A CHARACTER IS RECEIVED
        JMP .-1         / WAUT FOR A CHARACTER
        SKRB            / CLEAR AC, READ THE CHARACTER, CLEAR THE RX FLAG
        STLS            / SEND THE CHARACTER BACK
        STSF            / SKIP IF TRANSMIT COMPLETE
        JMP .-1         / WAIT FOR TRANSMIT COMPLETE
        JMP LP          / START OVER
Pretty straightforward. Reads a character and echoes it back. If the far side sends too fast then you might miss characters. If you just have a terminal where you are typing then it should be fine. Otherwise the same comments as before. Either another device on the same code or you didn't get it jumpered where you think.

I don't have an M8650 but I must say that the documentation on Doug Jones's page and the PDP-9.net page seem somewhat confusing. The photo and the jumpers are not the same. May have to go to the schematic and figure it out from that.
 
Last edited:
This might have been easier if I had an M8650 to look at.

What makes it confusing is the use of the default jumpers. On a board used for codes 03 and 04 all the middle jumpers are in place. On the Doug Jones chart you must remove all the default jumpers and then connect the pads as shown. The PDP-9.net photo shows a mix where the default jumpers were kept when that bit is unchanged and then added the jumpers for those bits that needed the other state. What confused me most is the horizontal jumpers which are easy to overlook in both the photo and on the Doug Jones chart. On the photos it looks like a trace because they did a neat job and were consistent. On the Doug Jones chart I didn't notice the - between some of the o's. The verticals are obvious. If you copy the PDP-9.net photo you will make the fewest changes. Changes need to be made to E, D, C and B sections. A and F can be left alone. If you leave off any of the jumpers you will have a floating input and the device probably will not respond to any code. Of course this is not guaranteed and the device could respond to multiple codes depending on which way the inputs float on the 5314 chips.

Lets look at the C config area. This one represents the LSB of the device code. Both receive and transmit change on this one. Pull both default jumpers. Place a jumper between pins 1 and 2. This sets the receive side to expect a 0 bit. Place a jumper between pins 3 and 4 which sets the transmit side to expect a 1 bit.

I suspect that you missed the horizontal jumpers like I did when looking at the chart and the photo.

I hope that helps. I had kind of wanted one of these boards but now I am not so sure....
 
I suspect that you missed the horizontal jumpers like I did when looking at the chart and the photo.

I hope that helps. I had kind of wanted one of these boards but now I am not so sure....

Thank you Doug!!!

I am obviously blind. :-(

Now that you pointed out the horizontal jumpers I wonder how I missed them.

I prefer the M8650 board not just because it can go faster, but because it uses a discrete TTL logic implementation rather than a LSI UART.

I wish DEC would have documented the board better. The hand drawn M8650 schematic in the PDP-8E_Engineering_Drawings_RevAD_Dec72.pdf on Bitsavers is terrible.

The address decoding is bizzare.

Best regards
Tom Hunter
 
After adding the horizontal jumpers the M8650 works perfectly at addresses 40/41 and at 115200 bps the SerialDisk server works much nicer.

I successfully assembled the two handlers and then inserted them into BUILD. Performance using SerialDisk at 115200 bps was quite reasonable.

All went well and all the steps looked identical to what is shown in Kyle's document but unfortunately the final step of the "RUN SYS BUILD" process diverged from the description:

$BO
WRITE ZERO DIRECT?Y
SYS BUILT
.SAVE SDB0 BUILD

.DIR SDB0:/P
NO CCL!
.DIR
NO CCL!

So somehow I lost the CCL (I assume this is the command line interpreter).

Note the prompt "WRITE ZERO DIRECT?" to which I replied "Y" is not documented in Kyle's instructions.

Where did I go wrong?

Thanks and best regards
Tom Hunter
 
I haven't committed the new assembler yet, through, as I want to see it work correctly for more sources, first.

Comitted this tonight, after running it through the palbart tests.

I got mostly better answers than palbart, though apparently palbart handles longer source lines. I also don't accept "EXPUNGE" or have some of the extra symbols defined.

There was one case where a bunch of literals are defined, then another page is assembled, and then it comes back to the prior page and defines more literals. I'm pretty sure that's a no-no in the native assemblers, as keeping track of all that could theoretically require all 32K.

Also, here's a fun one. What should this assemble to?
JMP .-1 I
Palbart seems to think the answer is "JMP .-1". I'm thinking of adding an error check to mine, which currently computes .-1|400, then generates a (probably) off-page JMP to that. (If the I comes next to JMP, it correctly adjusts the MRI for indirect.)

Whee!

Vince
 
Write zero directory does exactly what it sounds like, It zeros out the directory erasing all the files. Try N. Don't offhand know why you get that if the original instructions didn't get it.
 
Write zero directory does exactly what it sounds like, It zeros out the directory erasing all the files. Try N. Don't offhand know why you get that if the original instructions didn't get it.

Thanks David.

I redid the whole process described in Kyle's docment and answered "N" when it asked "WRITE ZERO DIRECTORY?" and the system seems functional. Chess works but I cannot figure out how to play it.

I deleted a few large files with the ".X8" extension to create space on SDA0: and then copied the BASIC related files from SDB0: over onto SDA0: and eventually got them all so that I could start BASIC.

BASIC seems to work up to the point when I try to "RUN" the 3 line program I typed in. Then the SerialDisk server moans "Warning: client asking to write past disk boundary!" and the LAB-8/E halts.

I restarted the SerialDisk server and toggled in 7600 and then pressed ADDR LOAD, EXT ADDR LOAD, CLEAR, CONT but the system doesn't restart as documented in the OS/8 manual. I had to toggle in the bootloader to get it going again.

I retried running a small BASIC program and the exact same error happend again. :-(

Maybe some BASIC component is missing?

I didn't find a list of all the files needed for BASIC, so I just guessed that I need:

BASIC.*
BLOAD.SV
BCOMP.SV
BRTS.SV

It could also be that the LAB-8/E still has a subtle fault even though the MAINDEC diags seemed to run as expected.

Best regards
Tom Hunter
 
Also, here's a fun one. What should this assemble to?
JMP .-1 I
On my Straight 8, PAL opens the side panel and an arm with an open hand reaches out and slaps the programmer silly.

I think that should generate an error. I don't know what real OS/8 PAL does but what ever it does it is what all the cross assemblers should do.

No, I am already distracted enough. I am not going to test this.
 
There is a file on the disk called CHESS.TXT. Suggest reading it... It is also here https://technikum29.de/de/lernprojekte/schach/Chekmo II (english, original).pdf.

The error you are getting means that the PDP8 device driver is trying to write to a block that is not an a physical RK05 disk.

Just before the error report you get - you should see some other values printed out. What are they?

The BASIC compiler will compile the program to disk. If the disk handler - or the disk geometry - doesn't match, then this will potentially corrupt the disk also.

Dave
 
>>> On my Straight 8, PAL opens the side panel and an arm with an open hand reaches out and slaps the programmer silly.

I can think of quite a few machines where this optional add-on would be very welcome :)!

Why was it ever removed from machines after the Straight-8 I wonder?!

Dave
 
On my Straight 8, PAL opens the side panel and an arm with an open hand reaches out and slaps the programmer silly.

I think that should generate an error. I don't know what real OS/8 PAL does but what ever it does it is what all the cross assemblers should do.

Apparently a "JMP .-1 I" occurs in the tek4013 source, according to the palbart test suite. I think it was a typo, as the "I" immediately precedes the comment "/", some distance from the "JMP .-1". That file also seems to have a couple of lines that are 132 or more characters.

Compiling old source code from lots of authors and different coding styles is a challenge.

Vince
 
>>> On my Straight 8, PAL opens the side panel and an arm with an open hand reaches out and slaps the programmer silly.

I can think of quite a few machines where this optional add-on would be very welcome :)!

Why was it ever removed from machines after the Straight-8 I wonder?!

An easy one. Cost savings.
 
Apparently a "JMP .-1 I" occurs in the tek4013 source, according to the palbart test suite. I think it was a typo, as the "I" immediately precedes the comment "/", some distance from the "JMP .-1". That file also seems to have a couple of lines that are 132 or more characters.

Compiling old source code from lots of authors and different coding styles is a challenge.
It was eating at me not knowing so I tried it under PAL8.
Code:
.R PAL8
*TST4,TST4<TST4 /H

.TYPE TST4.LS


       0200  *200
00200  5177          JMP .-1         / WHAT WILL THIS GENERATE
00201  5777'         JMP .-1       I /7 SPACES BEFORE THE I
00202  5776'         JMP .-1 I       /1
00203  5775'         JMP .-1 I               /IS MORE DIFFERENT?
00204  5603          JMP I .-1       / THE MOST NORMAL OF THE LOT
00375  0602
00376  0601
00377  0600
                     $




ERRORS DETECTED: 0
LINKS GENERATED: 3
The case Vince mentioned is demonstrated at addresses 201 through 203. It surprised me with what is generated. It generates links (closely related to literals) which gets placed at 377 through 375. The JMP is assembled as an indirect through that link. The link stored at 377 is a 0600. Where did that come from? The link value is the value of the symbol "I" which is 0400 ored with the value for the current page which is 0200 ored with the value ((current address minus 1) AND 0177). PAL8 decided to generate a link because the value of all of that is 0600 which is not on page 1 (0200 through 0377). The only part of that I am unclear about is why the current page bit was included but I am sure it has to do with this being a memory reference instruction. The documentation for PAL8 make it clear that an I or Z after a memory reference instruction is special. They are in the fixed portion of the symbol table so you cant use them as variables. At least not easily. Just to verify some of what I said here is another test case this time assembled at *600.
Code:
       0600  *600
00600  5777'         JMP .-1         / NO COMMENT
00601  5200          JMP .-1               I / EVEN MORE SPACES
00602  5201          JMP .-1       I /7 SPACES BEFORE THE I
00603  5202          JMP .-1 I       /1
00604  5203          JMP .-1 I               /IS MORE DIFFERENT?
00605  5604          JMP I .-1       / THE MOST NORMAL OF THE LOT
00777  0577
                     $




ERRORS DETECTED: 0
LINKS GENERATED: 1
This behavior verifies what I suspected. Note that the JMP .-1 at 00600 is now the only one with a link. The addresses all resolve (except for the first) to this page so they generate the page absolute jump addresses.

With that in mind I don't see how that typo could have left the code working the way it was intended. Maybe it didn't work correctly but was brushed off as an unexplained glitch on the monitor. I suppose it could have just happened to have been assembled on page 3.
 
Last edited:
The error you are getting means that the PDP8 device driver is trying to write to a block that is not an a physical RK05 disk.

Just before the error report you get - you should see some other values printed out. What are they?

The BASIC compiler will compile the program to disk. If the disk handler - or the disk geometry - doesn't match, then this will potentially corrupt the disk also.

Dave

Thanks Dave!
The error mis-reports that it is a write when in fact it is a read. The last few messages from os8disk are:

Code:
Successfully completed read
Request to read 6 pages to side 0 on system disk
Buffer address 23000, starting block 05010
Successfully completed read
Request to read 6 pages to side 0 on system disk
Buffer address 24400, starting block 06256
Warning: client asking to write past disk boundary!
Failed to initialize, sending NACK
Received unknown command 0000

It tries to read past the last disk block at 06257 (octal). There are 06260 blocks in total on the disk.
The 6 pages it tries to read are 3 more blocks so it exceeds the disk size by 1 block.
Maybe the directory has been corrupted somehow?

Edit: I restarted the system using 07005 as the restart address and it immediately halted. As I had nothing to lose I pressed "CONT" and to my big surprise my 3 line BASIC program run to completion. Then I entered "RUN" again and the system halted again when it tried to read past last disk block. As I pressed "CONT" it successfully executed my 3 line BASIC program. So this is much more robust than I thought. I wonder what these 3 blocks are that it tries to read unsuccessfully but seems to be able to do without. Weirdness!!!

So BASIC appears to work fine with SerialDisk but has a glitch when you run your program. To recover from the glitch simply press "CONT".

Thanks

Tom Hunter
 
Last edited:
Edit2: I noticed that the file SDA0:BASIC.UF was the last file in the directory listing. On a hunch I just renamed the file to BASIC.JK and recopied the file from SDB0:BASIC.UF. Now BASIC works perfectly without halting and the need to press "CONT" when trying to run a program. My theory is that the BASIC RUN command compiles & loads my program and for that it reads BASIC.UF without actually using all sectors from it.

Edit3: It turns out that when a BASIC program is compiled, loaded and executed (via "RUN") that it will try to read BASIC.UF but does not really need it. If it is present it reads 2 additonal blocks beyond the size of the file. If the file happens to be in the last sectors of the disk you get the problem I experienced where SerialDisk moans that you try to read past the end of the disk and the Lab-8/e halts which you can recover from by pressing "CONT" on the front panel. I have now renamed BASIC.JK to BADBLK.JK (what used to be BASIC.UF in the last few sectors of the disk). The OS/8 system and BASIC work fine with this.

Tom Hunter
 
Last edited:
The case Vince mentioned is demonstrated at addresses 201 through 203. It surprised me with what is generated.

Sweet! That's pretty much exactly what my cross assembler does since the expression parser rewrite.

With that in mind I don't see how that typo could have left the code working the way it was intended. Maybe it didn't work correctly but was brushed off as an unexplained glitch on the monitor. I suppose it could have just happened to have been assembled on page 3.

The exact case lacks a space between the I and the slash, though I wouldn't expect that to matter.
(I think the 0400 page, or any page with 0400 set in the address ".-1", would also work.)

The palbart suite comes with a script to fire up SIMH and extract the binary produced by PAL8, and it comes with "correct" binaries allegedly produced this way. I'm not sure all the binaries actually come from the script, as even in the "good" directory, some of those reference binaries are "off" in subtle ways that I wouldn't have expected from PAL8. Then there's another script to run palbart and see if they get the same answer, and if so, the case goes in the "good" directory, otherwise it goes in the "bad" directory.

I basically did the work of this latter script by hand for both "good" and "bad", getting various discrepancies, then convinced myself that my assembler was doing better than palbart (and sometimes better than PAL8, for a couple of the not-quite-legit constructs).

The exception was that I don't remember the on-page literals generated on a previous assembly to a particular page. I also don't remember page zero literals across visits to other fields. When you leave a page (or a field), the relevant literals are emitted, then forgotten (also at the end of the program). That's also what I expect PAL8 does. Palbart apparently does remember them, but I imagine it uses more than the 8K that can be assumed available to PAL8 to do it.

Oh, and I suppose I should someday implement EXPUNGE so that FOCAL will assemble correctly unchanged. (Just making it have no effect would also work for FOCAL, since the new definitions actually match the old.)

Vince
 
Tom,

Yes, the text "write" appears to be hard-coded where the warning appears - but the previous messages correctly identify the transaction as a read.

Does this imply there is a fault somewhere in the PDP-8 software end of the world (from your EDIT3 text) I wonder? I would be surprised if (after all this time) there is - but perhaps no one has tried with the disk almost full to the extent you have just fallen over...

Mike did find a problem with a paper tape reader driver when he tried to modify it for a parallel device (but it worked fine as a serial device). Not sure whether that was for OS/8 or just 'bare metal' PDP-8 now?

Dave
 
Back
Top