• Please review our updated Terms and Rules here

What did I do to my PDP-8 today.

Is no-one working on cool PDP-8 stuff lately?!

I continue to work on my "big list" of the DEC PDP-8 software. It continues to get more complete, and I am currently adding the DECtape and RK05 media that you could buy (for the -8 or -12) from DEC.

It is clear though that the list won't be "ready for prime time" by Christmas -- maybe New Years.

Remaining issues are meaningful grouping of "ax-*" and "bx-*" part numbers, and actually fetching as many of them as possible. Also, the web page has grown quite huge (over 2500 files) so the table is very awkward to page through. In general, the HTML needs to do a much better job of presenting things.

http://svn.so-much-stuff.com/svn/trunk/pdp8/src/xx/xx.php

Happy Holidays!

Vince
 
I don't know whether this classifies as 'cool' or not...

I am currently shaking the bugs out of my serial port driver for the PDP-8 4K Disk Monitor System (DMS).

I have modified it to talk serial to a disk server unit rather than a physical disk controller and drive for my PDP-8 LD12 project.

The bug I have just found today is the processing of an indirect return. The DEC documentation (sic) is not very clear on this aspect. You can read it in two (2) ways. I am sure I followed an example - but either I have misunderstood the example, or that doesn't work properly either... That is tonight's reading sorted out then...

The next problem I have is that the DMS appears to be loading a transient program (e.g. LOAD, PIP, EDIT etc.) but never seems to execute it or (if it does execute the program) it appears to be returning back to the MONITOR fairly instantaneously. I need to come up with a 'cunning plan' to trap that issue.

I next have a problem with PIP - as I think it contains it's own disk driver that I have to hack.

It would also be nice to get POLYBASIC to run as well. But that involves some disassembly...

Out of interest, does anyone if the source code to either the DEC PDP-8 4K DMS or POLYBASIC exists anywhere?

Dave
 
I am working on replacement paddles for 8/e and variants. I printed one a few days ago after posting about it in the replacement handle thread. It almost but not quite fit. I remeasured everything and fixed the problem(s) and am now printing 10 more yellow paddles (11 are needed). These are going to take about 5 and a half hours. Then I will print a set of 10 orange ones and put the panel back together to check the rest of the fitment. I will post more detail on the other thread either later today or tomorrow sometime.
 
I don't know whether this classifies as 'cool' or not...

Well, I thought so :)!
I am currently shaking the bugs out of my serial port driver for the PDP-8 4K Disk Monitor System (DMS).

I have modified it to talk serial to a disk server unit rather than a physical disk controller and drive for my PDP-8 LD12 project.

I haven't seen a DMS project in...ever? Is the LD12 a 4K only machine?

I was fairly pleased to check and find most of the pieces for a DMS project in the "big list".
(Let me know if you found other bits from DEC that I should include.)
The bug I have just found today is the processing of an indirect return. The DEC documentation (sic) is not very clear on this aspect. You can read it in two (2) ways. I am sure I followed an example - but either I have misunderstood the example, or that doesn't work properly either... That is tonight's reading sorted out then...

The next problem I have is that the DMS appears to be loading a transient program (e.g. LOAD, PIP, EDIT etc.) but never seems to execute it or (if it does execute the program) it appears to be returning back to the MONITOR fairly instantaneously. I need to come up with a 'cunning plan' to trap that issue.

I next have a problem with PIP - as I think it contains it's own disk driver that I have to hack.

I'm not familiar with DMS internals. I'd probably cobble up a SIMH environment and get it working there.

It would also be nice to get POLYBASIC to run as well. But that involves some disassembly...

If you need forensic tools, maybe my 8tools would be of some small help:
http://svn.so-much-stuff.com/svn/trunk/pdp8/8tools/
It doesn't know DMS file-system format yet, but there's a decent disassembler in there.

Out of interest, does anyone if the source code to either the DEC PDP-8 4K DMS or POLYBASIC exists anywhere?

