China DOS Union

> Since there is no BCDL source code and no detailed documentation explaining its working principles, it is indeed impossible to say whether what BCDL expects is "soft" or "hard."

It wants to boot a real CD-ROM drive, and assuming it cannot use the BIOS's own CD-ROM boot routine, then it probably has only this one way: using the ATAPI hardware IO standard to implement it. It is not impossible that it also implements a soft method at the same time, but that possibility is too small. If it had implemented a soft method, then it should by the way also have implemented booting from ISO files. Or rather, the purpose of implementing a soft method would precisely be to implement booting from ISO files.

> However, if GRUB writes a patch for BIOS, although it may achieve some very beautiful functions, since BIOS CD read functions originally have no standard, can this GRUB patch really be made universal? Also, what if the BIOS itself does not support CD booting in the first place (for example, one of my computers is like that)?

If GRUB makes a patch, then of course it will be GRUB's own calling method (placed into int 13h), different from everyone else's; and since nobody else's has ever appeared, it is impossible for anyone to be the same as it. Since it is GRUB's own, then of course it is unified. As long as you use GRUB, there will be this unified patch. If you do not use GRUB, then of course there is none.

GRUB's patch is meant to find the CD sector functions inside BIOS. These functions may not appear in the form of ints. The intention of the GRUB patch is to wrap these functions into int 13h. If some motherboard encrypts this (not very likely), then we may be unable to find this function, and in that case we will naturally give up support for this type of motherboard. My machine has an ASUS motherboard; it seems this function is relatively easy to find. There are already some clues now, I just have not had time to do it.

If the BIOS itself does not support it, then of course there is no such function. In that case we give up support for that motherboard.

There is also such a clear hint in GNU GRUB's TODO list: BIOS itself must support CD booting. It seems the GNU GRUB developers are also thinking this way, and their line of thought may be the same as ours.

When, as described above, some motherboard cannot be supported, we mean it does not support booting from a real CD-ROM drive. Booting from an ISO file is completely supported, and this has nothing to do with whether BIOS supports CD booting. An ISO file is soft and uses the "bootable CDROM standard."

If you want to support booting from real CD-ROM drives on those motherboards, you can choose SBM or BCDL. Both are beautiful pieces of software. GRUB cannot replace them.

I discovered in the last few days that the latest 3.0 version of BCDL has also been released, and it has clearly expanded its own flexibility. Specifically, it automatically looks for the following files under C:\:

VIDE-CDD.SYS (IDE/ATAPI CD-ROM driver)
USB_CD.SYS (USB CD-ROM driver)
USBASPI.SYS + ASPICD.SYS (USB CD-ROM driver)
ASPI2/4/7/8DOS.SYS + ASPICD.SYS (SCSI/ASPI CD-ROM driver)
and so on...

So it can be seen that BCDL.BIN does not lock the driver to IDE/ATAPI CD-ROM drives by hardware methods, but instead implements booting for the corresponding CD-ROM drives by piecing together various types of CD-ROM drivers from all over the Internet (such as SCSI, USB, etc.). Maybe someday BCDL really will implement booting ISO files through SHSUCDHD?

Those CD-ROM drive drivers should all be using the ATAPI hardware standard. Implementing booting from ISO files is not difficult. Even if there were no BCDL or SBM and the like, one could still start from scratch and write an ISO boot program using the bootable CDROM standard. Booting CDROM requires both of the above standards at the same time.

Of course GRUB can also add support for the ATAPI standard and thus boot CDROM. But the cost of doing that is that the code would grow to an unacceptable size. And that is the smaller matter; more importantly, maybe nobody will write it. Even porting SBM's program over would be quite difficult.

Our current GRUB emulation program is only 1K of code. In the future, after adding support for CDROM and ISO, it is estimated it will grow to 2K or even 3K (speaking only of the int13 handler itself).

If the CD-ROM booting is implemented with the ATAPI standard, then the CDROM boot program in BIOS cannot be effectively utilized, which is also a kind of loss.

If the int13 interface for CDROM is implemented, then under DOS we would not need any driver programs at all; we could freely access sectors on the CD just by using int13 as we do with hard disks. This is a very revolutionary advantage that can never be obtained by the ATAPI hardware method.

