[Rpcemu] Hard disk image question

Hugo Fiennes hfiennes at gmail.com
Sun Mar 6 16:27:31 PST 2011


Yay!

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
*/

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
unsigned char buf[512];
int a,chk=0;
FILE *f;

f=fopen("hd4.hdf","rb+");
fseek(f,0xe00,SEEK_SET);
fread(buf,1,512,f);

/* Generate known-good hardware-dependent area */
for(a=0x1a0;a<=0x1bf;a++) buf[a]=0;
buf[0x1bb]=0x1;

/* Calculate checksum and store */
for(a=0;a<511;a++) chk=(chk&0xff)+(chk>>8)+buf[a];
buf[511]=chk&0xff;

/* Re-write */
fseek(f,0xe00,SEEK_SET);
fwrite(buf,1,512,f);

fclose(f);
}

....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
$ ./chk

...and bingo.

Thanks to everyone for their help and suggestions! Now, to get the BBS running, and hook up some virtual serial ports to it :)

Hugo

-- 
Hugo Fiennes
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
> 
> Mark
> 
> 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...
URL: <http://www.riscos.info/pipermail/rpcemu/attachments/20110306/16de98e5/attachment.html>


More information about the Rpcemu mailing list