I've got a version of POLYBASIC in the DECUS section of my website, but no relevant source code.

Vince
 
Yes, the LD12 doesn’t have any memory management circuitry, so it is limited to 4KW at the moment.

Yes, I am using SIMH - I am still building the LD12 hardware.... I have used it to get the initial RF08 disk images working and I am then using the disk image that SIMH created with my Java disk server - automatically overriding the disk interface driver with my own.

I think I loaded most of the constituent parts from your website in the first place...

I have written my own ‘noddy’ disk structure analyser. I have a few silly bugs to fix though...

I think I have got to the bottom of some of my bugs this evening. The interface between DMS and the disk interface software driver is not exactly as it is described in the manual! I have a bit more disassembling to undertake yet I can see...

Dave
 
The bug I have just found today is the processing of an indirect return. The DEC documentation (sic) is not very clear on this aspect. You can read it in two (2) ways. I am sure I followed an example - but either I have misunderstood the example, or that doesn't work properly either... That is tonight's reading sorted out then...

Care to expand what the issue is? I'm not even sure I understand what you mean by an indirect return. The only returns I know about are from a routine called with JMS, and the only way to return is to jump indirect through the start address, which I would hope there are nothing unclear about.
 
Is no-one working on cool PDP-8 stuff lately?!

I've got my TD8E working again; now I just have to give the left TU56 drive some attention.

Beside that I've been digitizing some message logs from "8BBS", the one and only PDP-8 BBS as far as I'm aware.
In time I'm aiming to recreate it on my 8/e, perhaps under MULTOS8 or TSS/8 once I get time to play with my RK05.


Not really... I'm just working on my RK05 exerciser project... Nothing special and not really PDP8 specific...

Ooh nice! If you have extras or make another run I'd like to buy one.


I don't know whether this classifies as 'cool' or not...

I am currently shaking the bugs out of my serial port driver for the PDP-8 4K Disk Monitor System (DMS).

I have modified it to talk serial to a disk server unit rather than a physical disk controller and drive for my PDP-8 LD12 project.

Neat, I had been wondering what to do about storage on the LD12.
Speaking of which, since the LD12 is an 8/I workalike, will your server also work with the original 8/I? I have a friend who's just acquired one and we've been wondering if something like what you describes exists. I know there's also os8diskserver but IIRC it expects an 8/E.
How's the front panel coming along BTW?

-Tom
 
Apart from a bit of tweaking to hole sizes and the silk screen text, the LD12 front panel should be “good to go” to fab. early January. The fun then starts in hoping that all of the mounting holes etc. are ok!

Yes: my disk server, bootstrap and DMS system driver should work on any physical machine from a straight-8 upwards. I am trying to avoid anything that is machine specific if I can. The only thing that is required is 4KW memory and two serial ports - one for the console and the second for the disk server. You will get the source code anyhow, so you can tweak the IOTs if you wish for the second serial port - or anything else come to that!

You will have to ‘hand crank’ the bootstrap into the machine initially, but that would have been true on any PDP-8 of the time. The bootstrap will get overwritten by DMS (or more correctly the utilities) when used - so core store wouldn’t have helped on a 4KW machine. Larger than 4KW - yes, but then you would probably be using a version of OS/8?

Unfortunately, the link at that Vince supplied back in post #89 doesn’t actually contain the source code for DMS itself, but for some ‘add ons’ that a company (?) provided. Some files also appear to be of zero length, so don’t seem to contain anything useful!

>>> Care to expand what the issue is?

I will do in a later post. I need a better keyboard than the virtual ‘thing’ I am using on the iPad at the moment...

Dave
 
Last edited:
I’ll correct my previous post if I may...

If you have core store, and don’t corrupt memory from 7600 to 7777, you can restart DMS from address 7600.

In the LD12 (because of the volatile SRAM) you will have to re-enter the bootstrap again.

I am thinking of a ROM-based bootstrap for later...

