Hi, I looked at the issue "kernel acts weird if there is no
diskette drive"... In short:
ddt *getddt(int dev) { return (ddt*)Dyn.Buffer + dev; }
#define getddt0() ((ddt*)Dyn.Buffer)
This assumes that the DDTs are at the start of the dynalloc area
and that the first DDT is for A:, second for B:, and so on. However:
init_call_intr(0x11, ®s); /* get equipment list */
if (regs.AL & 1) /* at least one floppy drive installed */
{
make_ddt(&nddt, 0, 0, 0);
if (regs.AL & 0xC0) /* more than one floppy */
make_ddt(&nddt, 1, 1, 0); /* real B: drive */
else
make_ddt(&nddt, 1, 0, DF_MULTLOG); /* phantom B: drive */
}
... and make_ddt calls push_ddt:
STATIC void push_ddt(ddt *pddt)
{
ddt FAR *fddt = DynAlloc("ddt", 1, sizeof(ddt));
fmemcpy(fddt, pddt, sizeof(ddt));
if (pddt->ddt_logdriveno != 0) {
(fddt - 1)->ddt_next = fddt;
if (pddt->ddt_driveno == 0 && pddt->ddt_logdriveno == 1)
(fddt - 1)->ddt_descflags |= DF_CURLOG | DF_MULTLOG;
}
}
... after the A: / B: definition, the partition scan starts after:
nUnits = 2;
So harddisks are always NUMBERED from C: on, but the internal
block device logics will be "off by two" if there are no
diskette drives! Trying to access A: will actually access C:,
for example. In addition, we get a pointer underflow in push_ddt
when it tries to "set the ddt_next pointer of the drive before C:",
because push_ddt always assumes that only A: has no previous DDT.
In short, even if we have no diskette drives, we must still
allocate DDTs for A: and B:. Possible code:
init_call_intr(0x11, ®s); /* get equipment list */
if (regs.AL & 1) /* at least one floppy drive installed */
{
... as before
} else {
make_ddt(&nddt, 0, 127, DF_NOACCESS);
make_ddt(&nddt, 1, 127, DF_NOACCESS);
}
This patch is for COUNT dsk_init() in initdisk.c
Eric
PS: As a bonus possible problem, I noticed that the cvs unstable SYS
FAT1x CHS/LBA FreeDOS boot sector assumes that DL will be the
drive number after int 13 (readdisk) when it passes on the boot
drive number to the kernel (in BL)... However, RBIL tells about
int 13.02 that:
> Apparently some BIOSes or intercepting resident software have bugs
> that may destroy DX on return or not properly set the Carry flag.
So if somebody has a kernel behaving like having booted from A:
while boot was from C:, it might be worth a try to use an older
SYS (like the sourceforge 2035 classic kernel one). This is not
to be confused with "the kernel calls my harddisk A:" - THAT would
be exactly what happens because of the above disketteless PC issue.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Freedos-kernel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
