The 1.44MB FAT32 floppy disk

[Mike Gonta]

http://forum.osdev.org/viewtopic.php?f=2&t=30339

http://board.flatassembler.net/topic.php?t=19150

https://www.reddit.com/r/osdev/

https://voat.co/v/programming

http://mikegonta.com/MikeOS-4.5_FAT32

Windows XP (the machine I have with a floppy disk drive)
happily reads and writes the physical floppy disk as FAT32.

MikeOS-4.5 FAT32 boots and runs as FAT32 from the physical
floppy disk.
Of course, the code (NASM) (and image) is designed to boot and run
from a USB flash drive.

[code]

SECTORS_PER_CLUSTER EQU 1
RESERVED_SECTORS EQU 72
NUMBER_OF_FATS EQU 1
SECTORS_PER_TRACK EQU 18
NUMBER_OF_HEADS EQU 2
SECTORS EQU 66602
SECTORS_PER_FAT EQU 522
HIDDEN_SECTORS EQU 0

; 1.44MB

org 0x7C00
_start:
jmp SHORT start
nop
db "144MB FAT32"
dw 512 ; bytes per sector
db SECTORS_PER_CLUSTER
dw RESERVED_SECTORS
db NUMBER_OF_FATS
dw 0
dw 0
db 0xF0
dw 0
sectors_per_track: dw SECTORS_PER_TRACK
number_of_heads: dw NUMBER_OF_HEADS
dd 0
dd SECTORS
dd SECTORS_PER_FAT
dd 0
dd 2 ; cluster number of root directory
dw 1 ; sector number of FS Information Sector
dw 0 ; sector number of boot sector copy (or 0 if none)
dd 0, 0, 0
drive_number:
db 0
db 0, 0x29
dd 0x20160510 ; volume ID
db " " ; volume label
db "FAT32 "

start:
xor ax, ax
mov ds, ax
mov es, ax
mov ss, ax
mov sp, 0x7C00
jmp 0:.1
.1:
cld
mov [drive_number], dl ; initialize BPB drive number
push es
mov ah, 8 ; get drive parameters
int 0x13
pop es
jc .2 ; use default BPB entries
and cx, 0x3F ; maximum sector number
mov [sectors_per_track], cx
movzx dx, dh
inc dx
mov [number_of_heads], dx
.2:
mov ax, 1
mov bp, 35
mov bx, fsi
call chs
mov ax, 36
mov bp, 30
mov bx, fsi+512*35
call chs
jmp next

chs:
xor dx, dx
div WORD [sectors_per_track]
inc dx
mov cx, dx
xor dx, dx
div WORD [number_of_heads]
mov dh, dl
xchg al, ah
shl al, 6
or cx, ax
mov dl, [drive_number]
read_sectors:
mov ax, bp
mov ah, 2
mov bp, 4
.1:
push ax
int 0x13
jnc .2
sub bp, 1
jc error
xor ax, ax
int 0x13
pop ax
jmp .1
.2:
pop bp
ret

error:
mov si, drive_error
exit:
call print
xor ah, ah
int 0x16
int 0x18
int 0x19

print:
lodsb
test al, al
je .1
mov ah, 0xE
xor bx, bx
int 0x10
jmp print
.1:
ret

start_of_data: dw 0
drive_error:
db 0x0D, 0x0A, "Drive error!"
press_any_key:
db 0x0D, 0x0A
db "Press any key to continue boot sequence ..."
db 0x0D, 0x0A, 0
times 510-($-_start) db 0
dw 0xAA55

fsi:
db "RRaA"
times 480 db 0
db "rrAa"
dd -1 ; number of free clusters or -1 if unknown
dd 2 ; number of the next free cluster
times 14 db 0
dw 0xAA55

next:
call last
mov esi, hello
call print
mov esi, press_any_key
jmp exit
times (512*63)-($-next) db 0
last:
ret
hello:
db 0x0D, 0x0A, "Hello 1.44MB FAT32 floppy disk!", 0
times 512-($-last) db 0
times 512*6 db 0

fat:
dd 0x0FFFFFF8, 0x0FFFFFFF

%assign i 3
%rep 14-1
dd i ; pre-allocate 14 root directory sectors
%assign i i+1
%endrep

dd 0x0FFFFFFF

%rep 2286-14
dd 0
%endrep

%rep (SECTORS_PER_FAT*128)-2288
dd 0x0FFFFFF7 ; mark clusters outside 1.44MB as "bad"
%endrep

root:
db "144MB FAT32"
db 8 ; volume label
times 20 db 0

; pre-allocate 14 root directory sectors
times (512*14)-($-root) db 0

times 512*(2880-RESERVED_SECTORS-SECTORS_PER_FAT-14) db 0xF6

[/code]


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[JJ]

On Tue, 10 May 2016 07:44:29 -0400, Mike Gonta wrote:
> http://forum.osdev.org/viewtopic.php?f=2&t=30339
>
> http://board.flatassembler.net/topic.php?t=19150
>
> https://www.reddit.com/r/osdev/
>
> https://voat.co/v/programming
>
> http://mikegonta.com/MikeOS-4.5_FAT32
>
> Windows XP (the machine I have with a floppy disk drive)
> happily reads and writes the physical floppy disk as FAT32.
>
> MikeOS-4.5 FAT32 boots and runs as FAT32 from the physical
> floppy disk.
> Of course, the code (NASM) (and image) is designed to boot and run
> from a USB flash drive.

Is there any advantage of using FAT32 on floppy disks? i.e. something that
FAT12 can't do? I could only find a disadvantage, which is lesser available
free space due to overhead caused by its 32-bit wide FAT table.

[Mike Gonta]

None whatsoever!
The 1.44MB FAT32 floppy disk is just a novelty.
The important thing is the formatted image (which can be any
size that you want).
With the addition of the preallocated root directory
clusters a simple FAT32 driver is actually simpler than it's
FAT12 counterpart. See http://mikegonta.com/MikeOS-4.5_FAT32
The code is exactly the same as the the FAT12 version, I
merely adapted it to FAT32. It's simpler due to the FAT32
entries handling.
To the seasoned professional the entire thing is only a
novelty. But to the beginner, it means goodbye to FAT12
(and FAT16) and hello to FAT32.

PS. I only formatted the floppy disk because I figured that
someone would complain that there was "no such thing as a
FAT32 floppy disk".

[Robert Wessel]

On Tue, 10 May 2016 07:44:29 -0400, "Mike Gonta"

There are systems that would refuse to mount such a volume because the
logical parameters conflict with the physical ones. That you're also
dedicating 250KB to bad FAT entries is also a downside.