Dave
 
>>> Care to expand what the issue is?

So I have been working on this problem today.

The 'indirect return' I was referring to is not a PDP-8 instruction - but the way the 4K Disk Monitor System (DMS) exits from the read/write system driver.

There are two (2) ways of doing this: (1) directly and (2) indirectly.

if you look at document https://www.pdp8online.com/pdp8cgi/query_docs/tifftopdf.pl/pdp8docs/dec-08-odsma-a-d.pdf in Appendix E you will see a good example of a direct return - and a very poor description of the indirect return mechanism.

Back on page C-4 there appears to be a better example of an indirect return - but it is still a little confusing to me...

Anyhow - I think I have implemented the code as per the DEC disk driver. I have had to start 'optimising' my code to fit it all in the available space...

However, things still don't work (even when no indirect READs are performed) - so I was chasing a ghost!

Anyhow, on start-up I get the '.' prompt as expected.

Typing the name of a utility that doesn't exists (e.g. "DER") gives me the "?" response as expected.

Typing the name of a valid utility (e.g. "PIP", "EDIT" or "LOAD") appears to result in the correct blocks being loaded from the disk into memory; but the utility never gets executed.

Code:
.DER
?
.PIP
.EDIT
.LOAD
.

I have put a SIMH break where the MONITOR enters address 7600 to save the two scratch blocks and reload the code into 72XX to 75XX - and the SIMH instruction history appears to think that the utility execution address is 0000 (i.e. none) so it returns to the MONITOR at address 7600 as a result.

I have dumped the disk directory out (DN and SAM blocks) and I can confirm that the DN does (in fact) contain the correct load and execute addresses and the SAM contains the correct block numbers for the utility contents.

DN:
Code:
First scratch block ........ 0373(8).
Two digit version number ... 4146(8) = 'AF'.
Block number of first SAM .. 0200(8).
File number 1(8)...
Filename 1/2 .. 4570 = 'EX'.
Filename 3/4 .. 0043 = ' C'.
Load address .. 7000.
Entry Point ... 7000.
Flags ......... 6101. SAVE FILE 0 SYSTEM 01.
File number 2(8)...
Filename 1/2 .. 6051 = 'PI'.
Filename 3/4 .. 6000 = 'P '.
Load address .. 0000.
Entry Point ... 1000.
Flags ......... 6102. SAVE FILE 0 SYSTEM 02.
File number 3(8)...
Filename 1/2 .. 4544 = 'ED'.
Filename 3/4 .. 5164 = 'IT'.
Load address .. 0000.
Entry Point ... 2600.
Flags ......... 6103. SAVE FILE 0 SYSTEM 03.
File number 4(8)...
Filename 1/2 .. 5457 = 'LO'.
Filename 3/4 .. 4144 = 'AD'.
Load address .. 7400.
Entry Point ... 7400.
Flags ......... 6104. SAVE FILE 0 SYSTEM 04.

SAM:
Code:
0000: 0101 0101 0101 1401 1401 1401 1401 1401 
0010: 1401 1401 1504 1504 1504 1505 1505 1505 
0020: 1505 1505 1505 1505 1504 1504 1502 1502 
0030: 1502 1502 1502 1502 1502 1502 1502 1502 
0040: 1502 1502 1502 1502 1502 1502 1502 1502 
0050: 1502 1602 1602 1603 1603 1603 1603 1603 
0060: 1603 1603 1603 1603 1603 1603 1603 1603 
0070: 1603 1606 1606 1606 1606 1606 1606 1606 
0100: 1606 1607 1610 1610 1610 1610 0010 0010 
0110: 0010 0011 0011 0011 0011 0011 0011 0011 
0120: 0011 0011 0011 0011 0011 0011 0011 0011 
0130: 0011 0011 0011 0011 0011 0011 0012 0012 
0140: 0012 0012 0013 0013 0013 0013 0013 0013 
0150: 0013 0013 0013 0013 0013 0013 0013 0013 
0160: 0013 0013 0013 0013 0014 0014 0014 0414 
0170: 0414 0414 0414 0114 0114 0114 0014 0001 
0200: 0401

