[rloew]

dencorso, on 20 July 2011 - 03:22 PM, said:

Back ontopic, please! I've done too much thread surgery already.

Here's the progress we've made:
1) The 36 MiB floppy image had to be created by hand, but that's done (by myself), and it's available for download.
2) It was truncated. That's been solved by using DCopyNT (by Jorgen Bosman).
3) The image is empty (at least that's what the FATs say...) so it must be populated): VDM (by jaclaz) / VDK (by Ken Kato) solves that nicely
4) The bootable ISO must be created. That's solved now by using The Free ISO Creator, by miniDVDsoft.
5) I've used Nero 6.6 to burn the ISO onto a physical medium (a mini-CD RW, in my case)... but any burner can do it, so it's not a problem.
Of course there are some hexediting to be done, for adjusting the Media Type in the El Torito Boot Catalog Default Entry (and more hexediting in case one wants to substitute the boot sector in the floppy image), but that's acceptable.

But what I miss is having an application to edit the ISO 9660 part of the ISO. I tried UltraISO for that, but it trashes the image. My current working hypothesis is that UltraISO might do it right *iff* (iff = if and only if) one changes the media byte to 0 (no-emulation) before editing, and then, after all is done, changes it back to 3. This is what I'm going to test from now on.

This is why I said this approach is not simple.

Quote

And more, although 36 MiB is the largest floppy image that can be used in an El Torito floppy emulation boot, I do suspect one can use a 127 MiB (the maximum FAT-12 image) to boot, in case one uses reanimatolog's great BCDW. Since jaclaz's pointed to reanimatolog's image repository, some posts above, I think it's just fair to mention it here, too. But I'll let that for later, at the moment. BTW, BCDW *is* a great way of creating multiboot CDs, in my experience. And, for sure, if FAT-12 is not used, reanimatolog himself has already gone well beyond that (see pic) so I'm sure the 127 MiB image will work. And, for the more adventurous, the german page hosting the last alpha version of BCDW is gone, but here's bcdw201a.rar. It has MD5 = CC821E28B3ED5FC32821D0861630CD6C. The stable 1.50Z version, which I use, can be found here, of course, as always.

@Multibooter: Do look into this, if you really are interested in > 100 MiB bootable diskete images working in optical media.

Unfortunately, the BIOS controls the CD's Floppy Emulation. The BIOSes I have tested, do not support LBA Mode and force the Geometry to 2x36 at best. With 1024 Cylinders, this sets the limit to 36MiB. You can define a larger Partition, but it will simply wrap back to zero when you pass 36MiB. You would need your own Code (DDO) to access the rest of the Image. You can do larger Images but only as Hard Disk Emulations (C:). Usually people just create a small Bootable Image and add the rest to the body of the CD.

[dencorso]

The El Torito Standard and Andrew Smith's Supplement to it let a careful reader understand that, when a floppy is emulated, it's booted by the BIOS as if it were a real floppy disk (the only difference being that the Int 0x41 pointer is not valid at boot time [Standard, section 4.0, p. 14]), CHS being used. It's also stated [Standard, section 4.1, p. 14] that a fixed head number (2) and a number of sectors per cluster dependent on the media byte, thus correponding to that used by the floppy format being emulated (15, 18 or 36, respectively) are used. But it's further stated that the number of cilinders used is fixed at 80 (care in reading the Standard: hexadecimal numbers are used everywhere), so that the undocumented fact that up to 1024 cylinders are acceptable is a precious piece of information uncovered by RLoew (as also is the undocumented fact that the > 32 MB sector count in the BPB is acceptable for FAT-12, which pushes the maximum limit of the FAT-12 system all the way to about 128 MiB). Of these facts we're all convinced by now.

rloew, on 20 July 2011 - 04:19 PM, said:

Unfortunately, the BIOS controls the CD's Floppy Emulation. The BIOSes I have tested, do not support LBA Mode and force the Geometry to 2x36 at best. With 1024 Cylinders, this sets the limit to 36MiB. You can define a larger Partition, but it will simply wrap back to zero when you pass 36MiB. You would need your own Code (DDO) to access the rest of the Image. You can do larger Images but only as Hard Disk Emulations (C:). Usually people just create a small Bootable Image and add the rest to the body of the CD.

