No replies to this topic

[deomsh]

FATINFO.G4B: grub4dos script to get FAT-related information from devices or from image-files. Some basic tests and some silent operations too. More information: https://github.com/deomsh/FATINFO.G4B

Now and then I am working on a script to make FAT-images. To more quickly check the results I needed a grub4dos command-line tool and giving more information than grubutil fat with function info. Also fat info is only working with devices, not with image files (so endless mapping ...).

FATINFO.G4B can do both, only DEVICE or FILE are needed - one optional switch. In case of HDD-images offset is needed too.
There are some non-standard read-outs like Last allocated sector (NextFree) FSinfo in case of FAT32, and found last allocated cluster in case of FAT12/16.
With switch /T some basic tests are performed. Because of the nature of some boot sector values, not all tests have to be noted to be 'PASSED'. With a few other switches there is silent operation with export of a result variable or otherwise.

Some action print-screens, first three starting with read-out of fat info. Watch 'test' for FAT16 and FAT32 shutdown flag in the last two print-screens:



BTW in case of floppies the Media descriptor will be only reported as 'valid' if 'all' standard values are found.
BTW2 be aware fat info does not count the 'real' number of free clusters, but will report the FSinfo value (in case of FAT12/FAT16 counting is always needed). With switch /T FATINFO.G4B will do the count for FAT32, took about 3 seconds on my system in case of a 40GB partition.

BTW3 FSinfo values are ment as a 'hint' for the FAT-driver, according to Microsoft's specs.

Two print-screens of file-images. In second print-screen Jaclaz' tool MBRVIEW.G4B is used to find the offset to partition:



BTW MBRVIEW.G4B can be found on: http://reboot.pro/in...&hl=mbrview.g4b
 

FATINFO.G4B seems to be working on grub4efi too:

 

 

I did some experiments on 36.90 MB vhd's, all partitioned as FAT32 with MS-DOS 7.1 FDISK /fprmt. Then I checked formatting of MS-DOS 7.1 (hd1), Windows 10 (hd2), Paragon Partition Manager 17 (hd3), EaseUS Partition Manager 13.5 (hd4) and Active@Partition Manager (hd5) and again Windows 10 format from command-line (hd6).

FDISK used rather uncommon CHS-values, during formatting all, except MS-DOS 7.1 and Active@Partition Manager wrote other CHS-values. So balancing of the partition can not be judged anymore. Most changed the file system type too:



Only MS-DOS 7.1 wrote the original H/S -values to the boot sector, and got a positive result for ALL performed tests:



Windows 10 ignored the file system type and formatted to FAT16, further 'good':



Most interesting was Paragon Partition Manager 17, who changed type to FAT16, but still (forced!) created a fAT32 file system. Notable too: 7138 reserved sectors before start of FAT:



EaseUS Partition Manager 13.5 gave rather normal results, but according to my test the backup of the boot sectors was not valid. As can be seen on the print-screen the number of hidden sectors was missing in the backup of sector 0:



Only Active@Partition Manager did not change the MBR, but set Sectors per track and Number of heads to usual 'modern' values, if NOT balanced the test will report in this case 'Unknown ....':



Windows 10 again, formatted from command-line to force FAT32: only type changed to 0x0C and it seems Windows 10 wants temporary reserve one cluster, by setting FSinfo value one higher ???



BTW same high number of 7138 reserved sectors before start of FAT as Paragon ???

[Wonko the Sane]

I am not sure about the exact conditions of the tests for partitioning (and later formatting).

 

Some (most) programs won't let you have a partition not ending on a Cylinder or head boundary, i.e. in the case of a CHS geometry, of n/255/63[1] the end sector is "forced" to x/254/63 in the CHS address.

 

This convention was common in the DOS era, up until at least Windows XP, then Vista started partitioning with alignment to the MB (actually MiB) abandoning the alignment to cylinder.

 

This is essentially the reason why most programs allow selection of sizes have a minimum "step" of 255*63*512=8,225,280 bytes, often displayed as 8 Mb.

 

As well most programs will also "force" the start sector to be the first one of a head (i.e. S=1), for the second partition this is due obviously to the previous one ending on 254/63, but for the first one normally a whole head is reserved,  i.e. first partition starts on LBA 63 or CHS 0/1/1.

 

So, you probably have *somehow* forced the programs to use a partition size that is not a multiple of 8,225,280 bytes, and some programs moved the start position to respect the end CHS boundary, whilst some other ones respected the start on S=1 thus having it end on a non-boundary address.

 

Starting a "first" partition on sector LBA 17 (CHS 0/0/18) is non-standard and can possibly cause inconsistencies in a number of (possibly completely unrelated to partitioning/formatting) programs and even in the way the booted OS behaves.

 

For experiments everything goes, but in normal operation, and particularly with DOS and Windows up to XP, partitions should start on S=1 and end on H/S 254/63 i.e. be a multiple of a whole cylinder.

 

Wonko

 

 

[1] since heads are numbered starting from 0 the last head on a 255 geometry is head 254

[deomsh]

