Most of the above is grabbed using Makemountlist in E-UAE so should be correct (LoCyl/HighCyl, etc.).
Does the TD_GETGEOMETRY implementation in diskimage.device matter at all in this case? I tried leaving the REMOVABLE flag unset but it didn't help any.
I can't understand why it isn't working...
Or could it be because I am first mounting the device and then "inserting" the disk? Doesn't seem like it to me though since the disk does show up, just that it shows up as "IHDO:Uninitialized" and can't be accessed...
Any help with getting this working would be appreciated.
I added some of the settings that were missing from my makefile but it didn't help any. Also tried with Reserved=1 (I used 2 with E-UAE though so that should be correct).
One interesting thing I noticed:
If I make a copy of the hardfile and then mount and format it the header looks very different.
If I make a copy of the hardfile and then mount and format it the header looks very different.
FFS2 stores the geometry in the first sector when formatting a partition, recovery tools like the "Find Partitions" option in PartitionWizard can use this data to find lost partitions on a HD with a destroyed RDB. Old versions of FFS didn't do that.
But it shows your mountlist doesn't match the size of the image file: Mountlist: 63995904 Bytes ((3905+1)*32*512) Actual size (FFS2 using TD_GETGEOMETRY since LowCyl is 0): 64000000 Bytes ((124999+1)*512)
If the file is 64000000 bytes but you used an old version of FFS in UAE with the parameters from the mountlist it can't work, the old FFS uses the mountlist size, FFS2 the real size.
Either change the size of the file to 63995904 Bytes, or fix the geometry used in UAE to match the file size, for example 2500 Cylinders, 1 Head and 50 Sectors per Track. If you want to read the existing image with FFS2 you have to fix the file size, for example create copy with "dd if=broken_imagefile of=fixed_imagefile bs=512 count=124992".
Edit: Reserved has to match as well, usually it's 2, but if the image file was formatted with Reserved=1 in UAE you have to use that in the diskimage.device mountlist as well.
Thanks for the explanation. So I guess if I modified TD_GETGEOMETRY to return the correct size it would work also. I'll have to try this out.
No! If the size of the image file is 64000000 bytes you'd have to change TD_GETGEOMETRY to return the wrong size (124992 sectors, 63995904 bytes), that would make it work with this broken image file, but all correct image files would stop working.
Still not a very ideal solution though. I'll have to think on this.
If this error is common in UAE hardfiles I'd include a small tool to fix the broken image files. BPTR fh = IDOS->Open(filename, MODE_OLDFILE); if (fh) { if (!IDOS->ChangeFileSize(fh, correct_size, OFFSET_BEGINNING)) { IDOS->PrintFault(IDOS->IoErr(), "fixing the size failed"); } IDOS->Close(fh); }
So some way of letting the device know the correct BlocksPerTrack, Heads and BlockSize would be needed hence the command I propose above.
[edit]
Anyway you're idea for a tool for fixing the files sounds good since that would mean they would still be mountable the usual way. I think I'll go for that. Thanks.
This adds a new tool called make_hdf which can be used from the command-line to create a blank hard-disk image (it also prints out appropriate config options which can be appended to or cut-n-pasted into a config file).
<path> = file path to hdf image to create <size> = size of image to create in MB follow <size> by G to specify size in GB <device> = device name to include in config option defaults to DH0 if omitted evilrich@anaximander:~/work/e-uae/uae/build_i386_x11$ ./src/make_hdf ~/work/test.hdf 4GB hardfile2=rw,DH0:/home/evilrich/work/test.hdf,32,5,2,512,0, hardfile=rw,32,5,2,512,/home/evilrich/work/test.hdf evilrich@anaximander:~/work/e-uae/uae/build_i386_x11$
You get the idea. Hopefully this will stave off some of the "How do I create a hard file" questions, and it'll mean users don't have to muck around with figuring out geometries too much. Plus on Linux it'll create sparse files - which is nice and really quick. Feedback welcome, but don't get too excited; I want to keep this simple for right now.
Except for dg_SectorSize it's correct even for image files using a different block size since AmigaOS file systems only support block sizes which are a multiple of 512.
Quote:
So some way of letting the device know the correct BlocksPerTrack, Heads and BlockSize would be needed hence the command I propose above.
File systems don't use SectorsPerTrack, Heads or Cylinders, they only use dg_SectorSize and dg_TotalSectors. If LowCyl isn't 0 they calculate the number of sectors themself using the data from struct DosEnvec (totalsectors = (de_HighCyl-de_LowCyl+1) * de_BlocksPerTrack * de_Surfaces) on startup, but never use the number of sectors per track or heads later, only the start offset of the partition, the number of blocks and the blocksize is used. Even image files using a different block size are no problem, you just need a seperate mountlist for each block size you use, but you'd need that anyway even if you'd add support in diskimage.device for different sector sizes. For the file systems for example SectorSize = 2048, SectorPerBlock = 1 is exactely the same as SectorSize = 512, SectorPerBlock = 4 since they only use the block size (SectorSize * SectorsPerBlock).
If there wouldn't be UAE image files with a wrong size, UAE never accesses the spare additional space in them either, there would be no problem and you wouldn't have to add special support for wrong sized image files. IMHO correcting the size of such image files would be better than adding workarounds in diskimage.device.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
. I could even mount the hardfile using "IDFO:" now.
Of course I would never hardcode such assumptions into the device! I'm not that stupid.
