Jump to content

On Bootable CD's Floppy Emulation


rloew

Recommended Posts


On 7/19/2011 at 5:33 AM, dencorso said:

and I can boot it as the boot sector of a CD!

And how did you create the .iso (or CD)?

@rloew

You need a sturdier desk! :) (or a self-standing "for sale" sign ;))

@all

Find attached an early, as usual half- @§§ed (in this particular case 3/4 ;)) approach :ph34r: .

Credits go to rloew :worship: and to the good guys at MenuetOS :thumbup :

http://www.menuetos.net/cdboot.htm

jaclaz

sfloppyCD_01.zip

Link to comment
Share on other sites

On 7/19/2011 at 6:34 AM, jaclaz said:

@rloew

You need a sturdier desk! :) (or a self-standing "for sale" sign ;))

And I suppose you are going to read all 1700 of them.

Would anyone else? If so, raise your mouse.

Quote

@all

Find attached an early, as usual half- @§§ed (in this particular case 3/4 ;)) approach :ph34r: .

Credits go to rloew :worship: and to the good guys at MenuetOS :thumbup :

http://www.menuetos.net/cdboot.htm

jaclaz

I downloaded your attachment. The headers appear to be padded for a specific CD configuration, it would not support Joliet, for example, and do not include even a null ISO block.

I already have a single tool that can take a Floppy Boot Image, like the one Dencorso posted, along with one or more folders of Files for the rest of the CD/DVD, and burn them in one step.

The other tools I mentioned previously were to facilitate making the Floppy Boot Image.

Link to comment
Share on other sites

Here's what I did, using the tools I already had, and a lot of patience:

(i) Tried to populate my original image with WinImage, but the result had messed-up FATs and was unbootable. I may have been unlucky in this attempt, but I did not stop to test whether WinImage always blorks the FATs or if it indeed was an unfortunate run.

(ii) Tried to populate my original image using jaclaz's VDM, which relies on Ken Kato's VDK, and this worked like magic! Then I run Win XP's chkdsk on it and it reported no problems.

(iii) Proceeded to boot the image directly with grub4dos, and succeeded. Then, while booted from the image, run MS-DOS SCANDISK (from Win ME) on it, and it found no problems. Here's the relevant excerpt of my MENU.LST:

title RRL 36MiB

find --set-root --ignore-floppies /boot_fd.ima

map /boot_fd.ima (fd0)

map --hook

rootnoverify (fd0)

chainloader --force (fd0)+1

(iv) Fed the image to UltraISO, and had it create a bootable 185 MB mini-CD ISO, and it did so. However it was unbootable. But it had incorporated the full Floppy image and created a reasonable ISO, to start with. On the other hand, it decided it was a no-emulation boot image it had loaded. And, BTW, it blorked the boot sector, and specifically destroyed the BPB, while creating this image. So, in the Default Booting Catalog, I set the media type to 03 and the partition type to 06 (!, but probably it could have been any value), and, using WinHex, copied the known-good floppy image again, over the blorked image UltraISO had included in the .ISO (they did have the same size, of course). I saved a copy of the floppy image blorked by UltraISO and compared it (with Beyond Compare) to the known-good one, finding that all the damage done was solely to the boot sector (so I might have copied over again to the .ISO just the boot sector instead of the whole image). The ISO 9660 part of the image I populated with 3 videoclips, just to fill space, and the full ISO ended up having a 91 MiB size.

(v) Fed the image to Nero and it burned it into a mini-CD RW, which it did without complaining.

(vi) Booted the freshly burned CD and took that picture I posted yesterday.

Link to comment
Share on other sites

@rloew

And I suppose you are going to read all 1700 of them.

Yes, it is very possible, I am usually very accurate and punctilious :).

I downloaded your attachment. The headers appear to be padded for a specific CD configuration, it would not support Joliet, for example, and do not include even a null ISO block.

Sure :) they are the headers from the Menuet Os guys, in their own words:

http://www.menuetos.net/cdboot.htm

Note that the CD image is for booting only

and does not include a iso9660 filesystem.

more generally I defined myself the approach as half-@§§ed (actually 2/4-@§§ed) exactly to save other people the need of coming out saying:

Hey, wait, that's not fully OK!

;):lol:

I already have a single tool that can take a Floppy Boot Image, like the one Dencorso posted, along with one or more folders of Files for the rest of the CD/DVD, and burn them in one step.

You share some common trait with one of the greatest geniuses in the whole history of mathematics, Pierre de Fermat :thumbup :

I have discovered a truly marvelous proof that it is impossible to separate a cube into two cubes, or a fourth power into two fourth powers, or in general, any power higher than the second into two like powers. This margin is too narrow to contain it.

;)

@dencorso

  1. Experiment for the day ;):
  2. populate your image with MSDOS 7.1 files+whatever else you might want to test
  3. use this app:
    http://www.minidvdsoft.com/isocreator/
    to create a bootable .iso with it (+ any files you want in the "accessible CD" part)
  4. hexedit in the .iso AA5555AA8802 to AA5555AA8803
  5. try booting the .iso in Qemu or whatever Vm you use

jaclaz

Link to comment
Share on other sites

@rloew

And I suppose you are going to read all 1700 of them.