Slightly better directory listing:

Code:
File number 2(8)...
Filename 1/2 .. 6051 = 'PI'.
Filename 3/4 .. 6000 = 'P '.
Load address .. 0000.
Entry Point ... 1000.
Flags ......... 6102. SAVE FILE 0 SYSTEM 02.
BLOCK: 0026, 0027, 0030, 0031, 0032, 0033, 0034, 0035, 0036, 0037, 0040, 0041, 0042, 0043, 0044, 0045, 0046, 0047, 0050, 0051, 0052, 
File number 3(8)...
Filename 1/2 .. 4544 = 'ED'.
Filename 3/4 .. 5164 = 'IT'.
Load address .. 0000.
Entry Point ... 2600.
Flags ......... 6103. SAVE FILE 0 SYSTEM 03.
BLOCK: 0053, 0054, 0055, 0056, 0057, 0060, 0061, 0062, 0063, 0064, 0065, 0066, 0067, 0070, 
File number 4(8)...
Filename 1/2 .. 5457 = 'LO'.
Filename 3/4 .. 4144 = 'AD'.
Load address .. 7400.
Entry Point ... 7400.
Flags ......... 6104. SAVE FILE 0 SYSTEM 04.
BLOCK: 0012, 0013, 0014, 0024, 0025, 0367, 0370, 0371, 0372,

It appears that either the execution address is not being processed correctly, or it is being overwritten by something later on.

I will need to come up with a debug strategy...

That's tomorrow's job though!

Dave
 
Last edited:
Interesting. I had never looked at this system before.

I think I understand how the indirect return is supposed to work, but since I don't have a system, I can't even start to test if me understanding is correct.

But just in case it might help you, here is my understanding from the manual:

In the indirect call, the block, address and link are read and handled the same way as for the direct call. However, the driver then reads in, in addition, the next word (which is the "ERROR" address). This is then stored as the return address to use. I assume it means it actually just puts this address in to the return address word for the routine.

This means that you will never return to where you were called from when you have an indirect return.

At the completion of the routine, if everything was successful, this read and saved address is then incremented by one, and if there was an error, it is not incremented.

After that, a jump is made to this address.

So in one sense, error indication is done exactly the same way as in the direct case. On success, the return address is incremented.

However, the return address is always just read out from the error value/argument after the call.

And, I even saw this hinted, this implies that the code that did the call to the I/O routine can be overwritten by the I/O routine itself, without problems. The return address have already been read out before any I/O is performed. And this also explains the example in appendix C, where you have an indirect call, which then gets to the command decoder, but at address+1, where it should be calling, since the successful I/O operation will increment the return address before returning.

I hope this all makes sense... :)
 
Yep, it all makes perfect sense - and is what I did originally...

However, I think I have been partially led down a blind alley somewhere.

