BPB

[muta...@gmail.com]

Currently I read the FAT boot sector which contains,
among other things, the number of heads and the
number of sectors per track.

I use those values in the boot sector code to convert
an LBA into CHS.

Someone has reported the "University Challenge" disk,
which is only 40 MB instead of the normal 1 GB, not
working on Hyper V under Windows 11.

The UC disk works fine on real hardware and qemu
and Bochs.

I haven't proven 100% but it is certainly getting to the
boot sector and I think it has an issue in there, not
loading the 3 sectors of the boot loader properly.

I suspect the problem is that the 40 MB drive uses
some "real" disk geometry values instead of the
fake ones needed for large disks.

Hunting around I found INT 13H AH=08H which looks
like it will retrieve the number of heads and sectors
per track actually being used by the BIOS, and I would
have thought that was the definitive values, which
should overwrite the values stored in the BPB of the
boot sector.

Is that the right approach?

Thanks. Paul.

[wolfgang kern]

the BIOS may be able to get correct geometry data
by using Identify-Device (you can do that as well).

CHS<->LBA conversions must be aware of faked head-
numbers,it were quite common to abuse heads>>tracks
to achieve a larger CHS range. IIRC std-limit=2GB.
24 bits addressing 512 byte sectors: 2^24*512=8GB

If the CHS value in the MBR is wrong then blame the
formatting tool. But perhaps you misinterpreted it.
__
wolfgang

[muta...@gmail.com]

On Friday, April 1, 2022 at 12:31:38 AM UTC+11, wolfgang kern wrote:

> > Is that the right approach?

> the BIOS may be able to get correct geometry data
> by using Identify-Device (you can do that as well).
>
> CHS<->LBA conversions must be aware of faked head-
> numbers,it were quite common to abuse heads>>tracks
> to achieve a larger CHS range. IIRC std-limit=2GB.
> 24 bits addressing 512 byte sectors: 2^24*512=8GB
>
> If the CHS value in the MBR is wrong then blame the
> formatting tool. But perhaps you misinterpreted it.

My MBR uses LBA (I will replace it with a CHS version
when I have one), so I only notice a problem when I
get to the VBR.

The formatting tool works fine, as my disk boots even
on real hardware.

But the "physical hard disk" (a VHD) is being moved to
a different machine (Hyper V), so I suspect the BIOS
there is using different rules.

Another factor is that the VHD information (512 bytes
at the end of the file) is not being used by the tool
(freedos under qemu) that formats the disk. I don't
know if the VHD records disk geometry.

I noticed that the MBR doesn't seem to record the
disk geometry, so I can't do what I am currently doing
with the VBR. ie I need to get disk geometry from
somewhere else.

What options do I have and what are the pros and cons?
You mentioned "identify device". What is that?

Thanks. Paul.

[wolfgang kern]

On 31/03/2022 22:46, muta...@gmail.com wrote:
> On Friday, April 1, 2022 at 12:31:38 AM UTC+11, wolfgang kern wrote:
>
>>> Is that the right approach?
>
>> the BIOS may be able to get correct geometry data
>> by using Identify-Device (you can do that as well).
>>
>> CHS<->LBA conversions must be aware of faked head-
>> numbers,it were quite common to abuse heads>>tracks
>> to achieve a larger CHS range. IIRC std-limit=2GB.
>> 24 bits addressing 512 byte sectors: 2^24*512=8GB
>>
>> If the CHS value in the MBR is wrong then blame the
>> formatting tool. But perhaps you misinterpreted it.
>
> My MBR uses LBA (I will replace it with a CHS version
> when I have one), so I only notice a problem when I
> get to the VBR.

