[Rpcemu] Hard disk image question
hfiennes at gmail.com
Sun Mar 6 16:27:31 PST 2011
Ok, so I first tried this and it didn't work at all; same issue. Then, after much hacking about (writing some code to generate checksums so I could just alter bytes willy-nilly and still have a valid bootblock, and faffing with everything including the spt and heads, based on some likely erroneous thoughts about LBA always being 63/16), I ended up having it first mount with a broken directory (though the disk name could be seen), then finally having it mounting correctly.
Backing out the changes one by one resulted in the magic bullet being indeed - as you had suggested - the 0x1 and all zeros in the 0xdbx line... AND prepending a blank sector to my image. Either one on its own wasn't enough, so I guess the IDE stuff appears to expect a certain format, which the raw ADFS SCSI partition wasn't satisfying.
For posterity/when I lose the disk image/anyone else who finds themselves in the same position, here's the code:
/* This makes my SCSI disk image work with RPCemu
First, prepend 512 bytes of zeros to the SCSI disk image, then run this code
to fixup the image
hfiennes at gmail.com 20110306
int main(int argc, char *argv)
unsigned char buf;
/* Generate known-good hardware-dependent area */
/* Calculate checksum and store */
/* Re-write */
....which I saved as chk.c, then did:
$ dd if=/dev/zero of=blanksector bs=512 count=1
$ cat blanksector scsiimage.hdf >hd4.hdf
$ gcc -o chk chk.c
Thanks to everyone for their help and suggestions! Now, to get the BBS running, and hook up some virtual serial ports to it :)
Sent with Sparrow
On Sunday, March 6, 2011 at 06:23 , Mark Adams wrote:
> I believe, ADFS is only interested in the boot block from 0xc00 to 0xdff.
> This is as follows:
> &c00 upwards - Defect list
> &dbf downwards - Hardware-dependent information
> &dc0-&dfb - Disc record
> &dfc-&dfe - Non-ADFS partition descriptor
> &dff - Check sum byte
> You've checked the disc record.
> The defect list is empty.
> There's no non-ADFS partition.
> I presume the checksum is correct.
> I'm assuming there is only one ADFS partition and there isn't any kind of partitioning such as was done by some third party drives.
> So that leaves the hardware-dependent information as a possible suspect.
> This contains data useful to the disk controller including information on how to map disk addresses to hardware addresses.
> What I think could be happening is that ADFS is using information in that area to determine the structure of the disk as presented on the IDE interface. However, the information relates to a SCSI interface and so is telling it the wrong thing.
> I think you need some data for that region from an IDE drive.
> My drive has all zeros except a single byte 0x01 at 0xdbb.
> So you could try that. You can try it in two ways:
> a) edit the data and re-calculate the boot sector checksum
> b) edit the data by moving bytes around to harmless places (the checksum is insensitive to the byte position)
> Option (b) is probably easier and would involve the following steps:
> 1. move bytes from 0xdb4 to 0xdbf inclusive to a safe place somewhere else in the boot sector, say 0xda4 to 0xdaf
> 2. set 0xdb4 to 0xdbf inclusive to 0x00
> 3. set 0xdbb to 0x01 and find a 0x01 byte in the previous data and set it to 0x00: i.e. set 0xdbb to 0x01 and 0xdac to 0x00
> On 1 March 2011 19:42, Hugo Fiennes <hfiennes at gmail.com> wrote:
> > Hi,
> > I just dug up a 20 year old SCSI drive from my old acorn BBS, and was trying to get the image file recognized by RPCemu; however, it just says :4 is unformatted. I did a little googling and tried some LBA-type hacks to the boot sector as suggested for a similar issue with imaged IDE drives, but no dice.
> > Does anyone have any idea what ADFS looks for in the boot sector? The image appears to be complete, I believe it was from either my A540 or RISCPC, and it's mountable under linux without issue.
> > In case it sheds any light, here's the first 32k od'ed (lots of zeros omitted, obviously!). The drive image is 520MB.
> > Thanks,
> > Hugo
> > 0000000 b7 7e fa f9 ae f5 7a e5 b7 7e fa f9 ae f5 7a e5
> > *
> > 0000c00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00
> > 0000c10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > *
> > 0000db0 00 00 00 00 0a 20 0c 0d ff 03 ff 03 01 06 00 1f
> > 0000dc0 09 20 04 00 0f 0b 00 00 00 3f 20 00 7f 02 00 00
> > 0000dd0 00 08 00 1f 00 00 00 00 00 00 00 00 00 00 00 00
> > 0000de0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0000df0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 de
> > 0000e00 b7 7e fa f9 ae f5 7a e5 b7 7e fa f9 ae f5 7a e5
> > *
> > 0008000 1a 82 21 4d 61 69 6c 44 69 72 00 00 00 00 00 3b
> > _______________________________________________
> > Rpcemu mailing list
> > Rpcemu at riscos.info
> > http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpcemu