179 replies to this topic

[tinybit]

OK, I have built a new version of eltorito.sys. Hopefully there would be no problems any more.

 

Unzip the attachment, you will get the binary driver eltorito.sys and the source code eltorito.asm.

 

And here is the patch to syslinux-5.00, for anyone who want to check:

--- eltorito.asm~       2012-12-06 18:47:31.000000000 +0800
+++ eltorito.asm        2012-12-22 01:30:42.356535569 +0800
@@ -1029,8 +1029,8 @@

 ScanDrives:    push    ax              ; at df3 in 1.4
                push    si
-               mov dl, 7fh             ;Start at Drive 0x80
-NextDrv:       inc     dl
+               mov     dl, 0h          ;Start at Drive 0xFF
+NextDrv:       dec     dl
                clc
                mov     ax,4B01h        ;Get Bootable CD-ROM Status
                mov     BYTE [SpecPkt],0        ;Clear 1st byte of SpecPkt
@@ -1044,16 +1044,16 @@
                jb      FindFail
                cmp     BYTE [SpecPkt], 20h
                ja      FindFail        ; in 1.4 at e16
-               jmp     short SendFound ; in 1.4 at e26
+               cmp     dl, [SpecPkt+2]
+               je      SendFound       ; success with CF=0

-FindFail:      cmp     dl, 0ffh
-               je      SendFail                ; Check from 80h..ffh
-               jmp     short NextDrv           ;Next drive
+FindFail:      cmp     dl, 80h         ; Check from 80h..ffh
+               jne     NextDrv         ; Next drive
 SendFail:      xor     dl,dl
                stc
-               jmp     short ThingDone
-SendFound:     mov     dl, [SpecPkt+2]
-               clc
+               ;jmp    short ThingDone ; yes, this jmp can be omitted.
+SendFound:     ;mov    dl, [SpecPkt+2] ; already equal on success
+               ;clc                    ; already cleared CF on success
 ThingDone:     pop     si
                pop     ax
                retn

 

Note: With Grub4dos, you should use the 0xFF drive number for the emulated cdrom drive. Or else the eltorito.sys might fail.

 eltorito.zip   9.41KB   471 downloads

 

 grub4dos_test.zip   302.91KB   428 downloads

 

 grub4dos_r312.diff.zip   1.17KB   400 downloads

 

[Wonko the Sane]

@Ady

Well, instead of the grub4dos floppy, use the actual USB mounted as PhysicalDrive, to load grub4dos.

A plain DOS or freedos booting USB could do if you run grub.exe.

Or use *any* of the availble utilities capable of directly make a USB thingy boot grub4dos.

Or install grldr.mbr to the MBR +hidden sectors of the thingy using bootlace.com, or do any of the several other methods known and actually explained step by step in the grub4dos guide:

http://diddy.boot-la...os/Grub4dos.htm

 

To test grub4dos (and/or experiment with it) you need to boot to it and get to it's command line, one way or the other.

 

The alternative I proposed - which is just an idea/PoC at the moment - is actually simple.

Right now in the UBCD a software solution (grub4dos or memdisk) is used to emulate a .iso as if it was a hardware device in order to be able to use a hardware driver (eltorito.sys or whatever) to make it available to DOS through SHSUCDX.

 

SInce seemingly all that the fdubcd.img needs to do is to load specifically the fdubcd.iso.gz and map  it to T: in DOS, by using directly a software (SHSUCDRD) capable of loading a .iso in memory and making it (the specific image which is all that is needed and intended to be loaded) to SHSUCDX with letter T: we by-pass a step.

The SHSUCDRD version I used seems like not being capable (for whatever reasons) to ungzip the fdubcd.iso.gz but this could be an issue with the specific SHSUCDRD version I used and or with the gzip used to compress the fdubcd.iso to fdubcd.iso.gz, but I am pretty sure this can be overcome.

 

