[Freedos-kernel] Two problems and patches related to Floppy Disk

[Koike Toshio]

Hello FreeDOS developers.

We are using FreeDOS 1.0 in our embedded systems. FreeDOS is a good 
replacement of ROM-DOS we previouslly used. Thank you for all the great work 
on FreeDOS.

I found two small problems related to Floppy disk(FD) and fixed it by 
modifying FreeDOS kernel sources(2036 cvs). I send patches to fix these 
problems. My patches are applicable to kernel 2036 cvs.
If you consider the patches and incorporate to your kernel tree, it should be 
great for me.

The patches are uploaded here. 
http://us.f13.yahoofs.com/bc/48b6f314_185bc/bc/freedos/patch080818.zip?bfh__vIBxIiwN9fQ

Two problems are:

Problem 1: Maxell new FD has No 55-aa magic number in boot sector.
Problem 2: Floppy disk change recognition problem.

---
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.
After precise investigation, I found a lack of 55-aa magic number in the last 
two bytes of the boot sector of Maxell FD. FreeDOS getbpb() function is 
checking 55-aa magic number. If no 55-aa magic number, FreeDOS assumes the FD 
as a 720KB(not 1440KB) FD.
 Maxell FD boot sector dump (No 55-aa at 01feh) 
  eb 34 90 4d 41 58 45 4c  4c 20 20 00 02 01 01 00  |.4.MAXELL  .|
0010  02 e0 00 40 0b f0 09 00  12 00 02 00 00 00 00 00  |[EMAIL PROTECTED]|
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
01f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
 TDK FD boot sector dump (There's 55-aa at 01feh) 
  eb 34 90 49 42 4d 20 20  33 2e 33 00 02 01 01 00  |.4.IBM  3.3.|
0010  02 e0 00 40 0b f0 09 00  12 00 02 00 00 00 00 00  |[EMAIL PROTECTED]|
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 12  ||
0030  00 00 00 00 01 00 fa 33  c0 8e d0 bc 00 7c 16 07  |...3.|..|
   :
01f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..U.|
--
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.
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
  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. 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().
Perfect disk change recognition will be accomplished by the patch. Though I 
have not examined other DOSs(PC-DOS, ROM-DOS), the same hooking may be used.

fdos-fd-change-patch-080818.diff modifies kernel/main.c and drivers/floppy.asm.

---

Please consider my patches.

Thanks for your reading. :-)

Toshio Koike

_
秋本番！連休たくさんのこの秋、みんなのオススメ週末旅行をチェックしよう
http://clk.atdmt.com/GBL/go/112813570/direct/01/-
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

Re: [Freedos-kernel] Two problems and patches related to Floppy Disk

[Alain M.]

You are a genius...

This floppy change problem has been around for some time because it is 
hard to reproduce. The steps 1 to 5 in problem 2 are all done from a 
single running program? If so it may be related to a problem I 
encontered a few times.

Thanks, very much
Alain


Koike Toshio escreveu:
> Hello FreeDOS developers.
> 
> We are using FreeDOS 1.0 in our embedded systems. FreeDOS is a good 
> replacement of ROM-DOS we previouslly used. Thank you for all the great work 
> on FreeDOS.
> 
> I found two small problems related to Floppy disk(FD) and fixed it by 
> modifying FreeDOS kernel sources(2036 cvs). I send patches to fix these 
> problems. My patches are applicable to kernel 2036 cvs.
> If you consider the patches and incorporate to your kernel tree, it should be 
> great for me.
> 
> The patches are uploaded here. 
> http://us.f13.yahoofs.com/bc/48b6f314_185bc/bc/freedos/patch080818.zip?bfh__vIBxIiwN9fQ
> 
> Two problems are:
> 
> Problem 1: Maxell new FD has No 55-aa magic number in boot sector.
> Problem 2: Floppy disk change recognition problem.
> 
> ---
> 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.
> After precise investigation, I found a lack of 55-aa magic number in the last 
> two bytes of the boot sector of Maxell FD. FreeDOS getbpb() function is 
> checking 55-aa magic number. If no 55-aa magic number, FreeDOS assumes the FD 
> as a 720KB(not 1440KB) FD.
>  Maxell FD boot sector dump (No 55-aa at 01feh) 
>   eb 34 90 4d 41 58 45 4c  4c 20 20 00 02 01 01 00  |.4.MAXELL  .|
> 0010  02 e0 00 40 0b f0 09 00  12 00 02 00 00 00 00 00  |[EMAIL 
> PROTECTED]|
> 0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 01f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
>  TDK FD boot sector dump (There's 55-aa at 01feh) 
>   eb 34 90 49 42 4d 20 20  33 2e 33 00 02 01 01 00  |.4.IBM  3.3.|
> 0010  02 e0 00 40 0b f0 09 00  12 00 02 00 00 00 00 00  |[EMAIL 
> PROTECTED]|
> 0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 12  ||
> 0030  00 00 00 00 01 00 fa 33  c0 8e d0 bc 00 7c 16 07  |...3.|..|
>:
> 01f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..U.|
> --
> 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.
> 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
>   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. 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().
> Perfect disk change recognition will be accomplished by the patch. Though I 
> have not examined other DOSs(PC-DOS, ROM-DOS), the same hooking may be used.
> 
> fdos-fd-change-patch-080818.diff modifies kernel/main.c and 
> drivers/floppy.asm.
> 
> ---
> 
> Please consider my patches.
> 
> Thanks for your reading. :-)
> 
> Toshio Koike
> 
> 
> 
> $B=)K\HV!*O"5Y$?$/$5$s$N$3$N=)!"$_$s$J$N%*%9%9%a=5KvN99T$r%A%'%C%/$7$h$&(B 
> $B!|[EMAIL PROTECTED]|K\A49q$I$3$X$G$b!d!d!d(B 
> 
> 
> 
> ---

Re: [Freedos-kernel] Two problems and patches related to Floppy Disk

[Eric Auer]

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

Re: [Freedos-kernel] Two problems and patches related to Floppy Disk

[Alain M.]

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