无忧启动论坛

标题: 进行磁盘交换后直接map时会在chainloader 时出现读磁盘错误，求解。 [打印本页]

作者: hotdll 时间: 2011-10-26 11:31
标题: 进行磁盘交换后直接map时会在chainloader 时出现读磁盘错误，求解。

进行磁盘交换后，map --memUD区的ISO无问题，但直接map时会在chainloader (0xff)时出现读磁盘错误，求解。
问题源于fbinst 启动后U盘被识别为fd0的问题！
G4D版本2011-10-19
刚刚重新整理测试几十次的数据，发现我晕了。
u盘被识别为hd0的时候，交换后没有问题。
u盘被识别为fd0的时候，交换后会出现该问题。
重新修改可以重现问题的代码！
文件如下：
tangope.iso 未压缩100%文件无碎片。位于(ud)/boot/下
wvblock.gz 压缩的标准1.44M软盘镜像文件，位于U盘可见区根目录
U盘在VM中启动会被识别为hd0

map (fd0) (hd0)
map --mem （fd0,0)/wvblock.gz (fd0)
map --hook
write 0x8280 0x80 && calc *0x82b9=*0x82b9&0xffffff00|0x80
map --mem (ud)/boot/tangope.iso (0xff)
map --hook
chainloader (0xff)
成功！
map (ud)/boot/tangope.iso (0xfa)
map --hook
chainloader (0xfa)
error 25: Disk read error!

复制代码

map --mem除了不要求文件连续，允许压缩，读取到内存外和直接map有什么不同？为什么map不可读电脑上map --mem可读？

--------------------------------------------------------------------------------------------------------------------------------------------
没有write 0x8280 0x81 && calc *0x82b9=*0x82b9&0xffffff00|0x81 这句的结果：

-------------------------------------------------------------------------------------------------------------------------------------
有write 0x8280 0x80 && calc *0x82b9=*0x82b9&0xffffff00|0x80 这句的结果：

[ 本帖最后由 hotdll 于 2011-10-26 14:24 编辑 ]

作者: sht123960585 时间: 2011-10-26 11:44
map 要求文件在磁盘上连续存放，不能有碎片，会不会这个问题？

作者: hotdll 时间: 2011-10-26 11:46
标题: 回复 #2 sht123960585 的帖子
文件不连续的提示不是error 25： Disk read error

并且不会出现在chainloader 处，而是直接map的时候提示错误。

作者: 135956 时间: 2011-10-26 11:50
fbinst fba做启动后，u盘的读写速度很杯具啊。。。。不用它了，直接用grldr启动。
我的是sd卡＋读卡器。

作者: zxw 时间: 2011-10-26 11:52
标题: 回复 #1 hotdll 的帖子
tangope.iso 是否经过gz压缩？

作者: hotdll 时间: 2011-10-26 11:55
标题: 回复 #5 zxw 的帖子
没有经过压缩。。。。
FD2HD 执行后
如果覆盖fd0，也会出现这个提示。
以前一直找不到原因。昨天做了几十次测试，终于发现是map 和 map --mem的差别。

作者: chenall 时间: 2011-10-26 11:57
标题: 回复 #6 hotdll 的帖子
也许是你自己处理的问题。

先试试不修改再说吧。

作者: hotdll 时间: 2011-10-26 11:58

原帖由 135956 于 2011-10-26 11:50 发表
fbinst fba做启动后，u盘的读写速度很杯具啊。。。。不用它了，直接用grldr启动。
我的是sd卡＋读卡器。

哪是因为您的u盘被识别为zip了
不用fb,很多机器启动不了。

作者: hotdll 时间: 2011-10-26 12:00

原帖由 chenall 于 2011-10-26 11:57 发表
也许是你自己处理的问题。

先试试不修改再说吧。

能不能具体点？
不修改哪里？
如果没有这句write 0x8280 0x81 && calc *0x82b9=*0x82b9&0xffffff00|0x81
则map 和 map --mem 会出现同一个提示：error 25: disk read error

作者: 135956 时间: 2011-10-26 12:01
标题: 回复 #8 hotdll 的帖子
不是启动的读写速度，
是可见区在系统中复制、删除文件，特别是大文件时，那速度相当让你郁闷。

作者: 135956 时间: 2011-10-26 12:02
U+ v2 听说很给力。。。没试过。

作者: 幸运的草 时间: 2011-10-26 12:46
标题: 回复 #7 chenall 的帖子
我对你这样的回复很无语
你是专家，如果你认为是那里的问题，直接提出来，菜单很明显的，我等菜鸟不知出错的原因。。
这样的回复不是对问题的无视就是对提问题者的蔑视，您还不如不回答呢。至少我这样认为。

楼主可以换用10月前的版本来测试，看看是否正常。

作者: chenall 时间: 2011-10-26 13:17
标题: 回复 #12 幸运的草的帖子
每个人的理解方式都有所不同，看问题的角度也不同，当然了也是我的表达有问题。

你可以当成我没有回答。

@hotdll
我说的是不处理ud的情况，直接启动后就测试map --mem xxxx和map /xxx的对比情况。
如果这时一切正常，那就是修改了ud设备号的问题了。

作者: hotdll 时间: 2011-10-26 13:36
标题: 回复 #13 chenall 的帖子
@chenall
问题新进展：
刚虚拟机和真机测试。U盘被识别为hd0的情况下正常。

U盘识别为fd0的情况不正常。我修改了1楼的帖子，请C大移步重看。

