Loading dos high on a XT

Krille · Jan 6, 2017

1541 said:
I am now using your updated version with an IBM PC 5150 which has two original IBM 64/256KB Memory Expansion Option cards in it. These cards actually allow putting RAM into the A000-AFFF segment (typically used by EGA and VGA graphics cards). That configuration can be used if one has a CGA, Hercules or MDA display adapter.

Maybe you could implement the functionality of CLEARMEM.SYS into USE!UMBS.SYS with a parameter like /ZEROFILL which would write zeroes into the configured upper memory blocks.

Thanks for the feedback and apologies for not responding sooner! Back when I did this I had apparently missed the discussion regarding parity errors and the need for something like Chuck's CLEARMEM.SYS, not to mention the fact that other people had already added command line parameter support.

Also;

Krille said:
Example CONFIG.SYS command line for a single 128 KB UMB starting at segment D000h:

Code:

DEVICE=USE!UMBS.SYS D000-EFFF

I don't know what I had been smoking that day because this command line will leave the last paragraph (16 bytes) unused. The correct line should look like this;

Code:

DEVICE=USE!UMBS.SYS D000-F000

Anyway, I've added the code to initialize the UMBs as requested (no need for any parameter though) and have also done some additional size optimizations.

View attachment USE!UMBS.ZIP

1541 · Jan 18, 2017

Thank you, this is now even more user-friendly and highly useful utility.

I have found out that IBM PC 5150 continues BIOS memory test to 704 kilobytes with undocumented SW2 DIP switch settings ON ON OFF ON OFF and DOS automatically uses all of that as conventional memory. This is an alternative way to utilize 64 kilobytes of RAM at segment A0000.

wondow · Feb 15, 2022

Thank you for making this utility configurable, it is very useful! I can now have UMB in my Tandy 1000 TX and SX. I was wondering if it is possible to have not continuous UMB? Does USE!UMBS accept arguments to take into account different memory range such as DEVICE=C:\USE!UMBS.SYS A000-AFFF D000-DFFF ?

Thank you!

Eudimorphodon · Feb 15, 2022

wondow said:
Thank you for making this utility configurable, it is very useful! I can now have UMB in my Tandy 1000 TX and SX. I was wondering if it is possible to have not continuous UMB? Does USE!UMBS accept arguments to take into account different memory range such as DEVICE=C:\USE!UMBS.SYS A000-AFFF D000-DFFF ?

FWIW, there *might* be an alternative for the TX (if the TX has "768K", see below if not) in your situation; if you google for "704K.COM" (or 704K.ZIP) you'll find an old piece of shareware that can give you 704K of contiguous conventional memory on machines that have RAM available in the A-page but the BIOS doesn't recognize it. I'm not sure it's compatible with *also* configuring upper memory blocks, however. (Long story why I suspect this, but I have no apropos hardware to test.)

This *won't* work on the SX, however. (Or a TX that only has "640K".) The way these machines take video pages dynamically off the end of DOS memory rules it out because A: the top of memory needs to fluctuate, and B: conventional RAM has to be contiguous.

wondow · Feb 16, 2022

Eudimorphodon said:
FWIW, there *might* be an alternative for the TX (if the TX has "768K", see below if not) in your situation; if you google for "704K.COM" (or 704K.ZIP) you'll find an old piece of shareware that can give you 704K of contiguous conventional memory on machines that have RAM available in the A-page but the BIOS doesn't recognize it. I'm not sure it's compatible with *also* configuring upper memory blocks, however. (Long story why I suspect this, but I have no apropos hardware to test.)

So I tried 704K.COM on my TX with 768K and UMB at A000-AFFF with the Lo-Tech 1mb card, but unfortunately, it doesn't seem to work. It just reboot the computer without any error messages. I tried it without anything else loaded just to be sure. Well, USE!UMBS.SYS seems to work well, so it's not that bad. CC00H is occupied by XT-IDE. There is a hard card at C8000h. I have a Lo-Tech EMS card at D000h. I understand that E000h is not available on the TX?