[Mike Gonta]

"Mike Gonta" wrote:

> [code]
>
> SECTORS_PER_CLUSTER EQU 1
> RESERVED_SECTORS EQU 72
> NUMBER_OF_FATS EQU 1
> SECTORS_PER_TRACK EQU 18
> NUMBER_OF_HEADS EQU 2
> SECTORS EQU 66602
> SECTORS_PER_FAT EQU 522
> HIDDEN_SECTORS EQU 0
>
> ; 1.44MB
>
> org 0x7C00
> _start:
> jmp SHORT start
> nop
> db "144MB FAT32"

I've got too many characters on the OEM field, should be
only 8.

db "144FAT32"

[Mike Gonta]

"Robert Wessel" wrote:

"Mike Gonta" wrote:
>
>>http://forum.osdev.org/viewtopic.php?f=2&t=30339
>>
>>http://board.flatassembler.net/topic.php?t=19150
>>
>>https://www.reddit.com/r/osdev/
>>
>>https://voat.co/v/programming
>>
>>http://mikegonta.com/MikeOS-4.5_FAT32
>>

> There are systems that would refuse to mount such a volume
> because the logical parameters conflict with the physical
> ones.

Can you test it on any of these systems and report back?
It also works fine on a USB flash drive.

> That you're also dedicating 250KB to bad FAT entries is
> also a downside.

I did a Windows XP chkdsk on the physical floppy disk and no
errors were reported. As I previously mentioned XP has no
problem reading/writing it. The upside is that the host
operating system won't write files outside of the Virtual
Partition.

[Mike Gonta]

"Mike Gonta" wrote:
> "Robert Wessel" wrote:
> "Mike Gonta" wrote:
>>
>>> http://forum.osdev.org/viewtopic.php?f=2&t=30339
>>>
>>> http://board.flatassembler.net/topic.php?t=19150
>>>
>>> https://www.reddit.com/r/osdev/
>>>
>>> https://voat.co/v/programming
>>>
>>> http://mikegonta.com/MikeOS-4.5_FAT32
>>>
>
>> There are systems that would refuse to mount such a volume
>> because the logical parameters conflict with the physical
>> ones.
>
> Can you test it on any of these systems and report back?
> It also works fine on a USB flash drive.

