Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

On Bootable CD's Floppy Emulation

- - - - -

  • Please log in to reply
101 replies to this topic

#26
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

I see. While I do strive to be clear, some times ambiguity gets the best of me.
So, just to set things right, what I wrote was:

I might be intersted if it gives me fine control to build unusual bootable .ISOs (as you said it does).

My intention was that those "it"s should mean "your software utilities", not Nero nor UltraISO. But "it" is too vague.
Sorry, my bad. :(

The answer to your intended question is yes. My utilities allow you to specify the Emulation Type Code, including No Emulation, overriding the default based on the size of the Boot Image chosen. The only requirement is that the Boot Image be a multiple of 512 Bytes.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.


How to remove advertisement from MSFN

#27
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,657 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Is there any interest in them, to justify packaging them?

Who knows? :unsure:

My remark was more a "generic" one, you have something in your closet, you may be willing to sell it, but until you don't take it out of the closet and put it on display on your desk, under a big "for sale" sign you have 100% possibilities (read as "certainty") that noone will ever buy it, or the other way round 0% probabilities of ever selling it.

Once you have it in plain view on the desk it is possible that someone is interested to it, you will have n% probabilities that someone will buy it, and no matter how little n will be it will always verify the n>=0 condition, with a chance of also verifying the n>0 one. :)

jaclaz

#28
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Here is the appropriate FAT-12 36 MiB floppy image. Usually double-compression doesn't give good results, but this is an unusual file, so I gave it a shot, and it worked! :P

@jaclaz: Now it's up to you... can you convince mkisofs to create a bootable .ISO from it?

Attached Files



#29
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,657 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Here is the appropriate FAT-12 36 MiB floppy image. Usually double-compression doesn't give good results, but this is an unusual file, so I gave it a shot, and it worked! :P

Strangely enough, the idea is not really-really new :whistle:
http://bootcd.narod.ru/images_e.htm
(though in those cases the .rar was inside the .zip, and you made it the other way round :))

@jaclaz: Now it's up to you... can you convince mkisofs to create a bootable .ISO from it?

I won't even try :w00t: , at least for the moment , I mean, let's go in steps, I would be happy enough to have it work with a 3840 Kb or 5760 Kb one ;)

jaclaz

#30
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag


Is there any interest in them, to justify packaging them?

My remark was more a "generic" one, you have something in your closet, you may be willing to sell it, but until you don't take it out of the closet and put it on display on your desk, under a big "for sale" sign you have 100% possibilities (read as "certainty") that noone will ever buy it, or the other way round 0% probabilities of ever selling it.

Once you have it in plain view on the desk it is possible that someone is interested to it, you will have n% probabilities that someone will buy it, and no matter how little n will be it will always verify the n>=0 condition, with a chance of also verifying the n>0 one. :)

jaclaz

I could write a Program that turns the background to pink. Would it even be worth investing in a "for sale" sign considering that I have never seen anyone show an interest in a pink background. How do I know that N>X where X is the cost of the "for sale" sign.

I have over 1700 Programs. Putting them on my Desk would cause the Desk to collapse under the weight of the "for sale" signs.
The same would be true of my Website.

This thread is the only one I have seen indicating an interest in extended Bootable CD Floppy Emulation, so this is the only "desk" worth putting it on.

Incidentally:

Who knows? :unsure:

Doesn't help raise the value of N.

@dencorso: Your latest Image is not totally empty but it should work. I would have worded it differently.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#31
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

And work it does! I can boot the image directly, with grub4dos... and I can boot it as the boot sector of a CD! Yay! Posted Image
Thanks for the great info! :thumbup

Attached Files



#32
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,657 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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 Posted Image and to the good guys at MenuetOS :thumbup :
http://www.menuetos.net/cdboot.htm


jaclaz

Attached Files


Edited by jaclaz, 19 July 2011 - 06:38 AM.


#33
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

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

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

Credits go to rloew Posted Image 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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#34
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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.

#35
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,657 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
@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
  • Experiment for the day ;):
  • populate your image with MSDOS 7.1 files+whatever else you might want to test
  • use this app:
    http://www.minidvdsoft.com/isocreator/
    to create a bootable .iso with it (+ any files you want in the "accessible CD" part)
  • hexedit in the .iso AA5555AA8802 to AA5555AA8803
  • try booting the .iso in Qemu or whatever Vm you use

jaclaz

#36
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Yes, it works! Posted Image
And no, I did not use any VM, but an Asus EeePC with an external USB CD/DVD burner as the test machine. :P

#37
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

@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, 20 July 2011 - 11:42 AM.

Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#38
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,657 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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:
  • development costs
  • marketing/advertising costs
  • production costs
  • distribution costs
  • 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:
  • development costs
  • 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

#39
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag


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:
  • development costs
  • marketing/advertising costs
  • production costs
  • distribution costs
  • 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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#40
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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.

#41
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#42
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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.

#43
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,657 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
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

#44
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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... Posted Image

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! Posted Image
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). :)

#45
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,657 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
Experiment #1 for today :) :

Experiment #2 :ph34r: :
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 Files



#46
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#47
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

@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. :w00t:
Please test it thoroughly and let me know of any bugs you all find.
Enjoy!

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

@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 Files



#48
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

@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! :thumbup

Attached Files



#49
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

@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! :thumbup

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#50
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,017 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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

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?

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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users