Re: [hatari-devel] Patch: IDE support for sector sizes > 512 bytes

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Am Sun, 20 Oct 2019 09:25:00 +0200
schrieb Uwe Seimet <Uwe.Seimet@xxxxxxxxx>:

> Hi,
> 
> > Ok, it took a little bit longer (sorry!), but I've now finally
> > checked the QEMU sources more closely to see whether it's also
> > wrong there. It's not. QEMU's bdrv_get_geometry() function is
> > simply always calculating with 512 byte sectors, no matter whether
> > it's an CD-ROM drive or a normal hard disk. That's why they've got
> > the "total_sectors  
> > >>= 2" shifts there. But since we're calculating with 2048 byte
> > >>sectors  
> > in Hatari, we can remove these shifts indeed.
> > 
> > I've pushed a fix to the repository now. Uwe, could you please check
> > whether it's working as expected?  
> 
> It's almost working. I was able to successfully use an image
> configured with 4096 bytes per sector just like a regular 4KN SATA
> drive. What's not yet correct is the capacity displayed by Hatari in
> the drive name, see attached screenshot. Hatari does not yet use the
> right sector size for the capacity calculation.

Does that patch fix the problem:

diff --git a/src/ide.c b/src/ide.c
--- a/src/ide.c
+++ b/src/ide.c
@@ -983,7 +983,8 @@ static void ide_identify(IDEState *s)
 	padstr((char *)(p + 23), FW_VERSION, 8); /* firmware version */
 	/* Use the same convention for the name as SCSI disks are using: The
 	 * first 8 characters should be the vendor, i.e. use 2 spaces here */
-	snprintf(buf, sizeof(buf), "Hatari  IDE disk %liM", (long)(s->nb_sectors / 2048));
+	snprintf(buf, sizeof(buf), "Hatari  IDE disk %liM",
+	         (long)(s->nb_sectors / (1024 * 1024 / s->bs->sector_size)));
 	padstr((char *)(p + 27), buf, 40);
 #if MAX_MULT_SECTORS > 1
 	put_le16(p + 47, 0x8000 | MAX_MULT_SECTORS);

?

 Thomas



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/