Date: Tue, 17 Nov 1998 17:08:52 +0100 From: Matthias Paul Subject: Re: LOADER error To: caldera-opendos AT rim DOT caldera DOT com Cc: opendos AT delorie DOT com Message-id: <60A5095759F@reze-1.rz.rwth-aachen.de> Organization: Rechenzentrum RWTH Aachen X-Mailer: Pegasus Mail v3.22 Reply-To: opendos AT delorie DOT com On 1998-11-11 Mark Aitchison wrote: >Is there a known problem when booting with DRDOS 7.03beta where there >is an error message about reading from drive 129 (I only have one >hard disk in my system) twice as it booots up? What is the exact wording of these error messages and when do they occur during the boot? I'm asking because (like MS-DOS) the DR-DOS boot sector now passes through the boot drive unit value in the DL register, while the old boot sector was hard-wired to 0 or 80h. However, at the moment the MBR code still does not passes through the DL value from the underlaying ROS (which will probably be added at a later stage, even though IBMBIO.COM currently does not make use of the boot drive unit any more - see below). For troubleshooting you can still smack in old style boot sectors using "SYS /O[:xxx]" where xxx is the fixed boot drive unit either 0..127 or 128..255 depending on removable/fixed disk (default is automatic selection). I'll send you my BOOTDUMP utility via private email. Maybe this can help shedding some light on the problem... Caldera has incorporated the following disk related patches in the kernel: IBMBIO.COM: The function INT 21h/AX=440Dh/CX=0842h has been changed so that if the ROM BIOS does not support the set media type for format functions, it will do a final check with the drives physical parameters (INT 13h AH=08h) for a match. This fixes some formatting problems on flash disks. The enhancement so that if you boot from the second physical disk, it reads the boot files (IBMDOS.COM, CONFIG.SYS...) from drive D:, has been removed. It caused problems when the first physical hard disk did not have a DOS partition. [This enhancement was only implemented in my IBMBIO.COM ALPHAs, and Caldera's DR-OpenDOS 7.02 and DR-DOS 7.02.] IBMDOS.COM: When testing a drive number for validity, anything from 81h -> FFh were return invalid, however some programs test all drives from 1 to FFh. This fixes the Iomega ZIP tools GUI. If you did not get these error message with the OpenDOS 7.01 (and some 7.02) kernel files, it looks to me as if the problem is related to one of these fixes. I also experienced a problem on an old 286 with flaky ROM-BIOS support for 1.44 Mb drives, where DR-DOS 7.02 (since spring this year) refuses to recognize and handle drive B: (the 1.44 Mb drive) properly - even with Ciriaco Garcia de Celis' 2M-ABIOS /13 installed. It worked without any problems with Novell DOS 7, OpenDOS 7.01, the OpenDOS 7.02 BETA 1, and my IBMBIO.COM ALPHA 3/4 files. Maybe this is related to your problem somehow? INTER59 knows: INT 13 - DISK - GET DRIVE PARAMETERS (PC,XT286,CONV,PS,ESDI,SCSI) AH = 08h DL = drive (bit 7 set for hard disk) Return: CF set on error AH = status (07h) CF clear if 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) Notes: may return successful even though specified drive is greater than the number of attached drives of that type (floppy/hard); check DL to ensure validity for systems predating the IBM AT, this call is only valid for hard disks, as it is implemented by the hard disk BIOS rather than the ROM BIOS Toshiba laptops with HardRAM return DL=02h when called with DL=80h, but fail on DL=81h. The BIOS data at 40h:75h correctly reports 01h. may indicate only two drives present even if more are attached; to ensure a correct count, one can use AH=15h to scan through possible drives for BIOSes which reserve the last cylinder for testing purposes, the cylinder count is automatically decremented on PS/1s with IBM ROM DOS 4, nonexistent drives return CF clear, BX=CX=0000h, and ES:DI = 0000h:0000h the PC-Tools PCFORMAT program requires that AL=00h before it will proceed with the formatting BUG: several different Compaq BIOSes incorrectly report high- numbered drives (such as 90h, B0h, D0h, and F0h) as present, giving them the same geometry as drive 80h; as a workaround, scan through disk numbers, stopping as soon as the number of valid drives encountered equals the value in 0040h:0075h Mark, are you using a Toshiba or Compaq machine? Which value is stored at 0040h:0075h? I guess, all these issues could easily be solved in a compatible way. The dilemma is that most of the time strange behaviour like this cannot be reproduced on other machines and other configurations. However, it would be very convenient, if Caldera would again provide the kernel source code free of charge (while still offering the full SBK kit with all the printed manuals, tools, etc. for money - for professional use), so that anyone affected by strange kernel behaviour could easily help locating these things in the sources and often even provide a fix. Also, this could create an even more trustable foundation for future projects and could help to reinforce life into 3rd party DOS software development. Matthias ------------------------------------------------------------------- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany eMail: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html ------------------------------------------------------------------- Caldera Digital Research Systems/OpenLinux: http://www.caldera.com/