Hi!
7-Июн-2004 04:48 [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.
>> Hm. Probably I not very understand this request, but FreeDOS does all
>> DMA checks in dsk.c:LBA_Transfer().
EA> Moving the check to int 13 means that DOS programs which use int 13 directly
EA> never have to worry about DMA boundaries. MS DOS provides this service. It
EA> also
EA> hooks int 13 to have more secure detection of disk changes (i.e. even if the
Hm. I myself don't ready to introduce such (complex) feature.
>> EA> * 1176 second floppy controller not detected.
>> FreeDOS detects second floppy drive presence through analyzing
>> "equipment list" (INT 11) ...
EA> Yes, sure, but I wrote about second floppy CONTROLLER. This is the thing
EA> to which you connect the third and possibly fourth floppy drive and which
EA> - I believe - can only be found in 808x PCs, not in newer models. Not sure
EA> if the BIOS has or needs special support for that as well.
As I understand, for BIOS this is easy: "floppy drives" numbered from 0
to 7F, hard disks numbered 80..FF. Thus, BIOS allows to have 128 floppy
drives. :) Of course, eqipment list enumerates only up to four drives (two
bits). Inefficient logic: with bit 0 eq.list there was possible to enumerate
up to 7 drives.
How DOS should deal with third and fourth drives - I don't know, but I
suggest, this is possible only through driver.sys (there you point physical
drive number 0..127, and it traps next logical drive letter).
In any case, this is not issue for kernel itslef (unless you builtin
driver.sys functionality, say, over drivparm= statement)
>> EA> * 1630 int 21.4bxx should clear the high parts of the general 32 bit
>> ? _Why_ DOS "should" clear hight parts of 32-bit registers?!
EA> Because some programs would conceivably assume that the high parts are 0
EA> instead of setting them to 0 manually. Check www.256b.com to see that DOS
EA> programs sometimes assume quite a lot of stuff about initial register
EA> values.
FD _already_ imitates most MS-DOS (undocumented garbage) - see
task.c:load_transfer(), where Lucho adds some initializations. I don't think
that we should add there also dealing with 32-bit registers, especially I
doubt that (16-bit) MS-DOS deals with high parts of 32-bit registers.
>> To make UMBs, DOS uses XMS services.
EA> Good point. Then UMBs on pre-286 PCs would need really special drivers.
Of course.
EA> Anyway, you can tell the user that UMBs are almost impossible if you detect
EA> an 808x at boot time then (i.e. if the user tries to use UMBs then the error
EA> message can be more helpful: If 286+, suggest loading an XMS plus if needed
EA> an extra UMB or if 386+ EMM386 driver. If 808x, suggest giving up X-)). Same
Ie. you offer to integrate help, tutor and training subsystem into
kernel? Currently DOS ignores DOS=UMB statement, if there are no UMBs
available. I think, extra messages like "NO UPPER MEMORY AVAILABLE FOR YOUR
DOS=UMB STATEMENT" makes only uncomfortable noise. I think, such messages is
an issue for system information programs - for example, Manifest from QEMM
package offers `Hints' menu, where it offer tips how to optimize the system
(like "Reduce the number of DOS FILES allocated").
>> EA> * 1789 the builtin disk format (!) function causes weird kernel error
>> EA> message LBA-Transfer error...
EA> Sorry, there is a word missing in the above!!
EA> The builtin disk format function OF PKZIP causes weird kernel error message
EA> ...
Hm. May you give details?
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