对我问题没表述清楚就发帖子表示歉意。

主要是测试的机器多了。汇总后头有些晕。

作者: 135956 时间: 2011-10-26 13:37
我刚好试了一下。不用那个(ud)，一切正常。。。。社会很和谐。

作者: chenall 时间: 2011-10-26 14:03
标题: 回复 #14 hotdll 的帖子
map (hd0) (hd1)
map --mem （hd0,0)/wvblock.gz (hd0)
map --hook
write 0x8280 0x81 && calc *0x82b9=*0x82b9&0xffffff00|0x81

这只是针对(hd0)的情况，如果是(fd0)那出错是肯定的，没有出错那才是BUG。

作者: rockrock99 时间: 2011-10-26 14:06
最近怎么经常见到U盘被识别成fd0的帖子，难道旧主板又重新复兴了？

作者: 幸运的草 时间: 2011-10-26 14:16
真机测试，U盘为HDD，与硬盘进行磁盘交换后，map UD区ISO就出错，
而加绝对路径map (hd1)/xx.ISO则正常。
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
map (ud)/tangope.iso (0xff)
map --hook
chainloader (0xff)
Error 13: Invalid or unsupported executable format.
如果把(ud)改成(hd1)则正常。
也就是，交换磁盘后，UD区有问题了。ls (ud)/能列出ud区内的文件。

[ 本帖最后由幸运的草于 2011-10-26 14:31 编辑 ]

作者: hotdll 时间: 2011-10-26 14:25

原帖由 chenall 于 2011-10-26 14:03 发表
map (hd0) (hd1)
map --mem （hd0,0)/wvblock.gz (hd0)
map --hook
write 0x8280 0x81 && calc *0x82b9=*0x82b9&0xffffff00|0x81

这只是针对(hd0)的情况，如果是(fd0)那出错是肯定的，没有出错那才是BUG。

c大重新看下帖子。
我刚才修改帖子的时候，网络断了。。。

网络刚刚连上。。。。我访问无忧是代理服务器，经常会出现断的现象。抱歉。

作者: hotdll 时间: 2011-10-26 14:26

原帖由 rockrock99 于 2011-10-26 14:06 发表
最近怎么经常见到U盘被识别成fd0的帖子，难道旧主板又重新复兴了？

不是旧主板死灰复燃，而是技嘉的板子基本上都会识别小于8G的U盘为USB-ZIP

因为技嘉用的bios是award

作者: hotdll 时间: 2011-10-26 14:27

原帖由 chenall 于 2011-10-26 14:03 发表
map (hd0) (hd1)
map --mem （hd0,0)/wvblock.gz (hd0)
map --hook
write 0x8280 0x81 && calc *0x82b9=*0x82b9&0xffffff00|0x81

这只是针对(hd0)的情况，如果是(fd0)那出错是肯定的，没有出错那才是BUG。

如果u盘被识别为fd0
我将fd0交换到hd0，
如何处理该部分的代码？让ud区能直接map?

作者: 幸运的草 时间: 2011-10-26 14:38
根据测试，如果进行磁盘交换，则要定位到交换后的盘符则无问题；如果再引用ud则会出现错误，即交换后UD区会出问题。

作者: hotdll 时间: 2011-10-26 14:41

原帖由 幸运的草 于 2011-10-26 14:38 发表
根据测试，如果进行磁盘交换，则要定位到交换后的盘符则无问题；如果再引用ud则会出现错误，即交换后UD区会出问题。

如果识别为hd0，在不同的机器上测试不同。我刚测试了几个机器。识别为hd0，和hd1交换。处理0x8280和0x82b9的值后，没有问题。

但是识别为fd0，我测试的几个机器都会有map不行，但是map--mem正常的问题。

作者: chenall 时间: 2011-10-26 14:49
标题: 回复 #21 hotdll 的帖子
如果U盘是(fd0)不要前面的交换代码就行了。

也不要随意修改0x82b9那个字节的值（这个值关系到ud的正常读取）

这个值代表着读取(ud)时从哪个设备读取。

因为(ud)有缓存，所以你修改了之后ls等看起来是正常的（因为缓存的关系），实际上的文件都是不可访问的。

作者: hotdll 时间: 2011-10-26 15:11
标题: 回复 #24 chenall 的帖子
因为我需要占用软驱fd0

如果不交换到其他分区，映射到镜像到fd0，原来的usb设备和ud会被覆盖，变成不可读。

当然有变通方法。不过我想交换到hd0，这样和识别为usb-hdd的时候盘符一致。

方便使用我代码的人使用。

作者: zxw 时间: 2011-10-26 15:17

原帖由 hotdll 于 2011-10-26 14:41 发表

如果识别为hd0，在不同的机器上测试不同。我刚测试了几个机器。识别为hd0，和hd1交换。处理0x8280和0x82b9的值后，没有问题。
但是识别为fd0，我测试的几个机器都会有map不行，但是map--mem正常的问题。

从楼主的几个帖子来看，总结一下：
恰恰是处理0x8280和0x82b9的值后才正常，或接近正常。
fbinst盘启动后被识别为(hd0)，如上处理后完全没有问题。如不处理，则有问题。
fbinst盘启动后被识别为(fd0)，如不处理，则有问题。如处理后，接近正常。

作者: chenall 时间: 2011-10-26 15:36
标题: 回复 #25 hotdll 的帖子
思路适应任意情况保证ud可以使用
1.先读取0x82b9处一个字节的值。设为变量比如%ud%
2.映射到新的设备map (%ud%) (xx)
3.修改0x82b9的值为新的设备号xx