I can confirm that Windows 98 (and I'm assuming DOS) will
not mount it. However, I'm not concerned with the "old"
systems (including XP which does work). The 1.44MB FAT32
floppy disk is only a "technical" novelty.
The interesting aspect is the adaption of the MikeOS FAT12
to FAT32. The FAT12 floppy disk (image) has long since been
the mainstay of the simple OS and standalone system. Now an
even simpler FAT32 system is available.
http://mikegonta.com/MikeOS-4.5_FAT32

[wolfgang kern]

Mike Gonta wrote:
>> "Robert Wessel" wrote:
>> "Mike Gonta" wrote:

>>>> http://forum.osdev.org/viewtopic.php?f=2&t=30339
>>>>
>>>> http://board.flatassembler.net/topic.php?t=19150
>>>>
>>>> https://www.reddit.com/r/osdev/
>>>>
>>>> https://voat.co/v/programming
>>>>
>>>> http://mikegonta.com/MikeOS-4.5_FAT32

>>> There are systems that would refuse to mount such a volume
>>> because the logical parameters conflict with the physical
>>> ones.

>> Can you test it on any of these systems and report back?
>> It also works fine on a USB flash drive.

Every system which rely on M$s "Hardware White Paper" about
FAT specification (ie: vsn 1.02 May 1999) will fail because
your total cluster count is less than 0xfff5 which indicate
FAT16 or even FAT12 if the cluster count is below 0x0ff5.

So my OS wont see your FAT32 image.
And according to specs: the minimum size of FAT32 is 32 MB.

> I can confirm that Windows 98 (and I'm assuming DOS) will
> not mount it. However, I'm not concerned with the "old"
> systems (including XP which does work). The 1.44MB FAT32
> floppy disk is only a "technical" novelty.
> The interesting aspect is the adaption of the MikeOS FAT12
> to FAT32. The FAT12 floppy disk (image) has long since been
> the mainstay of the simple OS and standalone system. Now an
> even simpler FAT32 system is available.

It's interesting that XP seem to ignore its own M$-rules :)

But isn't FAT already a dead horse ?
win7 want to be installed on a NT-partition only.

__
wolfgang

[Robert Wessel]

On Wed, 11 May 2016 11:43:56 +0200, "wolfgang kern" <now...@never.at>
wrote:

>
>Mike Gonta wrote:
>>> "Robert Wessel" wrote:
>>> "Mike Gonta" wrote:
>
>>>>> http://forum.osdev.org/viewtopic.php?f=2&t=30339
>>>>>
>>>>> http://board.flatassembler.net/topic.php?t=19150
>>>>>
>>>>> https://www.reddit.com/r/osdev/
>>>>>
>>>>> https://voat.co/v/programming
>>>>>
>>>>> http://mikegonta.com/MikeOS-4.5_FAT32
>
>>>> There are systems that would refuse to mount such a volume
>>>> because the logical parameters conflict with the physical
>>>> ones.
>
>>> Can you test it on any of these systems and report back?
>>> It also works fine on a USB flash drive.
>
>Every system which rely on M$s "Hardware White Paper" about
>FAT specification (ie: vsn 1.02 May 1999) will fail because
>your total cluster count is less than 0xfff5 which indicate
>FAT16 or even FAT12 if the cluster count is below 0x0ff5.

Unless I'm not reading it correctly, his cluster count appears to be
~66008 clusters of 512 bytes, so he's above that limit.

>So my OS wont see your FAT32 image.
>And according to specs: the minimum size of FAT32 is 32 MB.

What he's done is describe the volume as having 66602 sectors, and
then declaring all but the first 2280 clusters as invalid in the FAT.

>> I can confirm that Windows 98 (and I'm assuming DOS) will
>> not mount it. However, I'm not concerned with the "old"
>> systems (including XP which does work). The 1.44MB FAT32
>> floppy disk is only a "technical" novelty.
>> The interesting aspect is the adaption of the MikeOS FAT12
>> to FAT32. The FAT12 floppy disk (image) has long since been
>> the mainstay of the simple OS and standalone system. Now an
>> even simpler FAT32 system is available.
>
>It's interesting that XP seem to ignore its own M$-rules :)

I believe it's more likely that it's seeing a completely illogical
volume (the number of sectors declared in the BPB vastly exceeds the
physical capacity of the device) and refusing to mount that.

>But isn't FAT already a dead horse ?
>win7 want to be installed on a NT-partition only.

Sure, but FAT is used on many removable devices, even if floppies are
rare these days, massive numbers of flash drives of various sorts are
formatted FAT.

Mike has invented a new FS (which is fine), which bears some
resemblances to FAT, but is not actually FAT (his handling of the root
directory is a major issue). The problem is that he keeps trying to
claim it actually works and/or is actually compatible with FAT. To
maintain that position he's dismissed multiple issues pointed out to
him (in this case, he's just elected to dismiss Win98, likewise he's
just ignored the issue that a "real" FAT implementation can break his
"FAT" root directory by doing things that are perfectly allowed - for
example by creating more files than this volume has pre-allocated root
directory entries). If he wants to produce a FAT variant, it's on him
to demonstrate that it actually works on the many hundreds of
implementations that *can* mount FAT volumes, if he actually wants to
call it "FAT". Of course that's impossible to do, which is why
following the rules is pretty much required.

[Mike Gonta]

"wolfgang kern" wrote:
> Mike Gonta wrote:
>>> "Robert Wessel" wrote:
>>> "Mike Gonta" wrote:
>
>>>>> http://forum.osdev.org/viewtopic.php?f=2&t=30339
>>>>>
>>>>> http://board.flatassembler.net/topic.php?t=19150
>>>>>
>>>>> https://www.reddit.com/r/osdev/
>>>>>
>>>>> https://voat.co/v/programming
>>>>>
>>>>> http://mikegonta.com/MikeOS-4.5_FAT32
>
>>>> There are systems that would refuse to mount such a volume
>>>> because the logical parameters conflict with the physical
>>>> ones.
>
>>> Can you test it on any of these systems and report back?
>>> It also works fine on a USB flash drive.
>
> Every system which rely on M$s "Hardware White Paper" about FAT
> specification (ie: vsn 1.02 May 1999) will fail because your total cluster
> count is less than 0xfff5 which indicate FAT16 or even FAT12 if the
> cluster count is below 0x0ff5.

It's fully compatible with the specification. The file
system is in the BBP and FAT table structure on disk. It's
only the "old" systems that can't get beyond the physical
structure of the floppy disk.

> So my OS wont see your FAT32 image.

Transfer the image to a USB flash drive. I'm sure your "new"
system will access it just fine.

> And according to specs: the minimum size of FAT32 is 32 MB.

Windows reports the minimum 32.5 MB size.

>> I can confirm that Windows 98 (and I'm assuming DOS) will
>> not mount it. However, I'm not concerned with the "old"
>> systems (including XP which does work). The 1.44MB FAT32
>> floppy disk is only a "technical" novelty.
>> The interesting aspect is the adaption of the MikeOS FAT12
>> to FAT32. The FAT12 floppy disk (image) has long since been
>> the mainstay of the simple OS and standalone system. Now an
>> even simpler FAT32 system is available.
>
> It's interesting that XP seem to ignore its own M$-rules :)

MS rules are made to be broken. For example, on a newly
formatted FAT32 flash drive the "next free cluster" is 3,
yet in the FAT32 FSI sector "next free cluster" field MS
puts 2. This might be because MS doesn't trust this field
and ignores it when mounting a flash drive.

> But isn't FAT already a dead horse ?
> win7 want to be installed on a NT-partition only.

Win7 also reads/writes files with the image on a USB flash
drive just fine.

[wolfgang kern]

Mike and Robert replied:
...

>> Every system which rely on M$s "Hardware White Paper" about FAT
>> specification (ie: vsn 1.02 May 1999) will fail because your total
>> cluster count is less than 0xfff5 which indicate FAT16 or even FAT12
>> if the cluster count is below 0x0ff5.
> It's fully compatible with the specification. The file
> system is in the BBP and FAT table structure on disk. It's
> only the "old" systems that can't get beyond the physical
> structure of the floppy disk.

>> So my OS wont see your FAT32 image.
> Transfer the image to a USB flash drive. I'm sure your "new"
> system will access it just fine.

my OS isn't new at all ;) started 1985 and became standalone 1990.

>> And according to specs: the minimum size of FAT32 is 32 MB.
> Windows reports the minimum 32.5 MB size.

Ok, I missed that you filled the FAT with that many bad clusters.
So even it follows the specs, some OS may see such a volume as
corrupted.

My question still is where you see the advantage of wasting
almost 20% of the disk capacity just to have FAT32.

Issues with FAT12 are well known:
(not optimised nor tested, just to show how easy it is)

* multiply cluster number (in eAX) by three (add 2 in front of).
MOV cx,ax ;copy cluster number
ADD ax,2
MOV dx,ax
ADD dx,dx
ADD ax,dx
(or: LEA eax,[eax+eax*2+6])
; so AX is the total byte offset within the whole FAT

* calculate FAT-sector and offset for this entry.
XOR dx,dx
MOV bx,0x200 ;sector size
DIV bx
AX = FAT sector DX = offset within this sector.

* always load two (or multiple of 2) even FAT-sectors to RAM
to avoid odd sector bounds.
TEST AL,1
JZ even_sect
AND AL,0xFE
ADD dx,bx
even_sect:
ADD ax,FATstart ;LBA
MOV si,dx ;byte offset
CALL... ;load two or more sectors to [mem]

* get the FAT-entry
MOV ax,[si+mem]
TEST cl,1
JZ even_clust
SHR ax,4
even_clust:
AND ax,0x0fff

* check for valid/endmark/bad/fragmented/...
...

__
wolfgang

[Mike Gonta]

"Robert Wessel" wrote:

>"wolfgang kern" wrote:
>>Mike Gonta wrote:
>>>> "Robert Wessel" wrote:
>>>>> "Mike Gonta" wrote:
>>
>>>>>> http://forum.osdev.org/viewtopic.php?f=2&t=30339
>>>>>>
>>>>>> http://board.flatassembler.net/topic.php?t=19150
>>>>>>
>>>>>> https://www.reddit.com/r/osdev/
>>>>>>
>>>>>> https://voat.co/v/programming
>>>>>>
>>>>>> http://mikegonta.com/MikeOS-4.5_FAT32
>>
>>>>> There are systems that would refuse to mount such a volume
>>>>> because the logical parameters conflict with the physical
>>>>> ones.
>>
>>>> Can you test it on any of these systems and report back?
>>>> It also works fine on a USB flash drive.
>>
>>Every system which rely on M$s "Hardware White Paper" about
>>FAT specification (ie: vsn 1.02 May 1999) will fail because
>>your total cluster count is less than 0xfff5 which indicate
>>FAT16 or even FAT12 if the cluster count is below 0x0ff5.
>
>
> Unless I'm not reading it correctly, his cluster count
> appears to be ~66008 clusters of 512 bytes, so he's above
> that limit.

Actually it's 66602. The MS cutoff value for FAT32 is a
disk size greater than 66600 sectors. I tried 66601 which
didn't work, but 66602 did (might be an off by one MS error).

>>So my OS wont see your FAT32 image.
>>And according to specs: the minimum size of FAT32 is 32 MB.
>
> What he's done is describe the volume as having 66602
> sectors, and then declaring all but the first 2280
> clusters as invalid in the FAT.

The 66602 (and the correct number of FAT table sectors) is
all that's required. The "bad sectors" idea was suggested by
a Reddit comment.

>>> I can confirm that Windows 98 (and I'm assuming DOS) will
>>> not mount it. However, I'm not concerned with the "old"
>>> systems (including XP which does work). The 1.44MB FAT32
>>> floppy disk is only a "technical" novelty.
>>> The interesting aspect is the adaption of the MikeOS FAT12
>>> to FAT32. The FAT12 floppy disk (image) has long since been
>>> the mainstay of the simple OS and standalone system. Now an
>>> even simpler FAT32 system is available.
>>
>>It's interesting that XP seem to ignore its own M$-rules :)
>
> I believe it's more likely that it's seeing a completely
> illogical volume (the number of sectors declared in the
> BPB vastly exceeds the physical capacity of the device)
> and refusing to mount that.

It's more likely "assuming" a FAT12 BPB and not finding the
appropriate values. I have no way of confirming it just now
(the Win98 machine has no USB), but i would guess that a USB
flash drive with the image will be correctly mounted by
Win98/DOS.

>>But isn't FAT already a dead horse ?
>>win7 want to be installed on a NT-partition only.
>
> Sure, but FAT is used on many removable devices, even if
> floppies are rare these days, massive numbers of flash
> drives of various sorts are formatted FAT.

Exactly. Keep in mind that the 1.44MB FAT32 floppy disk is
just a novelty and even if it didn't work (I was surprised
it did) it wouldn't invalidate the use of the format on a
USB flash drive as a simple (simpler) replacement for the
simple system OS use of the FAT12 floppy disk image.

> Mike has invented a new FS (which is fine), which bears
> some resemblances to FAT, but is not actually FAT (his
> handling of the root directory is a major issue). The
> problem is that he keeps trying to claim it actually works
> and/or is actually compatible with FAT. To maintain that
> position he's dismissed multiple issues pointed out to
> him (in this case, he's just elected to dismiss Win98,
> likewise he's just ignored the issue that a "real" FAT
> implementation can break his "FAT" root directory by doing
> things that are perfectly allowed - for example by
> creating more files than this volume has pre-allocated root
> directory entries).

Nothing gets broken. This fact actually supports my 100%
compatibility claim. It's only a minor technical
"inconvenience" easily worked around that only effects the
primary use case. It doesn't need to work on old systems,
the beginner will be using a new system.

> If he wants to produce a FAT variant, it's on him
> to demonstrate that it actually works on the many hundreds
> of implementations that *can* mount FAT volumes, if he
> actually wants to call it "FAT". Of course that's
> impossible to do, which is why following the rules is
> pretty much required.

All the rules are followed.
The "inconvenience" is because the host OS won't overwrite
deleted directory entries (saving them for un-delete). The
simple system doesn't care about this (it's only reading an
ini file and/or writing a log file, etc). The restricted
size of the FAT12 root directory was no problem.
In most of the use cases a small binary will be
changed/updated by the assembler/compiler and written to the
flash drive/image which won't entail creating a new
directory entry. It's a simple a matter for my scripted
system to always begin with a fresh image, mount it and write
all the original files along with the new one always keeping
the root directory contents within the 14 sectors. The
limited size was no problem for such FAT12 root directory
restricted small systems. The idea is to replace that "old"
FAT12 system with an "old" but newer FAT32 system.
"Certain restrictions may apply".
For example the simple FAT12 system "assume" that there was
only one reserved sector (the boot sector) and conveniently
hard coded the locations of the FAT table and root directory.
They could do this since the image that they were
distributed on was formatted as such and there was no
intention to use the system otherwise. Also the size of the
tables was fixed by the floppy disk image. So even in these
cases what they called "FAT12" was only a small subset of the
the actual FAT12 world.

[Rick C. Hodgin]

On Wednesday, May 11, 2016 at 5:51:24 AM UTC-4, wolfgang kern wrote:
> Mike Gonta wrote:
> >> "Robert Wessel" wrote:
> >> "Mike Gonta" wrote:
>
> >>>> http://forum.osdev.org/viewtopic.php?f=2&t=30339
> >>>>
> >>>> http://board.flatassembler.net/topic.php?t=19150
> >>>>
> >>>> https://www.reddit.com/r/osdev/
> >>>>
> >>>> https://voat.co/v/programming
> >>>>
> >>>> http://mikegonta.com/MikeOS-4.5_FAT32
>
> >>> There are systems that would refuse to mount such a volume
> >>> because the logical parameters conflict with the physical
> >>> ones.
>
> >> Can you test it on any of these systems and report back?
> >> It also works fine on a USB flash drive.
>
> Every system which rely on M$s "Hardware White Paper" about
> FAT specification (ie: vsn 1.02 May 1999) will fail because
> your total cluster count is less than 0xfff5 which indicate
> FAT16 or even FAT12 if the cluster count is below 0x0ff5.
>
> So my OS wont see your FAT32 image.
> And according to specs: the minimum size of FAT32 is 32 MB.

It's a relatively minor fixup to gain access if you desire. If
not then ... no harm, no foul.

> > I can confirm that Windows 98 (and I'm assuming DOS) will
> > not mount it. However, I'm not concerned with the "old"
> > systems (including XP which does work). The 1.44MB FAT32
> > floppy disk is only a "technical" novelty.
> > The interesting aspect is the adaption of the MikeOS FAT12
> > to FAT32. The FAT12 floppy disk (image) has long since been
> > the mainstay of the simple OS and standalone system. Now an
> > even simpler FAT32 system is available.
>
> It's interesting that XP seem to ignore its own M$-rules :)
>
> But isn't FAT already a dead horse ?
> win7 want to be installed on a NT-partition only.

It still reads FAT partitions. NT partitions are used because of
the additional attributes they allow.

Best regards,
Rick C. Hodgin

[Robert Wessel]

You appear to have 66602 sectors. The number of clusters on that will
necessarily be less, since the reserved sectors and the FATs are not
allocated in clusters.

Looking at your code more closely, you've allocated an excessive
number of sectors to the FAT. Counting the 72 reserved sectors and
the 522 sectors in the (one) FAT, you end up with 66008 data sectors,
and (since you have 512 by clusters), 66008 clusters. Which means you
should only need 516 sectors in a FAT.

The 66600* cut-off for FAT32 for MS is really supposed to be just for
formatting the volume, where MS documents it as being the smallest
volume for formatting FAT32. It's possible there's a bug someplace
and it's being used as such. Another good reason for following the
rules.


*I believe that number comes from taking the normal number of FAT32
reserved sectors, and two copies of the necessary FAT, and that gets
you to about the 65524 cluster limit. Actually I get 66588 as a limit
then, and the limit in the formatting table (66000) is an oddly round
number, or is based on an incorrect maximum FAT size (522 sectors,
which should actually be 516 as I mentioned). Still, the point is:
don't do that, things will get confused. In any event those limits
are really for deciding what cluster sizes to use, and clearly take a
simplified view of the possibilities.

>>>So my OS wont see your FAT32 image.
>>>And according to specs: the minimum size of FAT32 is 32 MB.
>>
>> What he's done is describe the volume as having 66602
>> sectors, and then declaring all but the first 2280
>> clusters as invalid in the FAT.
>
>The 66602 (and the correct number of FAT table sectors) is
>all that's required. The "bad sectors" idea was suggested by
>a Reddit comment.

Well, yes, that's the theory, everyone has understood that approach
(fake the volume size, mark all the extra clusters bad) for decades
now.

>>>> I can confirm that Windows 98 (and I'm assuming DOS) will
>>>> not mount it. However, I'm not concerned with the "old"
>>>> systems (including XP which does work). The 1.44MB FAT32
>>>> floppy disk is only a "technical" novelty.
>>>> The interesting aspect is the adaption of the MikeOS FAT12
>>>> to FAT32. The FAT12 floppy disk (image) has long since been
>>>> the mainstay of the simple OS and standalone system. Now an
>>>> even simpler FAT32 system is available.
>>>
>>>It's interesting that XP seem to ignore its own M$-rules :)
>>
>> I believe it's more likely that it's seeing a completely
>> illogical volume (the number of sectors declared in the
>> BPB vastly exceeds the physical capacity of the device)
>> and refusing to mount that.
>
>It's more likely "assuming" a FAT12 BPB and not finding the
>appropriate values. I have no way of confirming it just now
>(the Win98 machine has no USB), but i would guess that a USB
>flash drive with the image will be correctly mounted by
>Win98/DOS.

Frankly I don't care why it doesn't work. I've given you a perfectly
valid reason why it might not, and you've postulated one that might be
due to a buggy FAT implementation (of which there are many!). Yet the
problem remains, here's a system (which might not be a current popular
system, but was at one time far and away the most popular system
supporting FAT) where your funky format does not work. Can you tell
me that this weird format isn't going to be a problem on any/some/many
of the hundreds of other implementations as well? OTOH, had you stuck
with the common formats, you'd likely work in a lot more places.

>>>But isn't FAT already a dead horse ?
>>>win7 want to be installed on a NT-partition only.
>>
>> Sure, but FAT is used on many removable devices, even if
>> floppies are rare these days, massive numbers of flash
>> drives of various sorts are formatted FAT.
>
>Exactly. Keep in mind that the 1.44MB FAT32 floppy disk is
>just a novelty and even if it didn't work (I was surprised
>it did) it wouldn't invalidate the use of the format on a
>USB flash drive as a simple (simpler) replacement for the
>simple system OS use of the FAT12 floppy disk image.

Fine. So insist that users buy at least a 33MB flash drive, and they
format with 512 byte clusters. And stop making a hash of the root
directory. Of course that leave you with the problem that you
immediately don't work with small flash drives *without* requiring the
user to reformat them. All of this to avoid a minor amount of extra
code to support FAT12/16.

>> Mike has invented a new FS (which is fine), which bears
>> some resemblances to FAT, but is not actually FAT (his
>> handling of the root directory is a major issue). The
>> problem is that he keeps trying to claim it actually works
>> and/or is actually compatible with FAT. To maintain that
>> position he's dismissed multiple issues pointed out to
>> him (in this case, he's just elected to dismiss Win98,
>> likewise he's just ignored the issue that a "real" FAT
>> implementation can break his "FAT" root directory by doing
>> things that are perfectly allowed - for example by
>> creating more files than this volume has pre-allocated root
>> directory entries).
>
>Nothing gets broken. This fact actually supports my 100%
>compatibility claim. It's only a minor technical
>"inconvenience" easily worked around that only effects the
>primary use case. It doesn't need to work on old systems,
>the beginner will be using a new system.

Seriously? It's "100% compatible", despite requiring a "workaround"
in some cases, and not working on "old systems"? That's the oddest
definition of compatibility I've ever heard.

>> If he wants to produce a FAT variant, it's on him
>> to demonstrate that it actually works on the many hundreds
>> of implementations that *can* mount FAT volumes, if he
>> actually wants to call it "FAT". Of course that's
>> impossible to do, which is why following the rules is
>> pretty much required.
>
>All the rules are followed.
>The "inconvenience" is because the host OS won't overwrite
>deleted directory entries (saving them for un-delete). The
>simple system doesn't care about this (it's only reading an
>ini file and/or writing a log file, etc). The restricted
>size of the FAT12 root directory was no problem.
>In most of the use cases a small binary will be
>changed/updated by the assembler/compiler and written to the
>flash drive/image which won't entail creating a new
>directory entry. It's a simple a matter for my scripted
>system to always begin with a fresh image, mount it and write
>all the original files along with the new one always keeping
>the root directory contents within the 14 sectors. The
>limited size was no problem for such FAT12 root directory
>restricted small systems. The idea is to replace that "old"
>FAT12 system with an "old" but newer FAT32 system.

Are you saying that you're going to write this image, including the
format from your device, and never allow write* access to the volume
from anything else with any guarantee that your device will be able to
use the volume after that? OK, in that case I'll conceed that your
approach (of having a fixed root directory, but not the artificially
inflated number of sectors), should work. But if that's the actual
restriction, you should probably make that clearer, and you're still
going to leave everyone wondering why. One way you might justify this
is if the device reformatted the volume every time it mounted it (IOW,
this is an output-only volume).

OTOH, that does *not* appear to be what you're saying, and you appear
to be inplying that a new executable might be loaded onto the volume
by a PC or something. Except that you may be using a custom
utility/process to load the volume. Which again would imply a
certatin lack of compatibility.

OTOH, how much work are you saving yourself here? Just do it right.


*Or at least no write access that allows the modification of the root
directory, including any sort of re-org or file creation/deletion
operation.

>"Certain restrictions may apply".

Because it's "100% compatible"?!

>For example the simple FAT12 system "assume" that there was
>only one reserved sector (the boot sector) and conveniently
>hard coded the locations of the FAT table and root directory.
>They could do this since the image that they were
>distributed on was formatted as such and there was no
>intention to use the system otherwise. Also the size of the
>tables was fixed by the floppy disk image. So even in these
>cases what they called "FAT12" was only a small subset of the
>the actual FAT12 world.

Certainly there have been FAT12 and FAT16 implementations that assume
one reserved sector (as has been pointed out many times, there are
vast numbers of buggy implementations out there). OTOH, a good
implementation won't. Still if the diskette is actually formatted
with exactly one reserved sector it doesn't matter. That doesn't
matter since you can't normally change the number of reserved sectors
on a volume, but you *can* change the number of entries in the root
directory.

[Rod Pemberton]

On Wed, 11 May 2016 05:19:24 -0500
Robert Wessel <robert...@nospicedham.yahoo.com> wrote:

> What he's done is describe the volume as having 66602 sectors, and
> then declaring all but the first 2280 clusters as invalid in the FAT.

Is this any different from having a large allocated file?

As long as the OS doesn't defrag or otherwise re-arrange or
move around sectors on the device, why would this be an issue?

> Sure, but FAT is used on many removable devices, even if floppies are
> rare these days, massive numbers of flash drives of various sorts are
> formatted FAT.

Yes, I wouldn't mind testing this on two Win10 machines,
but neither has a floppy drive. Both do have USB though.
E.g., will Win10 handle both floppy and usb the same here?

> Mike has invented a new FS (which is fine), which bears some
> resemblances to FAT, but is not actually FAT (his handling of the root
> directory is a major issue). The problem is that he keeps trying to
> claim it actually works and/or is actually compatible with FAT. To
> maintain that position he's dismissed multiple issues pointed out to
> him (in this case, he's just elected to dismiss Win98, likewise he's
> just ignored the issue that a "real" FAT implementation can break his
> "FAT" root directory by doing things that are perfectly allowed - for
> example by creating more files than this volume has pre-allocated root
> directory entries). If he wants to produce a FAT variant, it's on him
> to demonstrate that it actually works on the many hundreds of
> implementations that *can* mount FAT volumes, if he actually wants to
> call it "FAT". Of course that's impossible to do, which is why
> following the rules is pretty much required.

Has anyone tried to mount this image as loopback on Linux?
Has anyone run Linux fsck on it when mounted?


Rod Pemberton

[Rod Pemberton]

On Tue, 10 May 2016 07:44:29 -0400

"Mike Gonta" <mike...@nospicedham.gmail.com> wrote:

> http://mikegonta.com/MikeOS-4.5_FAT32

Mike,

On Linux, Qemu boots the mikeos.img just fine. The OS starts. The menu
comes up. The apps work.

DOSBox mounts the image just fine with DOSBox's mount command.
Unfortunately, there are no DOS .com's or .exe's present in the image.
Mounting bypasses the boot code. Of course, .BAS .BIN and .PCX are not
executable under DOS. This is the way I normally use DOSBox which is
intended to run games, not boot disks.

I was unsure as to how to get DOSBox to boot an image. Online webpages
said to use the imgmount and boot commands to boot images. I was not
able to get DOSBox's imgmount and boot commands to mount or boot your
image, but I'm not that familiar with this. I was able to get a
FreeDOS image to mount with imgmount, but it would not boot either. The
imgmount command wants the geometry for an image to mount it. I passed
the normal floppy geometry, e.g., 512,18,2,80. This worked for the
FreeDOS image. I'm not sure what I would need for yours to be
recognized. I'm assuming that the 80 at least needs to be much larger.

I have no problem getting Dosemu to boot my DOS partition on a hard
drive, but it kept spitting out the following Dosemu and FreeDOS errors
when I attempted to boot your image. Note, that I was entirely unsure
if I had set dosemu to boot an image correctly, or even if it could boot
an image. I wasn't finding much info online either ... So, I
attempted to boot a FreeDOS floppy image, and Dosemu booted it just
fine. Dosemu/FreeDOS errors for yours:

"Sorry, there is no operating system here:"
"~/.dosemu/drives/c"
"Please try to install FreeDOS from dosemu-freedos-*-bin.tgz"

I was having lots of problems booting a physical drive with Bochs. So,
I'm not even going to attempt an image.

Below, you can see the info that various Linux commands report for your
mikeos.img. E.g., the commands: file, df, mount, dosfsck, etc.

Mount thinks that there is plenty of space available, not allocated.
And, dosfsck thinks your image missing a backup boot sector. At a
minimum, they provide some info that you can cross check.

Are you ever going to set up a Linux system to check this stuff? ...

HTH,


Rod Pemberton


:# file mikeos.img
mikeos.img: x86 boot sector, code offset 0x58,
OEM-ID "MIKEBOOT", reserved sectors 162, FAT 1,
sectors 66602 (volumes > 32 MB) , FAT (32 bit),
sectors/FAT 522, Backup boot sector 0,
serial number 0x0, label: "MIKEOS "

:# dosfsck -v mikeos.img
dosfsck 3.0.11 (24 Dec 2010)
dosfsck 3.0.11, 24 Dec 2010, FAT32, LFN
Checking we can access the last sector of the filesystem
There is no backup boot sector.
1) Create one
2) Do without a backup
? 2
Boot sector contents:
System ID "MIKEBOOT"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
512 bytes per logical sector
512 bytes per cluster
162 reserved sectors
First FAT starts at byte 82944 (sector 162)
1 FATs, 32 bit entries
267264 bytes per FAT (= 522 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 350208 (sector 684)
65918 data clusters (33750016 bytes)
18 sectors/track, 2 heads
0 hidden sectors
66602 sectors total
Checking for unused clusters.
Checking free cluster summary.
mikeos.img: 22 files, 332/65918 clusters

:# mount -o loop mikeos.img /media/floppy1
:# df -v
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop0 32959 166 32793 1% /media/floppy1

:# mount
/mnt/ramdisk/mikeos.img on /media/floppy1 type vfat (rw)

:# cd /media/floppy1
:# ls -lR
.:
total 159
-rwxr-xr-x 1 .... .... 9187 Dec 21 2014 ADVNTURE.BAS*
-rwxr-xr-x 1 .... .... 9827 Dec 21 2014 ARCHIVE.BAS*
-rwxr-xr-x 1 .... .... 5566 Dec 21 2014 CALC.BAS*
-rwxr-xr-x 1 .... .... 15827 Dec 21 2014 CF.BAS*
-rwxr-xr-x 1 .... .... 14374 Dec 21 2014 DRAW.BAS*
-rwxr-xr-x 1 .... .... 1864 Dec 21 2014 EDIT.BIN*
-rwxr-xr-x 1 .... .... 2138 Dec 21 2014 EXAMPLE.BAS*
-rwxr-xr-x 1 .... .... 1228 May 3 19:04 FILEMAN.BIN*
-rwxr-xr-x 1 .... .... 1479 Dec 21 2014 FISHER.BIN*
-rwxr-xr-x 1 .... .... 9212 Dec 21 2014 FORTH.BIN*
-rwxr-xr-x 1 .... .... 3803 Dec 21 2014 HANGMAN.BIN*
-rwxr-xr-x 1 .... .... 19066 May 6 05:13 KERNEL.BIN*
-rwxr-xr-x 1 .... .... 761 Dec 21 2014 KEYBOARD.BIN*
-rwxr-xr-x 1 .... .... 13334 Dec 21 2014 MBPP.BAS*
-rwxr-xr-x 1 .... .... 6797 Dec 21 2014 MEMEDIT.BAS*
-rwxr-xr-x 1 .... .... 856 Dec 21 2014 MONITOR.BIN*
-rwxr-xr-x 1 .... .... 5860 Dec 21 2014 MUNCHER.BAS*
-rwxr-xr-x 1 .... .... 28352 Dec 21 2014 SAMPLE.PCX*
-rwxr-xr-x 1 .... .... 447 Dec 21 2014 SERIAL.BIN*
-rwxr-xr-x 1 .... .... 6861 Dec 21 2014 SUDOKU.BAS*
-rwxr-xr-x 1 .... .... 567 Dec 21 2014 VIEWER.BIN*

[Note: username replaced with ....]

[Robert Wessel]

On Wed, 11 May 2016 22:07:55 -0400, Rod Pemberton
<NoHave...@nospicedham.bcczxcfre.cmm> wrote:

>On Wed, 11 May 2016 05:19:24 -0500
>Robert Wessel <robert...@nospicedham.yahoo.com> wrote:
>
>> What he's done is describe the volume as having 66602 sectors, and
>> then declaring all but the first 2280 clusters as invalid in the FAT.
>
>Is this any different from having a large allocated file?
>
>As long as the OS doesn't defrag or otherwise re-arrange or
>move around sectors on the device, why would this be an issue?

The problem is that some OSs do sanity checks on the volumes they're
about to mount. And if the volume is larger than the physical disk or
partition that supposedly contains it, they can refuse to mount it.

[Mike Gonta]

"Rod Pemberton" wrote:
> "Mike Gonta" wrote:
>

>> http://mikegonta.com/MikeOS-4.5_FAT32
>
> Mike,

>
> I was unsure as to how to get DOSBox to boot an image.

boot mikeos.img -l a

DOSBox won't boot this image as a hard drive image though.
Qemu/Bochs will boot as either and of course it will boot as
either with a USB flash drive on actual hardware.

> "Sorry, there is no operating system here:"
> "~/.dosemu/drives/c"

Can you try it as floppy a.

> I was having lots of problems booting a physical drive
> with Bochs. So, I'm not even going to attempt an image.

Qemu will boot and run from a physical floppy disk or USB
flash drive, not so with Bochs.

<In bochsrc.txt - the hash sign comments out the other option>
floppya: image=mikeos.img, status=inserted

#ata0-master: type=disk, mode=flat, path=mikeos.img

boot: floppy
#boot: disk

> Are you ever going to set up a Linux system to check this
> stuff? ...

Thanks for helping out Rod.
I haven't got around to Linux yet will have a go at it in
the future.

[Mike Gonta]

"Rod Pemberton" wrote:

> Robert Wessel wrote:
>
>> What he's done is describe the volume as having 66602
>> sectors, and then declaring all but the first 2280
>> clusters as invalid in the FAT.
>
> Is this any different from having a large allocated file?

Exactly (and thanks for the support Rod), pre-allocating a
file is a common procedure for small systems, which then can
easily access the file (as a log file for example) without
any "file system" driver. Technically, the "virtual
partition" is not pre-allocated, but the root directory is.
The FAT32 root directory is essentially a "file".

> As long as the OS doesn't defrag or otherwise re-arrange
> or move around sectors on the device, why would this be an
> issue?

The 1.44MB FAT32 floppy disk image is not designed for
general consumption. It's main purpose in life is as a
direct replacement for the 1.44MB FAT12 floppy disk image
used by simple/hobbyist systems. The refence implementation
is a direct adaptation of a simple FAT12 driver (which is
actually simpler than the original). Most of the few changes
are in the "disk.asm" file and there is a "diff" as well.
http://mikegonta.com/MikeOS-4.5_FAT32

>> Sure, but FAT is used on many removable devices, even if
>> floppies are rare these days, massive numbers of flash
>> drives of various sorts are formatted FAT.

The floppy disk is just a novelty. It's main function is as
a flash drive or emulator image.

> Yes, I wouldn't mind testing this on two Win10 machines,
> but neither has a floppy drive. Both do have USB though.
> E.g., will Win10 handle both floppy and usb the same here?

I don't yet have Win10 (or a USB floppy drive) but I'm
betting that both will work just fine. I can confirm XP
(with both) and Win7 (but not the floppy on Win7). I can
confirm that Windows 98 (and DOS?) won't mount the floppy
disk and I'm assuming that all prior Windows won't either.
Coincidentally 2 years prior to XP's release (which was
probably in the works at the time) the BIOS EDD Specification
talks about the distinction between "removable" and "fixed"
disks differing from the conventional and that removable disks
could be handled as either. Where DOS "assumes that a floppy
disk only has a FAT12 BPB, XP and newer is more active minded.
https://staff.washington.edu/dittrich/misc/fatgen103.pdf
"The FAT type - one of FAT12, FAT16, or FAT32 - is determined
by the count of clusters on the volume and _nothing_ else....
To begin, let's discuss exactly how the "count of clusters"
value is determined. This is all done using the BPB fields
for the volume...."