Of course the limit for a El Torito floppy emulation *is* 36 MiB. Of course a DDO would be a solution to circunvert it. But what's beautiful in reanimatolog's solution (burn this proof-of-concept image and boot it to see for yourself) is that he avoided the need for a DDO by lateral thinking and used, instead, a perfectly normal no-emulation 4 sector boot image, called bcdwboot.bin, that loads a further 27 KiB file named bcdw.bin from the CDFS part of the CD, then transfers control to it, and it reads a configuration file named bcdw.ini (or bootcat.ini in the various versions of BCDW), and then bcdw.bin either presents a boot menu or boots the default entry if so instructed, by loading, by itself the image pointed to in bcdw.ini. When bcdw.ini actually loads the image, the El Torito routine in the boot part of BIOS has finished for a long time already, so that its limitations don't apply to bcdw.bin (which is a "normal application, from the BIOS POV, since it thinks booting is already over). The boot extension created by reanimatolog reminds me of the boot sequence in the NT-OS Family so much that I believe it may have been one of the sources of inspiration during the process of crating BCDW. That's how reanimatolog (wherever he may be nowadays) succeeded in doing the "impossible", and way back in 1999 or thereabouts! It's a real pity his beautiful solution never got very popular or widely known, AFAIK.

[jaclaz]

As I see it, right now the issue is to understand which bootsector CODE works with the sfloppy approach and which don't (and if they can tweaked to work).
As briefly mentioned in the .xls, the MS-DOS 7.x boot code works, the FreeDOS and the grub4dos one do not (but I did just a quick test, that ened to be repeated/reproduced ).

@dencorso
generally speaking editing .iso's is not the best idea in the world, I have seen more trouble coming form doing that than almost anything else, the "right way" is to rebuild the .iso, IMHO.

jaclaz

[dencorso]

While the sfloppy method appears to have limitations, the ISO created directly using the Free ISO creator works OK both with MS-DOS 7.1 and with FreeDOS 1.0, so that whatever may be the problem, it appears to be related to the ISOHDRs...

dencorso, on 20 July 2011 - 03:22 PM, said:

But what I miss is having an application to edit the ISO 9660 part of the ISO. I tried UltraISO for that, but it trashes the image. My current working hypothesis is that UltraISO might do it right *iff* (iff = if and only if) one changes the media byte to 0 (no-emulation) before editing, and then, after all is done, changes it back to 3. This is what I'm going to test from now on.

It simply works! Yay!
Now I know of a way to edit the ISOs, without having to recreate them: set the Media Byte=0, edit the .ISO, then set it back to 3. If a custom Validation Block is being used (optional), then that has to be restored too, because UltraISO recreates it, on editing. And, in the process of testing this, I've also demonstrated that any value, zero inclusive, set as the System Type = Partition Type Code works, no matter what (so, it is as it should be: since there is no partition in the boot image, the System Type byte is ignored).

[jaclaz]

Experiment #1 for today :

• get mkdosfs:
  http://www1.mager.org/mkdosfs/
  http://www1.mager.or...sfs/mkdosfs.zip
  
• get dsfok:
  http://members.ozema...eezip/freeware/
  http://members.ozema...eware/dsfok.zip
  
• get the attached file (usual half-@§§ed batch )
  
• expand everything in a directory
  
• run the batch (FAT12build.cmd)

Experiment #2 :
Try using this app instead of Free Iso Creator:
http://www.nbxsoft.com/
Free Create-Burn ISO
http://www.nbxsoft.c...eateburniso.exe
It should avaoid patching the 0x02 to 0x03

jaclaz

Attached File(s)

•  FAT12build.zip (1.63K)
  Number of downloads: 20

[rloew]

dencorso, on 20 July 2011 - 10:17 PM, said:

Of course the limit for a El Torito floppy emulation *is* 36 MiB. Of course a DDO would be a solution to circunvert it. But what's beautiful in reanimatolog's solution (burn this proof-of-concept image and boot it to see for yourself) is that he avoided the need for a DDO by lateral thinking and used, instead, a perfectly normal no-emulation 4 sector boot image, called bcdwboot.bin, that loads a further 27 KiB file named bcdw.bin from the CDFS part of the CD, then transfer control to it, and it reads a configuration file named bcdw.ini (or bootcat.ini in the various versions of BCDW), and then bcdw.bin either presents a boot menu or boots the default entry if so instructed, by loading, by itself the image pointed to in bcdw.ini. When bcdw.ini actually loads the image, the El Torito routine in the boot part of BIOS has finished for a long time already, so that its limitations don't apply to bcdw.bin (which is a "normal application, from the BIOS POV, since it thinks booting is already over). The boot extension created by reanimatolog reminds me of the boot sequence in the NT-OS Family so much that I believe it may have been one of the sources of inspiration during the process of crating BCDW. That's how reanimatolog (wherever he may be nowadays) succeeded in doing the "impossible", and way back in 1999 or thereabouts! It's a real pity his beautiful solution never got very popular or widely known, AFAIK.

