Hi! On Fri, 5 Sep 2008, Koike Toshio wrote:
> The patches are uploaded here. > http://us.f13.yahoofs.com/bc/48b6f314_185bc/bc/freedos/patch080818.zip?bfh__vIBxIiwN9fQ Redirects to a non existing hostname: http://bcvrf.yahoo.com/bc/48b6f314_185bc/bc/freedos/patch080818.zip > 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 :-). > 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 :-). Eric > 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