It says nothing about assumptions or sanity checks or direct
hardware inquiry.

[Rod Pemberton]

On Thu, 12 May 2016 14:30:50 -0400
"Mike Gonta" <mike...@nospicedham.gmail.com> wrote:

> "Rod Pemberton" wrote:
> > "Mike Gonta" wrote:

> >> http://mikegonta.com/MikeOS-4.5_FAT32
> >

> > I was unsure as to how to get DOSBox to boot an image.
>
> boot mikeos.img -l a
>

That works (as last line of ~/.dosbox/dosbox-0.74.conf with path
added). So, DOSBox and Qemu are good on Linux.

> > "Sorry, there is no operating system here:"
> > "~/.dosemu/drives/c"
>
> Can you try it as floppy a.
>

I get the same issue with the drive as a instead of c.


If I set the drive link in .dosemu/drives for either a or c to your
file image, mounted as /media/floppy1, I get:

"
Sorry there is no operating system here:
~/.dosemu/drives/a

Please try to install FreeDOS from dosemu-freedos-*-bin.tgz
"

Doing a FreeDOS image this way starts up the FreeDOS install page. So,
this seems to be correct or at least an acceptable way to start an
image.


If I set the drive link in .dosemu/drives for either a or c directly to
your file image (not mounted), I get:

"
ERROR: IMAGE .dosemu/drives/a header lacks magic string - cannot
autosense!
Segmentation fault
"

Doing FreeDOS image this way returns the same error message. So, this
is not likely the correct way to start an image.


Perhaps there is another way to set it up and run without the Linux
drive links. You may need someone more familiar with dosemu and Linux.


Rod Pemberton

[Robert Wessel]

So it's not 100% compatible anymore?

Nor does it describe partitions*. So obviously FAT can't be used on a
disk with partitions. (Yes, that's sarcasm.)

You can't seriously be claiming that a passage on the determination of
the type of *FAT* prohibits an OS from doing a sanity check on the
size of the volume?


*OK, so it mentions them twice. Once, in an offhand way, to talk
about support for disks bigger than 2GB. And once in the context that
the hidden sector count field might have something to do with
partitions. BTW, that's also a field commonly subject to sanity
checks.

[Mike Gonta]

516 is correct. However, the total sectors field is not
calculated from the available clusters in the number of FAT
sectors field (it's the other way around). The purpose of
the "extra" FAT sectors is padding so that the FAT (and root)
start on 1.44MB track boundaries (which simplifies the
loading). This is fully compatible with the specification
(and also described therein).

> Because it's "100% compatible"?!

I'm only claiming compatibility with the MS EFI FAT32 File
System Specification.
https://staff.washington.edu/dittrich/misc/fatgen103.pdf
and not every implementation good bad or otherwise.

Please keep in mind that the Virtual Partition (the
pre-allocated root and voluntary use restrictions) is
completely separate from the "format". Your complaint seems
to be that after I write my files to a newly (standard)
formatted volume it is no longer newly formatted (and you
seem to be recommending that I don't do so because of this).

> Certainly there have been FAT12 and FAT16 implementations
> that assume one reserved sector (as has been pointed out
> many times, there are vast numbers of buggy
> implementations out there).

It's not a bug if you plan it that way.

> OTOH, a good implementation won't. Still if the diskette
> is actually formatted with exactly one reserved sector it
> doesn't matter. That doesn't matter since you can't
> normally change the number of reserved sectors on a volume,
> but you *can* change the number of entries in the root
> directory.

The pre-allocation of the the root directory sectors is
perfectly compatible with the specification as well as all
implementations (which know nothing and need to know nothing
about it) and does not in any way prevent you from adding
root directory entries.

The purpose of the 1.44MB FAT32 floppy disk image is a as a
direct replacement for the simple system/hobbyist use of the
FAT12 floppy disk image (still in use today) for USB flash
drives and emulators. The reference implementation is here:
http://mikegonta.com/MikeOS-4.5_FAT32
The simple FAT32 driver is exactly the same as the original
FAT12 and the adaptation is even simpler due to the FAT32
entries handling. Also, (something else that you probably
won't "approve" of) there are no 32-bit instructions or even
32-bit variables used in the 16-bit real mode implementation.

[Mike Gonta]

"Robert Wessel" wrote:

> "Mike Gonta" wrote:
>>"Rod Pemberton" wrote:
>>> Robert Wessel wrote:

> Nor does it describe partitions*. So obviously FAT can't
> be used on a disk with partitions. (Yes, that's sarcasm.)
>
> You can't seriously be claiming that a passage on the
> determination of the type of *FAT* prohibits an OS from
> doing a sanity check on the size of the volume?

You can't seriously be claiming that compliance with a
specification is conditional upon compliance with something
not in the specification.

> *OK, so it mentions them twice.

Actually, it's mentioned 6 times.

> Once, in an offhand way, to talk about support for disks
> bigger than 2GB. And once in the context that the hidden
> sector count field might have something to do with
> partitions. BTW, that's also a field commonly subject to
> sanity checks.

Actually, it's implied here:
"
However, if BPB_TotSec16/32 is larger than DskSz, the volume
is seriously damaged or malformed because it extends past
the end of the media or overlaps data that follows it on the
disk. Treating a volume for which the BPB_TotSec16/32 value
is "too large" for the media or partition as valid can lead
to catastrophic data loss.
"
This is the reason that the "extra" sectors are marked "lost".
Ignoring the "free sectors list" when writing files will
result in "catastrophic (seriously, with a floppy disk today)
data loss" under any circumstances.

[Mike Gonta]

"wolfgang kern" wrote:
> Mike and Robert replied:

>>> So my OS wont see your FAT32 image.
>> Transfer the image to a USB flash drive. I'm sure your
>> "new" system will access it just fine.
>
> my OS isn't new at all ;) started 1985 and became
> standalone 1990.

Don't give up so easily, you could still try it.

> My question still is where you see the advantage of wasting almost 20% of
> the disk capacity just to have FAT32.

The advantage is in using FAT32 at such a small "cost".

The purpose of the 1.44MB FAT32 floppy disk image is as a

direct replacement for the simple system/hobbyist use of the
FAT12 floppy disk image (still in use today) for USB flash
drives and emulators. The reference implementation is here:
http://mikegonta.com/MikeOS-4.5_FAT32
The simple FAT32 driver is exactly the same as the original
FAT12 and the adaptation is even simpler due to the FAT32

entries handling. Also, there are no 32-bit instructions or

even 32-bit variables used in the 16-bit real mode
implementation.