Nice piece of work. But it still uses a DDO. They may not have called them DDOs back then.
The difference is he used No-Emulation Mode to load the DDO and referenced the CDFS for the entire Image.
I was suggesting using a DDO to take over and extend access to the El-Torito Image.
Either way works.
Presumably FREEDOS does not have the FAT12 restriction. He used FAT16.
There is nothing wrong with DDOs as long you don't have someone stupid design them as some of the Hard Drive Manufacturers did.

Note: The 36MiB El-Torito limitation has nothing to do with No-Emulation Mode. It is a simple Memory loader.

[dencorso]

@jaclaz: Sorry! I hadn't time for any tests today...

But I did write this handy little app to check and change the Media Byte.
Please test it thoroughly and let me know of any bugs you all find.
Enjoy!

Later edit: Just tested FAT12build.cmd. Works beautifully. Bravo!

@RLoew: Are you implying that it wouldn't boot were it set as MS-DOS 4.1 boot disk, instead of a FreeDOS one?
That sure would be an interesting finding. So I have a new test to perform, or have you tested it already? It was my understanding that the 36 MiB limit stemmed from the classic CHS BIOS 1024 cylinder limit when combine with The El Torito Standard (section 4.1, p. 14) 2 heads and 36 sectors-per-track, which I presumed the El Torito loader enforced for Media Type 3 booting... And, in any case, both heads and sectors-per-track are also set in the BPB, while the number of cylinders is not. Am I wrong, then?

Attached File(s)

•  cheltomb3.7z (51.63K)
  Number of downloads: 10

[dencorso]

dencorso, on 21 July 2011 - 10:07 PM, said:

@RLoew: Are you implying that it wouldn't boot were it set as MS-DOS 4.1 boot disk, instead of a FreeDOS one?
That sure would be an interesting finding. So I have a new test to perform, or have you tested it already? It was my understanding that the 36 MiB limit stemmed from the classic CHS BIOS 1024 cylinder limit when combine with The El Torito Standard (section 4.1, p. 14) 2 heads and 36 sectors-per-track, which I presumed the El Torito loader enforced for Media Type 3 booting... And, in any case, both heads and sectors-per-track are also set in the BPB, while the number of cylinders is not. Am I wrong, then?

Seems I was right, after all: I converted the inner megafloppy (690 MiB !) image to MS-DOS 7.1, and it booted all right, just as before. reanimatolog rocks!

Attached File(s)

•  SCREEN.gif (25.44K)
  Number of downloads: 9

[rloew]

dencorso, on 23 July 2011 - 09:00 PM, said:

dencorso, on 21 July 2011 - 10:07 PM, said:

@RLoew: Are you implying that it wouldn't boot were it set as MS-DOS 4.1 boot disk, instead of a FreeDOS one?
That sure would be an interesting finding. So I have a new test to perform, or have you tested it already? It was my understanding that the 36 MiB limit stemmed from the classic CHS BIOS 1024 cylinder limit when combine with The El Torito Standard (section 4.1, p. 14) 2 heads and 36 sectors-per-track, which I presumed the El Torito loader enforced for Media Type 3 booting... And, in any case, both heads and sectors-per-track are also set in the BPB, while the number of cylinders is not. Am I wrong, then?

Seems I was right, after all: I converted the inner megafloppy (690 MiB !) image to MS-DOS 7.1, and it booted all right, just as before. reanimatolog rocks!

Since your success is inconsistent with the results of my earlier experiments. I did a new set.

I created Floppy disks with FAT16 and FAT32 formatting.

FAT16 is bootable and works fine with no obvious issues under DOS 7 or Windows 9x.

FAT32 is bootable and works with DOS 7 but crashed Windows 9x when accessed.