On my SX, I would like to have UMB at A000-AFFF and D000-DFFF, also with a Lo-Tech 1mb card. CC00H would be occupied by XT-IDE and E000h would be occupied by an Lo-Tech EMS card.

Trixter · Feb 16, 2022

I'm not sure how you'd do this on a 768K TX, because the TX uses the extra 128K RAM beyond 640K for graphics -- that's the whole point of installing it, so that using 16-color graphics modes doesn't take RAM away from programs. (That said, you might be able to get away with it, as I don't know of any Tandy games that use more than two graphics pages, totaling 64K.)

BTW, 704k.com *does* reboot the system, that's how it works. Read the docs. You put it in autoexec.bat and it reboots once after cold boot to get the DOS BDA memory variable extended.

Eudimorphodon · Feb 16, 2022

Trixter said:
I'm not sure how you'd do this on a 768K TX, because the TX uses the extra 128K RAM beyond 640K for graphics -- that's the whole point of installing it, so that using 16-color graphics modes doesn't take RAM away from programs. (That said, you might be able to get away with it, as I don't know of any Tandy games that use more than two graphics pages, totaling 64K.)

The 128K is used for graphics, but when the video chip is set up for this mode (no 640K backfill) I think it's all page-flipped in the Bxxxx area, it doesn't just linearly appear from A0000-BFFFF. If someone could run "Check-It!" or similar's memory map function on an actual TX they could confirm this (I don't happen to have one), but if you look in the technical manual for the TX on page 44 there's a table that explains the memory mapping options of the Big Blue chip and it lines up with my interpretation.

That said, I think the video chip in the "L-series" (SL and higher) machines *can* put memory in the A-page. If they couldn't then that goofy hack to emulate VGA's 320x200x256 mode with their 640x200x16 mode wouldn't work. But the TX doesn't have support for this.

wondow · Feb 17, 2022

Trixter said:
I'm not sure how you'd do this on a 768K TX, because the TX uses the extra 128K RAM beyond 640K for graphics -- that's the whole point of installing it, so that using 16-color graphics modes doesn't take RAM away from programs. (That said, you might be able to get away with it, as I don't know of any Tandy games that use more than two graphics pages, totaling 64K.)

I was thinking the same thing, but someone far more knowledgeable explained me that the extra 128K is in the B area of the memory and, like Eudimorphodon said, is paged :

a common misconception is that the "768k" in those machines is contiguous; it's not. The way the memory is organized in a fully expanded TX is it has 640K of conventional memory just like a regular PC and the remaining 128k is devoted entirely to video memory and is page-switched in and out of the B-page. (It's the same 128k that in a 640k TX or a different 1000 like an SX is *shared* between video and conventional memory.)"

Also, loading TSR and drivers in the A000h area works fine with Tandy graphics. I tried multiple Tandy games, and also Windows 3.0 without any issues. It seems to also works fine on the SX, but for the SX, DOS does not see UMB anymore if Tandy graphics are used. Drivers already loaded in that area does not seems to be affected.

As for 704k.com, after the reboot, I don't see any more memory available. Is Dos supposed to see it?

Here is a picture of my TX running Checkit with 64K of UMB at A000h and EMS at D000h:

Eudimorphodon · Feb 17, 2022

Heh. I think that "far more knowledgeable" person was also me, so take everything with a grain of salt.

If you want to make absolutely sure I'm right about that feeling that the Tandy itself doesn't put anything there you could pull your memory card from the TX and run Check-it it again to make sure there's nothing between A000-AFFF. I do believe poking around there *is* something I tested at one point when I was running torture tests on the Big Blue chip, however. (*)

(* A couple years ago now I was experimenting with my Tandy 1000 HX to get a handle on how the various programming options on the Big Blue chip affected the memory map because I was pondering the idea of making a memory card for that machine that would essentially configure it like a TX, IE, 640K of "real" memory and the motherboard memory consigned to video only; pretty sure I did some PEEK/POKES in the A-page when it was set up like a TX and didn't see anything, but it has been a while.)

FWIW, my conclusion was that the theory at least for making a "real 640K" card for the EX and HX, and possibly the SX, is solid, the Big Blues in those machines appear to have the same functionality as the TX's chip, but I would need someone a lot smarter than I am to help me with the non-hardware-half of it, which is patching the BIOS appropriately to work with it.)

wondow said:
As for 704k.com, after the reboot, I don't see any more memory available. Is Dos supposed to see it?

As Trixter said it's supposed to patch the BDA (bios data area) so it moves the top of available RAM upward and then warm-boots the machine so DOS comes up with everything correctly adjusted... but part of me wouldn't be surprised if it doesn't work right on Tandy machines. Their BIOS is a little non-standard and from some of the behavior I've observed with them I think they may re-initialize some things on "warm" reboots that more strictly IBM-compatible clones don't.

Trixter · Feb 17, 2022

You could always FORCE the BDA to be adjusted, and see if that works. My solution was to patch the boot sector:

Krille · Apr 12, 2022

wondow said:
Thank you for making this utility configurable, it is very useful! I can now have UMB in my Tandy 1000 TX and SX. I was wondering if it is possible to have not continuous UMB? Does USE!UMBS accept arguments to take into account different memory range such as DEVICE=C:\USE!UMBS.SYS A000-AFFF D000-DFFF ?

Thank you!

You probably know this by now but just to be clear: Yes, you can have as many UMB ranges as you want. I guess the limit is the command line length in config.sys (whatever that is).

IIRC, each range will add 4 bytes to the size of the driver in RAM so if you have enough of them the driver may take up an extra paragraph (a paragraph is 16 bytes - the minimum memory allocation size in DOS).

BTW, your example command line would waste one paragraph of memory for each range. Instead, it should look like this;

Code:

DEVICE=C:\USE!UMBS.SYS A000-B000 D000-E000

wondow · Apr 19, 2022

Krille said:
You probably know this by now but just to be clear: Yes, you can have as many UMB ranges as you want. I guess the limit is the command line length in config.sys (whatever that is).

IIRC, each range will add 4 bytes to the size of the driver in RAM so if you have enough of them the driver may take up an extra paragraph (a paragraph is 16 bytes - the minimum memory allocation size in DOS).

BTW, your example command line would waste one paragraph of memory for each range. Instead, it should look like this;

Code:

DEVICE=C:\USE!UMBS.SYS A000-B000 D000-E000

Thanks!

So I used the above ranges on my 1000 SX. An Lo-tech EMS card is located at E000-F000.

DOS and Checkit report weird memory configurations.

If I use the PC DOS ram command, it reports 92 KB of UMB. According to Eudimorphodon, this can happen on Tandy 1000 and it is not a cause for concern. If I use the FreeDOS mem command, it reports the correct amount of memory (128 KB of UMB). But if I use USE!UMBS with these arguments (A000-AFFF D000-DFFF), the FreeDOS mem command reports incorrectly 256 KB of UMB.

Using Checkit, it is also very strange. There would be 145KB of programs between A000 and AC5C. If this was true, it would conflict with video ram and Xt-IDE. If I use the "Mi.COM program, the programs loaded in UMB are in the A or D regions, as they should.

Using PC DOS 7 MEM command:

Modules using memory below 1Mb:

Name Total = Conventional + Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 17,536 (17K) 9,040 (9K) 8,496 (8K)
USE!UMBS 208 (0K) 208 (0K) 0 (0K)
DOSMAX 240 (0K) 0 (0K) 240 (0K)
INSTALL 160 (0K) 0 (0K) 160 (0K)
COMMAND 4,800 (5K) 0 (0K) 4,800 (5K)
CTM-FR 3,104 (3K) 0 (0K) 3,104 (3K)
EXPRESS 2,272 (2K) 0 (0K) 2,272 (2K)
LTEMM 6,320 (6K) 0 (0K) 6,320 (6K)
PNPPKT 4,672 (5K) 0 (0K) 4,672 (5K)
ETHERDFS 7,440 (7K) 0 (0K) 7,440 (7K)
FREE 686,288 (670K) 629,712 (615K) 56,576 (55K)

Memory summary:

Type of Memory Total = Used + Free
---------------- ----------- ----------- -----------
Conventional 638,976 9,264 629,712
Upper 94,080 37,504 56,576
Reserved 315,520 315,520 0
Extended (XMS) 0 0 0
---------------- ----------- ----------- -----------
Total memory 1,048,576 362,288 686,288

Total under 1Mb 733,056 46,768 686,288

Total Expanded (EMS) 2,097,152 (2,048K)
Free Expanded (EMS) 2,097,152 (2,048K)

Largest executable program size 629,696 (615K)
Largest free upper memory block 44,784 (44K)

Using FreeDOS mem command:

Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 54,560 (53K) 9,088 (9K) 45,472 (44K)
USE!UMBS 224 (0K) 224 (0K) 0 (0K)
DOSMAX 240 (0K) 0 (0K) 240 (0K)
INSTALL 160 (0K) 0 (0K) 160 (0K)
COMMAND 4,800 (5K) 0 (0K) 4,800 (5K)
CTM-FR 3,104 (3K) 0 (0K) 3,104 (3K)
EXPRESS 2,288 (2K) 0 (0K) 2,288 (2K)
LTEMM 6,336 (6K) 0 (0K) 6,336 (6K)
PNPPKT 4,672 (5K) 0 (0K) 4,672 (5K)
ETHERDFS 7,440 (7K) 0 (0K) 7,440 (7K)
Free 686,112 (670K) 629,536 (615K) 56,576 (55K)

Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 624K 9K 615K
Upper 128K 73K 55K
Reserved 272K 272K 0K
Extended (XMS) 0K 0K 0K
---------------- -------- -------- --------
Total memory 1,024K 354K 670K

Total under 1 MB 752K 82K 670K

Total Expanded (EMS) 2,048K (2,097,152 bytes)
Free Expanded (EMS) 2,048K (2,097,152 bytes)

Largest executable program size 615K (629,520 bytes)
Largest free upper memory block 44K ( 44,784 bytes)

Using FreeDOS Mem command with USE!UMBS arguments A000-AFFF D000-DFFF instead of A000-B000 D000-E000:

Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 624K 9K 615K
Upper 256K 201K 55K
Reserved 144K 144K 0K
Extended (XMS) 0K 0K 0K
---------------- -------- -------- --------
Total memory 1,024K 354K 670K

Total under 1 MB 880K 210K 670K

Total Expanded (EMS) 2,048K (2,097,152 bytes)
Free Expanded (EMS) 2,048K (2,097,152 bytes)

Largest executable program size 615K (629,520 bytes)
Largest free upper memory block 44K ( 44,768 bytes)

Using MI.COM mem command:

Total bytes owned
Addr. Low area High area Program or device driver
----- -------- --------- --------------------------
0234h 208 .. Device=USE!UMBS Attr=E000h Name=ZwetsUMB
024Eh 629,520 .. <largest free area>
---- Begin High (Upper) Memory ----
A001h .. 224 DOSMAX
AB27h .. 144 INSTALL
AB31h .. 4,768 COMMAND
AC67h .. 3,088 CTM-FR
D002h .. 2,272 Device=EXPRESS Attr=C000h Name=GACDXXX0
D091h .. 6,320 Device=LTEMM Attr=8000h Name=EMMXXXX0
D21Dh .. 4,656 PNPPKT
D341h .. 7,408 ETHERDFS BC:5F:F4:CA:DE:0F C-R

638,976 bytes (624k) total DOS 7.00 conventional memory.
629,520 bytes (615k) largest executable program. 44,768 bytes if loaded high.

High memory is managed by DOS.

0 bytes Extended (AT/286/386) memory, reported by BIOS.

2,048k bytes EMS 4.0 memory: 0 used + 2,048k free. Page frame E000h.

Finally, this is how Checkit reports incorrectly programs loaded in UMB:

Trixter · Apr 19, 2022

A potential fix for the PC DOS 7 memory reporting discrepancy is to put DOS=HIGH,UMB in your CONFIG.SYS (or at least, DOS=UMB). I believe I had to add it before my whackadoodle UMB areas were reported properly by the mem command.

If you run "view cmdref" in PC DOS 7 and go to the CONFIG.SYS - DOS section, the documentation says the following:

Purpose: Specifies that DOS is to maintain a link to the upper memory area or is to load part of itself into the high memory area (HMA)
...
umb|noumb:
Specifies whether DOS should maintain a link between conventional memory and the upper memory area. The umb parameter provides this link. The default setting is noumb.

maxtherabbit · Apr 19, 2022

Has anyone who truly understands MCB black magic reviewed the USE!UMBS source? I have occasionally noticed what can only be described as "odd" behaviours when using it over the years, and have seen others post about the same

Krille · Apr 25, 2022

maxtherabbit said:
Has anyone who truly understands MCB black magic reviewed the USE!UMBS source? I have occasionally noticed what can only be described as "odd" behaviours when using it over the years, and have seen others post about the same

Can you give examples of those odd behaviours?

maxtherabbit · Apr 25, 2022

Krille said:
Can you give examples of those odd behaviours?

I wish I could remember specifics, but alas

explit · Jan 3, 2023

Hello guys, sorry for opening the old posting again, but i have very strange Problem here:
I have sergey's very cool Micro8088 with 640KB RAM and 128KB UMB. (D000-F000), i can go even till F400!
I use:
MS-DOS 6.22
4DOS 8.00
DOS=HIGH,UMB
USE!UMB.SYS (Version 2.2) in the Range D000-F400. USE!UMB is working fine without any problems.
DOSMAX.SYS to load DOS in the UMB is also working fine, it loads all the DOS Stuff in the DXXX range.
4DOS is to big to be loaded in the UMB with DOSMAX, so it loads somewhe in the 02XX Range.

And now when i run mem command from DOS - it shows me that i have only main memory and 0Kb UMB.
From my 640Kb i have only 19Kb used and 621Kb free. But it shows 0 Kb of UMB memory.
CheckIt 3.0 shows anything fine and shows me the upper memory in the D000-F400 range.

So my question is, what i do wrong, or what should i do, so the mem can see my UMB?

Thanks!

Trixter · Jan 3, 2023

As the previous discussion in this thread illustrates, USE!UMB works in a way that isn't compatible with DOS 6's extension of the MCB chain to upper memory blocks.

You might have some luck making DOS=UMB the first line of CONFIG.SYS, and removing the "HIGH" part since your XT doesn't have an HMA (HMA requires a 286+). This works for me in PC DOS 7, at least.

FreddyV · Jan 3, 2023

Hi,

The 2.2 Version by Krille is the last one ?

@Trixter What do you mean by not compatible with DOS 6.22 ?
The source code is not clear, but it seems to be too small to support all the UMB commands.

explit · Jan 4, 2023

Trixter said:
As the previous discussion in this thread illustrates, USE!UMB works in a way that isn't compatible with DOS 6's extension of the MCB chain to upper memory blocks.

You might have some luck making DOS=UMB the first line of CONFIG.SYS, and removing the "HIGH" part since your XT doesn't have an HMA (HMA requires a 286+). This works for me in PC DOS 7, at least.

The funny thing is:

With DOS=HIGH,UMB i have 621Kb free
With DOS=UMB i have 576Kb free

Loading dos high on a XT

Veteran Member

New Member

Member

Veteran Member

Member

Veteran Member

Veteran Member

Member

Veteran Member

Veteran Member

Veteran Member

Member

Veteran Member

Veteran Member

Veteran Member

Veteran Member

New Member

Veteran Member

Experienced Member

New Member