• Please review our updated Terms and Rules here

Loading dos into UMB on an XT

Another nifty little trick I can do is to re-enable the EMS page frame in the E region and have both 80kb of upper memory and expanded memory available concurrently. Just imagine what kind of damage I could do by using a monochrome adapter. In theory that could expand conventional memory by 96kb, though I might have to use another driver to get at it. Perhaps if I removed my SCSI ROM and booted by floppy I could get an extra 16kb UMB block too, but that wouldn't be very practical for me. That would provide 896kb memory in total...and there are definetly XT systems out there that can do it.

I have just an Above Board and an XT, so I can't do nearly this kind of config, but I was able to finally get some stuff loaded high. Here's my experience:

PC DOS 2000 has a driver that, if you have and EMS board but do NOT load an EMS driver, will allow you to use the 64K page frame as UMB. This disables all of the rest of EMS though, so it's not really the best use of the RAM.

I just loaded QRAM and was astonished to find that it somehow uses the 64K page frame for UMBs while at the same time allowing full EMS to function. I have no idea how that is working :confused: but it is indeed working and I've been able to shave my system down to 580KB free from 571KB free. Desqview is working under it as well, so the EMS must be working.

The people at Quarterdeck were simply amazing. It's a shame that they wiped several source code hard drives when they were acquired by Symantec; I would have loved to see that code.

update: I ran Manifest and it looks like QRAM is using LIM EMS 4.0 to keep the page frame where it is at D000 and it mapped an additional block of RAM at E000!!!! That is so cool! That makes sense based on what Desqview recommends -- if you are going to totally commit to Desqview, they recommend that you set your PC's system ram to only 256KB, so that the EMS board can map the rest of it and you can run programs simultaneously in the mapped RAM. LIM EMS can't map into a place where memory already is. If you have a regular 640K machine, all Desqview can do is multitask only in system ram and then swap in/out of EMS.

