The history of PDP2011 is more or less linked to the disk controllers and the disk images they would work with. The first disk controller I implemented was for RL – basically, because there were Unix V7 images that I really wanted to be able to boot from, and next to that, there were the XXDP images that I hoped would help me find the last bugs that stopped just about everything from working, some time in 2008 or 2009.
As I had hoped, things did slowly work out that way – I did find some bugs, things improved, I could run more images, and so on – just not as fast as I had hoped for maybe, but still. At some point I added the RK controller – which let me run the RT-11+MUBAS image which was great fun, and again led me to some hard to find bugs. Meantime, V7 started working better and better. But not quite. So while waiting for the inspiration that would solve the next bug, I decided to add the floating point controller – it was needed for 2.11BSD anyway, and also – why not. And of course for 2.11BSD I needed to have a big disk.
Hence RP06, and the RH70/RH11 controller for it. From the start the controller could also do RM05 – that was because there are a lot of XXDP test programs for it, and I used those a lot to check the logic. But somehow I still missed that RM05 is actually a bigger disk than RP06… then again, all the images that I found back then were for RP06, and I didn’t really bother with other images after mostly everything started working. That’s where things stood, from 2010 or so up to now – apart from some vague mentions on this site of other drive types ‘that were not very well tested’…
In theory, you could have already configured for RP04, RP05 – and that would probably have worked fine. Or for RM05 – still not quite sure about that. RP06 – sure, that works very well, I’ve run several systems for over 10 years on it. RP07 – ehh, well, I didn’t quite manage to actually include the sector calculation logic for that one… I’ve added that now, and works very well with 2.11BSD.
Things got a bit more interesting a couple weeks ago however, when Johnny Billquist mentioned the RM06 and RP12 disks, and the magical old names that go with those that spell high-tech and high speed – Setasi and Shelby. These were optical and regular drives that would have an RP/RM style controller interface towards the PDP11, but would have modern (well, then) drives for the actual storage – I suppose those were the Shelby part of the story. Somehow that name still rings a bell – apart from the cars with the go-faster stripes, I mean.
At the same time this came up though I was running an experiment that I had wanted to do for a long time – make a new disk type based on the RM/RP controller, but with a different geometry. Since I had read in the sources of the XP driver in 2.11BSD that it would use whatever geometry is stored in the disk label, it had been on my mind – what would happen if I would just implement a disk with 64 sectors per track, and 64 tracks per cylinder? or 256 while I’m at it, and 65536 cylinders?
To test if that would work, I’d just need to add the new drive type to PDP2011 and create a bootable image for it. And for that last part, I’d also need for SIMH to support that same disk type – and, to make a long story not too much longer, that proved to be easy enough if I limited myself to 64/64 and a max total size of 2GBytes. Hence the name of the new drive – RP2G. The drive could theoretically be a whole lot bigger still, but that would require a lot more changes to SIMH to be able to create the image.
Then Johnny found the details in the RSX sources that suggested that the RM06 and RP12 used 32 tracks and 64 sectors. That made it clear that the people at Setasi had thought the same way I had… and, sure enough, when I put a new drive together, added the new controller command that Johnny found the details for, I could use my old walkthrough to create a new RSX image, and it worked just fine on the new 1GByte RM06 drive that I botched together based on the 64/64 work I had already done for the 2.11BSD 2GBytes drive. And with a lot more effort a week later – mostly because of mistakes and issues with my laptop, it even worked with the double amount of cylinders for an almost-2GByte RM06.
That’s where things stand at the moment. The bigger RP/RM disks have now been tested and found to work. For 2.11BSD, RP07 is a good choice if RP06 isn’t big enough – RP07 is 504MBytes, while RP06 is 170MBytes. It’s also possible to use the 64/64 artificial drive type that I’ve for now given the name RP2G – but, I find that 2G is a lot, and it is much more room than I need for 2.11BSD for now so I’d happily use the smaller disk type. Also makes managing the images so much easier. In both cases, you’ll have to create a disk label that describes the disk geometry and also you will have to create a modified boot sector that has the correct geometry for the disk. I’ll do a write up on how to do that some time soon.
For RSX, RM06 with a size of 1024 cylinders (ie, 1GByte) seems best – although I should say I’m hardly an expert on RSX, and things might change while I improve my build and learn more. For one, I haven’t really tried to use one of the newer RSX images that came out of the pidp-11 community yet. So bear with me – and also, I haven’t finished my usual tests, but I hope to release the new version on the download page soon – and with all the rain forecasted for the coming week, it could be any day…
Oh, a table would probably help:
|disk type||rh_type code||size (in 512-byte blocks)||tested with|
|RP06||6(default)||340670||2.11BSD, RSX, RSTS, Unix V7|
and I should probably add that for RM06/RP12 the number of cylinders is configurable – as it is for RP2G; the sizes shown here (# of 512-byte sectors) are based on the default of 1024 cylinders for the RM06/RP12/RP2G. The numbers shown here are however tested both with a (slightly) modified version of SIMH and PDP2011; while larger numbers of cylinders are probably trivial for PDP2011 since there’s no logic that has a dependency on the cylinder number, there is a lot of complexity to deal with in SIMH; the image size first crosses the 2GByte limit and then the 4Gbyte limit, and both seem to cause problems. I have not yet managed to find and fix all potential issues with that – and I’ll probably leave it to the SIMH maintainers to deal with, if they will.
That’s it for now, the new version should be up on the download page within a week or so – depending on the weather in NL.