[HECnet] RSTS/E is really picky

[John Wilson]

From: Cory Smelosky <b4 at gewt.net>

The disk is 1048778 blocks.   I created a 512M image and copied it 
bit-for-bit to the disk.

So you're saying the image *did* work under emulation and only broke when
you copied it to the first 512 MB of a disk that you then moved to a
controller with an unknown private partitioning scheme?

If I'm understanding you right then it sounds as if the controller may
indeed be storing its own stuff in the first block(s) and the partition for
DU1: isn't supposed to start until a few blocks into the drive.   I would
experiment with that by zeroing the disk, and then partitioning it on the
PDP-11 (I assume this is done with the SCSI controller's firmware), move
it to the PC and pull off the first few blocks, then repeat the process
with different partitioning (assuming that's possible -- or do you mean
the firmware is hard-coded to split drives into chunks .LE. 512 MB?), and
see what changes in those first few blocks.   It might be very obvious...

Another thing to do is generate a bunch of different boot blocks that look
like this:

	.word	240		;NOP (required by some boot PROMs)
	.word	0		;HALT (unless the PROM also requires a BR ...)
	.word	blkno		;block # you'll be writing this one to
	.blkw	253.		;(junk for the rest of the block)

... and copy them to the first N blocks of the SCSI disk.   Then when you
move it to the PDP-11 and boot from it, it'll halt, and if you examine the
word at 000004, you'll know which actual block was read in as block 0.
Then next time write your image starting at that block instead of 0,
and it might work.

If you wanted to get *really* fancy, maybe you could set up a Linux (etc.)
box as a SCSI target, and log the actual block #s accessed by the PDP-11?
Seems kind of ridiculous...

John Wilson
D Bit