This directory contains my unfinished public domain boot block package. 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 soon. 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. 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 actually been tested (OK well, that's all of them at this point), and only under a simulator (except for DUBOOT) so there may be lurking bugs if the simulation is incorrect. The comments in BOOT.MAC explain how everything fits together, and individual boot blocks are assembled with, for example: .MACRO/OBJECT:DYBOOT BOOT+DYBOOT .LINK DYBOOT/LDA ! can't use .SAV format because it 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, that will simplify all of this. BLOAD.MAC is the 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 56KB 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 two-block .SAV file, of which ONLY THE SECOND BLOCK should be copied to block 2 of the boot volume. When I write that .OLB-hacking program 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 the garage 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 10 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/350 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 (since I haven't figured out how to entice my Pro to even try to run a boot block, I don't know whether r0/r1 are set up correctly on entry, somehow I doubt it). Anyway the DU: code is tested only with an RQDX3 at this point, and it has no knowledge of RT-11 partitions because I don't either. 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 that too. Anyway let me know of bugs, problems, or great ideas. Hopefully this will all improve soon, 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, 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 ,