C大，GRUB4DOS的map功能能不能添加缓存？

hotdll

我查了下grub4dos的资料，直接map的是时候，使用的是INT 13H 直接将操作参数映射到被映射文件。

如果bios识别设备U盘设备或者其他设备为USB-FDD 或者USB-ZIP设备的话，BIOS 的INT 13H 就会按照fd驱动及速度去访问该设备。

所以map的时候，哪速度肯定只有30K以下。甚至更慢。

如果在内存中开辟一块空间，比如2M，以直接以文件的方式读取被映射文件的前2M块到该缓存。然后将映射地址指向该内存。。。

这样直接map 就可以不用int 13h中断。甚至可以要求文件不连续。

那速度真是杠杠的。

[ 本帖最后由 hotdll 于 2011-11-14 22:03 编辑 ]

快雪时晴

关注中，看看有没有谁继续做出突破性的东西来...

hotdll

你从来不搞UD不能否定FB，FB对大部分人来说并不是浮云。

USB-ZIP你强制了不算。至于速度有没有关系，论坛早有定论。。。不是你说无关就无关的。

你强制的USB-ZIP还是USB-HDD，没有任何的讨论意义。

幸运的草

本来是跟ZIP模式无关，但由于大部分2.0接口的“老”电脑，并不是从BIOS起就支持2.0驱动，而是在WINDOWS下支持2.0驱动，所以在WINDOWS下读写U盘速度很快，但BIOS中没有集成ZIP的2.0驱动。当BIOS检测到U盘为ZIP时,G4D会根据BIOS的检测去调相应的模块，由于没有2.0驱动，只能以30K左右的速度去读U盘,慢得很，这时就与BIOS有关了。
  而你的新机是真正的支持2.0，也就是在BIOS中集成了2.0的驱动模块，所以就很快了。但并不是所有的新机都是如此，有的新机也没有集成2.0驱动，所以也并不快。

[ 本帖最后由 幸运的草 于 2011-11-18 08:18 编辑 ]

rockrock99

我也严重同意，因为我从来不搞UD，FB对我来说是浮云，还是加强G4D实际

另外插一句，速度跟USB-ZIP模式无关，我已经用联想的T4900V主板证实了：新旧两个BIOS，模式都是强制成USB-ZIP，但新BIOS就很明显改善了速度

hotdll

原帖由 不点 于 2011-11-17 09:39 发表
grub4dos 对于设备本来就有内部缓存，不过缓存较小，只有 63 个扇区（31.5K）。

任何设备，不管是不是被 map 了的设备，都有这个缓存。缓存是 1 个磁道（通常就是 63 扇区）。

这个缓存的功能是原来的 GN ...

我刚刚突然想起不点大师说的这句话。

识别为USB-ZIP的时候，读盘速度就是30K左右。

因为加载3.4M的镜像 大概需要2分钟时间，也就是120秒左右。算来就是30K/S的样子。

hotdll

但是BIOS并不这么认为。

Plantsoot

ud区有自己的格式，不是FAT也不是FAT32。

hotdll

严重同意。。。。
其实我现在觉得NTFS格式的U盘理论上通用性更好一些。
或者是FB的格式从FAT变成FAT32

不点

让 fb 识别为 HDD，估计也是 “有门” 的。

注意研究 fb 盘与那些被识别为 HDD 的有什么差别。先猜测 BIOS 会找到什么差别来区分两者，然后再验证这个猜测。

所以我觉得有必要开发 fb 的替代软件，克服 fb 的一些问题。

pseudo

现在机器普遍很好，速度不成大问题。好像不大必要为此做大动作。

有许多应对办法。例如借助burg、memdisk等。
纯g4d也可以对付。例如0pe的“半解开”部署方式，或直接U+（不创建分区）部署方式，对usb-zip与usb-hdd理论上速度没啥区别，都不会慢。

幸运的草

主要是ZIP时map 慢，而HDD时map 并不慢。估计是判断为ZIP时会以软驱的速度去读盘。
但如果想点什么办法，让BIOS识别成HDD，这个问题也就解决了。
能正确识别FB盘为ZIP及HDD的BIOS，把U盘fb 为HDD格式也解决了这个问题，主要是BIOS把FB的盘强行识别为ZIP，这个问题就有点麻烦。

　经测试，当U＋、U＋V2及用BOOTICE写入GRLDR引导代码时，BIOS都会正确识别为HDD。只有FB时才会识别成ZIP，无论是ZIP格式还是HDD格式。
　　不知FB时文件格式与其他的制作方式有什么不同？

2011qf020124

虽然我学习研究G4D的时间不长，但看到大家这么热情的讨论，也想来谈谈自己对G4D里MAP命令快慢的理解！！

1. 无论是直接map还是 map --mem,实现方式都是拦截int13中断，处理代码就放在640K的顶部！

2. 使用map --mem时，把映像加载到内存，然后在int13内部去访问内存，内存仿真盘int13的接口和普通物理磁盘的接口形式是一致的！！