The real "generic" issue is that there is IMHO no actual *need* for fdubcd.iso or fdubcd.iso.gz to exist at all, in the sense that it could be well replaced by a .ima or .img (either superfloppy and partitioned) that both memdisk and grub4dos have support for and need not any extension in DOS.

OR, alternatively since the actual fdubcd.iso.gz is expanded into memory, make just a single .img, or still alternatively, make the fdubcd.iso.gz an isohybrid and have it mounted whatever way one likes.

 

As a side note, and this could be of particular interest for Victor , relatively recently it was found out how there is NOT an actual limit to 2.88 Mb images for El-torito floppy emulation on CD's, the new limit is now 37,748,736 bytes:

http://www.msfn.org/...oppy-emulation/

And as yet another option - making a HD emulation .iso image would also most probably solve each and every problem.

 

In other words, besides what tinybit and chenall will be able (or will want) to do to have grub4dos "more compatible" and "specular" to memdisk for this particular use, getting rid of the .iso container (and thus for the DOS/FREEDOS CD-rom extension) would IMHO make things simpler (and faster when loading). 

 

Wonko

[Sha0]

@Ady

Testing. Test failed. How are you people replying and including quotes that properly include the timestamp? I've been using the Quote button, and it's failing miserably.

[steve6375]

SUCCESS!

 

New ElTorito.sys driver works when booting from UFD!

 

I added the new file to cdsys.cab which was inside fbucd.img (and which was inside fbucd.iso).

I did not put the new modified fbucd.img back into fbucd.iso, but just had fbucd.img as a flat file on my USB drive.

 

So I have a flat file USB UFD and I am booting from the UFD using QEMU.

 

First I extracted the original fbucd.img and tried the menus below and they all failed under QEMU as expected.

Then I replaced fbucd.img with a new version which had the new ElTorito.sys driver in it.

 

The following menu items in main.lst ALL WORK (under QEMU and real system).

I did not need to select any cdrom driver manually, the default choices just worked without any interference from me.

Note that memory mapping is not needed if you don't use a .gz file (menu 5) and so is quicker to boot.

 

title test 1 - WORKS
map --mem (bd)/ubcd/images/fdubcd.iso.gz (hd96)
map --mem /ubcd/images/fdubcd.img (fd0)
map --hook
root (fd0)
chainloader +1


title test 2 - WORKS
map --mem (bd)/ubcd/images/fdubcd.iso.gz (0xff)
map --mem /ubcd/images/fdubcd.img (fd0)
map --hook
root (fd0)
chainloader +1


title test 3 - WORKS
map --mem (bd)/ubcd/images/fdubcd.iso.gz (hd32)
map --mem /ubcd/images/fdubcd.img (fd0)
map --hook
root (fd0)
chainloader +1


title test 4 - WORKS
map --mem (bd)/ubcd/images/fdubcd.iso.gz (0xe0)
map --mem /ubcd/images/fdubcd.img (fd0)
map --hook
root (fd0)
chainloader +1


title test 5 - WORKS
map (bd)/ubcd/images/fdubcd.iso (hd32)
map /ubcd/images/fdubcd.img (fd0)
map --hook
root (fd0)
chainloader +1

 

[Sha0]

SUCCESS!

 

New ElTorito.sys driver works when booting from UFD!

 

I find this disappointing.

 

The goal of having a work-around means that bugs are less likely to be reported.  That is the wrong goal.  The goal should have been to ensure that using GRUB4DOS works, period.

 

tinybit was the influence behind the decision for ElTorito.sys to scan upward, and now tinybit offers an opposite preference and an eltorito.sys that scans downward.  Nobody will remember the original rationale, this modified eltorito.sys will be incorporated into FreeDOS (or at least FDUBCD), and then systems where scanning 0xFF breaks everything will be broken again, then the cycle will start all over.  I wonder if the originally-working MEMDISK method still works...

[steve6375]

