This directory contains my unfinished public domain boot block package (the support code is what's unfinished; the boot blocks themselves cover a pretty wide range of devices). As yet I provide no way to write a bootstrap on a device, which makes them difficult to use, but I hope to do something about this eventually. So you'll have to write a little quickie program to do it. bload.mac Secondary bootstrap loader, loads a .SAV file. boot.mac Boot block prefix file, defines macros. dlboot.mac RL11/RL01,RL02 boot block. dmboot.mac RK611/RK06,RK07 boot block. dtboot.mac (*) TC11/TU55,TU56 DECtape boot block. duboot.mac (*) MSCP boot block (with hopeless unfinished Pro code). dyboot.mac RX01/RX02/PDT11 boot block (PDT code not tested). hdboot.mac HD: boot block (Ersatz-11 specific). rkboot.mac RK11D,RKV11/RK05 boot block. Only those boot blocks marked with (*) have been tested on real hardware (the rest have only been tried under simulation), so there may be lurking bugs in the others if the simulation is incorrect. The comments in BOOT.MAC explain how everything fits together, and individual boot blocks are assembled with the following commands (DY: boot used here): .MACRO/OBJECT:DYBOOT BOOT+DYBOOT .LINK DYBOOT/LDA ! can't use .SAV format because file loads at 000000 Getting the boot block into a useful form at this point is Your Problem. I find Jim Cook's ABS2PDP program (part of the PDPXASM package, available on this host) to be very useful. I'm hoping to write a program that knows barely enough about .OBJ formats to be able to extract boot blocks from an .OLB file and write them directly to block 0 of a device, which would simplify all of this. BLOAD.MAC is a handy secondary boot loader, which searches an RT11-format directory for the load module. At the moment it makes brash assumptions about the machine having at least 56 KB of memory. Also it should be clearing all of memory to initialize the parity/ECC bits but it doesn't. Anyway at the moment it assembles to a three-block .SAV file, of which ONLY THE THIRD BLOCK should be copied to block 2 of the boot volume (since the primary boot blocks load blocks 2-5 of the boot volume at 002000). If/when I write that .OLB-hacking program (or whatever it turns out to be) it will have BLOAD embedded in it so this won't be a problem. The DY: boot block auto-detects at boot time whether the disk controller is an RX11, RX211, or PDT-11/150, and it is intended to handle "RX03" disks on an RX211. I haven't yet schlepped my PDT out of storage to verify the PDT code, and my PDT programming manual is buried in a hill of debris so I'm just hoping some PDT code I wrote 25 years ago is right since that's what I used as a guide. I was hoping the DU: boot block could auto-detect the Pro/3xx so that one RX50 would boot either machine, but I don't think they'll both fit. Things are very tight now and I haven't tried to write the code to locate the controller's slot (I haven't figured out how to entice my Pro to even TRY to run a boot block, so I don't know whether R0/R1 are set up correctly on entry to the boot block, but somehow I doubt it). Anyway the DU: code is tested only with an RQDX3 at this point. The structure of the boot blocks is intentionally different from either RT-11 or RSTS, just to ensure I don't accidentally write code that looks much like DEC's. The whole point of this project is to avoid licensing hassles... I don't know anything about RSX boot blocks so I couldn't make a big thing out of differing from them too. Anyway let me know of bugs, problems, or great ideas. Hopefully this will all improve eventually, and I'll have a utility program that can quickly slap together a bootable Fuzzball pack (or whatever else) on any disk. Fuzzball is going to need some more disk drivers first, and I'm trying to learn enough to write them. Evidently Fuzzball needs to have code added to handle allocating UMRs -- Unibus CPUs rule!!! It also needs to have the CPU type split into per-feature flags, since the existing system is fragile. John Wilson