标题: QDMA / QCACHE V3.6 (2006-10-09)
[打印本页]
作者: johnsonlam
时间: 2006-10-11 05:25
标题: QDMA / QCACHE V3.6 (2006-10-09)
2006-10-09
- [ QDMA / QCACHE V3.6 ] QDBOOT is now "general purpose", to support SATA and other disks for UMBPCI! QDBOOT takes only 32 low memory bytes! No run-time QCACHE/QDMA changes.
----
QDBOOT 已 变 成 一 般 常 用 程 序 ( 已 不 是 专 为 QDMA 而 设 ) ， 为 了 在 UMBPCI 下 支 援 SATA 作 出 了 些 修 改 ( QDMA 仍 未 有 SATA 支 援 ， 只 有 QCACHE 可 以 ) 。
QDBOOT 现 在 只 在 传 统 记 忆 体 占 32 bytes ! QDMA 和 QCACHE 没 有 改 动 。
[
Last edited by johnsonlam on 2006-10-11 at 05:27 ]
作者: weilong888
时间: 2006-10-11 09:05
With many thanks to Jack.
作者: fastslz
时间: 2006-10-12 13:25
测试QCACHE V3.6能在我的主板启动后，又测试了QHIMEM也能胜利加载。我的VIA P4X266 VL33-S即QCACHE V3.6、QHIMEM V3.1后终于能使用Q全系列了，请johnsonlam转告Jack这一消息，这一项突破意味着Q全系列兼容VIA有了更深一层。
简单描述下各版本测试情况：
QCACHE V3.4 启动过程中未看见提示直接重启
QCACHE V3.5 未做测试
QCACHE V3.6 启动后未见异常
QHIMEM2.8或2.9 之前任何参数都不能启动
QHIMEM3.0 未做测试
QHIMEM3.1 任何参数都能启动，启动后异常不能确定（可能我配置参数有误）
也就是说QCACHE V3.4～V3.6和QHIMEM2.8～3.1之间的变化，这些版本之间的差别对比可能对 Jack 有用
测试用参数：
| Quote: |
DEVICE=DOS\QHMBOOT.SYS
DEVICE=DOS\QDBOOT.SYS
DEVICE=DOS\QHIMEM.SYS
DEVICE=DOS\UMBPCI.SYS NOEMS
DEVICEHIGH=DOS\LOWDMA.SYS
DEVICEHIGH=DOS\QDREL.SYS
DEVICEHIGH=DOS\QCDROM.SYS /D:IDE-CD01 /UF /L
DEVICEHIGH=DOS\QDMA.SYS /K /L
DEVICEHIGH=DOS\QCACHE.SYS
SHELL=COMMAND.COM /E:1024 /P /F
DOS=HIGH,UMB,AUTO
FCBSHIGH=4,0
FILESHIGH=30
BUFFERSHIGH=20,0
STACKSHIGH=9,256
DEVICEHIGH=DOS\RAMDRIVE.SYS /E 8192
LASTDRIVEHIGH=Z |
|
MEM数据：
| Quote: |
1 Mb 以下使用内存的模块:
名称 总计 = 常规内存 + 上位内存
-------- ---------------- ---------------- ----------------
SYSTEM 18,160 (18K) 9,840 (10K) 8,320 (8K)
QHMBOOT 64 (0K) 64 (0K) 0 (0K)
QDBOOT 880 (1K) 880 (1K) 0 (0K)
QHIMEM 1,904 (2K) 1,904 (2K) 0 (0K)
UMBPCI 160 (0K) 160 (0K) 0 (0K)
TW 47,216 (46K) 38,800 (38K) 8,416 (8K)
QCDROM 2,304 (2K) 0 (0K) 2,304 (2K)
QDMA 1,088 (1K) 0 (0K) 1,088 (1K)
QCACHE 3,376 (3K) 0 (0K) 3,376 (3K)
RAMDRIVE 1,440 (1K) 0 (0K) 1,440 (1K)
SHCDX33A 6,048 (6K) 0 (0K) 6,048 (6K)
DOSLFN 28,816 (28K) 0 (0K) 28,816 (28K)
ZENO 1,376 (1K) 0 (0K) 1,376 (1K)
DOSKEY 3,968 (4K) 0 (0K) 3,968 (4K)
COMMAND 10,752 (11K) 0 (0K) 10,752 (11K)
CTMOUSE 3,328 (3K) 0 (0K) 3,328 (3K)
FREE 597,152 (583K) 594,480 (581K) 2,672 (3K)
内存总计:
内存类型 总共 = 已使用 + 空闲
---------------- ----------- ----------- -----------
常规内存 646,144 51,664 594,480
上位内存 81,904 79,232 2,672
保留内存 320,528 320,528 0
扩展内存 (XMS) 66,060,288 4,105,764,8 255,262,720
---------------- ----------- ----------- -----------
总内存 67,108,864 4,106,216,2 255,859,872
1 MB 以下内存数 728,048 130,896 597,152
总计扩充内存 (XMS) 66,060,288 (64,512K)
空闲扩充内存 (XMS) 255,262,720 (249,280K)
最大可执行程序尺寸 594,176 (580K)
最大空闲上位内存块 2,224 (2K)
空闲高内存区数 288 (0K)
MS-DOS 驻留在高位内存区中. |
|
唯一疑问；扩展内存 (XMS) 数总共为什么是66,060,288而不是 （已使用 + 空闲数的总和）；也就是之前说的不能确定异常情况。也试着用README.EXE推荐配置都有(XMS) 数不符的情况，请johnsonlam看下是否有更好的配置方法？
哦、补充说明上面的测试参数：在未加载SMARTDRV.EXE情况下进行594MB大小文件复制测试用时46.5秒。
[
Last edited by fastslz on 2006-10-12 at 13:46 ]
作者: darkradx
时间: 2006-10-12 15:09
哪个版本的mem得到的数据啊?建议用Freedos1.0里面的(举个例子:MS710的MEM就无法读FDXXMS的XMS信息, Freedos的就可以)
MEM程序如果INT15/XMS3.0(XMS16)/(XMS3.0)XMS32三种接口混合使用取内存信息的话, 会出现数值不符吧
作者: fastslz
时间: 2006-10-12 21:40
标准版MS-DOS 7.1里面的MEM，且用HIMEM.SYS时显示的(XMS) 总数是正确的
作者: Wengier
时间: 2006-10-12 21:58
| Quote: |
Originally posted by fastslz at 2006-10-12 09:40 PM:
标准版MS-DOS 7.1里面的MEM，且用HIMEM.SYS时显示的(XMS) 总数是正确的 |
|
这个MEM有一个我早已发现的特点，那就是如果它检测到INT2F的AX=1600号功能为非0的时候（比如WIN运行时或在HDPMI32加载后）会将总XMS内存最大显示为64MB，而剩余XMS内存则正确；如果INT2F的AX=1600号功能为0的时候（如通常的实模式DOS下等等）则两项均正常显示。由此可见，这仅仅是MEM显示的问题，而总XMS内存并不是说只有64MB。我觉得这有可能其设计者有意这样设计的，比如说在某些环境下为了某种兼容性（？）。
作者: fastslz
时间: 2006-10-12 22:22
谢谢站长解答
Re:darkradx
我对Freedos1.0不感冒一下子找个Freedos1.0版的MEM还真不容易
作者: Wengier
时间: 2006-10-12 22:32
| Quote: |
Originally posted by fastslz at 2006-10-12 10:22 PM:
谢谢站长解答
Re:darkradx
我对Freedos1.0不感冒一下子找个Freedos1.0版的MEM还真不容易:D |
|
fastslz不妨试试DOS完整版中的MEM（已上传到附件中），这个应该正确能显示出总XMS内存的：
附件
1: 
MEM.EXE (2006-10-12 22:32, 14.5 K, 下载附件所需积分 1点
,下载次数： 22)
作者: fastslz
时间: 2006-10-12 22:54
这个MEM和我之前用的MEM MD5校验值不同，得出的数据还是一样的不能显示出总XMS内存。
用Freedos1.0的MEM：
| Quote: |
Modules using memory below 1 MB:
Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 18,160 (18K) 9,840 (10K) 8,320 (8K)
QHMBOOT 80 (0K) 80 (0K) 0 (0K)
QDBOOT 896 (1K) 896 (1K) 0 (0K)
QHIMEM 1,920 (2K) 1,920 (2K) 0 (0K)
UMBPCI 176 (0K) 176 (0K) 0 (0K)
TW 47,216 (46K) 38,800 (38K) 8,416 (8K)
QCDROM 2,320 (2K) 0 (0K) 2,320 (2K)
QDMA 1,104 (1K) 0 (0K) 1,104 (1K)
QCACHE 3,392 (3K) 0 (0K) 3,392 (3K)
RAMDRIVE 1,456 (1K) 0 (0K) 1,456 (1K)
SHCDX33A 6,048 (6K) 0 (0K) 6,048 (6K)
DOSLFN 28,816 (28K) 0 (0K) 28,816 (28K)
ZENO 1,376 (1K) 0 (0K) 1,376 (1K)
DOSKEY 3,968 (4K) 0 (0K) 3,968 (4K)
COMMAND 10,752 (11K) 0 (0K) 10,752 (11K)
CTMOUSE 3,328 (3K) 0 (0K) 3,328 (3K)
Free 596,864 (583K) 594,192 (580K) 2,672 (3K)
Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 631K 51K 580K
Upper 80K 77K 3K
Reserved 313K 313K 0K
Extended (XMS) 258,176K 8,896K 249,280K
---------------- -------- -------- --------
Total memory 259,200K 9,337K 249,863K
Total under 1 MB 711K 128K 583K
Largest executable program size 580K (594,176 bytes)
Largest free upper memory block 2K ( 2,224 bytes)
Windows is resident in the high memory area. |
|
作者: Wengier
时间: 2006-10-12 23:03
可见如我上面所说这纯粹是MEM的显示问题，跟系统的实际总内存情况无关。不过上面这个MEM似乎也有个显示的小BUG，明明WIN没有运行甚至根本没有安装，却说“Windows is resident in the high memory area.”。
作者: fastslz
时间: 2006-10-12 23:29
理解了，确实只是MEM的显示问题。
另外测试：用HIMEME.SYS并加载HDPMI32后，显示XMS的总数还是正确的，也就加载QHIMEME.SYS后显示不正常
| Quote: |
1 Mb 以下使用内存的模块:
名称 总计 = 常规内存 + 上位内存
-------- ---------------- ---------------- ----------------
SYSTEM 28,880 (28K) 9,872 (10K) 19,008 (19K)
HIMEM 1,152 (1K) 1,152 (1K) 0 (0K)
UMBPCI 160 (0K) 160 (0K) 0 (0K)
LOWDMA 672 (1K) 672 (1K) 0 (0K)
QCDROM 2,304 (2K) 2,304 (2K) 0 (0K)
QDMA 1,088 (1K) 1,088 (1K) 0 (0K)
QCACHE 3,376 (3K) 3,376 (3K) 0 (0K)
NDOS 34,576 (34K) 34,048 (33K) 528 (1K)
TW 43,936 (43K) 38,800 (38K) 5,136 (5K)
HDPMI32 13,056 (13K) 13,056 (13K) 0 (0K)
RAMDRIVE 1,440 (1K) 0 (0K) 1,440 (1K)
SHCDX33A 6,048 (6K) 0 (0K) 6,048 (6K)
DOSLFN 28,816 (28K) 0 (0K) 28,816 (28K)
ZENO 1,376 (1K) 0 (0K) 1,376 (1K)
CTMOUSE 3,328 (3K) 0 (0K) 3,328 (3K)
COMMAND 7,808 (8K) 0 (0K) 7,808 (8K)
DOSKEY 3,968 (4K) 0 (0K) 3,968 (4K)
FREE 546,048 (533K) 541,600 (529K) 4,448 (4K)
内存总计:
内存类型 总共 = 已使用 + 空闲
---------------- ----------- ----------- -----------
常规内存 646,144 104,544 541,600
上位内存 81,904 77,456 4,448
保留内存 189,456 189,456 0
扩展内存 (XMS) 264,372,224 13,094,912 251,277,312
---------------- ----------- ----------- -----------
总内存 265,289,728 13,466,368 251,823,360
1 MB 以下内存数 728,048 182,000 546,048
总计扩充内存 (XMS) 264,372,224 (258,176K)
空闲扩充内存 (XMS) 251,277,312 (245,388K)
最大可执行程序尺寸 540,848 (528K)
最大空闲上位内存块 4,000 (4K)
空闲高内存区数 5,328 (5K)
MS-DOS 驻留在高位内存区中. |
|
作者: Wengier
时间: 2006-10-12 23:47
| Quote: |
Originally posted by fastslz at 2006-10-12 11:29 PM:
理解了，确实只是MEM的显示问题。
另外测试：用HIMEME.SYS并加载HDPMI32后，显示XMS的总数还是正确的，也就加载QHIMEME.SYS后显示不正常
|
|
在HIMEME.SYS并加载HDPMI32后的情况下，就要看是哪个MEM了吧？印象中前面那两个MEM的显示结果是不同的（其中前者，即你最开始用的那个会显示为64MB，除非设置HDPMI=16384；而后者，即上面附件中上传的那个则正确）。
作者: fastslz
时间: 2006-10-12 23:56
站长不好意思了，我没有注明，我用的是了之前的MEM，也没设置HDPMI=16384，就你最新加载ifs方法。
HDPMI32
NDOS -LFN -MOUNTALL -CP:936
DRVLIST.EXE
附上我用的MEM
原附件已被作者删除~~~~
[
Last edited by fastslz on 2006-11-8 at 02:39 PM ]
作者: Wengier
时间: 2006-10-13 00:14
| Quote: |
Originally posted by fastslz at 2006-10-12 11:56 PM:
站长不好意思了，我没有注明，我用的是了之前的MEM，也没设置HDPMI=16384，就你最新加载ifs方法。
HDPMI32
NDOS -LFN -MOUNTALL -CP:936
DRVLIST.EXE
附上我用� ... |
|
嗯，看来你上传的这个MEM和我说的那个“前者”所指并不相同。若你试试下面附件中的MEM就应该能看出区别了。
附件
1: 
MEM.ZIP (2006-10-13 00:14, 19.06 K, 下载附件所需积分 1点
,下载次数： 12)
作者: johnsonlam
时间: 2006-10-13 02:08
| Quote: |
Originally posted by fastslz at 2006-10-12 11:56 PM:
站长不好意思了，我没有注明，我用的是了之前的MEM，也没设置HDPMI=16384，就你最新加载ifs方法。 |
|
你 的 QDBOOT v3.6 占 880 bytes 即 是 CONFIG.SYS 內 次 序 排 错 了 ， 请 小 心 看 看 QDMA 的 README ， 配 合 QDREL 后 QDBOOT 不 该 占 880 bytes 那 么 多 !
還 有 ， 由 於 QHIMEM.SYS 為 了 省 記 憶 ， XMS handle 查 表 只 是 7 bit ， 除 了 FreeDOS MEM 能 夠 正 確 顯 示 ， 其 它 如 MI.COM 會 偵 錯 !
要 是 你 在 意 ， 可 以 用 QHIMEM2.SYS ， 它 是 與 M$ 的 HIMEM 一 樣 ， 使 用 10 bit handle 的
[
Last edited by johnsonlam on 2006-10-13 at 02:12 ]
作者: xugaohui
时间: 2006-10-13 02:16
还是98se中那个mem.exe显示的准确。文件日期1999-5-5，freedos的mem.com的有些问题， 用freedos的mem第一项SYSTEM 经常显示出占用上位内存100K以上。
Upper 内存总大小很离谱，freedos的中的deltree有两版本，其中一个版本不能用/y参数。换用98se的程序就没问题了，只是文件会大一些。
作者: darkradx
时间: 2006-10-13 02:29
很久以前做的表
XMS2.0 XMS3.0(XMS16) XMS3.0(XMS32) PMode EMS4.0
HIMEM.SYS(MSDOS7.10) N 64M 4G N N
HIMEM.SYS(ROMDOS7.10) N 64M N N N
HIMEM.SYS(DRDOS7.03) N 64M N N N
FDXMS.SYS(FREEDOS) 64M N N N N
FDXXMS.SYS(FREEDOS) N 64M 4G N N
HIMEM.EXE(FREEDOS) N 64M 4G N N
EMM386.EXE(MSDOS7.10) N N N Y 32M
EMM386.EXE(FREEDOS) N N N Y 32M
EMM386.EXE(DRDOS7.03) N 64M 64M Y 32M
QEMM386.SYS(QEMM7.50) N 64M 64M Y 64M
QEMM386.SYS(QEMM9.00) N 64M 4GB Y 4GB
作者: zts59
时间: 2006-10-13 06:03
我一直没有用过Qboot.sys
我想问一下，QDBOOT在应用上面起什么作用？
望告知。谢谢
作者: fastslz
时间: 2006-10-13 08:58
darkradx够细心的
站长14楼的附件试了，使用QHIMEME.SYS或HIMEME+HDPMI32后显示除总XMS数不正确外连已使用XMS数都成？了，此MEM应该就是xugaohui所说的98se中那个（文件日期也是1999-5-5的），站长8楼上传MEM和我13楼上传MEM估计版本相同的只是站长那个已经压缩过的（个头小）。
最后希望站长有空时把USBASPI.SYS V2.20和UMBPCI.SYS V3.67压缩下分享给大家这2个SYS经压缩后估计能节省30KB空间
作者: Wengier
时间: 2006-10-13 10:43
那个我上传的98se中的MEM在HIMEM+HDPMI32下会将总XMS内存显示为64MB，而剩余内存则超过64MB，总内存比剩余内存还小，所以已用内存自然会被显示为？号或错误的数值了。而我们上传的DOS 7.1启动盘中的MEM（分别为压缩版和未压缩版）则不会这样。
USBASPI.SYS和UMBPCI.SYS的压缩版见附件：
附件
1: SYS.ZIP (2006-10-13 10:43, 27.96 K, 下载附件所需积分 1点
,下载次数： 15)
作者: fastslz
时间: 2006-10-13 10:58
| Quote: |
Originally posted by johnsonlam at 2006-10-13 02:08:
你 的 QDBOOT v3.6 占 880 bytes 即 是 CONFIG.SYS 內 次 序 排 错 了 ， 请 小 心 看 看 QDMA 的 README ， 配 合 QDREL 后 QDBOOT 不 该 占 880 bytes 那 么 多 !...
|
|
经你提示检查了CONFIG.SYS，已确认不次序排错，是因QDBOOT.SYS未加参数/R /W的原因，我还为CONFIG.SYS里加载了QDREL.SYS用MEM查看却没有QDREL.SYS而不解呢，原来QDBOOT.SYS是依赖QDREL.SYS来减少内存占用的。既然其它MI.COM侦错也属于正常现象也无所谓 QHIMEM2.SYS 了
作者: fastslz
时间: 2006-10-13 11:12
谢谢站长的USBASPI.SYS和UMBPCI.SYS的压缩版，太好了个头小了26多K