grub4dos does work and so does the old ElTorito.sy driver (on real h/w) - it just does not work on an emulator/VM.

 

Doesn't this mean that it is a problem with emulators/VMs (probably the int 13h BIOS?) - or at least can we determine why real h/w works but emulators/VMs don't and why the new ElTorito.sys works for any device number?

 

tinybit said about the ElTorito.sys code:

 

It should firstly compare [SpecPkt+2] with DL, if not equal, it should fail out. At least one BIOS has etdump output as follows:

 

 

Maybe this is what fixed it and we can go back to the original search order?

 

[Edit] or maybe the search order is irrelevant as the real bug was not comparing the device number in the packet with DL?[/Edit]

 

[ady]

@Ady
Well, instead of the grub4dos floppy, use the actual USB mounted as PhysicalDrive, to load grub4dos.
A plain DOS or freedos booting USB could do if you run grub.exe.
Or use *any* of the availble utilities capable of directly make a USB thingy boot grub4dos.
Or install grldr.mbr to the MBR +hidden sectors of the thingy using bootlace.com, or do any of the several other methods known and actually explained step by step in the grub4dos guide:
http://diddy.boot-la...os/Grub4dos.htm
 
To test grub4dos (and/or experiment with it) you need to boot to it and get to it's command line, one way or the other.
 
The alternative I proposed - which is just an idea/PoC at the moment - is actually simple.
Right now in the UBCD a software solution (grub4dos or memdisk) is used to emulate a .iso as if it was a hardware device in order to be able to use a hardware driver (eltorito.sys or whatever) to make it available to DOS through SHSUCDX.
 
SInce seemingly all that the fdubcd.img needs to do is to load specifically the fdubcd.iso.gz and map  it to T: in DOS, by using directly a software (SHSUCDRD) capable of loading a .iso in memory and making it (the specific image which is all that is needed and intended to be loaded) to SHSUCDX with letter T: we by-pass a step.
The SHSUCDRD version I used seems like not being capable (for whatever reasons) to ungzip the fdubcd.iso.gz but this could be an issue with the specific SHSUCDRD version I used and or with the gzip used to compress the fdubcd.iso to fdubcd.iso.gz, but I am pretty sure this can be overcome.

@Wonko, thank you. Since I have currently very little knowledge about grub4dos (while I can manage syslinux not so bad), it seems to me that other users and UBCD testers might be able to test and find workarounds and solutions for this specific issue much effectively than myself. Until now I am blindly copying grub4dos code I've seen and just trying it. I shall really learn it; otherwise I am not being effective in my attempts to improve fdubcd. It may take me some time, but I'll get there.
 
 

 
The real "generic" issue is that there is IMHO no actual *need* for fdubcd.iso or fdubcd.iso.gz to exist at all, in the sense that it could be well replaced by a .ima or .img (either superfloppy and partitioned) that both memdisk and grub4dos have support for and need not any extension in DOS.
OR, alternatively since the actual fdubcd.iso.gz is expanded into memory, make just a single .img, or still alternatively, make the fdubcd.iso.gz an isohybrid and have it mounted whatever way one likes.
 
As a side note, and this could be of particular interest for Victor , relatively recently it was found out how there is NOT an actual limit to 2.88 Mb images for El-torito floppy emulation on CD's, the new limit is now 37,748,736 bytes:
http://www.msfn.org/...oppy-emulation/
And as yet another option - making a HD emulation .iso image would also most probably solve each and every problem.
 
In other words, besides what tinybit and chenall will be able (or will want) to do to have grub4dos "more compatible" and "specular" to memdisk for this particular use, getting rid of the .iso container (and thus for the DOS/FREEDOS CD-rom extension) would IMHO make things simpler (and faster when loading). 

@Wonko, to be clear, there *is* an advantage of "booting" fdubcd.iso with fdubcd.img inside it. Let me explain.

