That's pretty much how I do it with Disc Image Manager - I read where the header should be and if it isn't valid, try again 512 bytes later.
On 19/12/2021, 14:34, "Justin F" <[email protected] on behalf of [email protected]> wrote: Hiya, I've been implementing a fake block device driver in Pyromaniac and found that I was unable to access the hard disc files used by RPCEmu. All I was doing was the (I thought) most obvious solution of treating the disc file as a raw sequence of bytes. That's not how the HDF works, and from reading the ide.c source in loadhd and a clue from David Thomas, I see that it does some jumping around to decide whether it should skip 512 bytes at the start of the file. There's no justification given in the comments, so I tried to work out a reason for it. Other than 'leaving space for a potential header in the future, but still working with raw disc dumps', I couldn't come up with one. It would be handy if such things were described, so in my implementation I've left some commentary of this to explain it in the future. I offer that code and commentary in case it helps someone to improve the existing RPCEmu (ie someone could explain why this juggling is done), or someone can explain where it's wrong and I can update my code This is python code, and it's based an an existing BlockData class which provides the guarded access to the disc image between a given offset and size: ---- class HDFBlockData(BlockData): """ Handle a block file for a HDF file, as used by RPCEmu. These files are based around the storage of a harddisc image as written by the controller in RPCEmu using the parameters stored in the FileCore disc record at the start of the disc (disc address &C00). However, there is the potential for all the disc data to be offset by 512 bytes. The algorithm basically allows the HDF reader to read a raw FileCore image if one has been given, but defaults to the image being at offset 512. The result is that newly created discs will have the 512 byte header. Existing discs which skip a 512 byte header will be just fine. Existing, and newly ripped, discs that are just a dump of the disc contents will be fine. There's a risk that another format might have data in these low sectors but then the chance of those discs being supplied to RPCEmu is low, so this is probably reasonable. The probable reason for this offset was that some header containing metadata could be included in the future. However, no such metadata is used or present at the current time. """ def __init__(self, *args, **kwargs): super(HDFBlockData, self).__init__(*args, **kwargs) # First read some data from the start of the file. sector_c00 = bytearray(self.read(DiscTransfer(address=0xc00, size=0x200), 0x200)) sector_e00 = bytearray(self.read(DiscTransfer(address=0xe00, size=0x200), 0x200)) if len(sector_c00) < 0x200 or len(sector_e00) < 0x200: # This disc is short, so we'll do no manipulation at all. return secspertrack_c00 = sector_c00[0x1c1] heads_c00 = sector_c00[0x1c2] secspertrack_e00 = sector_e00[0x1c1] heads_e00 = sector_e00[0x1c2] offset = 0 if secspertrack_e00 != 0 and heads_e00 != 0: # The two fields we're using as our basis are valid at offset 512. So # we use that. So there is a disc record here, we'll use it _______________________________________________ RPCEmu mailing list [email protected] http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