QRAM is amazing, I can't believe I haven't run this until now. Now I need to try to find more EMS boards (I only have two :(

Update #2: I set DOS=umb and DOSDATA=umb and now I'm up to 591K free! I can load ncache2 and it loads in UMB too! This is crazy!
 
Last edited:
Ah, I missed the 'board printing' part; must be 4.0 then.

Digging through some related docs: the Quadram QuadMaster can only locate the page frame in D and E (if no graphics card is using them, of course).

Re the other thread on this topic; any idea if you can do anything like this with the extra memory on 1024K XT clone boards (other than RAM disks)? Qram can use the shadow RAM on certain 286 boards instead of expanded memory FWIW.

Remotely related, I've got an AST FASTRAM board here - looks like a 2MB 16-bit EMS board, but using the special AST memory bus; anybody got an AST MB that it'd fit into who could use it?

Also one or two conventional RAM expansion boards somewhere for 64K & 256K MBs...

m
 
Trixter, did you try using DOS-UP.SYS to load DOS into UMB as I suggested? That should give you another 32kb of conventional memory.

You were lucky to get QRAM to detect your E region without much effort. For a while I could get QRAM to report E region as available, it just simply refused to use it.

Mike, I think that the memory on 1024kb XT motherboards will not be useful to QRAM unless it can be configured as EMS. QRAM needs an EMM driver loaded in order to be able to see any of the extra memory. If you can get the extra memory to act as EMS you are guaranteed 64kb of UMB RAM.

UPDATE:

I just re-read what Trixter said. If it is true that PC-DOS 2k doesn't require an EMS driver to be loaded to make the pageframe available as UMB RAM, then it is possible that it might be used to free some ram on a 1024kb XT motherboard. No guarantees of course, but it might be worth a shot.
 
Last edited:
Last edited:
Interesting site for sure; thanks for the tip!

With certain chip sets QRAM can also use extended memory located in the upper 384K (instead of or in addition to EMS); probably not applicable to a 1024K XT but I was just wondering. Any idea how that memory is in fact accessed (e.g. by a RAMdisk program)?

I'm just too obstinate to agree without question that what Genocho wanted to do with his Juko board is indeed "impossible" (although it may indeed well be).

m
 
Two interesting things I discovered today.

There appears to be a way to tell QRAM.SYS to put RAM in a specific region...however I haven't been able to get it to work yet.

Also, in the QRAM directory there is an "Extended Memory Emulator" called EMS2EXT.SYS. I loaded it, but I couldn't get it to make any extended memory that QRAM can recognise. I don't know what this program is supposed to do, but apparently the answer may be in the book "Using QEMM 3.0".
 
I managed to get that extra 32kb in the B000-B7FF region that is used as a monochrome frame buffer. It seems there is no harm using it, and infact that is the entire purpose of the file MONOUMB.386.

Getting this UMB is not easy though, and I think for most people it is probably not going to be mappable. I am only able to do this using my AST RAMpage! There is a switch in REMM (undocumented for version 4.x) that allows you to specify additional frames. In my case it looks like /L=B000-B7FF. This in addition to my other UMB memory gives me 176kb of UMB.

In theory it should be possible to get a LIM 4.0 card to add an extra memory frame in the B000-B7FF region, but the problem is telling the card to do that. It seems many EMS drivers do not have an option to manually provide additional frames.

While many LIM 4.0 cards have limitations as to where the first 64kb page frame is located (usually C000-EFFF), I believe that additional frames can be put anywhere in memory above 640kb (and even below that region if you allow your card to backfill). This is the reason that programs like VIDRAM are able to fill the A region with EMS memory.

Naturally I'm going to keep trying to get my RAMQuest 8/16 board to use this extra region, but I have a feeling I may be SOL.

UPDATE:

I was looking through the MM816.sys ems driver file, and I noticed it appears to be possible to include additional memory ranges, though I don't know the switch setting to do this!
 
Last edited:
I don't think VIDRAM uses EMM memory; if you have an EGA or VGA card, it will make the memory on the adapter available to the OS as conventional memory above 640K (64K if mono, 96K if colour); the price is loss of extended graphics and (maybe) slightly slower access.

If you have a mono text adapter, then you can use QRAM to map EMM in there (if your board allows it, of course).

EMS2EXT converts expanded memory to extended, for things like RAMdisks and cache programs that don't understand XMS and want extended memory instead; incidentally, it can be loaded and unloaded for specifc programs that need it.
 
Hmm...when I was reading about VIDRAM with a VGA card, I was lead to believe that you can set it to choose between using the DRAM on the VGA card itself, or have much faster LIM 4.0 memory mapped into that region instead. I guess I won't know until I give it a try. You can verify which memory is being used with Manifest.

I've been meaning to try it out, but I'm working with my 5150 right now, which is having some SCSI problems. It seems the BIOS on my T128 card is too old and not being cooperative. I've switched it over to a TMC850, but unfortunately I don't have any extra v8.2 BIOS chips for it.
 
You're absolutely right again, of course; it's not mentioned in my qram 1.0 manual, but the QEMM version does indeed have an EMS parameter to use EMS memory instead of video RAM. Time to stop disagreeing with you and start learning...

m
 
Well, I was just guessing. I tend not to pay attention very well when I read something for the first time. I tried loading this on my XT, but only managed to lock up the system.

What I'm looking for right now is a 3rd party utility to manipulate EMS page frames. I want that 32kb region.
 
Maybe, since it's not mentioned in the qram manual, VIDRAM really does need a 386 or better for this trick.

Good thing I don't have any 8-bit EMS boards, or I'd be wasting my time right along with you... ;-) - once you get started you just can't get enough ;-) - good luck finding that elusive last 32K!

m
 
Trixter,

Do you know how to write software to use EMS memory?

I think there must be a way to tell LIM 4.0 memory boards to create extra pages in a desired location via calls to int 67.
 
Trixter,

Do you know how to write software to use EMS memory?

I think there must be a way to tell LIM 4.0 memory boards to create extra pages in a desired location via calls to int 67.

The EMS 4.0 spec should go into detail for what is available. I haven't written software that explicitly manipulates 4.0 stuff, only your basic "give me some pages in the page frame" 3.2 stuff.
 
Yes, if you read my previous posts you'll see that I got DOS-UP.SYS from QEMM8 to work with QRAM and loaded DOS into a UMB.

All you have to do is make sure that you replace your old versions of LOADHI.COM and LOADHI.SYS with the ones that come with QEMM8 (or from whatever version you steal DOS-UP.SYS from)
 
Last edited:
Yes, if you read my previous posts you'll see that I got DOS-UP.SYS from QEMM8 to work with QRAM and loaded DOS into a UMB.

All you have to do is make sure that you replace your old versions of LOADHI.COM and LOADHI.SYS with the ones that come with QEMM8 (or from whatever version you steal DOS-UP.SYS from)

I am getting a "can't load overlay" when I do that. Can you post your config.sys?
 
Here's my config.sys:

DEVICE=C:\MM816.SYS /Z /A /S=E000 /O=208
DEVICE=C:\QRAM\QRAM.SYS R:1 /FL=0
DEVICE=C:\DOS-UP.SYS
DOS=HIGH,UMB
FILES=20
BUFFERS=10
DEVICE=C:\QRAM\LOADHI.SYS /R:1 C:\PWRSCSI!\FDCD.SYS /D:MSCD0001
INSTALL=C:\QRAM\LOADHI.COM /R:1 C:\DOS\MSCDEX.EXE /D:MSCD0001
DEVICE=c:\QRAM\LOADHI.SYS /R:1 c:\2M30\2M-XBIOS.EXE A:4 B:1
LASTDRIVE=Z

For some reason, this doesn't work unless you specify DOS=HIGH,UMB. Yes, it has to be HIGH too. I guess the DOS-UP.SYS driver must fool it. I actually didn't realise that was necessary until just now. I don't even know why that works, but apparently it does.

Also, I don't believe MFT will report DOS being loaded high accurately...you probably have to upgrade MFT to a newer version. However, if you use the QEMM8 LOADHI.COM it will show that it is loaded UMB. Perhaps I've just created an anomaly?
 
Last edited:
I'm able to get COMMAND into umb memory, but it's causing some small problems. When using the SHELL line in config.sys, it always loads last regardless of location. This is a problem, because although COMMAND itself only takes 4kb of memory, the COMMAND.COM file is something like 52kb.

If I remove all of my other loadhi device lines from config.sys, there will then be enough "room" for COMMAND to be loaded high and I will get my extra 4kb (bringing me up to 619kb free conventional). The problem though is that I can't load any of my drivers into high memory until I figure out how to get the shell statement to run first, rather than last. Perhaps there are other methods to change the location of command.com?
 
Last edited:
Back
Top