Good day to all.
Since we've adopted Gary Tong's and Bart Lagerweij's ElTorito.sys
(now
modified by H. Peter Anvin and tiny changes from myself), I'd appreciate
if anyone with more El Torito experience might criticize my comments
below and advise as to how they might be wrong. Some of it is off-topic
GRUB4DOS detail; safe to ignore.
A bit of history: FDUBCD ("FreeDOS Universal Boot Compact Disc", I
should think) was reported to work with MEMDISK, but not with GRUB4DOS'
RAM disk logic. A modified eltorito.sys was offered by a GRUB4DOS
developer and appeared to resolve the issue. I'm not so sure it's the
best fix, though.
The comments can be found in their original glory, here:
http://reboot.pro/topic/17911-access-fdubcdiso-content-from-grub4dos/page-3#entry164754
The G4D developer's patch for eltorito.sys can be found at the top of
that page, in post #51.
- Shao Miller
--- Comments ---
tinybit (GRUB4DOS developer) typed:
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.
I responded:
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:
eltorito.sys does not need to be changed and continues to work on
BIOSes where probing 0xFF is problematic
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