If all the cab files were located directly in the UBCD boot media (no fdubcd.iso), then the fdubcd.img floppy image, once booted into DOS, would need to have access to the original boot media (the CD where UBCD was burnt, or the UFD were the files reside, or wherever else the cab can be found). This method might require DOS drivers and relevant DOS scripts so to support "any and all" such possible media.

Here is where an additional ramdisk solves the problem. By the time fdubcd DOS boots, the content of fdubcd.iso is seen as one ramdrive in DOS, and the fdubcd.img floppy image is the "A:" drive from where fdubcd DOS was booted. The local HDD are still available, with the same drive letter assignments as any DOS/Windows would do. If the user only needs the DOS programs already included in fdubcd.iso, the content of the original boot media doesn't matter and all the DOS programs are accessed from this ramdrive.

The other alternatives you mentioned, a superfloppy or a hdd, have their own negative effects. Among other effects, both need more space (bytes) than the iso image. The superfloppy ramdrive as "A:" is less compatible with BIOSes than the no_emulation ISO image method (or at least this is my understanding), and the HDD method needs even more space and also shifts the assignment of drive letters.

Besides the issue of grub4dos in this topic, and independently of using fdubcd.iso or a different method to access the cab files, I still would like to find a way to access the optical drives from within fdubcd DOS, at least for simple PATA and SATA optical drives.

Incidentally, leaving the current grub4dos entries as in UBCD 5.1.1, actually gives this option. When the user boots fdubcd by means of memdisk, then fdubcd.iso can be accessed but the additional cd drives can't. And, when using the grub4dos method, the original boot media can be accessed but the content of fdubcd.iso can't. The goal should be to be able to have access to all of those drives (whether ramdrives or cd drives) when booting fdubcd with memdisk or when booting it with grub4dos.

[Sha0]

grub4dos does work and so does the old ElTorito.sy driver (on real h/w) - it just does not work on an emulator/VM.

 

Doesn't this mean that it is a problem with emulators/VMs (probably the int 13h BIOS?) - or at least can we determine why real h/w works but emulators/VMs don't and why the new ElTorito.sys works for any device number?

 

tinybit said about the ElTorito.sys code:

 

 

 

Maybe this is what fixed it and we can go back to the original search order?

 

Thanks to the bloody forum software, I can't split your quote and respond to the different points.  Pretty frustrating!

 

tinybit's change to the search order means that the modified ElTorito.sys will break on some real hardware, without GRUB4DOS' INT 0x13 hook being present and furthermore without having the desired virtual disc having number 0xFF.  Having eltorito.sys rely on the presence of GRUB4DOS and the user using 0xFF does not strike me as an acceptable change.  tinybit was the original reporter of such broken hardware systems, so hopefully tinybit will understand this point.

 

Since the actual cause of the problem hasn't yet been described in great detail, I don't yet have an offer of "a good" solution, but I can only offer the opinion of "a bad" solution, above.   (I still have yet to reproduce the problem.)

[steve6375]

You don't have to use 0xff - see my example test menus.

 

maybe tinybit could upload another version of ElTorito.sys that has the original search order but includes the DL check. I will test it and see if that fixes it or not.

If it does fix it then we can keep the original search order and everyone will be happy?

[ady]

Since the actual cause of the problem hasn't yet been described in great detail, I don't yet have an offer of "a good" solution, but I can only offer the opinion of "a bad" solution, above.   (I still have yet to reproduce the problem.)

@Sha0, let me try again to describe the OP, at least with the most basic details (as the problem was originally reported by several different users, on different systems).

1_ Boot UBCD 5.1.1.
2_ Select the grub4dos menu.
3_ Select fdubcd DOS.
4_ The default boot is "silent". During this topic, other alternatives for more advanced configurations were mentioned, but the problem can be reproduced with the default "silent" selection. So let it get to the fdubcd menu (with "Launch", "Browse", "About"...).
5_ Select "Browse" so to use Volkov Commander. In VC, drive "T:" shows the content of the original boot media. The problem: drive "T:" needs to be the content of fdubcd.iso (as it happens when booting from the syslinux/isolinux menu, which uses memdisk).
6_ Exit VC and type "ubcd" in the DOS prompt if necessary. In the fdubcd menu, use "Launch" to try to use any program. Since drive "T:" is not what is needed, no DOS program can be executed.

