Hi everybody, I need some advice from kernel experts: when checking the error reported by Travis in the freedos-user thread "Travis" I found that initdisk does setup the DDT BPB and default BPB correctly for A: and B:, but fails to setup the DPB. As the latter is used to check if int25/26 access is okay for a drive, attempts to use int25/26 fail until something triggers a media_check (e.g. "DIR A:").
To check your own system: Use int 21.52 to get the ES:BX addr of the List of Lists, first entry is a far pointer to the DPB array. Entries in the DPB array are 0,0,[empty],70:5bc,0,ff*,[->next],[empty] for A: and 1,1,[empty],70:5bc,0,ff*,[->next],[empty], with the "ff" triggering an update on media_check. With DOSEMU, entries for "redirected Linux directory as DOS drive" suffer from the same emptiness, while all "real harddisk" style drives have their DPB data filled in properly. My problem: WHAT, WHY and HOW does set up the DPBs during boot? For floppy, the BPB are initially set to the BPB for the default capacity, so there is no need to access the (possibly empty) drive at boot for that. But the DPBs have to set up as well, as explained above. The FsConfig in main.c seems to init the CDSp[...] array entries and their pointers to DPB blocks and update_dcb adds yet more data for block devices added via DEVICE/DEVICEHIGH or (even before FsConfig) from dsk_init (the kernel block device driver setup for BIOS int13 disks). Actually FsConfig is called twice, before and after configsys is processed. Something quite interesting is InitializeAllBPBs which tries to open a nonexisting file on C: and all later drives but not on A: and B: - this is described as "make Norton Disk Editor happy by initializing BPB tables" (probably meant to say "DPB tables"). This is called at the end of init_kernel after all FsConfig. Is there a more elegant way than opening a bogus file? Is this where the DBP get set up? Looks like not only Norton but also the FreeDOS kernel itself needs proper DPB setup at boot even though the comment claims that FreeDOS sets up "BPB tables" (DPB?) "only when used". Maybe the problem is something different: inthndlr.c int2526_handler uses get_dpb and maybe that one is supposed to use media_check? Extra questions: Should make_ddt set ddt_descflags to indicate DF_DISKCHANGE and/or DF_NOACCESS? (initdisk) Does anybody expect any problems when I re-enable the old disabled "problems with FORMAT" DF_NOACCESS for disks in getbpb if RWzero fails for that drive or if the boot sector of that drive does not look like FAT? I mean somebody with some test drives could test if FORMAT still works, but which other apps and kernel issues might be triggered by the NOACCESS? Personally, I think it is a bad idea that FreeDOS now pretends that an invalid FAT drive is already "sort of okay". Nice to help FORMAT, but probably bad side effects... Thanks for your feedback guys :-) Eric ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