When I was running this scheme - I tripped over what seemed to be a problem. When I invoked LOAD (the simplest utility) I was unceremoniously 'dumped back' at the instruction at 7601 (which, in my implementation, is the parameter list for the first scratch block WRITE following the "JMS SYSIO". My hand disassembly of the DEC 4K DMS RF08 driver and the TD8E version presented here https://www.osti.gov/servlets/purl/5006739 both have constants appearing as the first 'executable' instruction at address 7600. I moved one of my constants into this location and then LOAD didn't 'bunk out' anymore - but it didn't work either!

This was when I found out that all of the utilities (LOAD, PIP, EDIT etc.) all end up back in the MONITOR and never appear to execute properly.

I have done a bit more 'sloothing' today and identified one silly that I have corrected...

When an indirect return is required, storing the LINK word back into the list of parameters that SYSIO was called with would result in corruption - especially if the block that has just been loaded overlaid the call in the first instance! This now makes sense based on my disassembly of the DEC RF08 driver. If an indirect return is requested, the address of the link word is modified to point to an unused/irrelevant or sacrificial word within the driver. The read link word is then stored here rather than corrupting the previous disk read. Even with this it is still not working.

Either way, if you load (for example) PIP - no indirect returns are invoked - so this is still a red herring...

I have added some further debug code to my driver and server and I can now see pretty much what is going on at the disk level. Where I 'think' the execute address should be stored in memory is just not being correctly processed. I can see the disk directory (DN1 block) being read correctly from my server - but the address 7526 ends up with 0000 stored in it.

I have gone back to SIMH with the same disk image I am using plus the standard DEC 4K DMS RF08 driver - and this works perfectly - so I know my disk image is OK. Using a similar diagnostic method, I can see word 7526 being correctly updated with the execute address of the utility as well.

Following the '.' prompt, if I type 'PIP' then I see the following:

Disk READ block 10 into address 7200. Word 7526 ends up with 0032 in it just after the disk read. This is described as the "MONITOR 1ST PAGE OF CALL". This is the same for the DEC RF08 driver and my own.
Disk READ block 177 into address 7400. Word 7526 ends up with 0000 in it just after the disk read. This is the DN1 block. This is the same for the DEC RF08 driver and my own.
Disk READ block 200 into address 7400. Word 7526 ends up with 0011 in it just after the disk read. This is the SAM1 block. This is the same for the DEC RF08 driver and my own.
Disk READ block 5 into address 7400. Word 7526 ends up with 0000 in it just after the disk read. This is described as the "MONITOR 2ND PAGE OF CALL". This is the same for the DEC RF08 driver and my own.
Disk READ block 26 into address 0000. Word 7526 ends up with 1000 in it just after the disk read for the DEC RF08 driver and 0000 with my own. This is the first block of PIP. Clearly, somewhere between reading block 5 and executing the code within it and then reading block 26 something has gone wrong.

I just need to find out where the error is :)!

Unfortunately, it seems as though the SIMH RF driver doesn't have disk read/write diagnostic capability built in.

On the plus side, I see that memory from 72XX, 73XX, 74XX and 75XX is written to scratch blocks 373 and 374 when the MONITOR is entered erroneously. These contain what should be the errant code from the 1ST and 2ND pages of CALL.

The fault is clearly mine - somewhere...

Dave
 
Last edited:
SOLVED!!!

When I was single stepping I noticed that the execute address for PIP was getting stored correctly in one memory location (7205) and then read out of there and transferred to a different memory location. This latter memory location was 7526 using the DEC RF08 driver but 7566 using my driver and server.

I then started to notice that the first word of some disk blocks had OCTAL 40 added to them...

My diagnostics in the server indicated the word was correct when it was sending it out - but was getting corrupt when it was read into the PDP-8 (SIMH).

I then noticed that some idiot (me) had forgotten to clear the L register before shifting the first byte 6 bits read from the UART to the left and ORing with the second 6 bits read from the UART. I was inadvertently setting a bit within the disk word that was being transferred. However, within the read loop for subsequent words, the L register was being cleared - so all subsequent disk words were read OK.

I just tried removing all of the debug code and invoking PIP (to perform a disk directory listing) and running LOAD and EDIT. They all seem to come up with the correct initial response; and PIP lists the directory correctly.

It is getting a little late in the UK now - so I will perform some more exhaustive tests tomorrow...

I will now have to think about optimising the driver a bit more to fit within the permissible 128 WORDS...

Dave
 
I noticed the potential problem with the LINK, but my suspicion/assumption was that this would be written before the I/O operation takes place. Thus, if the read is overwriting the page where the code is, the updating of the LINK happens before, so no corruption.
 
Unfortunately, things aren't quite that simple...

The disk (and tape units) contain 129 WORDS per block whereas the memory is divided into 128 WORD 'blocks'.

Unfortunately, the disk/tape units can only read/write the words sequentially from a specific start address within core.

