4 replies to this topic

[deomsh]

New version of FATINFO.G4B: https://github.com/deomsh/FATINFO.G4B

 

v0.5

Bugfix: total sector test on ram-disk
Bugfix: read-out startsector on partitioned ram-disk (grub4dos only!)
Blocklist: non-contiguous blocklists supported (max about 510 chars!)
Blocklist: same switches as FILE '--start=sectors|--skip=bytes'
Better distinction of volume/ partition in output
New test: read-out number of bad sectors marked as bad in FAT
New test: calculate number of padding sectors

 

Some action print-screens:

 

 

BTW first print-screen is just the normal read-out of FATINFO.G4B!

 

 

As can be seen on last print-screen the partition has 8 unused sectors at-the-end, while there are 16 sectors per cluster. I thought this 'test' (actually it is a calculation, although fit of total number of sectors in volume/ partition is tested before) is a nice addition. I baptized these unused sectors 'padding sectors'. Of course existence of these sectors is no reason to say tests are 'not passed'.

 

I found floppies never have 'padding sectors', corrected with number of sectors in the root -directory (and always an odd number - also on FAT12/16 number of reserved sectors is usually one). I don't know why, is there a (known) reason?

[Wonko the Sane]

Wait until you learn about the twilight zone (unused bytes inside total sectors in the bootsector but outside the volume/filesystem on NTFS):

http://reboot.pro/in...showtopic=18034

http://reboot.pro/in...=18034&p=166592

 

Loooong thread on floppies and their formats and their quirks:

https://msfn.org/boa...d-their-images/

 

Wonko

[deomsh]

Thanks!

 

I was not aware of the backup-option of the NTFS-mbr in the 'padding' sectors. Interesting option. Will the NT5 formatting always give unused sectors at the end of a partition?

 

About the superfloppy thread: I read it again, only one post mentions 'spare sectors', if I am right.

 

This time I downloaded your EBE955AA2.zip from https://msfn.org/boa...&comment=987482

 

I tested all ima's with FATINFO.G4B, with switch '/T' missing magic byte is correctly identified. Print-screen of 000000.ima:

 

 

I also found a bug in my (textual) Little Endian output of the jump-instruction if highest byte is zero, will be corrected in next version.

 

Also interesting: on Virtual Box internal grub4dos function 'ls' has no problems with the missing magic byte, but 'fat dir' needs them.

 

 

BTW I found that your Known_floppies2.xls (1.284.608 bytes) has following errors.

 

1) One Entry has a typo:

 

 12960K (9x1440K)  240    13.271.040 25.920 720 2 18 512  11960K (9x1440K) 240    13.271.040 25.920 720 2 18 512

 

2) FAT16 can not exist on floppies 160K-1920K, am I right?

Maybe too enthusiastic copy/ paste of (nice) formula's?

[Wonko the Sane]

About NTFS I think it depends on the size and alignment.

The backup sector (NOT the MBR, the first sector of the 16 sector $boot file, i..e. the PBR/VBR) is appended at the end of the NTFS volume, so the partition size (in the MBR) needs to be one sector larger.

Since in NTFS there are no hidden sectors or similar, every structure is actually a (hidden) file (with hardcoded names beginning with $) everything occupies clusters, so in a common sized NTFS (on 512 bytes/sector media) volume, with 8 sectors per cluster, the volume (untended as accessible/mapped clusters) needs to be a multiple of 8 and the partition needs to be nx8+1, which rarely matches the usual alignment rules (maybe with the cylinder alignment, never with the Mbyte alignment).

So you need an odd size of the partition (and an even number of sectors in the volume, multiple of 8) that can be divided by 255*63=16065.

Since 16064 is actually a multiple of 8, any partition of size mx16064+1 should leave no twilight zone.

 

I have to re-read what was written at the time, but if I remember correctly the algorithm(s) that determine a few values in floppy formatting avoid your "padding sectors", the info is in the "other" loong thread:

https://msfn.org/boa...oppy-emulation/

starting from here:

https://msfn.org/boa...oppy-emulation/

 