Yes, it is very possible, I am usually very accurate and punctilious :).

One so far.

Reduce that by the fact that Reading about something doesn't guarantee purchase.

Still leaves N<1700*X

I already have a single tool that can take a Floppy Boot Image, like the one Dencorso posted, along with one or more folders of Files for the rest of the CD/DVD, and burn them in one step.

You share some common trait with one of the greatest geniuses in the whole history of mathematics, Pierre de Fermat :thumbup :

I have discovered a truly marvelous proof that it is impossible to separate a cube into two cubes, or a fourth power into two fourth powers, or in general, any power higher than the second into two like powers. This margin is too narrow to contain it.

That's called "Closed-Source".

Also, have you ever heard of a "pre-marketing survey"?

Edited by rloew
Link to comment
Share on other sites

That's called "Closed-Source".

Well, no.

That's called "I have something that is not currently available, for free or for $. Additionally, WHEN and IF it will be available, it will be "Closed-Source"." :whistle:

Corollary:

"I won't also not reveal that I have this thing ready in the closet, unless someone will torture me" :ph34r:

Also, have you ever heard of a "pre-marketing survey"?

Sure, it is something that is done once one has decided to market something, in order to forecast revenues, if they are calculated to be too low, the item is not marketed after all.

Of course you are perfectly free to release (or NOT release) anything as well as market (or avoid marketing) any of your tools, that's the very good thing about freedom :yes: .

But you have to see it from a purely pragmatical viewpoint.

Real, physical things produced have usually 5 main source for costs:

  1. development costs
  2. marketing/advertising costs
  3. production costs
  4. distribution costs
  5. product support costs

When you talk about "immaterial" things like software item #3 is 0, item #4 is near to 0 (electronic dowmload) and #5 should be near to 0 as well (if the product is good ;)).

So you have only two items:

  1. development costs
  2. marketing/advertising costs

of which you ALREADY sustained the biggest item #1, so every cent you can get from the product is better than nothing.

Pre-marketing surveys may be useful to target the retail price and to validate the usefulness of an advertising campaign, for which till now you had no costs.

@dencorso

You mean you doubted about it? :w00t:;)

You deserve to go behind the green glass door as "leery, but heedful peep "! :rolleyes:

jaclaz

Link to comment
Share on other sites

That's called "Closed-Source".

Well, no.

That's called "I have something that is not currently available, for free or for $. Additionally, WHEN and IF it will be available, it will be "Closed-Source"." :whistle:

Corollary:

"I won't also not reveal that I have this thing ready in the closet, unless someone will torture me" :ph34r:

It already exists, so it is available. If someone bought it right this minute, I would write some instructions for it and E-Mail it. It does not have to be advertised to be available. I have already sold products to MSFN forum members that were never advertised on my Website.

No one asked the price or even if it was available. Everyone knows it exists. It is not torture to ask. The Forum does have a PM option, and my E-Mail Address is published.

Also, have you ever heard of a "pre-marketing survey"?

Sure, it is something that is done once one has decided to market something, in order to forecast revenues, if they are calculated to be too low, the item is not marketed after all.

Of course you are perfectly free to release (or NOT release) anything as well as market (or avoid marketing) any of your tools, that's the very good thing about freedom :yes: .

But you have to see it from a purely pragmatical viewpoint.

Real, physical things produced have usually 5 main source for costs:

  1. development costs
  2. marketing/advertising costs
  3. production costs
  4. distribution costs
  5. product support costs

#2 is the key here. Even at minimum wage, I would have to sell several to cover my time, or charge an unacceptable price.

#4 is not really anywhere near zero. Just the mechanics of making a Paypal payment takes up a lot of E-Mail to-and-fro. Even worse when it is not an option.

#5 isn't that small, no matter how good the product is. They want to use it for purposes it was not intended for, they keep asking about my upgrade policy, even after I said "free upgrades", etc.

Add them together, and consider what I just said above.

I think I will wait until the Workaround discussion runs it's course and see who has, what dencorso described as "lots of patience", such as you I'm sure, and who would rather not.

Link to comment
Share on other sites

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

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.

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 on 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.

Link to comment
Share on other sites

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

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.

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.

Link to comment
Share on other sites

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.

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.

Link to comment
Share on other sites

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 :ph34r: ).

@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

Link to comment
Share on other sites

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... dubbio.gif

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! celebrate14.gif

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). :)

Link to comment
Share on other sites

Experiment #1 for today :) :

  1. get mkdosfs:
    http://www1.mager.org/mkdosfs/
    http://www1.mager.org/mkdosfs/mkdosfs.zip
  2. get dsfok:
    http://members.ozemail.com.au/~nulifetv/freezip/freeware/
    http://members.ozemail.com.au/~nulifetv/freezip/freeware/dsfok.zip
  3. get the attached file (usual half-@§§ed batch ;))
  4. expand everything in a directory
  5. run the batch (FAT12build.cmd)

Experiment #2 :ph34r: :

Try using this app instead of Free Iso Creator:

http://www.nbxsoft.com/

Free Create-Burn ISO

http://www.nbxsoft.com/files/createburniso.exe

It should avaoid patching the 0x02 to 0x03

jaclaz

FAT12build.zip

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...