当然了这其中还有一些需要考虑的问题，比如如果是(hd0)需要交换等，这些需要另外处理。

作者: zxw 时间: 2011-10-26 15:58
标题: 回复 #27 chenall 的帖子
这些情况都处理了的。

作者: rockrock99 时间: 2011-10-26 16:28
标题: 回复 #20 hotdll 的帖子
我现在都是指定购买技嘉的主板，从945开始，U盘都是识别为USB-HDD的

作者: mygamexxx 时间: 2011-10-26 16:53
识别为zip的情况，不用wrie, 用cat写入试试。我试过write写入后有问题，用cat倒是没有问题。错了，原来楼主是写入内存地址，当我没说！！！

[ 本帖最后由 mygamexxx 于 2011-10-26 16:54 编辑 ]

作者: zxw 时间: 2011-10-26 20:38
@hotdll:
抽空找了个电脑，实机测试了一下zip盘启动后处理的情况。

!BAT
(hd0,0)/fd2hd.cmd
map (ud)/boot/imgs/ntboot.iso (0xff)
map --hook
chainloader (0xff)
boot

复制代码

或者

!BAT
map (fd0) (hd0)
map (hd0) (hd1)
map --hook
calc *0x82b9=*0x82b9&0xffffff00|0x80
map (ud)/boot/imgs/ntboot.iso (0xff)
map --hook
chainloader (0xff)
boot

复制代码

一切正常，没有你所说的情况。

作者: rockrock99 时间: 2011-10-26 20:55
标题: 回复 #31 zxw 的帖子
怀疑hotdll的不是USB-ZIP模式，可能是USB-FDD模式（纯粹猜测）才会出错

作者: hotdll 时间: 2011-10-26 21:02
标题: 回复 #31 zxw 的帖子
您测试忽略了最关键的一句让问题重现的代码：

您应该这样测试：

!BAT
(hd0,0)/fd2hd.cmd
map --mem (hd0,0)/wvblock.gz (fd0)
map --hook
map (ud)/boot/imgs/ntboot.iso (0xff)
map --hook
chainloader (0xff)
boot

复制代码

或者

!BAT
map (fd0) (hd0)
map (hd0) (hd1)
map --hook
map --mem (hd0,0)/wvblock.gz (fd0)
map --hook
calc *0x82b9=*0x82b9&0xffffff00|0x80
map (ud)/boot/imgs/ntboot.iso (0xff)
map --hook
chainloader (0xff)
boot

复制代码

[ 本帖最后由 hotdll 于 2011-10-26 21:16 编辑 ]

作者: rockrock99 时间: 2011-10-26 21:32
标题: 回复 #33 hotdll 的帖子
代码里面重复的“map --hook”，不对吧

作者: zxw 时间: 2011-10-26 22:03
标题: 回复 #33 hotdll 的帖子
wvblock.gz 在原来的可见区(fd0,0)么？

作者: Plantsoot 时间: 2011-10-27 01:21
fbinst的部分代码：
#define CODE_START 0x2000
……
setup_mbr:
pushw %ds
popw %es
movw $8, %cx
movw $(CODE_START + 0x1be), %si
movw $(0x800 - 18), %di
pushw %di
rep movsw
popw %si
movw orig_es, %es
movw orig_di, %di
xorb %dh, %dh
movb %dl, ABS(bootdrv)
ret
-----------------------------------------
#define OFS_max_sec 0x1ad
#define OFS_lba 0x1ae
#define OFS_bootdrv 0x1af
#define OFS_spt 0x1b0
#define OFS_heads 0x1b1
#define OFS_boot_base 0x1b2
#define OFS_fb_magic 0x1b4
-------------------------------------------

对比下ud为hd0和ud为fd0不同情况下 grub4dos下的两个数值：

1、ud 为 hd0，对比0x24和0x1af 两处的值：

cat --hex (md)0x10+1
cat --hex (hd0)+1

2、ud 为 fd0，对比0x24和0x1af 两处的值：

cat --hex (md)0x10+1
cat --hex (fd0)+1

不是很懂汇编，我是瞎鼓捣乱猜测，也许有点用。

[ 本帖最后由 Plantsoot 于 2011-10-27 01:25 编辑 ]

作者: yueyezhan 时间: 2011-10-27 03:43

原帖由 hotdll 于 2011-10-26 14:26 发表

不是旧主板死灰复燃，而是技嘉的板子基本上都会识别小于8G的U盘为USB-ZIP

因为技嘉用的bios是award

我用过的07年之后的技嘉的780 760 740 880的amd主板，都是把u盘识别为usb hdd，f12的时候可以直接在usb hdd或者hard disk栏目里选择

作者: rockrock99 时间: 2011-10-27 07:36
标题: 回复 #37 yueyezhan 的帖子
没错，所以不存在技嘉主板的AWARD BIOS把U盘识别为USB-ZIP之说，而且从G41年代开始，U启速度已经达到了2.0的速度

作者: hotdll 时间: 2011-10-27 08:49
标题: 回复 #36 Plantsoot 的帖子
上传本机u盘被识别为fd0的机器的两个值
cat --hex (md)0x10+1
cat --hex (hd0)+1

cat.7z (3.43 KB, 下载次数: 26)

[ 本帖最后由 hotdll 于 2011-10-27 14:04 编辑 ]