I'll have to recheck that excel file, cannot say from memory, but - besides the typo - I wouldn't be surprised I overdid with copy and paste formuias.

 

Wonko

[Wonko the Sane]

As expected, that spreadsheet is (besides half-@§§ed) somehow "wrong" in the create floppy batch (or I have *something* going on on my system, I tried creating a floppy image and it pre-pended to it some garbage vaguely connected with codepage 1252).

However, with a couple corrections, I did manage to create a seemingly working FAT16 160K floppy image.

Attached (but NOT tested)

Now, whether it is in any way "smart" to "under-size" a FAT16 volume, is another thing.

 

Wonko

 160K_FAT16.zip   934bytes   44 downloads

[deomsh]

I'd like to test, but my Windows Defender (WIN10-x64) does not like the zip. Maybe upload as .txt, or some other trick?



EDIT:
I found a workaround, thanks to a ReactOS VM I was just testing. Really nice: the Application Manager to install predefined programs directly from the internet..

[deomsh]

I looked at your FAT16 160K floppy image in various ways. See the print-screens first:

 

 

Never the floppy was seen as FAT16, all reported FAT12. About 'vol' and grubutil 'fat': I suppose they 'judge' by cluster count. FATINFO.G4B uses partly textual output of 'vol', PBRVIEW.G4B is independent of 'vol' and uses count/ calculation of clusters.

 

As can be seen on third print-screen 'fat copy' is still working, but FAT-handling does not look like FAT16. Seen with FATINFO.G4B --hex (fd0):

 

 

But the copy is absolutely good:

 

 

Is there any reason why your FAT16 did not start with 'FEFF FFFF'?

 

I have never seen your variation before, I changed FATINFO.G4B already to check whole start of FAT (as can be seen in second print-screen), instead of starting with media-byte only (as in v0.5).

 

MS-DOS' Scandisk doesn't like this floppy either, al sort of problems. If I clean the FAT's and change the start of each FAT to 'FEFF FFFF', Scandisk identifies the last 'FF' as a lost cluster, so changing the FAT back to FAT12 effectively.

[Wonko the Sane]

Yep, as said I have not tested the result, and I had some issues with the batch generator, it is entirely possible that the incipit/header of the FAT is just plain wrong.

And as well it is entirely possible that anything below 16 MB or so is assumed by this (or that) tool, either by MS or third party, as FAT12.

 

Wonko

[deomsh]

Hmm...

 

Currently I am working again on my tool MKFATIMG.G4B (unpublished). Almost all your floppy-types from 'Known_floppies2.xls (1.284.608 bytes)' are available as preset.

 

Lowest working type with FAT16 is the 2400k floppy, 'vol' has no problem in this case with FAT16:

 

 

Without preset it is possible to force FAT16 too, lowest value I could use is 2079k. In theory this is probably 2075k, but I can't reach that. Maybe because I use Microsoft's formula for sectors-per-fat?

 

 

I just tested presets with FAT16 in Virtual Box with Scandisk: 2400, 2880, 3120, 3200, 3600 and 3840 (max for VBOX).

 

Scandisk had no problems with FAT16-floppies 2880, 3120, 3200, and 3840, but was 'not happy' the 2400 and the 3600 (both multiples of 1200 of course).

 

Corrections made by Scandisk make no sense to me: on the 2400 my start of first FAT (F9FF FFFF) was replaced by 0000 0080. On the 3600 the start-of-FAT2 was set at another address. So maybe I should investigate my preset values in these cases. Also Scandisk' surface scan showed problems in these two cases (others mentioned are all good).

[Wonko the Sane]

Good.

 

Surely 160 KB was a "too extreme" example.

 

Maybe the limit is not on size but on number of clusters? The values you show are (coincidentally?) very near to 4096 (which is 2^12).

 

About FAT issues you could experiment (only experiment) with a single FAT first, and if you have no issues, add the second FAT?

 

If scandisk has issues with FAT tables, it is likely that *anything else* including surface scan will produce errors.

 

Wonko

 