The goal of the test was to compare read-out and basic tests of FATINFO.G4B with formatting from various providers. I decided FAT32 to be the most desirable option, because of number of read-outs, basic tests and overall complexity of FAT32. Test vhd's must be small because I have not much room left on my SSD.

 

I made a bunch of 36.90 MB vhd's with Virtual Box 7 and partitioned them all from MS-DOS 7.1 with FDISK /fprmt and forced FAT32. Partitions are all fully aligned (calculated and also checked with PowerQuest's tool PARTINFO).

 

The various format-providers did NOT change the LBA-values written by FDISK, further as described above. But if CHS-values are changed, I do not know how to 'judge' alignment from boot sector values only.

 

I don't know if any problems will arise in these cases, probably with 'old' drivers only. MS-DOS 7.1 found al volumes EXCEPT the special FAT16/FAT32 species produced by Paragon Partition Manager 17 (just tested).

 

About the 17 sectors per track: today I found *somewhere* this was the standard value of all disk types 0-46 (or at least with original ST-506/412 MFM controllers, this according to Scott Mueller's Upgrading and Repairing PC's 16TH edition, page 652).

 

If this is true, MS-DOS 7.1 FDISK did an excellent job in case of my small test-vhd.

 

Are you sure about 'in normal operation, and particularly with DOS and Windows up to XP, partitions should start on S=1 and end on H/S 254/63 i.e. be a multiple of a whole cylinder.' ? No lower number of Heads in case partitions are below a few GB's?

 

I just tested on another 36.90 MB vhd grub4dos partnew (hd5,0) 0x0B 17 75548 - exactly same CHS values as FDISK earlier.

 

To not have to force FAT32 I made two vhd's above 512 MB.

I attached vhd (hd6) in Windows 10 and partitioned first with DISKPART from cmd, than formatted as FAT32. Last vhd (hd7) was auto-partitioned to FAT32 by FDISK and formatted with MS-DOS 7.1.

 

As expected DISKPART used Type 0C with CHS-placeholders, and with 128 hidden sectors (64KB). FDISK used Type 0B with 63 Sectors per Track (CHS/ LBA aligned), but with 32 Heads.

 

All three in one print-screen:

 

 

BTW original disk (hd1) added for sake of comparison, other disk numbers are partly changed, because maximum number of 8 drives seen by FDISK.

 

 

[Wonko the Sane]

The old convention was:

1) partition must start on a head boundary

2) partition must end on a cylinder boundary

 

What CHS geometry a device uses depends on the device (for physical devices, a "virtual" one is, in itself, "undetermined") but also on the BIOS[1] and on the OS that is booted.

 

For anything bigger than 8.5 GB only LBA is possible, but for smaller sizes various geometries were adopted over the years, the limit is on 1024-255-63.

 

