China DOS Union
-- Unite DOS · Advance DOS · Grow DOS --Union site: www.cn-dos.net Forum site: www.cn-dos.net/forum
|
China DOS Union-- Unite DOS · Advance DOS · Grow DOS --Union site: www.cn-dos.net Forum site: www.cn-dos.net/forum |
| Guest | Log in | Register | Members | Search | China DOS Union |
|
中国DOS联盟论坛 The time now is 2026-08-01 22:58 |
48,037 topics / 350,122 posts / today 2 new / 48,250 members |
| DOS开发编程 & 发展交流 （开发室） » QDMA / QCACHE V3.6 (2006-10-0的9) |
| Printable Version 3,764 / 21 |
| Floor1 johnsonlam | Posted 2006-10-11 05:25 |
| 银牌会员 Posts 497 Credits 1,410 From 九龍，香港 | |
|
2006-10-09 - 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 has become a general-purpose program (no longer dedicated to QDMA), and some modifications have been made to support SATA under UMBPCI (QDMA still does not support SATA, only QCACHE does). QDBOOT now only occupies 32 bytes in conventional memory! There are no changes to QDMA and QCACHE. [ Last edited by johnsonlam on 2006-10-11 at 05:27 ] |
|
| Floor2 weilong888 | Posted 2006-10-11 09:05 |
| 银牌会员 Posts 548 Credits 1,270 | |
|
非常感谢杰克。
|
|
| Floor3 fastslz | Posted 2006-10-12 13:25 |
| 铂金会员 Posts 2,315 Credits 5,493 From 上海 | |
|
Tested QCACHE V3.6 and it could boot on my motherboard. Then tested QHIMEM and it loaded successfully. After that, with my VIA P4X266 VL33-S, QCACHE V3.6 and QHIMEM V3.1, I finally could use the Q series. Please inform Johnsonlam to tell Jack this news. This breakthrough means that the Q series has deeper compatibility with VIA.
Brief description of the testing situations of each version: QCACHE V3.4: Rebooted without seeing prompts during the boot process QCACHE V3.5: Not tested QCACHE V3.6: No abnormal situation seen after boot QHIMEM 2.8 or 2.9: Could not boot with any parameters before QHIMEM 3.0: Not tested QHIMEM 3.1: Could boot with any parameters, but abnormal situation after boot could not be determined (maybe I configured parameters incorrectly) That is to say, the changes between QCACHE V3.4～V3.6 and QHIMEM 2.8～3.1, the difference comparison between these versions may be useful to Jack Testing parameters: DEVICE=DOS\QHMBOOT.SYS Memory data: Memory modules using less than 1 Mb: Only question: Why is the total Extended Memory (XMS) 66,060,288 instead of the sum of used and free? That is to say, the abnormal situation could not be determined before. Also, there was a situation where the XMS number did not match when using the configuration recommended by README.EXE. Please let Johnsonlam see if there is a better configuration method? Oh, supplement the above testing parameters: Copied a 594MB file without loading SMARTDRV.EXE and it took 46.5 seconds. [ Last edited by fastslz on 2006-10-12 at 13:46 ] |
|
| Floor4 darkradx | Posted 2006-10-12 15:09 |
| 高级用户 Posts 420 Credits 972 | |
|
Which version of MEM gets the data? It is recommended to use the one in FreeDOS 1.0 (for example: MEM of MS710 cannot read XMS information of FDXXMS, but MEM of FreeDOS can). If the MEM program uses a mixed use of INT15/XMS3.0 (XMS16)/(XMS3.0) XMS32 interfaces to obtain memory information, there will be inconsistent values, right?
|
|
| Floor5 fastslz | Posted 2006-10-12 21:40 |
| 铂金会员 Posts 2,315 Credits 5,493 From 上海 | |
|
The total number of (XMS) displayed when using HIMEM.SYS in the standard version of MS-DOS 7.1 is correct
|
|
| Floor6 Wengier | Posted 2006-10-12 21:58 |
| 系统支持 Posts 10,521 Credits 27,736 | |
Originally posted by fastslz at 2006-10-12 09:40 PM: This MEM has a feature that I have long discovered: that is, if it detects that the AX=1600 function of INT2F is non-zero (such as when WIN is running or after HDPMI32 is loaded), it will display the maximum total XMS memory as 64MB, while the remaining XMS memory is displayed correctly; if the AX=1600 function of INT2F is 0 (such as in normal real-mode DOS, etc.), both items are displayed normally. It can be seen that this is only a display problem of MEM, and the total XMS memory is not said to be only 64MB. I think this may be designed intentionally by its designer, for example, for some compatibility in certain environments (?). |
|
| Floor7 fastslz | Posted 2006-10-12 22:22 |
| 铂金会员 Posts 2,315 Credits 5,493 From 上海 | |
|
Thanks to the webmaster for the explanation
Re: darkradx I'm not interested in Freedos 1.0. It's really not easy to find a MEM for Freedos 1.0 version at once  |
|
| Floor8 Wengier | Posted 2006-10-12 22:32 |
| 系统支持 Posts 10,521 Credits 27,736 | |
Originally posted by fastslz at 2006-10-10 10:22 PM: Why not try the MEM from the full DOS version (attached), this should correctly show the total XMS memory: Attachments MEM.EXE (14.5 KiB) |
|
| Floor9 fastslz | Posted 2006-10-12 22:54 |
| 铂金会员 Posts 2,315 Credits 5,493 From 上海 | |
|
This MEM has a different MD5 checksum from the one I used before, and the data obtained still can't display the total XMS memory.
Using MEM of FreeDOS 1.0:
|
|
| Floor10 Wengier | Posted 2006-10-12 23:03 |
| 系统支持 Posts 10,521 Credits 27,736 | |
|
It can be seen that, as I said above, this is purely a display problem of MEM and has nothing to do with the actual total memory situation of the system. However, there seems to be a small display bug in the above MEM. It says "Windows is resident in the high memory area." even though Windows is not running or not installed at all.
|
|
| Floor11 fastslz | Posted 2006-10-12 23:29 |
| 铂金会员 Posts 2,315 Credits 5,493 From 上海 | |
|
Understood, it's indeed just a display issue with MEM.
In addition, the test: when using HIMEME.SYS and loading HDPMI32, the total number of XMS displayed is still correct, that is, after loading QHIMEME.SYS, the display is abnormal Modules using memory below 1 Mb: |
|
| Floor12 Wengier | Posted 2006-10-12 23:47 |
| 系统支持 Posts 10,521 Credits 27,736 | |
Originally posted by fastslz at 2006-10-12 11:29 PM: Under the condition of HIMEME.SYS and loading HDPMI32, we need to see which MEM it is? I remember that the display results of the first two MEMs are different (the former, that is, the one you initially used will display as 64MB, unless HDPMI=16384 is set; while the latter, that is, the one uploaded in the above attachment is correct). |
|
| Floor13 fastslz | Posted 2006-10-12 23:56 |
| 铂金会员 Posts 2,315 Credits 5,493 From 上海 | |
|
Webmaster, I'm sorry. I didn't note it. I used the previous MEM and didn't set HDPMI=16384, just your latest method of loading ifs.
HDPMI32 NDOS -LFN -MOUNTALL -CP:936 DRVLIST.EXE Attached is the MEM I used The original attachment has been deleted by the author~~~~ [ Last edited by fastslz on 2006-11-8 at 02:39 PM ] |
|
| Floor14 Wengier | Posted 2006-10-13 00:14 |
| 系统支持 Posts 10,521 Credits 27,736 | |
Originally posted by fastslz at 2006-10-12 11:56 PM: Well, it seems that the MEM you uploaded is not the same as the "former" one I mentioned. If you try the MEM in the following attachment, you should be able to see the difference. Attachments MEM.ZIP (19.06 KiB) |
|
| Floor15 johnsonlam | Posted 2006-10-13 02:08 |
| 银牌会员 Posts 497 Credits 1,410 From 九龍，香港 | |
Originally posted by fastslz at 2006-10-12 11:56 PM: Your QDBOOT v3.6 takes 880 bytes, which means the order in CONFIG.SYS is wrong. Please carefully check the QDMA README. After matching with QDREL, QDBOOT should not take so many 880 bytes! Also, because QHIMEM.SYS saves memory, the XMS handle lookup table is only 7-bit. Except that FreeDOS MEM can correctly display, others like MI.COM will detect errors! If you care, you can use QHIMEM2.SYS, which is the same as M$'s HIMEM, using 10-bit handle [ Last edited by johnsonlam on 2006-10-13 at 02:12 ] |
|
| 1 2 Next |
|
[ Contact the Union admin team -
中国DOS联盟 -
Standard version ] Sponsored by ifanr Inc | © 2001–2023 |