China DOS Union

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 ]

非常感谢杰克。

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
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

Memory data:

Memory modules using less than 1 Mb:

Name Total = Conventional Memory + Upper Memory
-------- ---------------- ---------------- ----------------
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)

Total memory:

Memory Type Total = Used + Free
---------------- ----------- ----------- -----------
Conventional Memory 646,144 51,664 594,480
Upper Memory 81,904 79,232 2,672
Reserved Memory 320,528 320,528 0
Extended Memory (XMS) 66,060,288 4,105,764,8 255,262,720
---------------- ----------- ----------- -----------
Total Memory 67,108,864 4,106,216,2 255,859,872

Memory below 1 MB 728,048 130,896 597,152

Total Extended Memory (XMS) 66,060,288 (64,512K)
Free Extended Memory (XMS) 255,262,720 (249,280K)

Maximum Executable Program Size 594,176 (580K)
Maximum Free Upper Memory Block 2,224 (2K)
Number of Free High Memory Blocks 288 (0K)
MS-DOS is resident in the high memory area.

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 ]

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?

The total number of (XMS) displayed when using HIMEM.SYS in the standard version of MS-DOS 7.1 is correct

Originally posted by fastslz at 2006-10-12 09:40 PM:
The total number of (XMS) displayed by MEM in standard MS-DOS 7.1 when using HIMEM.SYS is correct

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 (?).

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

Originally posted by fastslz at 2006-10-10 10:22 PM:
Thanks to the webmaster for the answer
Re:darkradx
I'm not interested in Freedos 1.0. It's really not easy to find a version of Freedos 1.0's MEM :D

Why not try the MEM from the full DOS version (attached), this should correctly show the total XMS memory:

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:

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.

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.

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:

Name Total = Conventional Memory + Upper Memory
-------- ---------------- ---------------- ----------------
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)

Total memory:

Memory Type Total = Used + Free
---------------- ----------- ----------- -----------
Conventional Memory 646,144 104,544 541,600
Upper Memory 81,904 77,456 4,448
Reserved Memory 189,456 189,456 0
Extended Memory (XMS) 264,372,224 13,094,912 251,277,312
---------------- ----------- ----------- -----------
Total Memory 265,289,728 13,466,368 251,823,360

Number of memory below 1 MB 728,048 182,000 546,048

Total Extended Memory (XMS) 264,372,224 (258,176K)
Free Extended Memory (XMS) 251,277,312 (245,388K)

Maximum executable program size 540,848 (528K)
Maximum free upper memory block 4,000 (4K)
Number of free high memory blocks 5,328 (5K)
MS-DOS is resident in the upper memory area.

Originally posted by fastslz at 2006-10-12 11:29 PM:
Understood, it's indeed just a display issue with MEM.
In addition, testing: when using HIMEME.SYS and loading HDPMI32, the total number of XMS displayed is still correct, that is, the display is abnormal after loading QHIMEME.SYS

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).

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 ]

Originally posted by fastslz at 2006-10-12 11:56 PM:
Sorry, webmaster. I didn't note it. I used the previous MEM and didn't set HDPMI=16384, just used your latest method of loading IFS.
HDPMI32
NDOS -LFN -MOUNTALL -CP:936
DRVLIST.EXE

Attached is what I used...

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.

Originally posted by fastslz at 2006-10-12 11:56 PM:
Sorry, webmaster. I didn't note it. I used the previous MEM and didn't set HDPMI=16384, just your latest method of loading IFS.

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 ]