In essence, the ATAPI method only has value for old BIOSes . I think supporting old BIOSes and old CPUs such as the 286 is not very meaningful.

－－－－－－－－－－－

Let me add something. I seem to have seen someone say that on certain motherboards with SCSI CD-ROM drives, the motherboard itself can treat the CD-ROM drive as a hard disk, implementing it as a BIOS hard disk number such as 0x83. In the BIOS setup program, you can set whether to treat the CD-ROM drive as a hard disk.

Perhaps before long, IDE CD-ROM drives will do this too. If that really happens, it would be very convenient, and then we would not need to HACK anymore. Refreshing BIOS is very convenient now. Maybe we should wait rather than rush to write something. What I fear most is doing useless work.

Someone has written a BIOS optimization program used for flashing BIOS. Maybe we can wait for him to write a new program and add the CDROM patch into it. Wouldn't that save effort? If that really happens, then all that would remain for us is to write the program for booting from ISO files. So perhaps we should only do the ISO-file part, and that way our work would not be wasted.

Is it possible to get in touch with the author of bcdl?

> Is it possible to get in touch with the author of bcdl?

It should be possible. I am not good at this; I do not know whether wengier can.

Once you have hardware drivers, adding software drivers is comparatively easy. But starting from software drivers and then making hardware drivers is comparatively hard.

What I mean is that the author of BCDL or SBM can comparatively easily add support for ISO emulation, while it is not easy for others to add support for CDROM hardware. Hardware specifications are hard to understand, while software standards are somewhat easier to understand.

Actually, my personal guess is that BCDL does not stay resident in memory. It first acts as a provider of DOS system functions, and then loads the CD-ROM driver; at that point, this sys already provides a tiny atapi driver; then those system services are no longer needed; at that point, the CD can be accessed using a drive number just as when booting from a CD-ROM through BIOS.

Actually, personally I feel that even if support for ISO-file virtual CD-ROMs were added, its significance would not be great, for the following reasons:
There are three boot modes for CDs: emulated floppy boot, emulated hard disk boot, and no-emulation boot.
For the first two emulation boots, grub can already support them, so you only need to extract the image inside the CD.
As for ISO files in no-emulation boot mode, what is seen now in practice is only 2k/xp/pe series CDs. Even if CD-ROM boot emulation were possible, it would still only be BIOS-based emulation, while 2k/xp/pe are not BIOS-based systems. So even if the emulation succeeded, it could only complete the boot process and could not complete entering the operating system. This is just like how under 2k/xp/pe you cannot access the floppy drive emulated by grub; by the same logic, the hard disk and CD-ROM emulated by grub also cannot enter winpe. But judging from bcdl's boot principle, one may still draw lessons from it, and it may be possible (?) to use a similar principle to boot a USB drive on motherboards that do not support USB booting.

Then can the current version simulate an ISO image now, and install directly in DOS, without needing to unpack the image before installation?

Right now it cannot emulate ISO, but you can do this: extract the boot image from the ISO first, boot with a virtual floppy drive, then load a virtual CD-ROM program under DOS, and then start installation from the ISO. Perhaps the moderator could be asked to make it into an img+iso for greater convenience, with the step of loading the virtual CD-ROM and the ISO file completed inside the img.

Moderator, how can I use a virtual machine? Because I can't install MS-DOS7.10, so I want to use a virtual machine to play with it. Moderator, please help~~~

Modifying programs written by others is painful. Recently I have been looking at modules such as edd30 and myint13h, and found quite a few errors in them. At the same time I also feel it is very hard to fully grasp their programming ideas. The DOC is very incomplete.

Now I have started thinking again of my old viewpoint: HACK BIOS and directly find the CDROM sector functions. Although that is also difficult, at least it is written by myself, and I can definitely understand it myself.

I will first HACK the BIOS on my own machine. After succeeding and accumulating experience, I will then HACK the BIOS on the office machine. And I will make the HACK method public, so that others can also HACK in a similar way. In the ideal case, all BIOSes can be supported.

Having source code is not necessarily easier than not having source code. The BIOS on my ASUS motherboard is very clear even when using DEBUG, but programs like edd30 and myint13 look too messy and too bloated.

Useful~~~