中国DOS联盟

grub用的是http://grub4dos.jot.com/WikiHome上面下载的grub.exe和grub_for_dos-2006-08-16.zip里的grub.exe（这两个应该够新的，是修改过的版本了吧）,两个分别测试了，在我的u盘上还是不能正常读写文件。
u盘是sandisk 128M,主板KT133A(AWARD BIOS 6.00PG),有USB-ZIP,USB-HDD,USB-FDD,USB-CDROM启动项，试下来只有USB-ZIP可以正常启动，用USBOOT 1.68做的启动u盘。MS-DOS 7.1启动文件。
u盘上有些文件，如果用cat指定文件名则始终说文件找不到，但如果
cat (fd0)/后面加tab键，则会提示“可能文件为:XXXX”，XXXX为好几行的乱码。
geometry (fd0) 显示C/H/S=80/2/18,正好是1.44M，象是ah=8的int13h结果
map (fd0)+1 (fd1) 显示侦测出 C/H/S=118/64/32，这个结果符合实际容量（但不知道grub是怎么得出这个结果的，是ah=48的int13h结果，还是直接从BPB里获取的数据？）
放了两个txt文件到u盘上，每个有3M,用DOS 7.1的edit都能准确打开（由于两个加起来早大于1.44M的限制，DOS会怎么存取？应该不是把u盘当作软盘了，而是用扩展int13h来存取了吧，是否就说明扩展int13h就没问题了呢？）。
用map --mem来加载某个img文件，会在img文件开始启动后死机，而用VFloppy 1.5则正常运行。

请在 DOS 下用 debug 测试以下这些项目，并把输出结果贴出来：

int13/ah=8h
int13/ah=48h
int13/ah=41h

要求贴出全部的寄存器值，以及 Flags 的值。对于 ah=48h ， 还要 dump 出返回的数据结构（从 DS:SI 开始，只要有开头的 50 个字节就够了）。这些测试项目完成之后，我就可以给出一个分析报告，并能让 grub4dos 顺利访问这个 U 盘。抄写数值时，要反复核对，保证无误。我只需要这三项测试，如果这三项测试做得不完整，我可能还需要你做更多的测试。

有关 int13 的信息，可以参考 ralf brown 的 interrupt list， 也可以参考以前 neiljoy 测试时的详细说明，这里不再重复。

补充，你最好 cat 出第一扇区的内容。也就是在 grub 下 cat --hex (fd0)+1, 把输出结果贴出来。你可以像 nailjoy 那样在 DOS 或者 Windows 下截获扇区，打印出来，然后比较 cat 的结果和它是否一样。

[ Last edited by 不点 on 2006-8-23 at 08:04 ]

AH=8h,DL=00h
返回:CF=0,AX=0000h,BX=0010h,CX=4F12h,DX=0101h

AH=41h,DL=00h,BX=55AAh
返回:CF=0,AX=0000h,BX=55AAh,CX=0000h,DX=0000h,这个结果很奇怪不知道算成功还是失败

AH=48h,DL=00h
返回:CF=0,AX=0000h
下面是DS:SI的内容
偏移
00h :1E 00 5E 00 60 00 00 00-40 00 00 00 20 00 00 00
10h :00 00 03 00 00 00 00 00-00 02 07 83 3E 06 D0 02
20h :75 03 E9 EF 84 A1 BB DC-8E 06 1A D4 26 F6 06 43
30h :04 FF 74 08 E8 07 D0 BA-E5 84 EB 0B C6 06 83 E2
40h :01 BA
这个结果里C=96不对，而H=64和S=32都是对的。猜想这个BIOS是真的把这U盘当成ZIP来对待了，因为ZIP正好是96/64/32的结构，由于该U盘容量是128M超过了ZIP的容量,如果BIOS真的把C限制在96以下会有麻烦。

cat --hex (fd0)+1的结果是U盘的DBR(扇区32),而用WinHex察看U盘第一个扇区是是MBR(扇区0)

这块U盘只能用USBOOT做成USB-ZIP模式才能在该主板上启动，也就是必须把H和S固定在64和32，并且DBR必须在扇区32(对启动来说MBR反而是无足轻重的，把MBR填0该U盘照样可以启动，只要保证扇区32是DBR)。

