• Please review our updated Terms and Rules here

PC-DOS 3.2 for 5150

After attempting this stuff on and off for years, dorking around with QRAM, EMS cards, etc. on my 5160, I finally have 704K free in PC-DOS 7 with a lotech RAM card providing 64K at A000 only. My solution? Force it with a hammer:

Code: 
; Forceably resizes 640K to 704K.
; Only do this on an 8086 system with a known 64K segment of real RAM at A000h.
; Hacked up by trixter@oldskool.org 20201020

numPages        EQU     4                       ;assume 4 16K "EMS" pages avail
numPara         EQU     (numPages SHL 10)       ;number of paragraphs to add
extraK          EQU     (numPages SHL 4)        ;numer of KB to add

        push    ds
        mov     dx,40h
        mov     ds,dx                   ;point to BDA segment
        mov     ax,[13h]                ;grab existing BDA memory size
        cmp     ax,280h                 ;are we at 640k?
        jne     exit                    ;bail if not
        add     ax,extraK               ;increase by KB we're adding
        mov     [13h],ax                ;update BDA with new total count
        pop     ds
        mov     dx,ds
        mov     ax,numPara
        add     ds:[2],ax               ;modify our own PSP to reflect new size
        dec     dx
        mov     ds,dx                   ;point to our MCB
        add     ds:[3],ax               ;adjust it for 704K
exit:
        ret

DOS "MEM" and "CHKDSK" commands recognize the extension, but does it pass muster? CheckIT 2.1 happily recognized that memory went to AFFF and tested all of it, and it passed.

