rloew

On Bootable CD's Floppy Emulation

102 posts in this topic

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.

0

Share this post


Link to post
Share on other sites

@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! clapping.gif

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

cheltomb3.7z

0

Share this post


Link to post
Share on other sites
@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

post-134642-0-05511700-1311476467_thumb.

0

Share this post


Link to post
Share on other sites
@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.

0

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

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.

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.

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.

0

Share this post


Link to post
Share on other sites

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:

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.

grub4dos-0.4.4-2009-03-25.zip

0

Share this post


Link to post
Share on other sites

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 :ph34r: (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.com/p/grub4dos-chenall/downloads/list

or however a decently recent enough version, suggested is 2011-04-29.

jaclaz

grub4dos-0.4.4-2009-10-16.zip

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

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 ( :puke: ), 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. :wacko:

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

0

Share this post


Link to post
Share on other sites

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

http://reboot.pro/14/page__pid__133740__st__30 :whistle:

jaclaz

0

Share this post


Link to post
Share on other sites

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

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.

0

Share this post


Link to post
Share on other sites

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?. :unsure:

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

:whistle:

jaclaz

0

Share this post


Link to post
Share on other sites

True enough. But since:

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

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
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.