[deomsh]

Thanks for pointing me in that direction.

 

But in the end I found out the problem was fully Virtual Box (v7) related: on VMWare Player 17 NO issues at all.

Most of the time I test booting from the grub4dos command-line, never any issues and Scandisk is always 'happy'.

 

If I really booted from the 2400K floppie with boot code and MS-DOS 7 System files, I got during boot 'Invalid System Disk'.

 

I found following on the VBOX-logfile in case of the 2400k floppie:

 

00:00:08.994692 DrvVD: Automatically upgraded floppy drive from FLOPPY_1_44 to FLOPPY_2_88 to better support the 2457600 byte image
00:00:08.994753 DrvVD: Flushes will be ignored
00:00:08.994761 DrvVD: Async flushes will be passed to the disk
00:00:08.994946 VD: Opening the disk took 173511 ns
00:00:08.994957 DrvVD: Automatically upgraded floppy drive from FLOPPY_1_44 to FLOPPY_2_88 to better support the 3932160 byte image
00:00:08.995010 FDC: 2.88 MB 3"1/2 floppy disk (2 h 80 t 36 s) rw
00:00:08.995020 FDC: 3.84 MB 3"1/2 floppy disk (2 h 80 t 48 s) ro

 

Probably this can explain the 'weird' behavior of Scandisk too.

 

But also could imply my 1200KB floppie won't boot either in Virtual box. I tested, but this was not true, everything was fine:

 

 

This time the LOG mentioned only:

00:00:08.965312 FDC: 1.2 MB 3"1/2 floppy disk (2 h 80 t 15 s) rw

 

Action print-screen of production of the bootable 1200K floppie with MS-DOS 7 system files and copying Scandisk to the ram-disk first:

 

[Wonko the Sane]

One thing is making a working filesystem, another thing is actually booting from it.

 

It depends on the BIOS (on real or virtual machine), no way to know what is actually supported, very likely (but it is not given) the known geometries for most common real floppies, the same used/usable in El-Torito standard (2/15, 2/18, 2/36)[1], might be recognized, other ones is unknown, and each BIOS may have its own quirks.

A (super-) floppy image made into a (fake) virtual "hd-like" volume/partition may have some better chances as via grub4dos one can try/set geometry, but even then it has to be seen on a case by case test.

 

 

[1] and this may additionally only work for emulated floppies on CD and not for direct floppy images.

 

Wonko

[deomsh]

About the Floppy-geometry: in Virtual Box only multiples of 2/8 and 2/15 (ment ABOVE the standard floppies) seems to be rejected.

 

Today I tested all my FAT12 presets in the range from 160KB-1920KB: 160, 180, 320, 360, 400, 600, 640, 720, 800, 820, 1200, 1440, 1600, 1680, 1760, 1840 and 1920. In Virtual Box only 600k and 640k gave problems with Scandisk, all others were 'good'. In VMware 17 Player ALL where 'good'.

 

But now comes the interesting part: after my tests, I played a bit in VMware with the higher preset-floppies above 4MB. Highest one that worked was the 4320KB with 'SCANDISK.EXE /surface', already with size 5760KB the connection to the floppie even was 'removed' while checking surface ('removed' according to Scandisk):

 

 

BTW Afterwards 'DIR' still worked... Also: up to a size of 10800KB all Scandisk' tests except 'surface' were 'good', from 11520KB on the floppie was reported as 'removed' during normal testing already.

 

I took a look in the LOG:

2024-05-03T14:28:37.686Z No(00) vmx ConfigDB: Setting floppy1.fileName = "D:\FLOP36MB.IMG"
2024-05-03T14:28:37.729Z No(00) vmx ConfigDB: Setting ide1:0.fileName = "auto detect"
2024-05-03T14:28:37.729Z No(00) vmx ConfigDB: Setting floppy0.clientDevice = "FALSE"
2024-05-03T14:28:37.729Z No(00) vmx ConfigDB: Setting floppy1.clientDevice = "FALSE"
2024-05-03T14:28:37.803Z In(05) vmx FLOPPYLIB-IMAGE: Invalid number of cylinders (1024 while only 255 allowed)
2024-05-03T14:28:37.803Z In(05) vmx FLOPPYLIB-IMAGE: Could not detect floppy geometry from image file.
2024-05-03T14:28:37.803Z In(05) vmx FLOPPYLIB-IMAGE: Default 80/2/18 geometry used.

 

