China DOS Union

Does your floppy disk not have a partition table? Then why did you mention MBR above? If there is no partition table on the floppy disk, its first sector should not be called MBR, but DBR.

As for which software needs the full functions of int13, I haven't studied it either. I don't know which function has a problem in your this BIOS. You can study the int13 specification by yourself and check which part of your this BIOS has an error. However, this check is relatively cumbersome. Generally speaking, assembly language is needed.

If there is no problem with the int13 of your BIOS, you can't explain the problem that grub can't recognize (fd0) normally. Grub identifies the disk number, which is only related to int 13, and has nothing to do with others. There can't be a BUG in grub here (if there is, it would have been discovered and solved by people 10 years ago, because this is all too basic, all are basic int13 calls, strictly in accordance with the specification).

As long as you enter the OS, the USB flash drive will be simulated as a certain storage device. For example, under win2000, the entire USB flash drive looks like a hard disk, which can be partitioned and formatted. Under linux, it will be simulated as a SCSI device sda, and it is operated the same as a hard disk. In both of these OSes, the partition table on sector 0 of the USB flash drive will be recognized by the system. So I partitioned the USB flash drive into one partition under win2000. Now, because I am booting with the USB-ZIP mode, the motherboard BIOS will only read from sector 32 (DBR) and will not pay attention to the partition table in sector 0 (MBR)! I once made a DOS boot disk and cleared all the partition tables in sector 0 of the USB flash drive. At this time, under win2000, it will think that this USB flash drive has no partitions and is not formatted, but it is successfully booted into the system with the USB-ZIP method, and the data in the disk can still be accessed normally. That is to say, the motherboard BIOS treats this 128M USB flash drive completely as a large-capacity floppy disk and will not pay attention to the partition table in sector 0 of the USB flash drive. I can't figure out that for an ordinary 1.44m floppy disk, it has no concept of a partition table at all. If I map (fd0) (hd?), then where does the partition table on hd? come from? Now the situation is that under the grub prompt, root (+TAB, fd0 comes out, it should be said that grub also treats the USB flash drive as a floppy disk, and the DOS boot disk also finally comes out a:, which shows that the two have the same recognition of the USB flash drive (does it also show that the identification function of the USB flash drive in int 13 is correct? If grub does not correctly recognize the USB flash drive, will fd0 appear in root (+TAB? Can I set grldr to display all the information during execution on the screen or save it in a file?)? Next is the access to the files on the USB flash drive, DOS is normal. And the GRUB boot code in DBR can find grldr on the USB flash drive and load it, which also seems to show that the function of reading and writing sectors is normal. In addition, my BIOS is AWARD 6.0PG, many motherboards use this BIOS, and it has been around for a long time. If there is a problem with int 13, it should have been discovered long ago. I think a possible place is the understanding of fd0 by grldr. If grldr calls int 13 and finds that the USB flash drive is fd0, it may use two methods to locate the positions of FAT, root directory and data area. One is more general, obtaining parameters from the BPB of DBR and calculating, and the other is that grldr thinks fd0 is a pure floppy disk, and the positions of FAT, root directory and data area are fixed, and it directly finds according to the fixed positions in the code. In addition, I would like to ask BuDian DX, generally how the code in DBR finds the file it wants, for example, how the grub boot code finds grldr, and how the DOS boot code finds those 3 boot files?

> What I can't figure out is: For an ordinary 1.44m floppy disk, it doesn't have the concept of a partition table at all. If I do map (fd0) (hd?), then where does the partition table on hd? come from?

You've mentioned this question many times, and I may not be able to answer it well, but I'll do my best :-)

Floppy disks have no partitions, while hard disks have partitions. This is actually a historical legacy issue. Historically, because floppy disks were small, they were made into a single file system to avoid the MBR occupying excessive space. (At that time, space was very tight; even FAT only used 12 bits, that is, "one and a half" bytes, showing how tight space was.) Since hard disks have large capacities, they are divided into different file system areas, which are called partitions. Was the partition created by Microsoft? Or was there already a standard before Microsoft? I'm not sure. But one thing is clear: this has formed a de facto industrial standard: floppy disks have no partitions, hard disks have partitions, and the partition format is well-known and completely open.

On the other hand, logically, both floppy disks and hard disks are BIOS disk numbers and have a unified BIOS interface. The BIOS doesn't know about partitions on hard disks; it handles hard disks and floppy disks in exactly the same way. Partitions are recognized and interpreted by the operating system, and the BIOS is unaware of these. Therefore, logically, floppy disks can indeed have partitions; the key is that as long as the operating system can recognize them.

However, your BIOS skips the first sector of the USB flash drive and directly uses the DBR to boot, which violates the previous de facto industrial standard. (I don't know if there are other standards that allow the BIOS to boot from the DBR. If I'm wrong, please let those who know correct me.)