The 36MiB El Torito limit remains, but the DDO approach can get you to 2GiB, or more with Patches.

I am formally amending the FAT12 restriction I posted earlier to include FAT16. FAT32 does appear to have problems if Windows 9x is loaded but may be useable otherwise.
Without analysis, I do not know if reanimatolog's DDO supports LBA.
I did not retest some of the other limitations that may apply to non-standard FAT12 and FAT16 Partitions, such as reserving more than 1 Sector.

[dencorso]

You were too terse, Rloew, sorry. Would you please elaborate?

Quote

I created Floppy disks with FAT16 and FAT32 formatting.
FAT16 is bootable and works fine with no obvious issues under DOS 7 or Windows 9x.
FAT32 is bootable and works with DOS 7 but crashed Windows 9x when accessed.

Which sizes had the images?

Quote

The 36MiB El Torito limit remains, but the DDO approach can get you to 2GiB, or more with Patches.

By DDO here you mean reanimatolog's BCDW 1.50Z, right?

It's also possible to boot those images by chainloading using GRUB4DOS (or with GRUB4DOS --> memdisk), from anywhere, including a just booted CD-ROM. This is also something you would classify as using a DDO, so it's not that different, inprinciple. I'm mentioning it here just for the sake of completeness. And then there's also Plop, too... but that I have no 1st hand experience with. In any case, the goal would be to boot a floppy image as near 700 MB GB as feasible, but not bigger, because that's the most common size of inexpensive CD-Rs.

[rloew]

dencorso, on 24 July 2011 - 09:28 PM, said:

You were too terse, Rloew, sorry. Would you please elaborate?

Quote

I created Floppy disks with FAT16 and FAT32 formatting.
FAT16 is bootable and works fine with no obvious issues under DOS 7 or Windows 9x.
FAT32 is bootable and works with DOS 7 but crashed Windows 9x when accessed.

Which sizes had the images?

I did not use Images.
I was using a real 1.44MB Floppy which cannot hold an entire FAT16 or FAT32 Partition.
I Quick Formatted it with my RFORMAT Program knowing that not all of the Space actually existed.
I was more interested in seeing if DOS or Windows would access the portion I used correctly.
I used 8192 Sectors and 70000 Sectors as the defined sizes.

Quote

Quote

The 36MiB El Torito limit remains, but the DDO approach can get you to 2GiB, or more with Patches.

By DDO here you mean reanimatolog's BCDW 1.50Z, right?

I was being more general, but yes.

Quote

It's also possible to boot those images by chainloading using GRUB4DOS (or with GRUB4DOS --> memdisk), from anywhere, including a just booted CD-ROM. This is also something you would classify as using a DDO, so it's not that different, inprinciple. I'm mentioning it here just for the sake of completeness. And then there's also Plop, too... but that I have no 1st hand experience with. In any case, the goal would be to boot a floppy image as near 700 MB GB as feasible, but not bigger, because that's the most common size of inexpensive CD-Rs.

I don't consider chainloading to be a DDO as long as the chainloader does not hook Interrupt 13. I interpret a DDO to be software, excluding firmware, that Hooks the Interrupt 13 Call before the OS is Booted.
You already have a solution for 700MB (not 700GB). I was also thinking of DVDs and Blu-Rays.

[dencorso]

Well, according to your own definition, RLoew, GRUB4DOS is a DDO, since it does hook int 13.
BTW, it can be used to simply mount an image in DOS, with this entry in MENU.LST:

Quote

title Mount Image
find --set-root --ignore-floppies /whatever.ima
map /whatever.ima (fd0)
map --hook
chainloader +1

This has the effect of mounting the image, then booting again from the device it had just booted, not from the image.
Yet, in my Eee PC 900 which has no floppy, when the prompt returns I then have an A: (which is the image, now mounted). Now, whatever is done to the disk gets imediately saved to the image, so that all changes are permanent. To unmount, the only option is to reboot the system.
The emulation is not perfect, however, because on attempting to SYS it, the system files get transferred, but the boot sector is not written to, presumably because the emulation does not cover int 26 too. But SYS terminates without complaining, that is, fails silently.