3.直接map 时，本质是进行了int13的递归调用，即仿真盘的int13在其内部又去调用了真实磁盘的int13，这个递归的出口就是真实磁盘的int13调用！！

4.两种map都会使用到真实磁盘的int13，只是时机不同，所以依我看，g4d map的快慢，很大一部分原因取决于真实磁盘int13功能的速度，而这部分代码，是由主板bios提供的！除非g4d使用外部驱动，但使用外部驱动，可能会带来兼容性问题！

     以上属于个人理解，有不对的地方请指正！！！

hotdll

我记得软盘不能被格式化称fat32。软盘一般是fat12或者fat16 ,统称fat

幸运的草

确实经测试，我的那台机，如果U＋，U＋V2都可以正确识别是HDD还是ZIP格式，同时，用DG把U盘无论格式成FAT32还是NTFS，用BOOTICE写主引导为GRLDR时，也是识别为HDD。只有FB时，HDD格式才会识别为ZIP。
　但好像U盘为NTFS时有最小容量的限制，而且U盘上使用NTFS格式时会损伤U盘，缩短寿命。
所以微软开发了exfat分区格式。不过好像PE支持度不高。

hotdll

原帖由 不点 于 2011-11-17 15:23 发表
诚然啊！

不过现在我脑子中似乎就有了这样一个概念：既然主板 BIOS 不让传统的软盘支持 LBA， 那么，让 U 盘启动为软盘，这一行为，实际上成了 “不智之举”。

应该生办法不让 U 盘被主板识别为软盘，否则 ...

不点的解释正式我想要描述的。也让我明白了不少底层知识。

有一个办法，就是能不能让UD区变成NTFS格式或者其他格式。

因为研究发现。只要U盘的格式不是FAT格式，BIOS就是想把他当软盘，它也没那个本事。

Plantsoot

兼容UTF-8的代码已经写完，目前够用。格式化成UTF-8的代码没写，用fbinsttool1.605解决，暂时不考虑动fbinst的原始代码，当然，加上很简单。

今天下午 hdlist 的功能已经完成，准备加到plus版中，就OK了。

注意：杏雨梨云的udload 改用 plus版中的 output来导出文件就可以了。

[ 本帖最后由 Plantsoot 于 2011-11-17 16:10 编辑 ]

不点

诚然啊！

不过现在我脑子中似乎就有了这样一个概念：既然主板 BIOS 不让传统的软盘支持 LBA， 那么，让 U 盘启动为软盘，这一行为，实际上成了 “不智之举”。

应该生办法不让 U 盘被主板识别为软盘，否则，LBA 支持就可能被屏蔽掉了。这样，凭空产生了无穷无尽的麻烦。

比较而言，还是生办法让 U 盘被识别为硬盘比较好（支持 LBA 的可能性很大）。当 U 盘识别为硬盘 hd0 时，在 grub4dos 中，大不了就是一个磁盘交换（hd0 与 hd1）就可以把真实硬盘放在 hd0 的位置了。对于 grub4dos 来说，这是 “轻车熟路”，一点也不麻烦。

wannaknow

问题不仅如此，即使改进int 13h钩子，也会有性能损失。
对于虚拟的(0xff)来说，它是支持lba的大扇区光盘，不存在任何“对齐”的问题，每次读取都是以2048k为单位的。
可是，事实上，它可能是由1024/255/63的盘虚拟的。
只要bios不支持lba，再怎么改进，一次真实读取也不能跨过63这个“沟”
因此，会有大约3/63次读被“砍”成要读两次。

最糟的情况是18sectors per track，然后a.iso还是从奇数扇区开始的（又想了想，不对，a.iso的位置影响不大）。

[ 本帖最后由 wannaknow 于 2011-11-17 15:15 编辑 ]

wannaknow

唉，根源还是当初规定，一次int 13h调用(CHS)不能要求读写跨磁道的连续扇区，一切以简化bios编写为目标。

结果最后所有人都嫌麻烦，才提出LBA的概念。

不点

嗯，你的洞察力够强。

确实有这样的可能性。

当系统需要读取 b.iso 的时候，系统本身认为 b.iso 是在一个光盘上，这个光盘的号码是 0xff。

系统为 0xff 进行缓存。

但 0xff 是虚拟的，它的真实介质是普通的软盘（即 U 盘）。

所以，当系统需要读取 0xff 的一个磁道时（15 个大扇区，折合成普通的 512 字节小扇区，共有 60 个扇区），int13 的仿真程序需要去读取软盘介质。

当软盘支持 LBA 的时候，也就可以一次读取多个扇区了。每次可以读取 60 个扇区，这样，问题也不大。

但当软盘不支持 LBA 的时候，似乎为了简单起见，int13 仿真程序只使用 CHS 模式每次读一个扇区。这样，60 个扇区就需要 60 次读取的动作，那就慢如蜗牛了。由于 int13 程序没有缓存空间可用，所以，读取的速度也受到影响。

