Mail Archives: opendos/1998/11/17/15:08:36
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: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
-------------------------------------------------------------------
Caldera Digital Research Systems/OpenLinux: http://www.caldera.com/
- Raw text -