You should familiarize yourself with GRUB4DOS, RLoew... it's very powerful and versatile. There's an online manual for it which is good enough for you to get the gist of it: Grub4dos Guide. For the tests I described in this thread I used GRUB4DOS v. 0.4.4 (2009-03-25) which is now not very easy to find since nufans.net closed. So, for the sake of exact reproductibility, I'm attaching it here, just in case. But I'm being punctilious, really, because the version considered final, available from sourceforge, is 2009-03-31, so probably it would work just as well.

Attached File(s)

•  grub4dos-0.4.4-2009-03-25.zip (809.54K)
  Number of downloads: 7

[jaclaz]

dencorso, on 25 July 2011 - 05:16 AM, said:

For the tests I described in this thread I used GRUB4DOS v. 0.4.4 (2009-03-25) which is now not very easy to find since nufans.net closed. So, for the sake of exact reproductibility, I'm attaching it here, just in case. But I'm being punctilious, really, because the version considered final, available from sourceforge, is 2009-03-31, so probably it would work just as well.

That grub4dos version is SERIOUSLY outdated and BTW has also a number of bugs/limitations (though they do not probably apply to the tests you made), from history:

2009-10-16 Turned off int13/AX=4B01/DL=7F cdrom query which may hang on some machines. Commented out DMA code related to running via KEXEC. Implemented 64-bit int13 memdrive block moving code.
2009-06-20(r68) add (ud) device to access space created with fbinst.
2009-06-11 fixed a bug of missing assignment of ES and BX registers in
int13_handler(asm.S).
2009-05-13 fixed size-wrap-to-0 infinite loop issue in grub_read()(disk_io.c).
2009-05-07(r67) resolved conflict between int10 stack and BIOS Data Area(grldrstart.S).
2009-05-03 fixed a bug in geometry_tune(grldrstart.S, asm.S). zw2312914 report.
2009-04-30 triple mbr without bpb also bootable as a floppy(grldrstart.S).
2009-04-26 added ending CHS calculation for partition entry in mbr of the triple mbr(bootlace.inc).
2009-04-25 bug fix in dd about device length calculation(builtins.c).
2009-04-24 save and restore GDTR in int13_handler(asm.S).
2009-04-06 accept partitions starting in the mbr track(probe_mbr, builtins.c).
2009-04-05 triple mbr floppy partition (fdX,Y) support for some USB BIOSes(disk_io.c).
2009-04-04 fixed partition table entries in the 2nd and 3rd mbr of the triple mbr(bootlace.inc).
2009-03-31(r66) 0.4.4 official release.
2009-03-28 removed the problematic global variable "i"; reduced one open-file step for configfile on cdrom.
2009-03-27 fixed memory overlap issue on "map --rehook".

Don't even THINK of using anything older that 2009-10-16, which can be found here:
http://reboot.pro/15038/page__st__1
(but I am attaching a copy of it, just in case)

What one should really use nowadays - expecially if starting using grub4dos - is LATEST EXPERIMENTAL version, here:
http://code.google.c.../downloads/list
or however a decently recent enough version, suggested is 2011-04-29.


jaclaz

Attached File(s)

•  grub4dos-0.4.4-2009-10-16.zip (821.94K)
  Number of downloads: 24

[rloew]

dencorso, on 25 July 2011 - 05:16 AM, said:

Well, according to your own definition, RLoew, GRUB4DOS is a DDO, since it does hook int 13.
BTW, it can be used to simply mount an image in DOS, with this entry in MENU.LST:

I would agree. At least in the example you gave. It may depend on the GRUB4DOS options used.
A chainloader does not HAVE to use a DDO if it doesn't need to alter the layout or behavior of the Drives.
I have an experimental GPT booter that could be considered a chainloader but is not a DDO.

[dencorso]

@jaclaz: Yes! You're right, of course! I do use 0.4.4 (2009-10-16) everywhere, and that's the one I have in my main machine.
But... The Eee PC 900 is an unfinished machine. I have yet to install XP SP3 in the huge 128 GB RunCore SSD I gave it in replacement for the original (and slow) 16 GB Phison SSD. However, time is a commodity seriously lacking for me, then I didn't come around to finishing it yet. It has, for now, the original Xandros that came with it ( ), Slax 6.1.2, 7pe_x86 and MS-DOS 7.1 inside only, plus GRUB4DOS to manage that mess. And, to my big surprise, I found out, just as I was posting my previous post, that I'd never come around to updating the GRUB4DOS inside, which was the latest version available at the time!
Now, then, nufans.net is officially dead. download.gna.org/grub4dos is outdated and gna.org/projects/grub4dos/ has a very suspect certificate error... The page you pointed to has chenall builds. Where is tinybit's versions repository now? and there're karionix's versions too, isn't it? I've still not made sense of the 0.4.5 versions, but I do know the very initial ones didn't work for me, so I stopped at 0.4.4 (2009-10-16) for the time being, but should get back to it soon (I hope). Please do put me up to date about the repositories, because that's a recent change I wasn't aware of till yesterday.