The first 128 WORDS of the disk/tape block are stored into (or retrieved from) core. However, the 129th word has to be inserted in there as well for the disk/tape controller to process it. This would (if not handled correctly) corrupt the first word of the next memory 'block'.

This is the purpose of the LINK word stored within the disk/tape parameter block (supplied to the SYSIO call) and a temporary memory location within the disk/tape driver.

On a disk/tape write the following action is taken:

1. Store the 129th word in memory into the drivers local store to prevent it from being corrupted.
2. Copy the LINK word from the disk/tape parameter block into the 129th word in memory.
3. Perform the disk/tape write operation. This will write out 129 contiguous words from memory to the disk/tape block.
4. Restore the 129th word that was stored away in step 1 back into memory.

On a disk/tape read the following action is taken:

1. Store the 129th word in memory into the drivers local store to prevent it from being corrupted.
2. Perform the disk/tape read operation. This will read in 129 words from the disk/tape block into memory.
3. Copy the 129th word from memory into the LINK word of the disk/tape parameter block.
4. Restore the 129th word that was stored away in step 1 back into memory.

You can now see the problem with an indirect return from a disk/tape read identified within step 3. If the transfer overwrote the JMS instruction and the disk/tape parameter block, storing the LINK word would corrupt what was just read. The DEC driver(s) appear (under these circumstances) to still transfer the LINK word - but they point the address it will be transferred to at a safe/unused memory location within the driver itself. Basically, they dump the word to somewhere safe...

That's my understanding anyhow.

Within my serial implementation, I don't have any such limitation of course. The driver is responsible for 'shovelling' 128 words to/from core and the LINK word directly from the disk/tape parameter block to/from the serial port. The only additional thing I had to incorporate was finding a suitable location to 'dump' the LINK word into on an indirect read operation.

Now, I just have to obfuscate the code a bit to recover some space and make it all fit within 128 words...

I suppose the thing is (now I have found a problem with my serial port read routine) is to identify whether it is robust for 'real world' PDP-8 serial ports or not. Would some kind PDP-8 owners be able to identify a few things for me?

1. Serial port module number.
2. What octal values to you observe in the serial port receive buffer when you type various characters on the terminal device connected to the serial port for a given sequence of characters (e.g. ABCDEF XYZ 123 789).

Does what you receive vary depending upon whether you have parity enabled or not - and whether it is odd or even parity?

My code assumes that the only bits I get back relate to the ASCII value of the character itself. The code I currently have is:

Code:
GETNUM,	0		// Get a number from the server into AC.
			// This code assumes that the server only sends 6 valid bits in the byte through and
			// the serial port hardware doesn't set any 'mysterious' bits in the value returned
			// (e.g. parity or start bits etc.).
	SKCC		// Clear AC and flag.
	// Wait for a character to be received...
	SKSF		// Skip the next instruction if the flag is set.
	JMP .-1		// Loop on last instruction until the flag is set.
	SKRB		// Read buffer to AC.
	CLL		// Make sure the L register is clear before rotating! TODO: Combine with the RTL instruction to save a word...
	RTL		// Rotate AC twice left. Making 2 rotates in total.
	RTL		// Rotate AC twice left. Making 4 rotates in total.
	RTL		// Rotate AC twice left. Making 6 rotates in total.
	// Wait for another character to be received...
	SKSF		// Skip the next instruction if the flag is set.
	JMP .-1		// Loop on last instruction until the flag is set.
	SKRS		// OR AC with what is in the receive buffer.
	JMP I GETNUM	// Return to caller.
My concern is this will not work under all circumstances unless I start performing some masking.

In the meantime, I will look around for other examples on the internet... I think I used Kyle's SerialDisk as the basis of my code in the first place (but missed the CLL out in the process :-().

Dave
 
Last edited:
I admit being a little confused by the LINK.