I did a quick search, only two sources mentioned the 255 cylinder 'barrier' (MS-DOS/floppie controller related):

https://www.syslinux...old/memdisk.php

https://wiki.osdev.o...Disk_Controller

 

My tool MKFATIMG.G4B takes CHS too, so I quickly made a FAT12 floppie with CHS 255/2/45, including MS-DOS boot code and system. I booted the floppie in VMWare, and this time Scandisk was fully 'happy' (including testing surface).

 

In case of El Torito floppies maximum CHS in VMWare with two heads would be respectively 255/2/15 (3825KB)), 255/2/18 (4590kBKB) and 255/2/36 (9180KB). Not as big as the floppies discussed in the thread you mentioned earlier: https://msfn.org/boa...oppy-emulation/, but still nice sizes. I will test these sizes with ISOHDR later.

 

The maximum with two heads will be 255/2/63. I made this floppy image as FAT12. After booting in VMWare, Scandisk found NO errors. Action print-screen of the floppie-specs and 'Scandisk surface':

 

 

BTW Sadly Virtual Box uses the 4MB-barrier in case of floppies, so no tests possible.

 

EDIT:

 

I remember I reported earlier El Torito-booting was just fine in VMware, which seems to conflict with the 255 cylinder floppie 'barrier'.

 

So I made a new 34560KB floppie image, pasted this in an old ready-made ISOHDR, and booted the iso in VMware 17 Player to the MS-DOS command-line.

Everything was still fine, Scandisk was 'happy' with all tests.

 

So the El Torito boot-floppies seems to be handled different in VMware, than 'normal' floppies described above.

[Wonko the Sane]

Yep, very likely the floppy is treated (by BIOS) as a floppy , whilst the El-Torito emulated one is treated (by BIOS) as *something else* (an emulated volume?), so it is expected that BIOS support for the one or the other may have different limitations, to which you add MS-DOS own limitations (that may - or may not - be present in - say - FreeDOS, that from what I remember has its own little quirks, including the "mysterious" Bios Drive autodetect value of 255).

That could be another (possible) point of failure, one BIOS may access and "respect" the "BIOS drive" value (with its own interpretation of what it means) while another may have a different interpretation and another one ignore it altogether.

 

Wonko

[deomsh]

This unpredictable bios behavior drives me mad.

I played a bit with your idea of mapping hd-image partitions to a floppy. Up to 16MB Virtual Box 7 takes raw fat12 images with extension '.hdd'. After booting with GRLDR direct mapping worked with 16MB, and if booting the MS-DOS floppie with io.sys Scandisk found no errors. I also tried 1GB, this time 'map --mem' was needed to trick MS-DOS.

I returned to my El Torito experiments with ISOHDR. This time I tested ALL preset-floppies with 15, 18 and 36 Sectors Per Track, available in my tool MKFATIMG.G4B. But sadly same results as earlier experiments. In Virtual Box 7 Scandisk was only happy with the 1200k, the 1440k and the 2880k. In VMware 17 Player anything goes (not all tested):

TESTS of EL TORITO floppies with ISOHDR and MS-DOS 7:

15 SPT	VBOX7  SCANDISK SURFACE VMW17 SCANDISK  SURFACE
  600	ERROR			ERROR
 1200	BOOT   GOOD	GOOD	BOOT  GOOD	GOOD
 2400	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD
 3600	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD
 4800	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD
 8400	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD
 9600	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD
10800	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD
12000	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD
13200	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD
  15M	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD

18 SPT	VBOX7  SCANDISK SURFACE VMW17 SCANDISK  SURFACE
 1440	BOOT   GOOD	GOOD
 4320	BOOT   GOOD	ERROR
 5760	BOOT   GOOD	ERROR
 7200	BOOT   GOOD	ERROR
 8640	BOOT   GOOD	ERROR