改进 int13 程序是可能的，但改进以后，有可能加大代码的体积，使得 int13 的代码超过 12K 的极限值，从而与其他软件造成冲突。

目前这个问题不太适合去解决，放任它吧。

最好的解决办法，就是要求 BIOS 全面支持 LBA 模式（对于软盘 fd0），也全面支持 USB 高速访问。只要 BIOS 没有问题，我们这里的问题就不复存在了。

幸运的草

回复 #17 chenall 的帖子
回复 #22 jianliulin 的帖子

如果是这样的话，那可能是调用工具不支持缘故。我只知道调用工具是调用fbinst.exe。测试工具为udload.exe,fbinst plus .目前支持utf-8的新fbinst plus由百草正在开发。。
代表PE作品为0pe1.30、1.31散开放UD区。杏雨梨云A版。当编码为ansi时，UD内中文文件名调用正常，但为utf-8时调用出错。即不识别。

wannaknow

我突然想起来，很久以前，在老爷机上，用word打开软盘上的文件，能卡10分钟。
但是要是先拷贝，再打开就快多了。

map --mem (0)/a.iso (0xff)
map --mem  (0xff)/b.iso (0xfa)
第二步很快是因为做了优化，直接原地重新map。但第一步应该比较慢


map (0)/a.iso (0xff)
map --mem (0xff)/b.iso (0xfa)
第二步成了蜗牛了。。。比从(0)读a.iso要慢

是不是因为第一步的map导致的对齐的问题？

[ 本帖最后由 wannaknow 于 2011-11-17 12:59 编辑 ]

Plantsoot

关于fbinst对UTF-8文件列表的支持，我把fbinst plus更新了，用新版fbinst plus 和 fbinsttool1.605 应该可以解决UTF-8的问题了。
因为是第三方扩展fbinst，我没改动fbinst原始的命令，或者说不具备修改fbinst原始代码的资格。使用UTF-8文件列表，可以用fbinsttool格式化U盘和导入文件，使用fbinst plus的plus的命令导出文件等等。

希望下面的帖子有点用处。


【Fbinst Plus V1.1 Beta - 2011-11-15】Fbinst增强版(支持UTF-8格式文件列表)

[ 本帖最后由 Plantsoot 于 2011-11-17 12:31 编辑 ]

hotdll

不点大师过奖了。。
我目前还是个G4D的使用者。
里开发还有很长的一段路。
最近在加班读汇编。。忘记完了。

不点

这样说，是想“鱼与熊掌兼得”。真的不能吗？

时机不对。你得耐心等待一个时机。当时机未到的时候，那是不可能的。但当时机来临的时候，那就是可能的了。chenall，bean，我，roy，yaya，足迹，zw2312914，karyonix，wannaknow 等等，数不清的人，都在做自己力所能及的工作，一刻也没闲着。其实，大家都在为着一个目标而努力，至于说努力的结果，那就不可强求了。该是什么样的结果，就是什么样的结果。

jianliulin

原帖由 幸运的草 于 2011-11-17 09:38 发表
楼主的意愿是好的，但很可能不会引起重视，我发的那个帖子目的也就是引起开发者及使用者的注意及重视，以解决这个问题，但难！
     个人认为目前最应该解决的两个问题就是：1：zip盘map慢的问题。2、fbinst不 ...

fbinst 不存在支持不支持utf-8 的问题，fbinst是按照字节对比的， 放什么进去就读什么出来，或者说fbinst天生就已经支持utf-8

不点

他肯定 hook 过了，否则不能执行第二个 map（他已经成功执行了第二个map）。

[ 本帖最后由 不点 于 2011-11-17 11:43 编辑 ]

幸运的草

G4D目前来说其实是很不错的。但有一个对用户来说很头疼的问题。那就是当zip时非--mem map时那速度真叫人难以忍受。如果可能的话，我们可以把U盘做成HDD格式，以避免这个问题。但是，有的机会把HDD格式的盘也认成ZIP，加载一个内核为30M左右的ISO，得等14分钟左右才能启动完毕。这种速度真是挑战人的忍耐极限。

为此我等菜鸟进行过测试、讨论，也采取了变通的变法解决这一问题。论坛上HOTDLL的两个关于PE的处理，将加载PE的速度提高到了40秒以内。但这种办法不是根本性的。
      HOTDLL的意思可能表达不准确，也是为了解决ZIP盘MAP慢的问题。
    或者，那位英才能解决这个问题？无论是少驱动还是什么？这个问题解决了，那G4D才真叫完美。

至于讲到了BURG，也并不是说他就完美，如果完美，那早就转过去了。与G4D相比，它也有很多不兼容。但它有两个优点：1.map时不需文件连续存放。2：zip盘map时没有速度的问题。
      这样说，是想“鱼与熊掌兼得”。真的不能吗？

wannaknow

map (0)/a.iso (0xff)
map --mem (0xff)/b.iso (0xfa)
中间是不是还要有map --hook啊，你是不是省略了？