I did notice that when reading, the LINK appears to be expected to hold the next block to be read in the file, and contain 0 when you are at the last block.
But it was not clear what to do at write. You could of course just say that when writing, you need to provide the information exactly like this.

But when doing indirect, if you are not overwriting the same page, then I would assume code would still expect the LINK to behave that way, or else I can't see how things will work.

But you do have a point in that, in case case you actually do read all 129 words of a block, it becomes complicated. With DECtape, I know that you don't have to. OS/8 do not, even through the block itself always have 129 words.
RF08 do not, as far as I can recall, require that you read in all 128 or 129 words.

So, my assumption was actually that, when reading a file, the driver/system would be checking where the next block of the file was located, and provide LINK from there, before reading the actual content. But like I said, this is pure speculation on my part.
 
I suppose the thing is (now I have found a problem with my serial port read routine) is to identify whether it is robust for 'real world' PDP-8 serial ports or not. Would some kind PDP-8 owners be able to identify a few things for me?

1. Serial port module number.
2. What octal values to you observe in the serial port receive buffer when you type various characters on the terminal device connected to the serial port for a given sequence of characters (e.g. ABCDEF XYZ 123 789).

Does what you receive vary depending upon whether you have parity enabled or not - and whether it is odd or even parity?

My code assumes that the only bits I get back relate to the ASCII value of the character itself. The code I currently have is:

<code example deleted>

My concern is this will not work under all circumstances unless I start performing some masking.

In the meantime, I will look around for other examples on the internet... I think I used Kyle's SerialDisk as the basis of my code in the first place (but missed the CLL out in the process :-().

I am not certain what you are asking when you ask about serial port module number. But I don't think it matters because all the serial ports transfer the full 8 bits in AC4 through AC11. The transfer into the AC is a logical OR operation which is why you have to clear the AC somehow. In the case of the console this was done by setting bit 2 in the IOT which clears the AC and the transfer complete flag. The KCC (6032) which only clears the AC and transfer complete flag while the KRS (6034) does the logical OR of the buffer with the AC. The KRB (6036) is a combo of the previous two instructions where the AC and transfer complete flag are cleared and then the buffer is logically ored with the AC. I believe this was kept for all the serial ports although they didn't have to do so. The Routines like yours that are trying to build 12 bits from two transfers take advantage of this fact. If you have your server serial port set to 8 bits no parity then you will see the 8 bits you send. If you set your server serial port to 7 data bits with parity then the PDP-8 will see 7 data bits in AC5 through AC11 with the parity bit showing up in AC4. In other words, the 8 will get what you send up to 8 bits. On the machines that used UARTs it was possible to change the jumpers or switches to get other options but this was not normally done. The ASR 33 and 35 as shipped by DEC were configured to send 7 bits with mark parity which means that the 8th bit (shows up in AC4) was always set. An ASCII A, B, C was 301, 302, 303 octal. But this was a function of the terminal, not the serial port. Most of the OS/8 programs did mask off the 8th bit so it was generally ignored but this would not be necessary in your case since your server serial port is under your control.

With all that in mind, what you have should always work with the assumption that the server side always sends a zero in the upper 2 bit positions so that they show up as zero in AC4 and AC5.

I have never looked at DMS since I was never on a machine that had only 4k. Since PS/8 ( later renamed OS/8 ) has its SYS handler starting at 7607 on up to 7743. This means an OS/8 SYS handler has to fit in 93 words. You mention that in DMS the handler is on the last page and the entry point for DMS is 7600 so I am guessing that they are similar in this regard. I have modified a version of Kyle's serial disk that uses three 8 bit characters to transmit two 12 bit words giving a 25% bump in speed. There wasn't room in the SYS handler to do any of this so it applies only to the non SYS handler. I have been unable to get both read and write to fit if I include the control C checking as well. So I made it conditional assembly and you can choose two of the three options. It has not been tested since I needed/wanted to make rather extensive changes to the server side as well. I really need to get back and finish that.

Best wishes!
 
Back
Top