@RLoew: After getting some sleep, I see I wrote an improbable thing... Int 26 probably is implemented as just one more wrapper around int 13... SYS fails to write the boot sector most probably because it attempts to write directly to the FDD (which isn't there, of course). I didn't look at the SYS binary to ascertain whether this is true, but at least this seems to me make more sense, right now.

[jaclaz]

dencorso, on 25 July 2011 - 02:11 PM, said:

Now, then, nufans.net is officially dead. download.gna.org/grub4dos is outdated and gna.org/projects/grub4dos/ has a very suspect certificate error... The page you pointed to has chenall builds. Where is tinybit's versions repository now? and there're karionix's versions too, isn't it? I've still not made sense of the 0.4.5 versions, but I do know the very initial ones didn't work for me, so I stopped at 0.4.4 (2009-10-16) for the time being, but should get back to it soon (I hope). Please do put me up to date about the repositories, because that's a recent change I wasn't aware of till yesterday.

http://reboot.pro/14..._133740__st__30

jaclaz

[dencorso]

jaclaz, on 26 July 2011 - 01:18 AM, said:

http://reboot.pro/14..._133740__st__30

Did I ever say you rock? Well, you do!

Here's the progress we've made (version 2):
1) The 36 MiB floppy image had to be created by hand, but that's done (by myself), and it's available for download.
2) It was truncated. That's been solved by using DCopyNT (by Jorgen Bosman).
3) The image is empty (at least that's what the FATs say...) so it must be populated): VDM (by jaclaz) / VDK (by Ken Kato) solves that nicely. Moreover, it can also be mounted in True DOS, by using GRUB4DOS (and this is the only way to delete the Recycle Bin that is created once one deletes anything, while working on the image in Windows, by mounting with VDM/VDK).
4) Furthermore, thanks to jaclaz's script, FAT12build.cmd, many other images can be created, as needed.
5) The bootable ISO must be created. That's solved now by using The Free ISO Creator, but the Media Byte must be changed to 3. My little app cheltomb.exe helps changing and checking the Media Byte in a simple way.
6) It may be needed to edit the .ISO, once its created... UltraISO does it right *iff* (iff = if and only if) one changes the media byte to 0 (no-emulation) before editing, and then, after all is done, changes it back to 3.
7) I've used Nero 6.6 to burn the ISO onto a physical medium (a mini-CD RW, in my case)... but any burner can do it, so it's not a problem.

[jaclaz]

dencorso, on 26 July 2011 - 01:55 AM, said:

5) The bootable ISO must be created. That's solved now by using The Free ISO Creator, but the Media Byte must be changed to 3.

Or maybe not?.

jaclaz, on 21 July 2011 - 04:57 AM, said:

Experiment #2 :
Try using this app instead of Free Iso Creator:
http://www.nbxsoft.com/
Free Create-Burn ISO
http://www.nbxsoft.c...eateburniso.exe
It should avaoid patching the 0x02 to 0x03

jaclaz

[dencorso]

True enough. But since:

dencorso, on 26 July 2011 - 01:55 AM, said:

6) It may be needed to edit the .ISO, once its created... UltraISO does it right *iff* (iff = if and only if) one changes the media byte to 0 (no-emulation) before editing, and then, after all is done, changes it back to 3.

I considered the issue of the Media Byte settled, and I'm not willing to install yet another program just because of the Media Byte. After my next backup I may test it, because then I'll have an easy way to remove it, after testing, unless I decide to keep it. Did you try cheltomb? It makes changing the Media Byte quite easy, if I may say so.

[dencorso]

I've updated cheltomb once more. The new version replaces the old one, on post #47, just in case someone bookmarked that post. The new version does all the previous two did, but also displays the offset within the .ISO image where the Boot Floppy image starts, to help extracting it by hand with an hexeditor, or using the great PartCopy, jaclaz gave me a pointer to, way back when.