The specific (real) hardware or the virtual software might influence, so to be able to trigger the problem, but the above steps are, basically, what has been reported.

[Sha0]

You don't have to use 0xff - see my example test menus.

 

maybe tinybit could upload another version of ElTorito.sys that has the original search order but includes the DL check. I will test it and see if that fixes it or not.

If it does fix it then we can keep the original search order and everyone will be happy?

You do have to use 0xFF, because I am not talking about your hardware, I'm talking about real hardware that tinybit (and others) have reported where probing 0xFF is problematic.  If your hardware works, then it is not one of those problematic systems.

 

I'll only be happy when I can explain what the cause for the problem is in this thread.

[tinybit]

maybe tinybit could upload another version of ElTorito.sys that has the original search order but includes the DL check.

 

No. I will not upload another version of ElTorito.sys scanning upward.

 

I guess this version will solve all problems. If it were not, then I will trace any bug reports and give fixes for each.

 

This build of eltorito.sys can be considered as a branch of mine. Syslinux developers do not have to be responsible for this build of eltorito.sys.

 

tinybit's change to the search order means that the modified ElTorito.sys will break on some real hardware,

 

Don't worry. It is only my build. Just can be considered a workaround. Anyone can use it or not use it freely. Everyone can make the decision of his own will.

[steve6375]

@ady - Boot UBCD 511 how? From an ISO under a VM? From a real CD? From a USB drive as an ISO file using grub4dos? Please clarify...

 

@Sha0 - I guess that the root cause of the problem was probably that the old ElTorito.sys code was not testing the device number in the packet buffer against DL. The search order is (and was) actually irrelevant. The crashing problem just seemed to be fixed by changing the search order because the device number was never double-checked against the data returned by the BIOS. So it was the 'bug' in the ElTorito.sys (probably a mixture of a bad BIOS + bad ElTorito code) that was the real problem and the new version will actually work on even the 'buggy' hardware that originally showed the problem, because tinybit now double-checks that the right device is found.

 

see post http://reboot.pro/to...e-2#entry164705

 

FF: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
FE: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
..
9F: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
..
81: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
80: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7

 

So entry 9f:  has 9F as the 3rd byte (the device number) and is the only legal entry.

the other entries are not 'legal' as the device number of all of the entries have 9F in them! Also the carry flag is 0 for all of them and the packet size is 13h for all of them.

This means the old ElTorito.sys driver would think they were all legal!

(I think this is what is happening???).

 

By checking the 3rd byte to match the device number, we make sure that we find the correct device (if one exists).

 

 

[tinybit]

You don't have to use 0xff - see my example test menus.

 

 

But one have to use 0xff for maximum compatibility with various BIOSes. The scan must be downward, or else 0xff will not be the first one encountered and another real or emulated cdrom drive would hit.

 

There should be no problems with memdisk, because memdisk has disabled all the rest of real or emulated CDROMs.

[ady]

I'll only be happy when I can explain what the cause for the problem is in this thread.

Unfortunately, my very limited knowledge of grub4dos doesn't allow me to understand what "should" happen, what is the expected "correct" behavior according to each command. If I knew what exactly to expect, I would be able to compare it with what actually happens in each case (different booting media, real systems, VMs...), and eventually report if there is an error or ask for help. But since I don't have the knowledge, I don't even know if the commands are correct, if what I see is the expected behavior, or if I am simply using the wrong commands.

For example, I have absolutely no idea what's the difference between the several working menu entries that Steve presented, which one is more adequate for each case and so on. I can partially guess only some of the symbols/characters, but that's just a very general guess, not knowledge nor real understanding.