Anyway, it's a plus that your BIOS can boot from the USB flash drive. It's trying to find a balance between the old standard and new practical applications. The old standard says that floppy disks can't have partitions; the new application is that it wants to treat a USB flash drive with a partition table as a floppy disk. This is a contradiction. Therefore, it chooses to skip the partition table and directly boot from the DBR. Yes, after the DBR, it's in the same format as a floppy disk, which is DBR + FAT + ROOT_DIR + DATA_AREA. Therefore, this method has its viable aspects. But the problem is that some things haven't been fully taken into account, or say, not considered, or neglected. On my machine, there was a similar error with CDROM floppy disk emulation. CDROM also uses a continuous sequence of sectors to emulate floppy disk booting, which is exactly the same as your USB flash drive. My machine also has AWARD code, and I estimate that the person who wrote this program also made the same mistake with the USB flash drive, that is, the int13 implementation is incomplete and flawed. On my machine, int13/ah=8 wasn't implemented, causing grub to not recognize the floppy disk on the CDROM.

GRUB can root (+TAB to bring up fd0, which doesn't mean fd0 is completely problem-free. It can see the fd0 drive letter, which is certain (such as testing the return result of int13/ah=0). However, when GRUB further tries to determine specifications like the number of tracks/sectors/heads/total sectors of fd0 (int13/ah=8 and ah=15h), it fails. In this way, GRUB refuses to recognize the data on that disk. That is to say, this disk exists but is not usable, just like your floppy drive exists but there is no floppy disk inside or the floppy disk is completely broken.

As for the fact that the code of DBR can find IO.SYS and GRLDR, it is because these programs may not use those calls (such as int13/ah=8 and 15h). However, after GRUB takes over control, it needs these calls to ensure that the various specification data of the disk are accurate. This is necessary and safe. It does not recognize non-compliant disks, so you will not damage the sectors on that disk device, whether intentionally or unintentionally. Note that the setup command of GRUB will write to the disk, which will be disastrous for disks without exact specifications (or with incomplete specification data). Therefore, the strict requirements of GRUB for BIOS are reasonable. If GRUB's requirements are not met, it is definitely a bug of BIOS. (The above things are all the functions of GNU GRUB, not unique to GRLDR.)

As for your problem, if it is consistent with my above guess, there is still a way to rescue. You can try one of the following commands:

map (fd0)+262144 (fd0)

map (fd0)+262144 (fd1)

map (fd0)+262144 (hd2)

Then use map --hook, and then see if the USB drive file system is normal (respectively: fd0, fd1, hd2).

The above 262144 actually means 128M. You think it is too large, you can reduce it a little, because if it is too large, errors will occur when reading the tail sectors. You should fill in the total number of sectors of your fd0, that is, the total number of sectors determined by the BPB table.

If there are no accidents, it should be successful.

After careful consideration again, I think you can try the following simple method:

map (fd0)+1 (fd0)
map --hook

In this way, you can access the files in your (fd0). In case it doesn't work, you can try the following one more:

map (fd0)+1 (fd1)
map --hook

In this way, you should be able to access the files in (fd1).

map (fd0)+262144 (hd2)

The system doesn't recognize this parameter, and there's no such parameter seen in help map. What does the sentence "stage1 encodes the location of Stage 2 (or Stage 1.5) in a block list format" mean?

You didn't post the error message.

(fd0)+1 and (fd0)+262144 both represent a file (A_FILE). I said that using 262144 is inappropriate, you need to use a suitable value. If you are too lazy to calculate, try using 1, and you might be lucky.

map A_FILE (fd0)

This usage is not special, there are no parameters here. There is a space between map and A_FILE, and also between A_FILE and (fd0). If your GRLDR version is not too old, this usage should be fully supported. You can also find the latest copy and put it in the root directory of the floppy disk, no problem.

Note that (fd0)+1 represents a file, and no spaces or other characters can be inserted in between. The plus sign in the middle is there, and the + sign cannot be omitted.

GRLDR does not use stage1 and stage1.5 at all, nor does it use stage2 files. So, there's no need to pay attention to the meaning of that sentence.

That sentence says that the stage1 boot sector contains information to locate the stage1.5 or stage2 file. The information is stored in the stage1 sector in the format of "block list". The so-called "block list" refers to the list of sector positions. So, once the physical sector positions of stage1.5 or stage2 change, for example, after disk defragmentation, then stage2 cannot be booted, resulting in the system freezing during boot.

GRLDR has no such problem, completely getting rid of those complicated stages, and directly using Microsoft's way to find the GRLDR file, which is foolproof. We know that the Microsoft boot sector code finds IO.SYS in this way. No matter how fragmented it is, as long as the IO.SYS file exists, it can always be booted successfully and never fails.

Tried it, and the display for map (fd0)+1 (hd2) is: FAT16 BPB found with starting 0xEB(jmp) confirmation. Probed C/H/S=117/64/32, probed total sectors=240943 (this is consistent with the information in BPB). Then map --hook but when root (hd2), it freezes. The +1 in (fd0)+1 is the same meaning as +1 in chainloader, indicating the first sector of fd0? If changed to +240943, it will report Attempt to access black out side partition. Changing hd2 to fd1 also freezes. Also found a problem: just when booting to the grub prompt, root shows fd0 is ntfs, but unlike a few days ago when it showed fat, then root (+ enter), at this time it shows fd0 is fat again.

There are two issues you haven't made clear:

1. After using map (fd0)+1 (fd0) and map --hook, can you access the files in (fd0)? This is very important. If it fails, talking about other things is meaningless, and we estimate there won't be a good way.

2. Your BPB is obviously contradictory. I calculated that 117 × 64 × 32 = 239616, which is the total number of sectors, but your BPB has 240943, which is obviously incorrect.

Either modify 240943 in the BPB to 239616, or you use:

map (fd0)+239616 (fd0)
map --hook

It can almost be certain that this should succeed.

=============

In addition, using (hd2) is wrong because your (fd0) contains a partition table, that is, the first sector of your (fd0) is DBR, not MBR. The first 32 sectors at the very beginning of your USB flash drive are not accessible, and the BIOS has blocked your access rights.

You can't use (fd1) either. Because according to the above-mentioned industrial standards, only (fd0) and (hd0) can be used as bootable disks. Other ones such as (fd1) (hd1) (hd2) and so on cannot be used as bootable disks.

===============

Your (fd0) is in fat16 format, as the probe report of the map command says, it is definitely not NTFS.

===================

map (fd0)+1 (fd0)

Here (fd0)+1 does not refer to the first sector of (fd0), but refers to all sectors on (fd0), that is, (fd0)+240943

Therefore, after you correct 240943 to the correct 239616, you can use the simple (fd0)+1 to handle this situation.

(fd0)+1 represents all sectors on (fd0), this is special, only valid in the disk emulation command of map, invalid in other occasions of GNU GRUB, that is, this is a special interpretation made by GRUB for DOS.

In occasions other than the map command line, (fd0)+1 still only represents the first sector of (fd0).

Changed the number of sectors in the BPB and tried map (fd0)+X (fd?). When X=1, the map command shows FAT16 BPB found with starting 0xEB(jmp) confirmation, Probed C/H/S=117/64/32, probed total sectors=239616, then map --hook, but then root to fd? will definitely crash. When 1<X<=2880, the command can succeed, successfully showing Auto detect number-of-heads failed, Use default value 2. Auto detect sectors-per-track failed, Use default value 18. Then root to fd? still crashes. When X>2880, shows error 15, Attempt to access block outside partition.

From the error of X > 2880, it can be seen that your BIOS may only support a boot floppy disk of 1.44M. If you read beyond 1.44M, it may crash.

There are many "crashes" here, crashing at every turn. The cause of the crash is not in GRUB, but in the BIOS. For such operations, GRUB all uses int13 calls and finally calls the BIOS program in the ROM. It is because the ROM BIOS is roughly programmed that it crashes at every turn.

You change the BPB to a 1.44M floppy disk image (of course, it needs to be reformatted), and then try this operation method to see if you can avoid the BIOS bug.

I estimate that this may be a limitation of your motherboard BIOS. Maybe it requires 1.44M, and you may have forgotten to check the motherboard manual.

I feel that the BIOS should not have a 1.44M limit for the boot disk. After I formatted the USB flash drive, I first copied some data into it, then copied the DOS system files in, and made sure that the three boot files were outside the 1.44M. When booting the system, everything was normal, and any newly created file was also in the sectors after 1.44M. The previous time when I used map (fd0)+2880 (fd0), it said "Auto detect number-of-heads failed, Use default value 2". Then how does GRUB automatically detect the number of heads and the number of sectors per track? Also, how does GRUB know whether a device is HD or FD? Does it call BIOS interrupts? In the DBR boot code, to find grldr, does this boot code need to know whether this device is HD or FD?

The map command of GRUB for DOS detects the C/H/S values from the BPB or MBR. As you specify, fd is for floppy disk and hd is for hard disk. This is not subjectively judged by GRUB but specified by the user.

The code of GRLDR in the DBR doesn't need to know whether it's a floppy disk or a hard disk. However, if it's a floppy disk, it must be (fd0), and if it's a hard disk, it must be (hd0). Violating these, I can't be sure it will definitely fail, but it may fail.

The GRLDR boot code in the DBR doesn't need to know whether it's booted from FD or HD. But the BIOS places the disk number during booting in the DL register, so GRLDR also knows whether it's booted via FD or HD.

There is no bug in GRUB here. The one with the bug is the BIOS. I think you might as well experiment with a 1.44M floppy disk. Just use the Win98 boot floppy disk plus grub.exe, which is not troublesome at all. If there is still a problem at this time, then we can also determine whose fault it is.

I found a problem. I'm using the Chinese version of Gandalf, but I think the problem should be here.
Originally I was using grldr to boot grub using the XP built-in bootloader. Now I want to install grub to the mbr, so I enter in the grub command line
root (hd0,0)
setup (hd0)
At this time, it will prompt that grub is being installed, and actually grub is also installed to the mbr. But what is installed is GNU's grub, not the improved grub for dos. This is very obvious from the header text and the fact that Chinese fonts are not supported.
Is it that I am missing some parameters, or is this a bug?