正如你看到的，这块主板比 neiljoy 的那块更糟糕。neiljoy 的 AH=41h,DL=00h,BX=55AAh 还能返回 成功，而你的这块返回的是混乱不堪：CF＝0表示成功，而AH＝0以及BX不等于0xAA55以及CX＝0又表示失败，自相矛盾。当具有 AH=48h 功能的支持时，最好能够在 AH=41h 功能查询调用中返回成功，并在 CX 寄存器中返回支持的功能位。当然规范中没有这么说，所以，AH=41h 功能查询返回失败也是可以的。

在现有的 GRUB4DOS 中，你用如下的方法可以获得 U 盘的访问：

map --heads=64 --sectors-per-track=32 (fd0)+1 (fd0)
map --hook

执行上述两条命令之后，你就可以访问 U 盘 (fd0) 中的文件了。

另外，也已经上载了一个版本来适应你这块 BUGGY 主板，在 http://grub4dos.jot.com/

请直接下载那里的 grub.exe 或者 grldr 文件来测试。

[ Last edited by 不点 on 2006-8-24 at 10:12 ]

最新的grub.exe可以读取U盘上的文件了！谢谢不点的辛勤工作！

在以前的grub中
map --heads=64 --sectors-per-track=32 (fd0)+1 (fd0)
map --hook
然后再用cat命令会死机，试了几次都死。这种死机是键盘完全没有反应，但光标还在那里闪。

最新的grub用geometry会显示CHS=96/64/32,似乎就是int13h/ah=48h的返回,比以前的int13h/ah=8的结果精确。

请问不点，最新的grub.exe里做了什么改动才使得能顺利读取U盘上的文件？对具体某个扇区来说，CHS的组合应该

是很多的，为什么限定H=64,S=32才能正常访问文件？以前grub默认会用什么参数？


在http://grub4dos.jot.com/ 上下载grub.exe很顺利，但下载其他的zip包总是在下载到99%快要好的时候报错，

说和服务器的连接意外中断，会是什么原因？

H 和 S 的值决定了磁盘扇区的逻辑结构。H 和 S 的不同，会导致同一物理扇区的绝对扇区号的不同。文件系统都是按照绝对扇区号的顺序来组织的，所以，错误的 H 和 S 会使文件系统产生混乱。在 LBA（这里说的是 EBIOS 的扩展磁盘访问） 寻址模式下，不存在这个问题。

GRUB 没有默认的 CHS 值。以前这个值是通过 int13/ah=8h 获得的。另外，如果 ah=41h 指示 ah=48h 有效，那么 ah=48h 的返回结果也会被考虑。但是你这个机器不支持 ah=41h，所以，ah=48h 被跳过了。新的改动是不检查机器是否有 ah=41h 的功能查询支持，直接从 ah=48h 获得结果。

grub要读取数据的时候，它会先把绝对扇区转换成CHS,然后调用int13h,那么接着BIOS会是直接把CHS参数交给U盘的控制器，还是BIOS本身会先对CHS做个转换，然后再提交给U盘控制器？U盘控制器是否会限死U盘数据的组织结构，比如它固定住HS，或者是因为U盘闪存的内部结构而导致其HS是固定的？

如果磁盘支持 LBA（EBIOS），GRUB 会首先使用 LBA（EBIOS），如果 磁盘不支持 LBA（EBIOS），GRUB 则使用 CHS。GRUB 对磁盘的访问，完全是基于 BIOS 的。那些 BUGGY 的 BIOS 在遇到某些 CHS 组合的时候之所以会死机，大多是因为它们在转换 CHS 到 绝对扇区号的时候，BIOS 程序出现了 BUG，比如执行了除以零的操作。如果 BIOS 盘只能认得某个固定的 HS 组合，那就说明这个 BIOS 极烂。事实上，从 CHS 转换到绝对扇区号的算法很简单的。现代的磁盘 BIOS 在内部都是按照绝对扇区号来访问扇区，因为以往的 CHS 规格，现在是没有的。U盘更是没有CHS，它只有绝对扇区号。所以BIOS在内部对U盘的处理是用绝对扇区号的。这一般不会出现问题。容易出现问题的，就是从 CHS 到绝对扇区号的转换，就像刚才说的，一个很烂的 BIOS，弄不好会出现除以零的错误，或者其他类似的低级错误，导致死机。

