Indeed. I know it's cool to be modest and all but your board is amazing. And there will always be nut cases like me that will run RD54's and such into the dirt, cleaning the internal filters and properly lubricating the bearings and all :-) Chris On 10/25/2025 12:22 PM, Doc Shipley via cctalk wrote:

On Sat, Oct 25, 2025 at 7:48 PM Bill Gunshannon via cctalk < cctalk(a)classiccmp.org&gt; wrote: You can use the vtserver tool under Linux to transfer a disk image created via an emulator and have the hardware PDP write it to a disk or emulator. It runs over the serial console. The format of the simh (for example) disk container doesn't have all the data a physical disk has, the low level format. You can create an RD-image using the emulator by specifying the number of sectors and heads, and then use XXDP to low-level format it. Then use vtserver to transfer the simulator image. I have done this with my 11/23+ and 11/23 several times. Even to real physical MFM drives. Works great. I have not found any archives for images like that though. -Peter

On Sat, Oct 25, 2025 at 11:48 PM cz via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: If you don't mind? I for one am always curious about what's out there. I have gathered up a few of languages that I'm interested in, and a few other things but there's always room for more.:) -Peter

On Sat, Oct 25, 2025 at 07:30:58PM -0400, Bill Gunshannon wrote: I've linked to a few images people have sent me or I've made but I don't know of any large collection. https://www.pdp8online.com/mfm/status.shtml For many machines yes. For many DEC controllers what the OS sees isn't exactly the same as whats on the disk. Some space is used by controller and some remap bad sectors but don't use the sector headers for that. Someone would need to take the time to figure out what the controller is doing and write code to manupilate the images. I know RQDX3 remaps. Not sure about other controllers.

MSCP controllers do "bad block replacement", producing an error free logical address space from a physical space that has bad blocks in it. In some early controllers, like the UDA50, BBR required help from the OS driver. Also, MSCP introduced logical addressing not tied to the physical geometry of the device, enabling such features as variable sector counts on inner vs. outer tracks. PRO disk controllers don't do any remapping, though the drivers do. For the hard disk that amount simply to skipping the first sector, which is reserved for the powerup self test. For the floppy drive, the driver software implements the interleaving, track skew, and oddball cylinder numbering (matching what the RQDXn controllers do in the controller firmware). Some earlier devices, like the RM80, have spare sectors (one per track on the RM80). I think that was handled by flagging a bad sector with a header bit saying it was replaced, at which point the driver would use the spare instead. Most older DEC disks were simply a collection of physical sectors with bad sectors handled in the OS. The RK05 nominally had 3 spare cylinders but at least in RSTS those were never used. Bad sectors were typically marked as "in use" in the file system, so they would not be allocated. That information would be initialized from the DEC Std. 166 bad block table, if present on the particular device, and in any case bad blocks found by the pattern test pass of the disk initialization utility. Blocks going bad while in use tended to be a bit more problematic; RSTS/E had ways to handle this but they are quite primitive. paul