[mist] 25063: ReactOS Intel Mac compatibility commits, part 2/2 == LBA Functionality BIOS Bug == When the BIOS is asked whether it supports INT 13 extensions, it will answer yes if the device is a hard disk, but it will pretend that even the function to ask about this functionality is unsupported if asked about a CD drive. This is similar to what is documented in the code already: Some BIOSes return "doesn't support INT 13 extensions" for CDs. Code has been added to use INT 13 extensions (and th

Author: mist
Date: Mon Dec  4 18:33:06 2006
New Revision: 25063

URL: http://svn.reactos.org/svn/reactos?rev=25063&view=rev
Log:
ReactOS Intel Mac compatibility commits, part 2/2

== LBA Functionality BIOS Bug ==
When the BIOS is asked whether it supports INT 13 extensions, it will answer yes if the
device is a hard disk, but it will pretend that even the function to ask about this
functionality is unsupported if asked about a CD drive. This is similar to what is
documented in the code already: Some BIOSes return "doesn't support INT 13
extensions" for CDs.
Code has been added to use INT 13 extensions (and therefore LBA read as opposed to CHS)
even if the BIOS claims this is unsupported, if the device is a CD-ROM. The check for the
drive type is done by comparing with 0x90: If the device number is 0x90 or above, it's
a CD drive. (On Insyde's BIOS, it's 0x90, on most others, it's 0x9F).

(Ironically, Insyde's BIOS cannot even do CHS on CDs, so if the bootloader correctly
asks for LBA support, it will get a "no" and will fail when trying to do CHS:
When querying the max. CHS values, the BIOS returns 0 sectors per track, which will make
conversions from LBA to CHS impossible.)

== LBA Read BIOS Bug ==
When trying to read from CD using the LBA function INT 13/42, the BIOS function will
return as it is supposed to, with CF and AH cleared, but with an unchanged buffer. This is
because freeldr passes a "disk address packets" that structure contains an extra
64 bit value at the end and is therefore 24 bytes long instead of 16. This is perfectly
fine, and a BIOS should ignore any extra data in the structure, but Insyde's BIOS,
which doesn't support the extra field (and thus the EDD-3.0 standard) just ignores the
complete task and returns in this case.
The extra field has been removed from the structure in freeldr, as it is not used anyway.
The structure is now 16 bytes long.

Modified:
    trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c

Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/…
==============================================================================
--- trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c (original)
+++ trunk/reactos/boot/freeldr/freeldr/arch/i386/pcdisk.c Mon Dec  4 18:33:06 2006
@@ -30,8 +30,10 @@
 	USHORT		TransferBufferOffset;	// 04h - Transfer buffer offset (seg:off)
 	USHORT		TransferBufferSegment;	//       Transfer buffer segment (seg:off)
 	ULONGLONG		LBAStartBlock;			// 08h - Starting absolute block number
-	ULONGLONG		TransferBuffer64;		// 10h - (EDD-3.0, optional) 64-bit flat address of
transfer buffer
+	//ULONGLONG		TransferBuffer64;		// 10h - (EDD-3.0, optional) 64-bit flat address of
transfer buffer
 									//       used if DWORD at 04h is FFFFh:FFFFh
+									//       Commented since some earlier BIOSes refuse to work with
+									//       such extended structure
 } PACKED I386_DISK_ADDRESS_PACKET, *PI386_DISK_ADDRESS_PACKET;
 

/////////////////////////////////////////////////////////////////////////////////////////////
@@ -84,7 +86,6 @@
 	Packet->TransferBufferOffset = ((ULONG)Buffer) & 0x0F;
 	Packet->TransferBufferSegment = ((ULONG)Buffer) >> 4;
 	Packet->LBAStartBlock = SectorNumber;
-	Packet->TransferBuffer64 = 0;
 
 	// BIOS int 0x13, function 42h - IBM/MS INT 13 Extensions - EXTENDED READ
 	// Return:
@@ -274,6 +275,18 @@
 	{
 		DbgPrint((DPRINT_DISK, "Using cached value %s for drive 0x%x\n",
LastSupported ? "TRUE" : "FALSE", DriveNumber));
 		return LastSupported;
+	}
+
+	// Some BIOSes report that extended disk access functions are not supported
+	// when booting from a CD (e.g. Phoenix BIOS v6.00PG and Insyde BIOS shipping
+	// with Intel Macs). Therefore we just return TRUE if we're booting from a CD -
+	// we can assume that all El Torito capable BIOSes support INT 13 extensions.
+	// We simply detect whether we're booting from CD by checking whether the drive
+	// number is >= 0x90. It's 0x90 on the Insyde BIOS, and 0x9F on most other
BIOSes.
+	if (DriveNumber >= 0x90)
+	{
+		LastSupported = TRUE;
+		return TRUE;
 	}
 
 	LastDriveNumber = DriveNumber;
@@ -323,27 +336,13 @@
 		return FALSE;
 	}
 
-	// Note:
-	// The original check is too strict because some BIOSes report that
-	// extended disk access functions are not suported when booting
-	// from a CD (e.g. Phoenix BIOS v6.00PG). Argh!
-#if 0
 	if (!(RegsOut.w.cx & 0x0001))
 	{
 		// CX = API subset support bitmap
 		// Bit 0, extended disk access functions (AH=42h-44h,47h,48h) supported
+		printf("Suspicious API subset support bitmap 0x%x on device 0x%lx\n",
RegsOut.w.cx, DriveNumber);
 		LastSupported = FALSE;
 		return FALSE;
-	}
-#endif
-
-	// Use this relaxed check instead (most BIOSes seem to use 0x9f as CD-Rom)
-	if (RegsOut.w.cx == 0x0000 && DriveNumber != 0x9f)
-	{
-		// CX = API subset support bitmap
-		printf("Suspicious API subset support bitmap 0x%x on device 0x%lx\n",
RegsOut.w.cx, DriveNumber);
-		LastSupported = FALSE;
-		return LastSupported;
 	}
 
 	LastSupported = TRUE;