my formatting uses both CHS and LBA regardless of actual
disc size (when CHS is set to limit it's ignored anyway).

> The formatting tool works fine, as my disk boots even
> on real hardware.
>
> But the "physical hard disk" (a VHD) is being moved to
> a different machine (Hyper V), so I suspect the BIOS
> there is using different rules.
>
> Another factor is that the VHD information (512 bytes
> at the end of the file) is not being used by the tool
> (freedos under qemu) that formats the disk. I don't
> know if the VHD records disk geometry.

if the V in VHD mean virtual then you only can guess.

> I noticed that the MBR doesn't seem to record the
> disk geometry, so I can't do what I am currently doing
> with the VBR. ie I need to get disk geometry from
> somewhere else.

the MBR can only report not record :)
there once were reserved disk-geometry entries in MBR,
seems they applied to Floppy only yet.

> What options do I have and what are the pros and cons?
> You mentioned "identify device". What is that?

It's called Identify Drive in RBIL look at INT 1325
or read RBIL-PORTS: 01F0... command EC(ATA) and A1(ATAPI)
are direct ways (w/o needing BIOS) to get all info.
I use the latter method for IDE and SATA both HD/CD.
__
wolfgang
(all my figures are HEX, except noted or obvious else)

[muta...@gmail.com]

On Saturday, April 2, 2022 at 12:10:39 PM UTC+11, wolfgang kern wrote:

> if the V in VHD mean virtual then you only can guess.

Yes it does.

> It's called Identify Drive in RBIL look at INT 1325

Thanks. That is for PS/1-2. I was hoping for something
that would work on the IBM PC XT, which shipped with
a 10 MB hard disk.

Is there anything wrong with INT 13H AH=08H?

Note that if I wanted something modern I could just
stick with LBA.

Thanks. Paul.

[wolfgang kern]

On 02/04/2022 14:23, muta...@gmail.com wrote:
> On Saturday, April 2, 2022 at 12:10:39 PM UTC+11, wolfgang kern wrote:
>
>> if the V in VHD mean virtual then you only can guess.
>
> Yes it does.
>
>> It's called Identify Drive in RBIL look at INT 1325
>
> Thanks. That is for PS/1-2. I was hoping for something
> that would work on the IBM PC XT, which shipped with
> a 10 MB hard disk.
>
> Is there anything wrong with INT 13H AH=08H?

quote 1308:
CF=1: ;error
AH = status (07h) (see #00234)
CF=0: ;successful
AH = 00h
AL = 00h on at least some BIOSes
BL = drive type (AT/PS2 floppies only)
CH = low eight bits of maximum cylinder number
CL = maximum sector number (bits 5-0)
high two bits of maximum cylinder number (bits 7-6)
DH = maximum head number
DL = number of drives
ES:DI -> drive parameter table (floppies only)
...
I think this is a very old obsolete function, but if
your BIOS is that old too ...

look at the weird bit distribution in CX and if DH
reports more than 0f heads it's a fake extension.
And such fakes may are also be used in the MBR CHS,
not necessarily with equal meaning.and then check
on INT1321 to see another CHS fake interpretation.
with only 4 bits defined for DH there is too much
room for various extension methods.
Ie: bit 5-7 of DH become bit 8-10 of max cylinder
bit 4 of DH become bit 6 of sectors/track.
have seen others as well.

the I/O-port Identify Drive is lesser weird :)
and even ATA7 tell that geometry entry is obsolete,
it is still there on all HDs I checked on.

> Note that if I wanted something modern I could just
> stick with LBA.

hard to imagine that 50 year old stuff is still around.
__
wolfgang

[Joe Monk]

> Someone has reported the "University Challenge" disk,
> which is only 40 MB instead of the normal 1 GB, not
> working on Hyper V under Windows 11.
>

Windows 11 Hyper-V secure boot is turned on by default - also requires TPM. So if you dont support those things, you will probably not be able to boot.

Joe

[muta...@gmail.com]

On Saturday, April 2, 2022 at 11:23:26 PM UTC+11, muta...@gmail.com wrote:

> Is there anything wrong with INT 13H AH=08H?
>
> Note that if I wanted something modern I could just
> stick with LBA.

Note that using INT 13H AH=08H to obtain the drive
configuration solved the problem.

But then I decided to start debugging the FAT32 boot
sector, and I fixed that, and switched to that for my
main needs, and used LBA so that I could support
drives bigger than 8 GB.

BFN. Paul.