Eric Auer escreveu: > >> Problem 1: Maxell new FD has No 55-aa magic number in boot sector. > > You might have fixed that the wrong way round... FreeDOS tries too > much to behave well for unformatted disks, which should be fixed in > www.coli.uni-saarland.de/~eric/travis.zip ... the idea is to make > clear that disks are not in standard format instead of trying to > treat them as if they were. The QUESTION is whether all your disk > tools enjoy the patch :-). The GOOD thing is that things should be > safer the "Travis" way. The BAD thing is that you will probably > have to (quick-) format your Maxell disks once before the Travis > style kernel lets you access them. Please try :-).
I am not so sure if it is the wrong way. Most of my floppy problems may be related because Maxell is the most common brand here. Let's think a bit... Maxell floppies work just fine with MS-DOS and DR-DOS, which I used a lot. So they *have to* work well inFreeDOS too, because users buy them and expect them to work (yes I know they *should* format them but I repeat it endlessly withou result) Maybe, if you feel unsafe about using a floppy without he 55AA mark, some other test could be done to decide that the floppy is ok :) Please consider this... >> Problem 2: Floppy disk change recognition problem. > > Implementing int 13 hooking can be quite complex, how long is > your patch and did you check it and have it reviewed? Our own > UNSTABLE kernel branch for example had int 13 hooking as work > in progress but I think it was not smooth yet. You can find > the source of this branch in our SVN repository :-). Maybe (I haven't checked) a simple hook of int13, just for disk cahnge can be made safely, while a more complete solution is under way. The unstable branch will take a very long time to come, and we need to fix this floppy problem because it causes Data Corruption :( Alain >> Problem 1: Maxell new FD has No 55-aa magic number in boot sector. >> When we used Maxell FD, we encountered strange phenomena. We wrote files to >> FD. >> Write process was looking good. But there is no file in checking the FD on >> Windows... getbpb... if non 55aa then FreeDOS assumes 720k (??)... >> ROM-DOS, PC-DOS and Windows has no problem with the Maxell FD. So I think >> FreeDOS is too strict in checking boot sector format. Original FreeDOS >> checks 55-aa magic number and sector size (=512). My patch disables >> checking of 55-aa magic number and only checks sector size... >> fdos-maxell-fd-patch-080818.diff modifies kernel/dsk.c. > > > >> Problem 2: Floppy disk change recognition problem. >> When we write two FD on our application, the first FD's directory >> entries was copied onto the second FD. This problem was not occurred >> on ROM-DOS and PC-DOS. After precise investigation, I found that our >> application is calling BIOS int-13h AH=02h(Sector read) before the >> second FD write. > > Ouch. > >> Test program DISKCHG.C demonstrates this problem through steps as follows. >> 1. insert disk-1 >> 2. write A:FILE1 calling DOS >> 3. change FD to disk-2 >> 4. read FD boot sector calling BIOS int-13h AH=02h > > Probably to verify that disks were changed, but in FreeDOS > with the side effect that DOS itself misses the change... > >> 5. write A:FILE2 calling DOS >> Disk-2 directory entry contains two files FILE1 and FILE2. >> >> Normally disk change is notified on calling BIOS int-13h AH=00h-05h,08h, >> 15h-18h. But disk change notification from BIOS is the ONLY ONCE. > > Exactly... > >> So on the subsequent call of BIOS int-13h AH=16h(Detect disk change) >> from FreeDOS kernel, no disk change will be notified and FD cache in >> kernel will NOT be flushed. Then the first FD's directory data will >> be written into the second FD. >> >> My patch introduced int-13h hooking. Disk change status on calling >> int-13h AH=00h-05h,08h,15h-18h is memorized and reported on the call >> of fl_diskchanged(). > > What motivated your selection 0-5,8,15h-18h? Sounds okay :-) > >> Perfect disk change recognition will be accomplished by the patch. > > Possibly ;-) > >> Though I have not examined other DOSs(PC-DOS, ROM-DOS), >> the same hooking may be used. > > Good idea - avoid touching closed source software while > writing GPLed software to stay on the cleanroom side :-). > > Eric > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
