Hi!

6-Июн-2004 00:47 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:

EA> * 698 floppy change / floppy DMA boundary check should be moved from
EA>   "int" 25/26 to the int 13 handler. This is also needed for later when
EA>   we want Win 3.1x /3 compatibility. Please comment on how hard it would
EA>   be to move the boundary check function.

     Hm. Probably I not very understand this request, but FreeDOS does all
DMA checks in dsk.c:LBA_Transfer().

EA> * 1176 second floppy controller not detected. Am I right in writing
EA>   in the bug report that this can only affect 808x systems? How about
EA>   required BIOS support, if any? A solution could be to interpret the
EA>   "installed hardware" bitmask from the BIOS differently if CPU is 808x!?

     FreeDOS detects second floppy drive presence through analyzing
"equipment list" (INT 11) in initdisk.c:ReadAllPartitionTable(). I know no
other (defined) way, how to detect second floppy(ies), without accessing
hardware directly - and equipment list was defined from the starting IBM PC.

EA> * 1630 int 21.4bxx should clear the high parts of the general 32 bit
EA>   registers - of course this must check if CPU is 386 or better first.

     ? _Why_ DOS "should" clear hight parts of 32-bit registers?!

EA>   I think a CPU detection at boot time could also provide other advantages:
EA>   If CPU is 808x, you can disable HMA detection and stuff (but I believe
EA>   UMBs can be possible on 808x),

     To make UMBs, DOS uses XMS services. IF you have RAM in A000-FFFF
region AND IF you write own driver, which will imitate the XMS (version
2.x), then DOS will able to reuse those RAM for UMB. Notwithstanding the
CPU. By itself DOS doesn't deals with upper memory.

EA> * 1789 the builtin disk format (!) function causes weird kernel error
EA>   message LBA-Transfer error... - Somebody already tried but could not
EA>   reproduce, so maybe this depends on the used hardware?

     The internal formating code (INT 21/440D/CL=42, also 0x13 Generic IOCTL
Call) in dsk.c:Genblkdev() is bad. I already report this some years ago and
now again prepare bugfix for it.




-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Reply via email to