10080	BOOT   GOOD	ERROR
12960	BOOT   GOOD	ERROR
14400	BOOT   GOOD	ERROR
15840	BOOT   GOOD	ERROR
17280	BOOT   GOOD	ERROR
  18M	BOOT   GOOD	ERROR

36 SPT	VBOX7  SCANDISK SURFACE VMW17 SCANDISK  SURFACE
 2880	BOOT   GOOD	GOOD
 8100	BOOT   GOOD	ERROR
11520	BOOT   GOOD	ERROR
20160	BOOT   GOOD	ERROR
23040	BOOT   GOOD	ERROR
25920	BOOT   GOOD	ERROR
28800	BOOT   GOOD	ERROR
31680	BOOT   GOOD	ERROR
34560	BOOT   GOOD	ERROR
  36M	BOOT   GOOD	ERROR	BOOT  GOOD	GOOD

FROM VBOX 7 LOG:
[...]
00:14:27.300630 VMMDev: Guest Log: BIOS: int13_cdrom: unsupported AH=02
00:14:27.301928 VMMDev: Guest Log: BIOS: int13_cdrom: function 42, status 04 !
00:14:27.302795 VMMDev: Guest Log: BIOS: int13_cdrom: unsupported AH=08
[...]

TESTS of EL TORITO floppies with ISOHDR and GRLDR:
15 SPT	VBOX7  SCANDISK SURFACE VMW17 SCANDISK  SURFACE
  600	BOOT   GOOD	GOOD    ERROR

I tried booting from a small El Torito floppy with GRLDR and afterwards mapping the second 36m-floppie (pasted after the small boot floppie in the iso). Although booting to MS-DOS is not good because of read-errors, this was not the case while staying on the grub4dos command-line. I could open the floppie with my ImDisk-cmd while the iso was attached to a running VM, and copy or delete files.  Of course this won't work with 'map --mem'. Changes can be 'seen' from the grub4dos command-line too. Also copying the whole content of the mapped floppy to a floppie on a ram-disk seems to work well:

 

 

[deomsh]

I continued testing booting from a regular sized El Torito floppie and mapping the big floppy behind. I made all three types with 15 SPT, 18SPT and 36 SPT.

This time I got some read-errors if I fully filled up the big floppy, using ImDisk. In the last 32 KB or so, of my mapped 15MB floppy (booted with GRLDR on the 1200k boot floppy). If I gave the iso ONE extra CD-sector (so +2k or +0x800 bytes), the problem was gone, no read-errors anymore. Also no read-errors if I gave an extra sector to the combinations 18 SPT, 1440k boot floppy with 18MB 'map'-floppy, and 36 SPT, 2880k boot floppy with 36MB 'map'-floppy.

Is there any explanation why grub4dos needs ONE extra CD-sector?

If anyone wants to test, attached is a '7z' with all three ISOHDR-iso's. Only boot floppies have GRUB boot code and are loaded with GRLDR and a MENU.LST. The 15/18/36MB floppies have no boot code and are fully empty. Further SIX cmd's are included to use with ImDisk.

The '120015M1.ISO_Mount_15m2A.cmd' to attach a floppy looks like this:

C:\Windows\System32\imdisk -a -f D:\120015M1.ISO -b 1294336 -s 15728640 -o fd -m A:

BTW I use 'D:\' , also 'imdisk.exe' must be in the specified path.

Can be changed easily to another location like:

C:\Windows\System32\imdisk -a -f "d:\VirtualBox VMs\Small MS-DOS 7.1\120015M1.ISO" -b 1294336 -s 15728640 -o fd -m A:

BTW don't forget the double quotes if spaces are involved. Also 'fd -m A:' can also be changed to say 'hd -m F:'