我们提供给 BIOS int13 的，无论是多么奇特的 CHS 值，一个设计良好的 BIOS 都不应该死机。一些比较好的 BIOS，在访问 U 盘时也支持 LBA （EBIOS），这些机器运行 GRUB 就没有问题了。这样的机器以前就有，它们的 U 盘和 GRUB 可以畅通无阻，就像普通的软盘和硬盘那样。

购买机器时，主板最要紧。什么都可以凑合，但主板是不能凑合着来的。

请教不点，你的意思说，在正常情况下，主板应当支持int13/ah=42h，我有两个问题：
1.int13/ah=42h能够具体提供磁盘的什么参数？在这种情况下，磁盘的参数是否还是通过int13/ah=48h来获取？int13/ah=42h、int13/ah=8h、int13/ah=48h之间的关系能否再说明一下？

2.我如何判断某一主板是否支持int13/ah=42h？以你的经验，你觉得什么品牌的主板对LBA（EBIOS）的支持较好？

[ Last edited by neiljoy on 2006-8-27 at 11:32 ]

5年前的主板，u盘还不普及，出现这样的问题很正常（我怀疑BIOS中USB-ZIP启动不是让你用u盘启动，而是用USB接口的ZIP来启动，所以HS参数会固定下来，而int 13h/ah=48h的返回会是96/64/32）。BIOS主要还是AWARD,Phoenix,AMI这些公司在研发，主板厂商只是买了BIOS回来用在自己的主板上，那么同一时代用同样BIOS的主板在int 13h这类基本代码是一样的，bug也就会一样。谁有条件用当时AWARD BIOS 6.0PG的主板，在DOS下用debug测试下int 13h的一些调用，看看结果如何。
有一点很奇怪，这块主板的BIOS有bug是毫无疑问的，那DOS是怎么样来避开这些bug的？对dos来说，它访问u盘也会调用int 13h,那么int 13h/ah=08也是返回80/2/18,而int 13h/ah=41h返回结果也是矛盾，这时候dos应该也就用int 13h/ah=48h的结果了吧？

neiljoy: 很遗憾到目前为止，我还没有接触过一台具有U盘启动功能的机器。但是我接触过一款DELL机器，它虽然不能从U盘启动，但如果在启动时先插入U盘，那么（从硬盘或者软盘启动）进入 DOS 后，就可以访问 U 盘了。所用的 DOS 是普通的 DOS，不含任何驱动程序。这说明这个 BIOS 已经支持 U 盘了。进一步研究时发现，这个 BIOS 还支持 LBA（EBIOS） 模式的 U 盘访问。

几年前就有人把 U 盘当作硬盘或者软盘成功启动 GRUB。这样的 U 盘 BIOS，不管它是否支持 LBA（EBIOS），都应该算是好的 BIOS。具体哪些机器、哪些主板是好的，你可以在网上搜搜看，我可是不能在这里乱说了（因为我没有使用过具有 U 盘启动功能的机器）。

关于 EBIOS，需要说明一下。EBIOS 是为了访问大容量存贮设备而设计的。像现在的 U 盘最大不过 1G 或者 2G，这么小的容量是不需要 EBIOS 支持的，但是如果有 CHS 支持，同时也有 EBIOS 支持，那当然是最好的了。如今的每台机器，都有 EBIOS 支持，注意这是对硬盘来说的。因为现在的硬盘都超出了旧的 CHS 的寻址范围，这要求主板必须支持 EBIOS 功能，否则就会遇到 1024 柱面问题。

如何判断 EBIOS 支持功能？答案是用 int13/ah=41h 的 EBIOS 的功能查询来判断。参看 int13 说明，例如可以参看 Ralf Brown 的 interrupt list （用 google 搜索它）。

int13/ah=08h 是每个 BIOS 必须支持的功能（对于 CHS 模式的访问而言）。
int13/ah=48h 和 ah=41h 是每个 BIOS 必须支持的功能（对于 EBIOS 模式的访问而言）。

老的软件不认识 ah=48h, ah=41h 等等这些 EBIOS 功能，所以，由 int13/ah=08h 所返回的 CHS 参数，必须是正确的，以便兼容以前的老软件。你们两位的机器，都把 int13/ah=08h 搞错了。这在技术上是很严重的错误，就 U 盘 BIOS 而言，可以将这两个 BIOS 定性为垃圾。

