Re: Linux vs. DOSEMU geometry (Was: Re: DosEMU, Ghost: VGA screen garbled...)

[Bart Oldeman <bartoldeman@users.sourceforge.net>]

On Sun, Sep 20, 2009 at 4:05 PM, Frantisek Rysanek
<Frantisek.Rysanek@post.cz> wrote:
> On 18 Sep 2009 at 18:00, Bart Oldeman wrote:
>> In fact HDIO_GETGEO gives bogus info so I changed it
>> to look at the MBR as well to determine CHS limits.
>> It's now in SVN.
>>
> you mean completely bogus?

Well it may not be completely bogus as you explained -- however things
have changed in the Linux kernel too. particularly from 2.4 to 2.6.
And I could not find anywhere where the kernel parses the MBR to find
CHS values though fdisk certainly tries.

I have a 4G USB key that I used to test "wholedisk" with a
preformatted geometry (as I could see in the DOS boot sector) of
CHS=978/128/63; however HDIO_GETGEO reported CHS=1017/125/62. This
value was invented by setsize() in the Linux kernel's
drivers/scsi/scsicam.c. Similarly, there's ata_std_bios_param() in
drivers/ata/libata-scsi.c which invents xxx/255/63 (the standard
values used for large hard disks nowadays).

Linux fdisk even says 5922/37/36 because it parses the MBR, assuming
that the partition ends at a cylinder boundary (it does not; the MBR
is
Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
 1 80   0   9    0  36  36  978          8    7888888 0b
 2 00   0   0    0   0   0    0          0          0 00
 3 00   0   0    0   0   0    0          0          0 00
 4 00   0   0    0   0   0    0          0          0 00
so it stops a little before the boundary).

All I wanted in DOSEMU was some kind of geometry that agrees with the
MBR so DOS can make sense of it (and FreeDOS boots without warnings).
And an "S" value of 63 is very common so I put some code there to
check whether that values makes sense.

Of course in reality for modern OSes CHS is irrelevant but the older
DOSes that also may get used in DOSEMU such as MSDOS 6.22 only use
CHS.

Bart