OS/8 running on a PDP-8/L with 8KW memory and a non-standard mass storage device.

[vrs42]

Since it's only a DTXA rather than a DTCA DTXA, it will XOR the GO bit with 1

Ah. Thank you sir!

 

[antiquekid3]

You are most welcome!

 

[vrs42]

does it matter at all what I answer to the "CORE?" prompt?

Looked into this. The resulting images for "4" have CDF CIF instructions disabled, so presumably will fail with larger programs. The resulting images for "8" and "32" are identical, and have the MMU instructions enabled. (A grand total of three words changed from the 4K images.)

 

[vrs42]

What is the "patch" to PIP, do I need it, and how is that loaded?

I'm looking at the PIP patch, and it appears to consist entirely of a new RF08 driver. At 1314 it loads the text "RF08?", and at 5200 it loads a new resident page with a new/different RF08 driver in it.

 

[daver2]

This is what I was saying earlier (although I confused myself with OS/8 and DMS) in that PIP contains a driver itself.

When you say PIP "patch", where is the patch located in the net?

Dave

 

[vrs42]

dec-d8-sba1-pb
DEC-D8-SBA1-PB(L)     3/21/69
Patch to D8-SBAE Builder for
use with RF08 only  R022A.PAT
After loading this tape start at 0200

You can look for sba1 here:

Software Files

 

[daver2]

Thanks Vince.

I knew it would be on your site somewhere!

Dave

 

[vrs42]

I'm looking at the PIP patch, and it appears to consist entirely of a new RF08 driver. At 1314 it loads the text "RF08?", and at 5200 it loads a new resident page with a new/different RF08 driver in it.

I finished the disassembly of the driver from the patch. The patch is interesting/wierd. It is meant to be applied to the "AE" version of PIP. It replaces the prompt "PDP-8/S?" with "RF08?", and updates the RF08 driver. There are no other changes, so apparently the PDP-8/S? prompt used to load a special (DF32? RF08?) driver for the 8/S, or something.

 

[daver2]

I have a partial disassembly I am working on for dec-d8-pdze-pb (PIP-RF08) and the memory it occupies is from 0 through to 5177. The RF08 'device driver' appears to be distributed throughout the code rather than localised to one area - however, this may not be 100% correct, as further disassembly may contradict my current knowledge.

It is interesting that the patch has located a new 'driver' at 5200 (just above the PIP code itself by the looks of it).

I would be interested in your disassembly at some point, as there must also be some patches to vector to the new entry point(s) somewhere from the existing PIP code - or is this version of PIP different to the one I have been disassembling I wonder?

Dave

 

[vrs42]

I would be interested in your disassembly at some point, as there must also be some patches to vector to the new entry point(s) somewhere from the existing PIP code - or is this version of PIP different to the one I have been disassembling I wonder?

From what I can see there seem to be memory layout differences for all the different versions of PIP that I have. The only one that lines up with the patch is the sbae version. My current thinking is that in the AE version, PIP likely came with drivers for the TC08, DF32, and a tweaked DF32 driver for the 8/S. The RF08 patch, then, simply replaced the special driver for the 8/S with one for RF08. Without a deeper look at AE PIP internals, I don't know it for sure, but that's what I suspect.

I'd also like to directly compare the AE and AF RF08 drivers, as they seem rather different. If I can decide what to call the patch driver, I'll check it in .

I also have a noob question. When I use the RF08 version of PIP, I get S0:-S7:, as expected. If I use PIP's L option to list the directories for S1:-S7, they are empty, which isn't surprising. However, the free block count isn't right. I think that the directory is all 0000 (since it's a new volume and SIMH hasn't put anything there), which is OK, sort of. However, having the SAM be all zero isn't quite right. The underlying situation is that S1:-S7: need to get initialized properly. How do I do that?

 

[daver2]

Good question regarding S1: to S7:.

I'll have a think - I have half an hour spare before my next meeting...

Dave

 

[daver2]

I just found an interesting page (F-2) in manual at: https://www.pdp8online.com/pdp8cgi/query_docs/tifftopdf.pl/pdp8docs/dec-08-odsma-a-d.pdf related to the S: and S0: duality issue you raised previously.


There is a "note 1" associated with the S: device name for an RF08. This is in the footnote for the page as:


I will give this a go this evening (along with dumping my RF08 SIMH disk to see what the blocks for S1: look like).

It looks like using a directory listing may not have been conclusive about the 'duality' of S: and S0:. Perhaps a different PIP option does take S: and meaning S0:?

If the note is correct, the "temporary restriction" is a "permanent restriction" now!

Dave

 

[vrs42]

It looks like using a directory listing may not have been conclusive about the 'duality' of S: and S0:. Perhaps a different PIP option does take S: and meaning S0:?

I wonder why it couldn't have been treated like the DECtape case where S: and D0: are presumably the same drive. Maybe that would have created an issue where the DF32 driver would need to reject I/O to units 1-7.

 

[daver2]

I tried copying PIP as a system file and the 'S' option does permit the use of S: and S0: interchangeably as the first disk!

Dave

 

[daver2]

I examined the virtual RF08 disk image I created from the original paper tapes using SIMH and the 'other' 7 disk drives (S1: through S7 and all appear to have 'empty' (but valid) DN and SAM blocks allocated to them.

Therefore, something must have created these. I assume the system builder did?

PIP tells me there are 1756 (octal) free blocks on each of S1: through S7:.

This seems to make sense...

3 DN blocks (DN1, DN2 and DN3).
4 SAM blocks (SAM1, SAM2, SAM3 and SAM4).
3 scratch blocks.

Total used = 12 (octal) blocks.

The blocks are numbered from 0 through 1767 (octal), giving 1770 (octal) blocks in total.

1770 (octal) - 12 (octal) = 1756 (octal) blocks free.

Dave

 

[vrs42]

I seem to have been confused slightly, as SBAE is a part number for BUILDER, rather than PIP, but otherwise my comments apply. I looked at AC, AD, and AE, and they all have drivers at 5200, 5600, and 6000. The AF version has the drivers at 2200, 2400, and 2600. The message/query part of the patch still only lines up with the SBAE version, though.

 

[daver2]

So the AF version now makes sense (I will check).

Dave

 

[daver2]

It's pretty worrying (!) but I am starting to understand the RF08 variant of DMS PIP. I hadn't realised I had got as far as I had with my previous disassembly. I can now see the code for initiating a read or write transfer and start to follow it. Not 100% sure of the mathematics in there - but it must evaluate to calculating the respective values for the RF08 DMA and EMA registers, and the WC and CA memory locations.

I do see that it is an interrupt-driven driver within PIP. Hence (in order to implement a serial server arrangement) I will also have to hack it. Perhaps adding my code to the end of PIP and patching accordingly is the best way to go.

I will also have to do a similar thing with the DMS build tape - this is probably going to take a similar route to the PDP-8/S vs RF08 patch tape...

Dave

 

[vrs42]

I have checked in an update to the DMS driver disassembly work:

svn - Revision 5716: /trunk/pdp8/dms/drivers

https://svn.so-much-stuff.com/svn/trunk/pdp8/dms/drivers/README.txt

 

[vrs42]

I would be interested in your disassembly at some point

I finally integrated the code I was disassembling from the patch with the code in the drviers directory above. The file sba1.bin is the reference binary, and rf08-ae.* are the disassembly. The Makefile will assemble as needed and check the result. The README describes the various files.