Caveats:

  • The above code should only be used on systems without an extended BIOS data area, which is typically located at the top of 640K. It can be relocated, and "proper" programs like VIDRAM and EEMRAM do this, but those programs require EGA or VGA hardware (VIDRAM) or an EMS card that can map into A000 (QRAM, EEMRAM), but the above program clearly does not. You only need to worry about this on ATs and later.
  • On PC-DOS 2000, the UMB chain suddenly disappears after this is run. Any programs loaded there continue to run, but you can't view it or load/unload there any more. So if that happens to you, don't run this. (It happens to me, so I don't run QRAM any more, and just load everything in the lower 704k -- I still have more free RAM than when I started).
Above code is donated to the public domain, do whatever you like with it.
 
Trixter said:
On PC-DOS 2000, the UMB chain suddenly disappears after this is run. Any programs loaded there continue to run, but you can't view it or load/unload there any more. So if that happens to you, don't run this. (It happens to me, so I don't run QRAM any more, and just load everything in the lower 704k -- I still have more free RAM than when I started).
Click to expand...

The "UMB Disappearing" thing happens if you have a Tandy 1000(*) with upper memory blocks and run a TGA program that uses more than 16K of memory so, yeah, apparently the crudest possible "hit it with a hammer" solution (which is undoubtedly what the Tandy BIOS does) breaks it. I believe I've actually observed that by using the little top-of-memory reservation program that's out there for the Tandy I can actually switch the top lower, see the UMB chain disappear, and switch it back and have it *reappear*. (But if I actually run something that uses the memory it's nuked for good.) I'm *pretty sure* I tested and saw it get nuked under 6.22 as well, but I can't 100% swear to it.

(* Presumably this only happens on the 8088 models that have to share video memory, not "768k" TX/TL/whatevers.)

Presumably there's some kind of pointer/data structure that those other programs that shift the top are relocating/preserving. I'm curious what it is.

Edit: Someone smarter than I am that knows how to actually use DOS debugging tools needs to compare a before/after memory dump of running VIDRAM and see what changed besides the BDA. :p
 
Last edited:
maxtherabbit said:
My 0.1 revision DOS downgrade thread certainly is yielding some interesting and excellent results :cool:
Click to expand...

Heh. It's certainly an interesting puzzle. I'm learning just enough about DOS internals to be even more intimidated by it.

My wild guess is the reason those programs like VIDRAM are walking the "list of lists" is there's some kind of linked-list structure to the MCBs that depends on appending the UMB stuff after a "free memory" block and for some reason just poking a new top-of-memory value into the BDA *alone* breaks the chain. (Maybe DOS does some kind of internal sanity check to see if this "pointer to UMBs" matches the BDA value and things fall on the floor if one is updated without the other. For laughs I tried poking some new values into the BDA on my machine smaller than 280h and it likewise breaks the UMB link.) But this is me talking with no idea how any of this actually works.
 
Eudimorphodon said:
USE!UMB.SYS takes 192 bytes of conventional RAM, according to "mem /c", although I think you also need DOSMAX stacked on top to enable the LOADHIGH/DEVICEHIGH commands? "mem /c" pegs the usage for that as 240 bytes conventional and 240 bytes upper. (I was able to verify this by booting a super-stripped config.) So a little less than half a K conventional.

Since I still have QRAM on my system (even though it's sort of useless to me) I did a quick basic setup where it's using the EMS' 64k frame as upper memory. (Since it lamentably can't make use of all the static upper memory I have) QRAM seems to "cloak" its actual memory usage by hiding in the upper memory it creates, but running "LOADHI" indicates it's taking 1.4k of the UMB, and the LTEMM driver is taking 6k of conventional.

So, yeah, from a strict memory consumption angle USE!UMB seems to handily beat QRAM if static UMBs are an option. But this is kind of an apples to oranges comparison; if you had a full EMS 4.0 card and software to make good use of it (like DESQView or whatever) the additional memory overhead would probably be worth it.
Click to expand...
USE!UMBS requires DOS 5 or better to be useful. And DOSMAX doesn't provide a mechanism to load device drivers high, just DOS data structures. It seems like QRAM is the way to go for using the network card UMB on DOS 3.x since it can provide both.
 
maxtherabbit said:
USE!UMBS requires DOS 5 or better to be useful. And DOSMAX doesn't provide a mechanism to load device drivers high, just DOS data structures. It seems like QRAM is the way to go for using the network card UMB on DOS 3.x since it can provide both.
Click to expand...

Except, as noted, from what I can tell you can’t use QRAM with a UMB that’s not created with either EMS or 286 shadow memory. If you know the secret syntax to have it use “hardwired” memory I’m happy to try it.

(Also, technically, if you were to use DOSMAX to load dos data like files/fcbs high even without having enough UMB to load the dos kernel high you’ll get the footprint of DOS 5+ to be smaller than, or at least very close to, 3.x.)
 
How would QRAM know the difference from a range of memory on an expansion card vs. shadow RAM provided by the chipset? They both appear to the system as linear memory. Should be able to use QRAM with the RAM=xxxx-xxxx parameter and have it just work. I haven't yet tried it so this is speculation
 
I tried it, the "RAM" parameter still involves backfilling from EMS. (The manual is kind of confusing about the distinction between RAM and INCLUDE but, trust me, neither work. Unless someone can actually demonstrate the contrary.)

Re: the difference between hardwired and shadow memory, the manual specifically lists the 286 chipsets it works with, which apparently have mechanisms to switch a pool of memory in and out or on and off. It doesn't detect any supported hardware on my machine which is positively chock full of hardwired upper memory.
 
Well that raises the question "what is the proper syntax to use it with shadow ram?"

Maybe trixter can weigh in, he's got more experience using it than I do
 
maxtherabbit said:
Well that raises the question "what is the proper syntax to use it with shadow ram?"

Maybe trixter can weigh in, he's got more experience using it than I do
Click to expand...

Here's the manual I was going off of:

ftp://computermuseum.informatik.uni-stuttgart.de/misc/Quarterdeck_qram.pdf

I couldn't find anything about forcing it to use some particular shadow memory scheme, and both trying various switches manually and using OPTIMIZE just told me it couldn't find any supported hardware. (Unless I load the EMS driver for the lo-tech, in which case it will grudgingly turn that into a 64k UMB.)

(*Edit: Just to note, if the manual is to be believed the "Shadow Ram" systems it supports are the C&T chipsets that can essentially also fake being EMS cards?)
 
Last edited:
maxtherabbit said:
Well that raises the question "what is the proper syntax to use it with shadow ram?"

Maybe trixter can weigh in, he's got more experience using it than I do
Click to expand...

QRAM attempts everything it can sense, and most of the command-line options are to tell it NOT to do something. If it detects supported shadow RAM chipsets, it will do the needful.
 
I wonder if a 3rd party loadhi.sys (quarterdeck's or otherwise) could be used with USE!UMBS in DOS 3.x to load device drivers in UMBs?
 
maxtherabbit said:
I wonder if a 3rd party loadhi.sys (quarterdeck's or otherwise) could be used with USE!UMBS in DOS 3.x to load device drivers in UMBs?
Click to expand...
You can try with The Last Byte Memory Manager: http://files.mpoli.fi/unpacked/software/dos/utils/misc/tlb_v252.zip/
According to the docs, it is compatible with dos >= 3.1. By loading LASTBYTE.SYS with the option DOS=<segment>:<size> adds statically mapped UMBs. Then you can use HIGHDRVR.SYS and HIGHTRS.EXE to load device drivers high. I don't have UMBs (yet) on my XT, so I cannot test it.

By the way, I would like to thank anyone for the excellent discussion! The possibility of adding SRAM to network cards is very interesting: I have an RTL8019AS on my XT, and using the empty ROM socket to add some UMBs would be very useful.
 
I've been reviewing the docs of TLB. It appears to also support appending memory in the A000 segment to conventional through the use of a program in its optional advanced utilities pack called HIGHAPND
 
maxtherabbit said:
I've been reviewing the docs of TLB. It appears to also support appending memory in the A000 segment to conventional through the use of a program in its optional advanced utilities pack called HIGHAPND
Click to expand...

Here's the "advanced" pack:

http://files.mpoli.fi/unpacked/software/dos/utils/misc/tlb_a252.zip/

I have a DOS 3.3 boot partition on my Tandy, I suppose I could probably see if it does anything with my statically addressed upper memory. I can't test the conventional memory append function, of course.

One of these days I guess I have to hope that I trip over a plain XT to play with. I kinda want one but the going rates are currently, well, nope.
 
FWIW, "The Last Byte" does work on DOS 3.3 with static upper memory blocks. Running the "chipset" auto-detect program automatically sniffed out the 96k of memory type PHYSICAL in the right place, and I've confirmed I can load ANSI.SYS, CTMOUSE, and LTEMM.EXE (among others) high.

If you have enough upper memory to load DOS high this is still a loser compared to that, I have *way* more free memory under PC-DOS 7. But if you have 3.x and only a small amount of upper memory, like 32k on a network card, this may fill a niche. I am also very curious if the extend-base-memory function works properly if you have hardwired memory in A000.

The 30 second-then-hit-a-key shareware wait is pretty obnoxious, so unless you can register it that's a thing.
 
You must log in or register to reply here.
Back
Top