Index of /pub/pdp11/boot/block

      Name                    Last modified       Size  Description


[DIR] Parent Directory        21-Oct-2000 00:40      -  
[TXT] bload.mac               21-Nov-1995 00:00     3k  
[TXT] boot.mac                21-Nov-1995 00:00     3k  
[TXT] dlboot.mac              11-Jan-1997 00:00     4k  
[TXT] dmboot.mac              13-Apr-1996 00:00     4k  
[TXT] dtboot.mac              13-Jan-1997 00:00     3k  
[TXT] duboot.mac              25-Nov-1995 20:25     6k  
[TXT] dyboot.mac              19-Jan-1996 00:00     6k  
[TXT] hdboot.mac              16-Nov-1995 00:00     1k  
[TXT] rkboot.mac              16-Nov-1995 00:00     2k  

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 soon.  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, that will 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 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 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).  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 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 to the boot block, 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.  Someone enlighten me!

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  <wilson@dbit.com>