微软制定了一个新的标准，当 int13/ah=08h 返回 BL=10h 的时候，软件可以进一步查询 int13/ah=48h 功能。我以前曾经在下面这个网页有过详细说明：

http://www.cn-dos.net/forum/viewthread.php?tid=22105&fpage=2

看看上述网页就可知道，你们两位的机器都不遵从微软的规范。这些 BIOS 编程者没有领会微软的这个规范的精神实质。这是一个 “功能扩展” 性质的规范，并非是一个和以往故意搞不兼容的一个规范。在这个规范之下，大硬盘也可以能够被软件探测到了。大硬盘的柱面号 C 可以超过 1024，这在 ah=48h 的功能中可以体现。但是，容量小的存贮介质，以及大容量的存贮介质，都是可以用传统的 CHS 模式来访问的，只不过传统的 CHS 模式只能访问 8G，超过 8G 的部分是无法访问而已。由此可见 int13/ah=8h 是最重要的，如果这个功能没有毛病，那么兼容性基本上就可以得到有效的保障了。

那DOS是怎么样来避开这些bug的？－－－－旧的 DOS 使用 BPB，新的 DOS 也许已经考虑了上述新的规范（这是微软自己制定的规范），所以，DOS 本身不会遇到问题。但是 DOS 上有大量的软件是使用 BIOS 的（包括使用 int13/ah=8h），旧的软件可能不知道有 ah=48h 这个功能（或者不知道有 ah=8h 返回的 BL＝10h），所以，这样的软件都可能碰上这个错误的。GRUB 就是一个这样的软件。

谢谢不点大师的详细解释！

另外，我看了你建议的那个文件，它有如下内容：

INT 13 - IBM/MS INT 13 Extensions - INSTALLATION CHECK
AH = 41h
BX = 55AAh
DL = drive (80h-FFh)


这岂不是说，仅适用于硬盘？这里的驱动器包括象U盘这样的移动介质吗？

[ Last edited by neiljoy on 2006-8-28 at 11:52 ]

无论是 EBIOS，还是其他任何规范，都可能出现原始规范和它的变种。RALF BROWN 的网页很好，但也不完整，其中有些规范的说明也很欠缺。另外还存在不同的人所写的书对同一规范的解释是矛盾的这类情况。所以，同时参考多个资料比较保险。比如关于 EBIOS 的几个功能，有些资料说 返回的错误码在 AX 中，有些说是在 AH 中。不同机器对同一规范的实现也可能是不同的，这取决于 BIOS 编程者对规范的理解。所以，看待规范不要是静态的，而要是动态的。比如说，Int13 中的许多子规范，现在已经被淘汰了（对于一个特定的规范，如果 BIOS 硬件设计者懒得实现它或者难以实现它，或者软件程序员用户们可能不去用它，它就有可能被淘汰。例如可启动的 CDROM 的中的某些子规范就可能被永久淘汰掉）。新的规范还在不断产生，因为硬件在不断发展和创新。那些好的规范，无疑将具有强大的生命力，可以活得久一些。比如，int15/EAX=E820h 这个扩展内存规范就是比较新的，然而这个规范很快被各个硬件厂家支持。EBIOS 也是一个很好的规范，它的生命力也是很强的。虽然 EBIOS 可能最初是为了大容量硬盘而设计，但是，我就碰到不少机器的软盘（1.44M的真实软驱）也可以用 EBIOS 来访问。一个好的规范，即使当初的设计可能针对的是某些用途，但也可能被 BIOS 编程者引申到更广泛的情况下来使用，并有可能逐步发展成为事实工业标准。随着 U 盘容量的增加，EBIOS 会被很自然地采纳的。硬件厂家肯定希望它的硬件能够运行尽可能多的软件，从而得到用户的好评，这样它才能在激烈的竞争中赢得一些筹码。怎样让自己兼容更多的软件呢？那就是要全力实现那些最好的 BIOS 规范，并且尽量不出现 BUG，从而保证软件的畅通无阻。

谢谢不点大师耐心而又细致的解释！

不点乃高手也！！