Sure if you make a partition with command partnew (hd5,0) 0x0B 17 75548 you will have a partition starting on LBA sector 17 and extending over 75548 sectors, whatever Scott Mueller wrote, these values are simply "wrong" (this doesn't mean that such a geometry never existed, it only means that you are looking for troubles).

 

On hard disks sectors have always been any of (which again doesn't mean that some "queer" device or BIOS/OS with different geometry existed):

16/32/63

Heads any of:

16/32/64/128/240/255

 

Of course smaller devices had a lower number of sectors and/or heads.

 

With 75548 sectors (which already is a queer number and should be rounded up depending on chosen geometry) "plausible" (and hypothetical) HS geometries (of a "real" tiny hard disk as would have been implemented at the time by the manufacturer) may be:

16/63 16*63*75=75600

16/32 16*32*148=75776

16/16 16*16*296=75776

 

But what actually counts is how the BIOS will see/detect them and what result the Int13h will provide (and then - at least for NT based systems - this geometry may be overridden).

 

Wonko

 

 

 

You can see a (good) list of geometries in the BIOS used in qemu (seabios)

https://github.com/c...ter/src/block.c

 

jaclaz

 

 

[1] a reknown example were whole series of IBM and HP laptops that "forced" the heads to 240 even when the device was 255. 

[deomsh]

Thanks a lot for the information.

 

In my (unfinished) project MKFATIMG.G4B I currently use 128/64/32/16 heads, for image sizes according to Microsoft guidelines (because I use fat mkfile to make these images, I cannot go from 4GB upwards).

 

But so far I found I had to use always 63 sectors per track, so I will study the possibilities of 32/16 sectors per track you mentioned. For my goals it is most important I can map my images with grub4dos.

 

About the C/H/S of 889/5/17 (0/1/1-888/4/7): I found those are the 'virtual' physical characteristics of the VHD made by Virtual Box 7, the 17 sectors per track are one choice mentioned in Microsoft's Virtual Hard Disk Image Format Specification - October 11, 2006 - Version 1.0 (cylinders are rounded down according to the spec).

 

Can be found in the Hard Disk Footer of the VHD:

 

 

BTW of course this does not imply the logical CHS must be the same as the physical specs in this case.

 

I also checked my VHD's with TESTDISK.

 

The x64-version seems not to read the actual CHS values in the MBR, but gives always H/S values 255/63. Or CHS/LBA was wrong, or 'Bad sector count'.

The Dos/Win9x-version however readed the actual CHS values in the MBR, and did NOT comment on the CHS of the partitions created by FDISK/ PARTNEW. On the other VHD's only 'Bad sector count'.

[Wonko the Sane]

That is a (further) complication.

There is nothing in a non-physical device (a RAW image) telling anything about geometry.

A NT based OS will ignore the actual int13h geometry and default to *something*, in NT times that default would have been 64/32 then 128/63 (if I recall correctly) in 2K and XP would go for 255/63 (again if I recall correctly), see also this:

 

http://reboot.pro/in...ic=3191&p=23089

In the times of VDK it was recommended (by me) to use .pln descriptors (a form of descriptor files for VmWare images) to "force" the NT/2K/XP drivers to a given geometry (avoiding the default):
https://www.forensic...-image/paged/5/

For Virtual machines, such as Virtualbox, a .vmdk descriptor is instead advised:
https://www.forensic...ith-virtualbox/

DOS/Win9x are essentially based on BIOS int13h values, but not all BIOS behave the same.

All of this is about NON partitioned/formatted images, i.e. blank RAW images.

Once there is a partition the OS mounting mechanism or the partitioning tool may "decide" that the info in the CHS values of the existing partition are indicators of the geometry.

I have no idea how the good MS guys devised the algorithm at the end of the paper that you reference that should be this one:

https://download.mic...ec_10_18_06.doc

but in 2006 CHS had lost most if not all its relevance, so I suspect they just "invented" something that worked for whatever their aim was, regardless of any adherence to existing (old) hardware.

The possibility of having an image with 255 sectors per track that comes from that algorithm is a sign that it is *something different* from "orthodox" CHS, as sectors per track in CHS cannot exceed 63 (it is a 6 bit value), check:

https://thestarman.p.../PartTables.htm

Yet another MS official specification that makes no sense.


Wonko

[deomsh]

Thanks a lot for the links.

 

Nice script to make images, with examples of H/S values I can use. But currently I am not sure I should stay inside conventional specs regarding total number of sectors for FAT12/16 hard disk images.

 

About the vmdk descriptor script: seems very good too. So far I made quick 1MB vmdk's to get the structure and changed number of sectors (and H/S if needed) and renamed my images accordingly. Good to know the identifier uses random values.

 

In case of Microsoft's VHD-specification: I used indeed same document.

I am afraid there is some misunderstanding, hopefully productive. What I said about the 17 sectors per track: I ment the physical CHS. Also ATA allows 255 sectors per track, so I do not understand why the VHD-spec makes no sense? Please correct me if I am wrong.

 

BTW I tried to found a tool to report these CHS-values, but in the end I had to use HxD Hex Editor. If partition managers report 'physical' values, these are already translated (exception can/ will be drives up to 504 M(i)B - which could explain FDISDK's 'choice').

[Wonko the Sane]

Well, you can use Tiny Hexer and (shameless plug) my structure viewers:

 

http://reboot.pro/in...?showtopic=8734

 

The CHS addressing system uses 6 bit for the sectors per track or sector per track value in a partition table entry.

 

The ATA may well allow 255 of them, but they will only be addressable via LBA, not via CHS (and BTW geometry, when using LBA, loses most if not all relevance), if you prefer, ATA is a "communication" protocol, CHS is an "sector addressing convention".

 

Besides, for all the specifications in the world, you can use for geometry any value 0-254 for heads and any value 1-63 (0 is not used) for sectors, in theory.

 

In practice, if you use any of the non-common/most used/de facto standard ones, you are likely to find issues, surely with partitioning and formatting tools, but - additionally - also with BIOS and bootloaders/mbr code/bootsectors and I would not completely rule out possible issues with other programs.

 

In 2006 (the time that stupid MS documentation was made) CHS was not used anymore (exception made for MS' own bootsectors [0]) so having a never-seen-in-the-real-world device geometry, BTW used only in extremely small images that noone likely used did not create any real issue, this doesn't mean that it is "smart".

 

Wonko

 

[0] See:

 

http://reboot.pro/to...32-boot-sector/

http://reboot.pro/in...ic=8528&p=72651

http://reboot.pro/in...ic=8528&p=73205

[deomsh]

Tiny Hexer looks nice, and your structure viewers too. But I didn't found a viewer for the VHD-footer.

 

About the CHS-values in the MS-documentation: I found the initial 'target' was Windows Server 2003 (https://www.microsof...s.aspx?id=23850), and that this platform should be backwards compatible with ATA/ATAPI-5 (https://www.google.c...iQ&opi=89978449)

 

This standard states (according to a working draft 6.2):

- All devices shall support LBA translation.
- If the device’s capacity is greater than or equal to one sector and less than or equal to
16,514,064 sectors, then the device shall support CHS translation.
- If the device’s capacity is greater than 16,514,064 sectors, the device may support CHS
translation.

https://docplayer.ne...ta-atapi-5.html

 

And ATA/ATAPI-6 (according to a working draft 6.2):

In standards ATA/ATAPI-5 and earlier, a CHS translation was defined. This translation is obsolete but may be
implemented as defined in ATA/ATAPI-5.

https://web.archive.org/web/20110915154404/http://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf

 

To (more or less) check if there is a read-out of those CHS-values in practice, I studied the logs of my tests in Virtual Box 7 (with PIIX3 controller). The log reported same PCHS values as in the VHD's (which still not prove they are actually read-out):

00:00:08.204233 VirtualBox VM 7.0.6 r155176 win.amd64 (Jan 11 2023 16:38:38) release log
(...)
00:00:10.570997 AHCI: LUN#0: disk, PCHS=889/5/17, total number of sectors 75575 [BTW 0x0379/0x05/x11]
(...)
00:00:10.574737 AHCI: LUN#2: disk, PCHS=889/5/17, total number of sectors 75575 [BTW 0x0379/0x05/x11]
(...)
00:00:10.578484 AHCI: LUN#3: disk, PCHS=1167/16/63, total number of sectors 1176859 [BTW 0x048F/0x10/0x3F]
(...)
00:00:10.582456 AHCI: LUN#4: disk, PCHS=1069/16/63, total number of sectors 1078137 [BTW 0x042D/0x10/0x3F]
(...)
00:00:10.583456 FDC: 2.88 MB 3"1/2 floppy disk (2 h 80 t 36 s) rw
00:00:10.583472 FDC: 360 kB 3"1/2 floppy disk (2 h 40 t 9 s) rw
(...)
00:00:10.588989 PIIX3 ATA: LUN#0: disk, PCHS=10/16/63, total number of sectors 10080  [BTW VMDK 10080 sectors, geometry 0x10/0x16/x63]
(...)
00:00:10.589267 PIIX3 ATA: LUN#1: disk, PCHS=889/5/17, total number of sectors 75575 [BTW 0x0379/0x05/x11]
(...)
00:00:10.589542 PIIX3 ATA: LUN#2: disk, PCHS=889/5/17, total number of sectors 75575 [BTW 0x0379/0x05/x11]
(...)
00:00:10.592898 PIIX3 ATA: LUN#3: disk, PCHS=16383/16/63, total number of sectors 1953525168 [BTW dynamic VHD 0xFFFF/0x10/0xFF]
(...)
00:00:10.655091 PcBios: ATA LUN#0 LCHS=10/16/63
00:00:10.655401 PcBios: ATA LUN#1 LCHS=889/5/17
00:00:10.655593 PcBios: ATA LUN#2 LCHS=4/255/63
00:00:10.655621 PcBios: ATA LUN#3 LCHS=1024/30/23
00:00:10.655887 PcBios: SATA LUN#0 LCHS=4/255/63
00:00:10.656052 PcBios: SATA LUN#1 LCHS=889/5/17
00:00:10.656219 PcBios: SATA LUN#2 LCHS=73/255/63
00:00:10.656382 PcBios: SATA LUN#3 LCHS=534/32/63
(...)
00:00:10.690996 VMMDev: Guest Log: BIOS: ata0-0: PCHS=10/16/63 LCHS=10/16/63
00:00:10.692031 VMMDev: Guest Log: BIOS: ata0-1: PCHS=889/5/17 LCHS=889/5/17
(...)
00:00:10.693799 VMMDev: Guest Log: BIOS: ata1-0: PCHS=889/5/17 LCHS=4/255/63
00:00:10.695503 VMMDev: Guest Log: BIOS: ata1-1: PCHS=16383/16/63 LCHS=1024/30/23
(...)
00:00:10.698891 VMMDev: Guest Log: BIOS: AHCI 0-P#0: PCHS=889/5/17 LCHS=4/255/63 0x0000000000012737 sectors
(...)
00:00:10.836406 VMMDev: Guest Log: BIOS: AHCI 1-P#2: PCHS=889/5/17 LCHS=889/5/17 0x0000000000012737 sectors
(...)
00:00:10.837583 VMMDev: Guest Log: BIOS: AHCI 2-P#3: PCHS=1167/16/63 LCHS=73/255/63 0x000000000011f51b sectors
(...)
00:00:10.838749 VMMDev: Guest Log: BIOS: AHCI 3-P#4: PCHS=1069/16/63 LCHS=534/32/63 0x0000000000107379 sectors
(...)
00:00:13.511503 VMMDev: Guest Log: BIOS: int13_harddisk: function 02, disk 83, parameters out of range 03ff/0053/0016!

BTW: I used DISK2VHD (v2.02) to copy my Windows 10 system partition to a VHD, sadly dynamic. Seen the CHS-values in the VHD-footer of 0xFFFF/0x10/0xFF while the (full) size is 549MB, OR Mark Russinovich doesn't want to support ATA/ATAPI-5 any longer, OR I misunderstood things (I do not claim any authority in this field).

 

I also did some more tests with FDISK (MS-DOS 7.1) on my VHD's. I will not repeat every result, but all in all FDISK wrote same values as the PCHS values to the MBR, IF the CHS/LBA values of the whole VHD the whole disk was partitioned, with sectors per track of 17, 31 or 63 (no higher values in the used VHD's). However if not all space was used, FDISK used 'classic' values, even H/S of 254(=255)/63 on a 15 MB FAT12 partition and on a 23 MB FAT16 partition too (both on different 37 MB-VHD's).

 

About the use of small images that 'noone likely used': at least one user in the world needs them desperately. I am working on different virtual platforms, all with not-so-much-space-left. Because my scripts + MS-DOS 7.1 + grub4dos doesn't fit on two 2880KB floppies anymore, I started with FAT32 images with the minimum size. I am currently scripting on Virtual Box and on two different Android devices with LimboX86, so sending small images with WhatsApp is rather convenient.

[Wonko the Sane]

Tiny Hexer looks nice, and your structure viewers too. But I didn't found a viewer for the VHD-footer.

 

You are the first one that ever noticed that .

 

But for a scripting guy like you are, it shouldn't be too difficult to change/adapt any of the existing viewers, last time I made a "new" one, I had completely forgot the little I learned at the time about Tiny Hexer script language, but managed to make a (half-@§§ed as always) new one in a short time just by copying and pasting from the previous ones, see here and a few following posts:

http://reboot.pro/in...=21977&p=210742

 

 

 

About the use of small images that 'noone likely used': at least one user in the world needs them desperately. I am working on different virtual platforms, all with not-so-much-space-left. Because my scripts + MS-DOS 7.1 + grub4dos doesn't fit on two 2880KB floppies anymore, I started with FAT32 images with the minimum size. I am currently scripting on Virtual Box and on two different Android devices with LimboX86, so sending small images with WhatsApp is rather convenient.

 

Well, there are non-standard (but actually standard ) bigger floppy-like sized examples.

Namely (and it is an occasion to show how specifications may be misread, seemingly noone properly read the good ol' ISO 9660 before 2010/2011):

 

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

 

but besides them 5760 kB floppy images have been used rather often in the past (with a geometry of C=80 H=4 S=36 )

 

Here you can find many examples of larger than 2.88 MB floppy-like images:

 

http://bootcd.narod.ru/images_e.htm

 

no reason why you cannot use the 11520 one there or "invent your own", possibly following the basic HS geometries here (the above ones use H=4, but even with H=2 you can go up to 36 MB):

 

https://msfn.org/boa...&comment=970811

 

Though - personally - I have more sympathy for using hard disk like images, I would anyway only use "known" HS geometries.

 

Wonko

[deomsh]

Thanks for all the information. I will take a closer look at the Tiny Hexer script language as soon I have more spare time (if ever) .

 

I was reading your post on my smartphone first, I immediately tested the Russian 5760 and 11520 floppies on Limbo x86 (so qemu-based).

Changing floppies didn't go well, FATINFO.G4B's basic tests where not passed: FAT12 couldn't be read-out to count empty clusters and Number of sectors didn't fit.

 

 

But AFTER a full reboot with the newly attached 11520-floppy everything was fine.

 

 

BTW: Limbo x86's bios is rather picky, it doesn't even allow me to boot from grub4dos WITHOUT a full reboot of the system*.

 

 

Virtual Box is a different 'beast': all floppy-images I tested up to 2.88M where taken, but above: NO-GO.

 

 

So I am afraid I will have to 'stick' to hard disk images for now. Sad, because floppy images can be attached with ImDisk and are writable from the Host during a Virtual Box session, as Jaclaz once teached me on msfn.org . On my desktop both my floppy images are always auto-attached after booting Windows 10. With Total Commander I can, without losing time, copy my latest script versions to the B-floppy, or test newest/ older grub4dos version from the A-floppy (which I boot my main VBox system from).

 

The only annoying properties of Imdisk: auto-opening Explorer (while attaching within Total Commander with context-menu), and that ImDisk is not aware if there is already an floppy image attached to A (while B is empty of course). In case of hard disk images this is NOT the case, first free drive letter is always right. But I doubt there are many users with such experiences .

 

* On my Android smartphone I use Limbo v4.1.0-x86: rather unstable if using the grub4dos command-line, but WITH shared folder. On my Android Tablet I use v6.0.0-x86 (QEMU 5.1.0): (almost) fully stable, but WITHOUT shared folder.

[Wonko the Sane]

Re: VirtualBox

 

It could well be an artificial limitation of the VirtualBox BIOS related to image size or the (non-standard) 4 heads/sides of those images.

 

You should try the oversized floppy geometries mentioned for CD-floppy (superfloppy) emulation,  those are 2 heads/sides.

 

IMDISK should be able to map an extent (besides a whole image), maybe this way it works even on hard disk images (-b and -s parameters), see here for the syntax:

http://reboot.pro/in...=20450&p=192170

pointing to the partition/volume address and size

(there could be issues with "sectors before", but since the image is not booted, very likely that field is ignored by IMDISK and by the mounting OS)

 

Wonko

[deomsh]

Thanks for the ideas.

Although Dencorso's 36MB superfloppy had 2 heads already, I tried to adjust the 5760KB floppy. But nothing worked in Virtual Box 7.

Then I remembered Virtual Box took empty (floppy-size) images too, so I did some experiments. The max size taken was about 3600KB.

I made a 3600KB floppy with my tool (2 h, 80 t, 45 s), But although Virtual Box seems to be happy with the image size, SCANDISK threw out an error I'd never seen:



It seems to be related to Q106094:



Test of FATINFO.G4B showed FAT1 and FAT2 where no longer equal. It appears the second fat and the root sector where fully empty now!

When I looked in the VBox.log I found this:

00:00:08.176491 DrvVD: Automatically upgraded floppy drive from FLOPPY_1_44 to FLOPPY_2_88 to better support the 3686400 byte image
00:00:08.176542 FDC: 2.88 MB 3"1/2 floppy disk (2 h 80 t 36 s) rw

BTW I tried other combinations like (6 h, 15 s => 80 t), (2 h, 36 s => 100 t) and (2 h, 90 s => 40 t). I have been looking a bit in floppy controller datasheets etc. 8-bit values seems possible, but no examples above 5760 KB (so 2.88M).

Any ideas?

I am not sure if I fully understood what you said about ImDisk. If I mapped the empty 3600KB image as a floppy, I could format it in Windows 10. The result not look fully normal to me however:



BTW SCANDISK gave same error as earlier.

EDIT:
Today I was reading the msfn-superfloppy thread, and I came across your Known_floppys2.xls. So I will first continue writing images above 2.88M, but with max 80 tracks to see if scandisk will 'take' them (and finding the 'real' max of VBox).
Somewhere in that thread was stated that 83 tracks is max in case of NON-superfloppies? given two heads, what is max sectors per track?

[Wonko the Sane]

Those are other issues.

AFAICR in floppies (real floppies) the formatting was actually a real "low level formatting", the standard was already 80 tracks, but 81 or 82 was doable, while for some reasons at 83 most floppies (the actual drives) did not work anymore (the head was forced out of its intended range and on some floppy drives this could result in permanent damage).

 

IMDISK can "read" a hard disk like image (which includes the MBR and the "hidden sectors") but will actually map only the partition/volume, it is improperly named because it is not a "disk" driver, but rather a "volume" driver.

 

Then it offers a "save" option where it will recreate optionally the MBR and hidden sectors, this may (or may not) work in all cases.

 

But it can also map an extent, if you provide the offset and size, an extent mapped this way will (should) when saved maintain the original MBR and hidden sectors of the original image (as instead of being mapped and ignored that area is not mapped at all).

 

The Virtualbox BIOS/whatever seems like wanting to "fix" the device.

 

It has to be seen what happens if you use the (super) floppy image within a .iso.

Virtualbox (if it allows this non entirely standard image) should not be able to change anything in it (after all it is a read only CD  device) while in IMDISK you can map only the actual (super) floppy extent (and this will have sectors before 0, so that it cannot have any issue, possible with the hard disk approach).

 

There is yet another thing to try, the MakebootFAT approach.

 

Basically it is a special setup where the first sector is at the same time a MBR and a PBR.

It was developed at the time to allow USB sticks to be bootable on old BIOSes (both those that only booted from floppies/superfloppies only and those that booted from partitioned devices only), it uses a derivative of the Syslinuix code which is fairly "universal".

 

Virtualbox should have (in theory) no issues whatsoever if you connect the image to the "hard disk" controller. (it will see it as a hard disk with a single partition)

IMDISK should also have no issues (still in theory) and it should be able to see it as floppy (superfloppy).

 

It is a possibility (IMHO) worth exploring, some info and an experimental batch linked to here:

 

http://reboot.pro/in...=22277&p=215728

 

Wonko

[deomsh]

I did some tests, and I have good news and bad news.

 

Regarding floppies above 2880 KB taken by Virtual Box 7:

I succeeded with 3120K (2 h 80 t 39 s), 3200K (2 h 80 t 40 s), 3520K (2 h 80 t 36 s) and 3840K (2 h 80 t 48 s). Your Known_floppys2.xls was quite handy, I only had to convert all values to hex. See https://msfn.org/boa...&comment=980908 (members only, didn't saw it on reboot.pro).

I did all kind of tests, like copying until floppies where (almost) fully filled up, running FULL SCANDISK in MS-DOS 7,1, SCANDISKW in Windows 98SE and CHKDSK in Windows XP (in XP I had to run CHKDSK from CMD if I wanted to test file system too):

 

 

I also made floppies 820K (Winimage) (2 h 82 t 10 s) and 1743K (2 h 83 t 21 s), but on both SCANDISK found (non-existing) errors:

 

 

 

Regarding ImDisk:

I could read the floppy-part from an ISO using IMDISK.EXE with the -b and -s switches (ImDisk didn't take the hex-values I red-out with Total Commanders Lister in hex-mode, but that's not a big problem). However the floppy part was still a CD/DVD in Windows 10, so read-only. Drive Letter was first free HD-letter, if I forced A: still a CD/DVD. But if I renamed the ISO to IMG, I could write to the floppy-image part:

 

 

Regarding booting Superfloppy inside an ISO with Virtual Box:

If I copied with COPY /B your ISOHDR288+2880K floppy image to an ISO everything was fine.

If I made a 5760K floppy image (2 h 160 t 36 s) and mapped the image in grub4dos to copy the MS-DOS7.1 boot files and set the right attributes and 'back' in Windows 10 made the ISO, Virtual Box booted happily, but SCANDISK had big problems:

 

 

All in all I am very happy I can use TWO 3840K floppies, and write to them with ImDisk during a Virtual Box session, really a big difference .

Sadly on my Limbo X86 platforms SCANDISK and COMMAND.COM are not so happy .

 

BTW I will take a look at the 'MakebootFAT approach' later.

[Wonko the Sane]

Good.

 

Re: the .iso to .img  the IMDISK mapping the extent as CD automatically as it "senses" the extension, you can try using the fd switch to "force" it to map it as floppy (i.e. with write capabilities) without needing to rename the file:

cd      Creates a virtual CD-ROM/DVD-ROM. This is the default if the file

        name specified with the -f option ends with either .iso, .nrg or .bin

        extensions.


fd      Creates a virtual floppy disk. This is the default if the size of the

        virtual disk is any of 160K, 180K, 320K, 360K, 640K, 720K, 820K, 1200K,

        1440K, 1680K, 1722K, 2880K, 123264K or 234752K.

Wonko

[deomsh]

With the switch '-o fd' ImDisk mapped part the ISO to a writeable floppy, changes are visible in Virtual Box 7 afterwards, if booting from the ISO. ImDisk can be stay attached to the floppy-part of the ISO while in a Virtual Box session, changes in between are visible after resetting Virtual Box :

 

 

BTW filename of last last print-screen is truncated while uploading to reboot.pro, my quite long descriptive name was longer than 259 chars

 

I tested floppies 5760K HS 2/15 with ISOHDR120 and 5760K HS 2/18 with ISOHDR144, but same problems with SCANDISK as earlier.

 

However, SCANDISK.EXE gave some nice advice too:

 

[deomsh]

Would it be possible to modify ISOHDR288 so I can boot an ISO from my 3840K floppy image? Lets say ISOHDR375 to have a nice file name (3840/1024=3.75 of course)

 

BTW: I compared ISOHDR120, ISOHDR144 and ISOHDR288: the only difference was byte 0x9821 with respective values 01, 02 and 03.

[Wonko the Sane]

The 01/02/03 correspond to the three values available for the El-Torito Floppy Emulation:

 

https://msfn.org/boa...&comment=970680

 

Calling those files ISOHDR120/144/288 might be misleading, as we have seen that (depending on BIOS) they actually mean:

 

https://msfn.org/boa...&comment=970811

 

0x01 n/2/15

0x02 n/2/18

0x03 n/2/36

 

so you cannot have your 3840 (80/2/48), but you should be able to use the 3520 (80/2/36) with the isohdr288 header.

 

But I don't understand why you cannot use any other n/2/36 size, is it the scandisk error? Personally I would ignore it, the floppy disk image is anyway read only.

 

have a look at this thread:

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

 

the isoinfo by erwan.l could be the "right" tool to check your .iso.

 

Wonko

[deomsh]

Thanks for enlighten me.

 

I understand now why El Torito 3840K floppy is not booting if there are only three values of floppy sectors per track possible. I tried 3520K with ISOHDR288, but no boot either.

 

In fact I do not understand how '3520 (80/2/36)' can exist - did you revolutionize arithmetics, or am I not understanding what you ment?

 

About the El Torito 5760k with Virtual Box 7: 'normal' SCANDISK was okay, but surface scan showed read-errors. Normally I do not continue in such cases, but now for the sake of experiment I did.

 

I opened the floppy inside the ISO with ImDisk and wrote some trash, until floppy was almost filled up. After booting VBox with the ISO I checked with MS-DOS 7.1 DIR /S. This gave a read-error, so in my opinion SCANDISK was right. I booted to grub4dos and used some of my tools to check and copy the full floppy to a directory on some vhd. Afterwards DIR was fine with this directory and SCANDISK had no problems reading the whole vhd. See print-screens for details.

 

 

Lately I started with VMware Workstation player 17, but I am stilI at the level of Ctrl+Alt to get Windows 10 back

 

I tested same 5760K ISO in VMware, no problems with DIR (nor with SCANDISK):

 

 

Lately I 'discovered' newer grub4dos versions gave INT13 information if geometry is used with debug 3 - but only first time a drive is accessed. Only differences I can detect is INT13/41(0), version=AA300007 AND drive 0x00(LBA) respective AA200007 AND drive 0x00(BIF) ??

 

First print-screen is geometry (fd0) in Virtual Box 7, next in VMware workstation player 17:

 

[Wonko the Sane]

 

In fact I do not understand how '3520 (80/2/36)' can exist - did you revolutionize arithmetics, or am I not understanding what you ment?

 

You wrote it and I trusted you:

 

 

 

 

I did some tests, and I have good news and bad news.
 
Regarding floppies above 2880 KB taken by Virtual Box 7:
I succeeded with 3120K (2 h 80 t 39 s), 3200K (2 h 80 t 40 s), 3520K (2 h 80 t 36 s) and 3840K (2 h 80 t 48 s). 

 

Note: I now checked and it should be 80/2/44 so not compatible with floppy emulation  0x3.

 

You can try 3600K 240/2/15 compatibel with 0x01 or 4300K 240/2/18 compatible with mode 0x2.

 

About the issues in Virtualbox, very likely they are due to Virtualbox being more royalist than the king.

 

If it automagically corrects floppy type/size/geometry/whatever, as you showed earlier:

 

 

 

When I looked in the VBox.log I found this:

00:00:08.176491 DrvVD: Automatically upgraded floppy drive from FLOPPY_1_44 to FLOPPY_2_88 to better support the 3686400 byte image
00:00:08.176542 FDC: 2.88 MB 3"1/2 floppy disk (2 h 80 t 36 s) rw

 

it is a no go.

 

Wonko

[deomsh]

Sorry about my error, the copy/ paste devil took me. I used the '(2 h 80 t 36 s)' from the VBox log file, but failed correcting the 3520K.

I tried all different Virtual Box 7 controllers: no difference. Different guest OS's neither. But at least VMware Player 17 is 'good', so it does not seem a MS-DOS 7.1 issue.

I will try 3600K and 4320K (4300 will be a typo).

[deomsh]

I tried:

 

1) floppy 4320K with ISDOHDR144: both VBox 7 AND VMware 17 Disk I/O error, so not bootable (standard MSWIN4.1 bootcode). To be sure I tried 1440K: all good in VBox already (as expected).

 

2) floppy 3600K with ISDOHDR120: in VBox 7 SCANDISK gave a read-error at cluster 1,183; VMware 17 all good. Plus nice picture of MSD.EXE inside VMware showing floppy type:

 

[Wonko the Sane]

Sorry about my error, the copy/ paste devil took me.

 

Yep, it took me as well.

 

 

 

 

2) floppy 3600K with ISDOHDR120: in VBox 7 SCANDISK gave a read-error at cluster 1,183; VMware 17 all good. Plus nice picture of MSD.EXE inside VMware showing floppy type:

 

So, maybe you could go "up" (on VmWare) the 4800K and 6000K (4*1200K and 5*1200K) might work, still with 0x2 emulation.

 

Depending on bootability (which I believe only the makebootfat double MBR/PBR appeoach can guarantee) the next step could be testing (on the hard disk/ATA interface) ZIP100 (both partitioned and not partitioned) and the LS120 sizes, maybe they were replicated in these Virtual Machines (or maybe not, as a matter of fact they were pretty much rare and/or lasted only a short time in the real world before the USB sticks became ubiquitous).

 

Since you use this setup for grub4dos experiments, it shouldn't be an issue to remap the device to floppy.

 

 

Wonko

[deomsh]

I tested 4800K and 6000K (4*1200K and 5*1200K), with 0x1 however. This time Virtual Box 7 had no problem booting. Further the usual read errors, while VmWare Workstation 17 player was fine.

I also made the max sizes: 14400S15.ISO with ISOHDR120, 17280S18.ISO with ISOHDR144 and 34560S36.ISO with ISOHDR288. Further same results as above, but for instance cluster 180 on floppy part of 34560S36.ISO is still almost 2880K:



I think I found a workaround for Virtual Box 7: If system files + GRUB.EXE + grubutil fat are at the beginning of 34560S36.ISO I had no problem running grub4dos to map the floppy part of the ISO to memory and 'overmap' (fd0). If I booted IO.SYS again, everything was fine on the superfloppy with MS-DOS 7.1.

For now I used following setup:

1) Boot the ISO to A:
2) Run ET.BAT with special MENU.LST

---------------------------------------
ET.BAT
---------------------------------------
A:\GRUB.EXE --config-file="A:\MENU.LST"
---------------------------------------

---------------------------------------
MENU.LST
---------------------------------------
map --floppies=2
## watch: 2KB sectors on (0xe0)
map --mem (0xe0)26+17280 (fd0) > nul
map --hook
root (fd0) > nul
fat del /menu.lst > nul
fat ren /menu.new /menu.lst > nul
fat del /et.bat > nul
chainloader /io.sys > nul
---------------------------------------

BTW can also be done with small CONFIG.SYS/ AUTOEXEC.BAT + deleting/ renaming to fully automate the boot process.

 

Some action print-screens:



Also DIR /S gave no errors if floppy was fully loaded:



Finding the disk number of the ISO was not so easy however, is there a reliable method in this case?

Nice of this setup is I have write access to A: / (fd0) after booting the ISO in Virtual Box, and if I want to save I can simply copy with raw dd (fd0) to the original image 34560S36.IMG, located on some (virtual) disk. Even better: if this disk is attached to the AHCI controller I can use hotplug to get my image back and copy changes to the floppy part of 34560S36.ISO, still available thanks to the ImDisk method you teached me. Together with my 3840K floppy - attached to A, shifted to B - I have write access to Virtual Box too. Even no need to leave the session .