I started this topic in spite of my lack of knowledge about grub4dos, because other UBCD users have reported the problem, was replicated by Victor, and not even one user was able to come up with an adequate grub4dos entry (including Victor).

@Sha0, BTW, using "multiple quotes" even for quoting just one post, and using "BBcode edit mode" might help you in your posts.

[ady]

@ady - Boot UBCD 511 how? From an ISO under a VM? From a real CD? From a USB drive as an ISO file using grub4dos? Please clarify...

@Steve, as I already said, I am almost blind regarding this topic. Currently, I am testing with VBox, booting a PIIX3 VM with ubcd511.iso as a PATA primary slave optical drive, with one PATA primary master fixed VHD, one additional secondary master optical drive (with some other iso image so to simulate the presence of an additional optical drive) and one floppy image (to simulate a 1440KiB floppy). This is just one testing method. I have also a UBCD fixed VHD booting as PATA primary master. I also test SATA, and also real optical drives and UFDs. There where reports replicating the problem from real UFD (at least that's how it was reported), and other users test with qemu and with VMware (including Victor).

Unfortunately I am currently _very_ limited regarding real hardware. Since other users (and Victor) are able to test this issue, and my knowledge of grub4dos is very limited too, I am hoping other users / forum members can also help with tests and reports. Please rest assured that I am not presenting this topic for my personal gain, but for the improvement of the next release of UBCD. The reason _I_ started this topic here is just because others (more knowledgeable and capable) gave up searching for an adequate solution.

I really appreciate all the input, ideas, help, test, advice, feedback. Hopefully Victor will find the most adequate answer here. Please keep the comments coming.

Edited by ady, 22 December 2012 - 01:51 AM.

[Sha0]

There should be no problems with memdisk, because memdisk has disabled all the rest of real or emulated CDROMs.

No, it hasn't.  I do not see any parameters that would cause MEMDISK to do that.  But besides that, you are forgetting the case where there is no GRUB4DOS INT 0x13 (or any other) hook involved.  That means that the BIOS' INT 0x13 will be probed for 0xFF with your downward scan.  Problem!   So if your modified ElTorito.sys is incorporated into the next release of FDUBCD and GRUB4DOS isn't involved at all and the user boots the burned CD on problem hardware, it is broken whereas today it is not.

[Victor Chew]

I probably won't be incorporating the modified eltorito.sys, given that the BIOS INT 0x13/0xFF bug is well reported in the syslinux mailing list. Even if eltorito.sys compares [SpecPkt+2], with the old scan order, it will still pick up 0x9F (i.e. the physical CDROM drive) first. The main reason why it works in this case is because the scan order is reversed.

 

Note that this behaviour has been observed when booting from _CDROM_ under real machines (Dell Inspirion 1501 and HP D630) as well, not just emulators.

 

The reason why FDUBCD is embedded in another ISO is because it is not always able to mount the physical CDROM (containing DOSAPPS) via eltorito.sys due to incompatible/buggy hardware. You can search the UBCD forums for many such reports. So instead we make it mount a virtual CDROM, which leads to this unexpected problem.

 

I have explored the large floppy image route, but there are a few reports that certain buggy BIOSes may not happy with them.

 

So currently, for the next release of UBCD, I am using a 50MB HDD image, which seems to be the most compatible way of getting lots of virtual disk space under DOS. This has one minor problem: the shifting of drive letters (since the HDD image becomes C:, your physical HDDs become D:, E: etc).

[Sha0]

The above code has another issue. Look at this:

 

SendFound:	mov	dl, [SpecPkt+2]
		clc
ThingDone:	pop	si
		pop	ax
		retn

It should firstly compare [SpecPkt+2] with DL, if not equal, it should fail out. At least one BIOS has etdump output as follows:

 

FF: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
FE: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
..
9F: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
..
81: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
80: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7

 

In the above output, only the line for drive 9F is correct. All the others are meaningless.

After reviewing, I don't believe this is an issue for ElTorito.sys.  I have several reasons outlined, below:

1. In the El Torito specification 1.0 (1995), the strategy for floppy emulation and HDD emulation is to shift up the pre-existing drive numbers and to inject the El Torito disk before those pre-existing drive numbers.  This is another reason why it makes sense to scan upward instead of downward.  You will get the last-booted El Torito floppy or HDD.  This has been the case for close to 17 years.
2. For no-emulation mode, it is completely up to the BIOS (or hook) as to which drive number is used, as long as it's >= 0x81.  In EDD-4, it is suggested to use 0xA0 or anything else > 0x9A (26 drive letters starting from 0x80, though they forgot that A: and B: floppies would be < 0x80).
   
   This allowance creates a challenge: If you want to know the last-booted El Torito drive number, how do you do it?  Is there a special invocation?  Do you scan downward or upward?
   
   Reading the 1995 specification, one might guess that requesting the status for drive 0x7F would return the last-booted El Torito drive number.  Reading EDD-4, it explicitly states that simply requesting status is expected to return the last-booted drive number, with no mention of DL anywhere in sight.  That means that compliance with EDD-4 requires returning the last-booted drive number regardless of the user's DL query.  However, eltorito.sys has to deal with other [non-EDD-4] cases, which one reason for why it performs a scan.
3. Since probing 0xFF is buggy on some BIOSes, eltorito.sys prefers to scan upward.
4. Since the general strategy of injecting the El Torito drive number and shifting the conflicting drive number up can be adopted (for consistency) for no-emulation mode, then a pre-existing 0xA0 can be shifted to 0xA1 and a upward scan is preferred for this reason, too.
5. When eltorito.sys gets a valid status, it doesn't care about further probing, since it now has the EDD-4 answer, and at least a valid answer for a booted (but maybe not last-booted) El Torito disc.

I propose that GRUB4DOS' INT 0x13 hook should comply with EDD-4 and unconditionally return an expected drive number for the El Torito status query.

1. If GRUB4DOS established any virtual optical discs, this could be the first one in the drive mapping table, or
2. If the root or chainloader commands were used, it could be whichever drive number was involved

Suggested benefits:

1. eltorito.sys does not need to be changed and continues to work on BIOSes where probing 0xFF is problematic
2. eltorito.sys does not need to rely on downward or upward probe order when talking with GRUB4DOS' hook, as the very first response from G4D will give the answer
3. GRUB4DOS can put a shiny star sticker beside EDD-4's 8.27

Suggested disadvantages:

• The time taken to code the changes

Meanwhile, I haven't quite yet reproduced the problem, but given that tinybit's modified eltorito.sys appears to work for steve6375's tests, I would wonder if the following GRUB4DOS command-sequence would work:

map --mem /fdubcd.iso (0xA0)
map (cd) (0xA1)
map --hook
root (0xA0)
map --mem /fdubcd.img (0x00)
map (0x00) (0x01)
map --rehook
map --status
root (0x00)
chainloader +1
boot

[Sha0]

The reason why FDUBCD is embedded in another ISO is because it is not always able to mount the physical CDROM (containing DOSAPPS) via eltorito.sys due to incompatible/buggy hardware. You can search the UBCD forums for many such reports. So instead we make it mount a virtual CDROM, which leads to this unexpected problem.

With an apology for being off-topic, I'd suggest that buggy hardware might be worth reporting, in case work-arounds (for the hardware, where we have no control) can be developed.

[steve6375]

Mapping as (cd) works as reported earlier, but when booting from UFD there is no (cd) and so the grub4dos command fails (as reported earlier).

 

I tried the menu below and it did not work

title Sha0's test
map  /ubcd/images/fdubcd.iso (0xA0)
map  /ubcd/images/fdubcd.iso (0xA1)
map  /ubcd/images/fdubcd.iso (0xA2)
#map (cd) (0xA1)
map --hook
root (0xA0)
map /fdubcd.img (0x00)
map (0x00) (0x01)
map --rehook
map --status
root (0x00)
chainloader +1

 

 

[Wonko the Sane]

The other alternatives you mentioned, a superfloppy or a hdd, have their own negative effects. Among other effects, both need more space (bytes) than the iso image. The superfloppy ramdrive as "A:" is less compatible with BIOSes than the no_emulation ISO image method (or at least this is my understanding), and the HDD method needs even more space and also shifts the assignment of drive letters.

Besides the issue of grub4dos in this topic, and independently of using fdubcd.iso or a different method to access the cab files, I still would like to find a way to access the optical drives from within fdubcd DOS, at least for simple PATA and SATA optical drives.

Incidentally, leaving the current grub4dos entries as in UBCD 5.1.1, actually gives this option. When the user boots fdubcd by means of memdisk, then fdubcd.iso can be accessed but the additional cd drives can't. And, when using the grub4dos method, the original boot media can be accessed but the content of fdubcd.iso can't. The goal should be to be able to have access to all of those drives (whether ramdrives or cd drives) when booting fdubcd with memdisk or when booting it with grub4dos.

Well, no.
A container is a container.
A FAT image won't be in any way (or not "sensibly") bigger than a .iso.
The currrent choice of .iso as a container is IMHO not smart, not because of itself, but because DOS/FreeDOS need an extender (and an external driver) to access it.
The CD-ROM container gets letter T:, the .img could take letter T: as well.
Which does not mean that both the memdisk and grub4dos should work on each and every possible "real" and "virtual" hardware without problems, it simply means that there are IMHO simpler, safer methods to get the same result.
I will repeat how  having a software to make appear an image as an hardware device in order to use an extension and a driver for a hardware device is more complex than needed.
 
 
 

I have explored the large floppy image route, but there are a few reports that certain buggy BIOSes may not happy with them.
 
So currently, for the next release of UBCD, I am using a 50MB HDD image, which seems to be the most compatible way of getting lots of virtual disk space under DOS. This has one minor problem: the shifting of drive letters (since the HDD image becomes C:, your physical HDDs become D:, E: etc).

 
Maybe there are ways to modify not the drive lettering scheme.
First one that comes to mind is to have inside the "external" UBCD5xx.iso both a floppy image and a hard disk image.
Or make the actual UBCD5xx.iso directly an El-Torito floppy emulation image.
I have personally never seen a single BIOS not compatible with an El-Torito Floppy Emulation image, while I have seen a few very old ones choking on No-Emulation images.
The floppy image will get A: normally, then all the real hardware drives will be enumerated, and then you mount the HD image which will get a "later" letter.
Would letter assigner work for Freedos?
http://www.msfn.org/...post__p__826574
 

Wonko

[steve6375]

@tinybit

I was experimenting with the debug command in grub4dos (Dec 2012 version) to see how grub4dos mapped iso's and got a strange result...

debug 2
echo 1a
map  /ubcd/images/fdubcd.iso (0xA1)
echo 1b
map --hook
echo 1c
root (0xA1)
echo 1d
map /fdubcd.img (0x00)
echo 1e
map --status
echo 1f && pause

 

 

 

 

Can you explain the line circled in red in attached jog screenshot? Why is it reporting A1 as FAT12??

 

Attached Thumbnails

• 

[tinybit]

@everyone

 

I am responsible for this build of eltorito.sys attached above.

 

Any bug reports are welcome.

 

Sorry but I have no time and interest to just talk about the whole thing.

 

If there are no bug reports, I will not reply any more.

 

And say sorry again because I cannot speak English fluently. In fact, quite difficult. I cannot use English to talk too much.

 

 

[tinybit]

@steve6375

 

Can you post it in a new thread? I think it is somewhat off topic.

 

And I cannot see your JPG picture. Maybe the site has a traffic problem.