作者: hotdll 时间: 2011-10-27 08:52
标题: 回复 #34 rockrock99 的帖子
谁规定map --hook不可以重复执行的？
我调用别人的批处理，别人map --hook
我现在需要创建新的虚拟驱动器，我就不能map --hook?

作者: hotdll 时间: 2011-10-27 08:54

原帖由 rockrock99 于 2011-10-27 07:36 发表
没错，所以不存在技嘉主板的AWARD BIOS把U盘识别为USB-ZIP之说，而且从G41年代开始，U启速度已经达到了2.0的速度

你没遇到不代表没有这种情况。
fbinst的反馈贴您自己去翻翻。
这个帖子是寻求帮助的，不是让您否定有usb-hdd被识别为usb-zip这类情况的。
说话有点重，望海涵。

作者: hotdll 时间: 2011-10-27 08:55

原帖由 zxw 于 2011-10-26 22:03 发表
wvblock.gz 在原来的可见区(fd0,0)么？

是的，在原来的(fd0,0)可见区。即U盘可见区。

作者: hotdll 时间: 2011-10-27 08:56

原帖由 yueyezhan 于 2011-10-27 03:43 发表

我用过的07年之后的技嘉的780 760 740 880的amd主板，都是把u盘识别为usb hdd，f12的时候可以直接在usb hdd或者hard disk栏目里选择

F12的时候都有usb-hdd
但是并非是一定都会识别为usb-hdd。
毕竟您用用的主板不会超过三位数。

作者: chenall 时间: 2011-10-27 09:03
标题: 回复 #33 hotdll 的帖子
失败之后做如下检查

先确定fb_status的值是否正确read 0x82b8
得到的第二个字节值要等于新的ud设备（比如0x80或0x81）

使用cat命令检测UD上的文件是否可以正常访问
cat --hex (ud)/grldr

对比一下(ud)和(hd0)中的文件读出来的是否一样，例子
cmp (ud)/grldr (hd0)/grldr

如果以上测试完全通过的话，没有理由不行的。

作者: hotdll 时间: 2011-10-27 09:10
标题: 回复 #44 chenall 的帖子
>>>先确定fb_status的值是否正确read 0x82b8
答：确定，zxw帮助测试的，这里不会错。

>>>使用cat命令检测UD上的文件是否可以正常访问
cat --hex (ud)/grldr
答：刚测试过，可以cat 我按了足足2分钟，终于显示器完。

对比一下(ud)和(hd0)中的文件读出来的是否一样，例子
cmp (ud)/grldr (hd0)/grldr

答：没有差别。

备注：
您可能没看清楚，fd0 换到 hd0后，处理过82b9 82b8的设备号，这个时候map和map --mem命令都正常。然后创建新的虚拟驱动器并映射设备号为fd0
这个时候(ud)内的文件使用map 命令会出现error 25: Disk read error，但是这个时候使用map --mem命令，则完全正常。

我怀疑是不是ud的缓存作怪？fd0换到hd0设备号后，处理了fb的值，但是ud的缓存没变。当map的时候读取的是缓存，缓存指向的是fd0，fd0被赋予新虚拟软驱的设备号后，map 指令应该还是去ud缓存指向的地址去查找，肯定出错。map --mem是不是会忽略ud的缓存或者是刷新ud的缓存？

[ 本帖最后由 hotdll 于 2011-10-27 09:26 编辑 ]

作者: chenall 时间: 2011-10-27 09:32
标题: 回复 #45 hotdll 的帖子
缓存只是缓存文件列表资料。关键的的数据还是从ud设备中读取的，其中最关键的还是fb_status的值

如果这个值错了，那肯定会读错。

看看map --status的状态就明白了.

另外其实你可以先
map (ud)/xxxx (0xfa)的而不必等到交换了再去执行这一句。

作者: 幸运的草 时间: 2011-10-27 09:48
在zip机上测试，如果改成下面这样，成功。红色部分不能有。否则失败。
!BAT
map (fd0) (hd0)
map (hd0) (hd1)
map --hook
calc *0x82b9=*0x82b9&0xffffff00|0x80
map --mem (hd0)/wvblock.gz (fd0) 注(UD) 如果是可见区是(hd0,0)
map --hook

map (ud)/boot/imgs/ntboot.iso (0xff)
map --hook
chainloader (0xff)
boot

作者: Plantsoot 时间: 2011-10-27 09:59

原帖由 hotdll 于 2011-10-27 08:49 发表
上传本机u盘被识别为fd0的机器的两个值
cat --hex (md)0x10+1
cat --hex (hd0)+1
131207

识别为fd0，你cat的是hd0，不需要所有数据，记录三个关键数据就可以了。

2、ud 为 fd0，对比0x24、0x26、0x1af 三处的值：

cat --hex (md)0x10+1
cat --hex (fd0)+1

作者: hotdll 时间: 2011-10-27 10:31

原帖由 Plantsoot 于 2011-10-27 09:59 发表

识别为fd0，你cat的是hd0，不需要所有数据，记录三个关键数据就可以了。

2、ud 为 fd0，对比0x24、0x26、0x1af 三处的值：

cat --hex (md)0x10+1
cat --hex (fd0)+1

晕。我中午回去测试。

作者: hotdll 时间: 2011-10-27 10:34

原帖由 chenall 于 2011-10-27 09:32 发表
缓存只是缓存文件列表资料。关键的的数据还是从ud设备中读取的，其中最关键的还是fb_status的值

如果这个值错了，那肯定会读错。

看看map --status的状态就明白了.