While preparing the iso' I found out WHY mapping the 1GB partition from a hd-image was not good.
I booted with help of 'chainloader /io.sys' (boot code was GRUB's) into an 'blind' MS-DOS command-line.
Preparing the 1GB-vhd has been a 'quicky' using my binary boot code files. It turns out the OEM-name 'GRLDR   ' was the culprit, while in my script MKFATIMG.G4B - I found out again - I was using 'IBM  2.0'. After changing, everything was fine, I can run a full surface scan with Scandisk:



So 'map --mem', mentioned in previous post, was not needed in this case!

 ISOHDR123_GRLDR_MAP_BIG_FLOPPIES.7z   332.25KB   15 downloads

WARNING: booting GRLDR is not working in VMware 17 Player. I don't knwo why.

[deomsh]

I worked a bit more one El Torito booting in VMware 17 Player, and it seems nothing is working except using the 'bcdl', a floppy image belonging to 'BCD201a', as suggested by Wonko the Sane earlier. See: http://reboot.pro/in...774#entry222440

 

Archive 'bcdw201a.rar' can be found on https://web.archive....mp/bcdw201a.rar - click September, 15. To attach 'bcdl.ima' to a VMware floppy station, rename to 'bcdl.img' first. On the VMware-System's I have tested, only CD-ROM in IDE-mode is booting with this method.

 

Another thing is that VMware uses (0x9f) for the boot-cd, so I made some changes to MENU.LST. For instance in case of the 288036M3.ISO:

[...]
title commandline + set-path=(bd) + set-ext=.g4b + map (cd)1472+18432 (fd0)
map --floppies=2
map (fd0) (fd2)
raw cat --hex --length=1 (0xe0)1472+1 > nul && map (0xe0)1472+18432 (fd0) && set mapped=Y
if not %mapped%==Y && raw cat --hex --length=1 (0x9f)1472+1 > nul && map (0x9f)1472+18432 (fd0)
map --hook
command --set-path=(bd)
command --set-ext=.g4b
commandline
[...]

With help of the ImDisk-cmd's for the boot-floppy, changes can be made easily.

[Wonko the Sane]

Preparing the 1GB-vhd has been a 'quicky' using my binary boot code files. It turns out the OEM-name 'GRLDR   ' was the culprit, while in my script MKFATIMG.G4B - I found out again - I was using 'IBM  2.0'. After changing, everything was fine, I can run a full surface scan with Scandisk:

Yep, JdeBP's take on the matter:

 

http://jdebp.info/FGA/

http://jdebp.info/FG...name-field.html

 

 

It is an implementation disaster because not only are the various checks different for MS-DOS, PC-DOS, OS/2, and Linux, they are different for individual different versions of those operating systems. In fact, there is only one value for the OEM name field that all versions of all operating systems will agree to mean that the creator of the BPB is to be trusted: "IBM  2.0".

 

Wonko

[deomsh]

Thanks!

 

I came earlier across the boot sector "IBM  2.0" OEM. I believe in one of your posts in the msfn thread on-bootable-cds-floppy-emulation.

 

In my tool MKFATIMG.G4B I found in a PBR boot code sub-routine the note '#BADwithGRLDRNoFilesShownUnderMS-DOS7.1#', but somehow in my mind I thought I reserved the "IBM  2.0" OEM for images without boot code only, which is not according to the choices I made in the past.

 

But repeating 'bad practices', experiencing the consequences and finding again a 'way out' is at least 'good' for memory.

[deomsh]

Version 0.6: https://github.com/deomsh/FATINFO.G4B

 

NEW: switch '/B' to get silent result 'sectors marked bad' in FAT
NEW: CD-ROM starts at 0x9f, as (hd31) still accepted as harddrive
IMPROVED: use of '--start=sectors|--skip=bytes' with blocklist (non-contiguous blocklists too)
Bugfix: bad dividing to sectors with '--skip=bytes' in case of CD
Bugfix: echo 'partition starts [not] at begin of a head' if hidden sectors=0
Bugfix: bad read-out of padding sectors in certain cases
Bugfix: bad echo 'Filesystem (...) at sector xxx': correction for CD
Bugfix: bad echo of 'jump' value if low byte was zero