另外其实你可以先
map (ud)/xxxx ( ...

刚才忘记输入这个命令了。
中午回去测试后拍照上传。
然后再请C打指点。

>>>其实可以在交换前map。。。。。。。。。。
答：之所以这么做主要还是不想限制用户的写菜单方式。
其实我个人觉得这个问题由g4d开发人员处理更好，只要读取到FBBF标志就识别为存在FB，不管BIOS是否认为是FD0，都将设备号设定为hd0

这样zip问题就不存在了。

作者: yueyezhan 时间: 2011-10-27 10:53

原帖由 hotdll 于 2011-10-27 08:56 发表

F12的时候都有usb-hdd
但是并非是一定都会识别为usb-hdd。
毕竟您用用的主板不会超过三位数。

技嘉的amd主板，除了890系列，我几乎都用过，我认为某一种型号的主板我用过一块的话就可以了，因为同一型号的产品的bios是一样的，这个是由产品性质来决定的，大概技嘉的amd主板的型号也不超过三位数吧

作者: hotdll 时间: 2011-10-27 11:43
标题: 回复 #51 yueyezhan 的帖子
请提供每款您用过的技嘉主板usb-hdd启动后的read 0x82b8的值.
谢谢。
技嘉nf550，技嘉kt890，这两个主板我测试的100% USB-HDD启动识别为fd0

作者: rockrock99 时间: 2011-10-27 12:56
标题: 回复 #52 hotdll 的帖子
技嘉nf550，技嘉kt890都是已经很老的主板了，暂时手头上没有，没办法验证

何必去提三位数主板的问题，我之前在电脑城工作，接触三位数的主板比较多，但也不缺乏四位的，你这样说有点看不起人。

发贴只为了提供多些信息而已，莫见怪！

作者: hotdll 时间: 2011-10-27 14:00
标题: 回复 #53 rockrock99 的帖子
这个帖子是为了解决ZIP问题的，
你们遇不到不代表别人遇不到。何况PE或者是启动主要是用来维护系统用的。
现在维护机器是老机器多还是刚买回家用不到三天的机器多？

如果大家的帖子是出于解决问题的，我欢迎，如果不是，建议另开贴。。。。

希望不要跑题。NF550可以支持AM3 X965的CPU，很老吗?这主板的性能并不比amd 870差。难道换个马甲我们就必须换？

电脑是拿来用的，不是拿来换的。否则搞什么无忧启动？直接给论坛的朋友说，有问题扔了换个电脑。

作者: hotdll 时间: 2011-10-27 14:03

原帖由 chenall 于 2011-10-27 09:32 发表
缓存只是缓存文件列表资料。关键的的数据还是从ud设备中读取的，其中最关键的还是fb_status的值

如果这个值错了，那肯定会读错。

看看map --status的状态就明白了.

另外其实你可以先
map (ud)/xxxx ( ...

执行FD2HD后的
map --status 的结果

作者: hotdll 时间: 2011-10-27 14:05

原帖由 Plantsoot 于 2011-10-27 09:59 发表

识别为fd0，你cat的是hd0，不需要所有数据，记录三个关键数据就可以了。

2、ud 为 fd0，对比0x24、0x26、0x1af 三处的值：

cat --hex (md)0x10+1
cat --hex (fd0)+1

我更新了cat.7z文件。
或者是下载这个也可以

cat.7z (3.43 KB, 下载次数: 20)

作者: chenall 时间: 2011-10-27 14:22
标题: 回复 #55 hotdll 的帖子
要出现失败的情况。。

这个是没有什么问题的。关键是出错后的状态。

作者: roytam1 时间: 2011-10-27 15:31

原帖由 hotdll 于 2011-10-27 10:34 发表

刚才忘记输入这个命令了。
中午回去测试后拍照上传。
然后再请C打指点。

>>>其实可以在交换前map。。。。。。。。。。
答：之所以这么做主要还是不想限制用户的写菜单方式。
其实我个人觉得这个问题由 ...

實為不可能，因為G4D正是用BIOS給出的盤號(FD0=0x00,HD0=0x80)來存取磁區，並不是你要它是什麼就變什麼的東西。

作者: hotdll 时间: 2011-10-27 15:58
标题: 回复 #58 2010roytam1 的帖子
但是我们现在移动fd0到hd0成功了90%
移动hd0到hd1 100%成功。

作者: chenall 时间: 2011-10-27 16:09
标题: 回复 #59 hotdll 的帖子
这个是两回事。
这个移动使用的是GRUB4DOS的MAP功能。

暂时不用再纠结于这个问题上了，我测试了一下，初步怀疑是GRUB4DOS的BUG。

具体的需要等不点来看一下，相信过几天就会有结果。

关于BUG的描述。
例子：

以下是正常的
map (fd0) (hd0)
map --hook
map (hd0)/xxx.img (yy)
##关键的问题来了，到执行这一步时还是正常的
map --mem (md)+2880 (fd0)
map --hook
##以下开始出现问题了
map (hd0)/xxx.img (zz)

如果新映射的(fd0)和之前的(fd0)的H/S值一样那就没有问题，可以正常使用新的(zz)
如果不一样则新的(zz)将无法正常访问。yy可以正常访问

原因是MAP命令在map的处理时可能有bug。映射时使用的H/S不是旧的(fd0)的值，而是新的(fd0)的值，所以才导致这个问题。

等不点再下结论了,,,又揪出一个BUG。

floppies_orig=1, harddrives_orig=2, floppies_curr=1, harddrives_curr=2

Number of ATAPI CD-ROMs: 0

ram_drive=0x7F, rd_base=0x0, rd_size=0x100000000

Fr To Hm Sm To_C _H _S Start_Sector Sector_Count DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
80 00 00 01 004F 01 52 0000000000000000 0000000000000000 F=S
F1 00 FE 3F 234C 3F 7F 000000000001D29C 000000000003FDE0 F=S
F2 00 FE 3F A04F 01 52 000000000001D29C 000000000003FDE0 F=S
00 FF 01 12 8A6C FE 7F 00000000006789F8 0000000000000B40 M=S
F3 FF FE 3F A26C FE 7F 0000000000638C18 000000000003FDE0 M=S

F1是正常的
F2是失败的

F2的TO_C _H _S数据不一样。

F3是加载到内存中的。

[ 本帖最后由 chenall 于 2011-10-27 16:16 编辑 ]

作者: chenall 时间: 2011-10-27 16:12
后面的信息中
F1是正常的
F2是失败的

F2的TO_C _H _S数据不一样。

F3是加载到内存中的。

作者: hotdll 时间: 2011-10-27 17:19
标题: 回复 #61 chenall 的帖子
很佩服c大测试代码的简要和严谨。
我啰嗦了一大堆，您几句代码就揪出BUG
不过，
C大，为什么map --mem 正常？

[ 本帖最后由 hotdll 于 2011-10-27 17:21 编辑 ]

作者: chenall 时间: 2011-10-27 17:50
标题: 回复 #62 hotdll 的帖子
map --mem是直接读取到内存中了,不需要转换,但直接map不一样,需要转换.

作者: hotdll 时间: 2011-10-27 18:08
标题: 回复 #63 chenall 的帖子
明白了。等c大的最新版的g4d版本。
接下来我可以专心更新我的F6IMG到将厂商打包成gz了。
先谢谢ZXW大大、C大，不点，幸运的草、百草霜、赵大等兄弟的帮测。

作者: 幸运的草 时间: 2011-10-27 18:44
标题: 回复 #60 chenall 的帖子
问题明了了，其实很早就怀疑是BUG，但又苦于无证据，所以我等不能随便说。
其实楼主发帖前我们就进行了很多测试，一直找不到原因。
发贴是想引起G4D高手们的注意，特别是要引起你和不点的注意，目的是要弄清问题的原因。

看了你的那个回复，对您有点小小的失望，所以给了您一个“刺激”。
望C大不要在意，对您的辛勤工作深感敬佩。

作者: mygamexxx 时间: 2011-10-27 20:18
越来越接近真相了，我说怎么fbinst制作的U盘的占用(fd0)处理怎么这么麻烦（都想放弃用FBINST制作的启动盘了），map交换软驱后总有问题。明明交换成功，DOS启动文件已经在(fd0)，却总是启动有点问题或无法启动。不过，我上次提到的map 交换软驱后，(fd1)丢失的机器还没有机会再去测试，确定问题在哪里。

我曾经试过下面的代码：
map (fd0) (hd0)
map --hook

发现是(fd0,0)映射到了(hd0,0)，而(fd0)是UD区内容
再接着
map --mem (hd0)/dos.img (fd0)
map --hook
好像是出现问题了(有点记不清了)，(hd0,0)好像就不能访问了。

考虑到原(fd0)是UD区，可能有问题，再用下面的代码测试：
map (fd0) (hd0)
map (fd0) (fd1)
map --hook
发现是(fd0,0)映射到了(hd0,0)和(fd1,0)，(fd0)和(fd1)均是UD区内容。发现(fd0)与(fd0,0)在map时有联动效果。
再接着
map --mem (hd0,0)/dos.img (fd0)
map --hook
可以发现(fd0)内容为DOS映像内容，但再使用chainloader (fd0)/io.sys启动，却无法成功启动DOS（可能就是C大说的C、H、S参数不正确的原因，也就是交换后(fd0)的C、H、S参数不是dos.img的C、H、S参数）。

最后没办法只能用下面的代码启动DOS。
map --mem (fd0,0)/dos.img (fd1)
map --hook
map (fd0) (fd1)
map (fd1) (fd0)
chainloader (fd0)/io.sys
难道这样(fd0)的C、H、S参数才会正确？？？
不过那台有问题的电脑就是在这个过程中出现了(fd1)丢失现象。

[ 本帖最后由 mygamexxx 于 2011-10-27 21:10 编辑 ]

作者: 不点 时间: 2011-10-27 21:17

Fr To Hm Sm To_C _H _S Start_Sector Sector_Count DHR
-- -- -- -- ---- -- -- ---------------- ---------------- ---
80 00 00 01 004F 01 52 0000000000000000 0000000000000000 F=S
F1 00 FE 3F 234C 3F 7F 000000000001D29C 000000000003FDE0 F=S
F2 00 FE 3F A04F 01 52 000000000001D29C 000000000003FDE0 F=S
F1是正常的
F2是失败的

复制代码

初步怀疑是这样的：第一个映射是整盘映射，此时没有仔细计算真实磁盘 (fd0) 的 geometry。就是说，第一行的 004F 01 52 是错的。

而在仿真 0xF1 的时候，却计算了 (fd0) 的几何参数 234C 3F 7F（应该是正确的），因此 0xF1 可以正常访问。

当 (fd0) 也变成虚拟盘的时候，又影响（误导）了仿真 0xF2 时 (fd0) 的几何参数计算。导致它采纳了第一个映射中的错误几何参数值 004F 01 52 。

在第一个映射中，几何参数是用不上的，因为是整盘映射。所以，几何参数的错误，没有对 (hd0) 造成任何影响。

chenall 再研究研究，看看如何解决比较好。

＝＝＝＝＝＝＝＝＝＝＝＝

我目前正在处理 lianjiang 以前报告的图形模式花屏问题，以及 800x600 的 6A 模式失败问题。

已经上载了新版本到时空论坛，请大家注意测试。应该没有大问题了。

等 chenall 弄好此处的 map 以后，可以一并更新到 svn 数据库里面。

[ 本帖最后由不点于 2011-10-27 21:27 编辑 ]

作者: hotdll 时间: 2011-10-27 22:13
标题: 回复 #67 不点的帖子
谢谢不点和C大，估计要辛勤劳动了。
等g4d更新后，我就把F6IMG的单包GZ驱动版发布。
呵呵，这样USB-ZIP的F6IMG速度也是很喜人的。

作者: mygamexxx 时间: 2011-10-28 10:13
我怀疑不是map的BUG，而是FBINST制作的启动盘在被识别为USB－ZIP后，必须占用一个软驱，如果(fd0)被覆盖(实际是UD区，并在0x82b8中记录了位置)，就会有问题。

我现在通过下列办法测试没有问题
map --mem (fd0,0)/dos.img (fd1)
map --hook
map (fd0) (fd1)
map (fd1) (fd0)
map --hook
calc *0x82b9=*0x82b9&0xffffff00|0x01 #将UD区指向(fd1)
map (fd1) (hd)
map --hook
root (fd0)
chainloader /io.sys
顺利启动DOS。

作者: chenall 时间: 2011-10-28 10:15
先上传一个测试,,,,<br /><br />理论上应该是没有什么问题.

[ 本帖最后由 chenall 于 2011-10-28 11:10 编辑 ]

作者: zxw 时间: 2011-10-28 11:03
标题: 回复 #70 chenall 的帖子
貌似改出问题了。正常的仿真也不行了。

[ 本帖最后由 zxw 于 2011-10-28 11:08 编辑 ]

作者: chenall 时间: 2011-10-28 11:09
试试这个..........

grub4dos_test.zip

287.46 KB, 下载次数: 75, 下载积分: 无忧币 -2

作者: zxw 时间: 2011-10-28 11:45
标题: 回复 #72 chenall 的帖子
真棒，我测试一切正常。

作者: mygamexxx 时间: 2011-10-28 13:26
新的测试版，USB－ZIP启动：
1、
map --mem (fd0,0)/dos.img (fd0)
root (fd0)
chainloader /io.sys
boot
启动DOS正常。

2、
map (fd0) (hd1)
map --hook
map --mem (hd1,0)/dos.img (fd0)
map --hook
root (fd0)
chainloader /io.sys
boot
死机
有谁能指点一下是否代码有问题吗？

[ 本帖最后由 mygamexxx 于 2011-10-28 13:30 编辑 ]

作者: chenall 时间: 2011-10-28 13:36
标题: 回复 #74 mygamexxx 的帖子
死机有很多可能,你可以换个版本对比一下,不一定是GRUB4DOS的问题.

作者: mygamexxx 时间: 2011-10-28 13:40
确实如此，我用标准1.44M的软盘映像不会死机。

作者: 幸运的草 时间: 2011-10-28 13:48
标题: 回复 #72 chenall 的帖子
在ZIP机上测试正常。

作者: 幸运的草 时间: 2011-10-28 13:49
标题: 回复 #76 mygamexxx 的帖子
是不是进行了压缩处理，有时，压缩版会有点小问题。

作者: zxw 时间: 2011-10-28 13:53
标题: 回复 #74 mygamexxx 的帖子
我测试正常。

作者: mygamexxx 时间: 2011-10-28 13:54
不是，将标准映像进行扩容（7.2M），还是第二种情况，无法启动DOS。

[ 本帖最后由 mygamexxx 于 2011-10-28 13:56 编辑 ]

作者: chenall 时间: 2011-10-28 13:58
标题: 回复 #80 mygamexxx 的帖子
扩容后可能需要重新格式化一下,和MSDOS的版本也有关系,比如MSDOS6.22的就不能随意更改.

用高一点的版本比较好用.

另外很可能是C/H/S的值不对,所以启动失败.

你可以在启动前geometry --sync (fd0)也许就行了.

作者: chenall 时间: 2011-10-28 14:01
标题: 回复 #74 mygamexxx 的帖子
对比一下两个的C/H/S的值看看是否正常

geometry (fd0)

还有map --status状态

作者: mygamexxx 时间: 2011-10-28 14:03
谢谢C大，加入geometry --sync (fd0) ，测试成功。再请教一下，扩容后如何格式化软盘映像？算了，用ultraiso.exe另存一下问题解决。

[ 本帖最后由 mygamexxx 于 2011-10-28 14:29 编辑 ]

作者: rockrock99 时间: 2011-10-28 14:21
我测试的结果：对比普通版本运行效果会不一样
菜单如下：
title 01. 微软内存检测
map /BOOT/MWMD.IMA (fd0)
map --hook
rootnoverify (fd0)
chainloader (fd0)+1

普通版本：加载镜像后会清屏，然后出现“loading............................”
这个测试版：加载镜像后不清屏，直接在下一行显示“loading............................”

作者: hotdll 时间: 2011-10-28 14:58
你们大家的效率太高了
早上看这个帖子没动静，于是开始修改我的F6IMG
刚改好，发现C大已经发了两个测试版了。。。。。
ZXW的效率也很高啊。

呵呵，可以发布了。

作者: chenall 时间: 2011-10-28 15:22
标题: 回复 #84 rockrock99 的帖子
测试版本并没有针对这个作出任何的改动.

作者: hotdll 时间: 2011-10-28 15:53
标题: 回复 #86 chenall 的帖子
C大，我看了下1009版的体积是279K，1028测试版的体积是252K。
小了不少了啊。

刚才测试了几个机器，完美解决map问题。谢谢C大辛勤劳动，辛苦了。

作者: mygamexxx 时间: 2011-10-28 16:04
奇了怪了，dos6.22的能启动，dos7.1的不能启动，加了geometry --sync (fd0)也没用。

如果不进行map (fd0) (hd0)
dos7.1的都能启动啊，用同一个映像测试的。

title 测试
map (fd0) (hd1)
map --hook
map --mem (hd1,0)/onekey/onekey.ima (fd0)
map --hook
write --offset=46 (fd0)/autoexec.bat todos
geometry --sync (fd0)
root (fd0)
chainloader /io.sys

[ 本帖最后由 mygamexxx 于 2011-10-28 16:14 编辑 ]

作者: hotdll 时间: 2011-10-28 16:17
标题: 回复 #88 mygamexxx 的帖子
再加一个试试

再试：
geometry --tune (fd0)
geometry --sync (fd0)

作者: chenall 时间: 2011-10-28 16:23
标题: 回复 #88 mygamexxx 的帖子
把能启动和不能启动的map --status信息和geometry (fd0)的信息贴上来看一下.

作者: rockrock99 时间: 2011-10-28 21:07
也顺便贴下我的不能启动Bug：

对比两张图显示的数值一致，图1是AHCI模式，图2是IDE模式，MS-DOS只能在IDE模式里面启动，不知道为啥？

[ 本帖最后由 rockrock99 于 2011-10-28 21:08 编辑 ]

IMG_1452.JPG (52.92 KB, 下载次数: 140)

IMG_1453.JPG (53.93 KB, 下载次数: 155)

作者: mygamexxx 时间: 2011-10-29 08:36
title 测试1 （启动DOS7.1后死机）
map (fd0) (hd1)
map --hook
map --mem (hd1,0)/onekey/onekey.ima (fd0)
map --hook
commandline
map --status
geometry (fd0)

title 测试2 （启动DOS7.1正常）
map --mem (fd0,0)/onekey/onekey.ima (fd1)
map --hook
map (fd0) (fd1)
map (fd1) (fd0)
map --hook
commandline
map --status
geometry (fd0)

可以看出(fd0)的To_C _H _S几何参数不一样，DOS映像是同一个文件。
使用的是10月28日的测试版grldr。

[ 本帖最后由 mygamexxx 于 2011-10-29 08:44 编辑 ]

作者: chenall 时间: 2011-10-29 09:19
标题: 回复 #92 mygamexxx 的帖子
有没有试过以前的版本?以前的版本的情况是怎么样的.一样的吗?

作者: mygamexxx 时间: 2011-10-29 09:19
title 测试1 （启动DOS6.22正常）
map (fd0) (hd1)
map --hook
map --mem (hd1,0)/onekey/onekey.ima (fd0)
map --hook
commandline
map --status
geometry (fd0)

Fr To Hm Sm  To_C _H _S

00 FF 03  12 88F1 FE 7F

title 测试2 （启动DOS6.22正常）
map --mem (fd0,0)/onekey/onekey.ima (fd1)
map --hook
map (fd0) (fd1)
map (fd1) (fd0)
map --hook
commandline
map --status
geometry (fd0)

Fr To Hm Sm  To_C _H _S

00 FF 03  12 809F 03 52

To_C _H _S两次测试也不一样，DOS6.22却都能正常启动，搞不懂。

[ 本帖最后由 mygamexxx 于 2011-10-29 09:22 编辑 ]

作者: chenall 时间: 2011-10-29 09:29
标题: 回复 #94 mygamexxx 的帖子
使用--mem参数的时候都是使用LBA的C/H/S的值没有用处.

作者: chenall 时间: 2011-10-29 09:30
标题: 回复 #91 rockrock99 的帖子
你可以先简单映射一个IMG启动试试,不要交换磁盘等操作.排除影响.

作者: mygamexxx 时间: 2011-10-29 09:50
测试8月9日和5月9日的grldr，每种测试分别相同。

测试1
Fr To Hm Sm  To_C _H _S

00 FF 03  24 8840 FE 7F

测试2
Fr To Hm Sm  To_C _H _S

00 FF 03  24 8040 FE 7F

作者: rockrock99 时间: 2011-10-29 09:55
标题: 回复 #96 chenall 的帖子
之前根据P大的指导测试过，确定是MS-DOS 7.1的问题（这个问题会导致0PE v1.3.x的PE启动不了），freeDOS是可以正常启动的（DiskGen镜像）

作者: chenall 时间: 2011-10-29 09:58
标题: 回复 #94 mygamexxx 的帖子
把你的IMG传给我测试下,看看能不能重现.

作者: chenall 时间: 2011-10-29 09:59
标题: 回复 #98 rockrock99 的帖子
那看来就是属于MSDOS 7.1的问题了.

欢迎光临无忧启动论坛 (http://wuyou.net/)