• Please review our updated Terms and Rules here

Headland HT12/A 286 chipset: UMB driver?

K

keropi

Experienced Member
Joined
Feb 28, 2012
Messages
195
Location
Ioannina , Greece
Hiya!

This is a crosspost as the topic is kind of obscure... :D I have a couple 16mhz 286 motherboards with the Headland HT12/A chipset and I was wondering if there is a UMB driver for it.
I have tried "The Last Byte Manager" that provides up to 64kb of UMBs for the HT12 chipset but all it does is hard-lock both machines... :mad:
Perhaps there is a HT12 chipset without the /A and that's why it doesn't work :confused:

The HT12MM.SYS EMS driver does work and provides EMS RAM but no UMBs. Is it even possible?
Here are some photos from the chipset, BIOS screen and TLB manager:







and here is the MEM output with HT12MM.SYS loaded to provide EMS:



Any ideas/tips?
TIA for any help/info! :)
 
You may want to disable Shadow Ram and especially EMS. If all the memory above 640K is used as EMS himem.sys won't be able to allocate the High Memory Area as it needs XMS to do this. IIRC the A20 option needs to be enabled, as well.
 
"Memory relocation: Enabled" means you don't want any upper memory (i.e. any memory between 640K and 1MB that's not being used as Shadow RAM should be moved above the 1MB boundary).

For UMB, you want as much RAM as possible between 640K and 1MB so you need to turn that option off. Once you have figured out a way to get RAM active between 640K and 1MB (changing the Memory relocation setting may be all you need to do, or there might be additional steps required to make the memory active or to make it read/write, this depends on your system) there are UMB drivers that will make it available for DOS to use. For example "umm03.zip" does this and is available from the SIMTEL20 archives.

In general, the way upper memory works with DOS is this:

1. DOS will load device drivers, etc. into upper memory if you use the appropriate commands (DOS=HIGH,UMB, DEVICEHIGH=, LOADHIGH, etc.)
2. DOS will only do this if it thinks you have upper memory available
3. DOS finds out what upper memory is available by calling a particular XMS function
4. XMS functions are made available by loading an XMS driver such as HIMEM.SYS
5. HIMEM.SYS will by default report that no upper memory is available
6. to make HIMEM.SYS report upper memory, you need an additional driver like the one in umm03.zip

-ken
 
Last edited:
thanks for the explanation, will test out tomorrow...
what I don't like about UMM is that you need to specify the memory range... how can one know the safe range to specify? TLB only wants to allocate 64kb out of 384 - most likely anything else will just cause issues...
 
kgober said:
For UMB, you want as much RAM as possible between 640K and 1MB so you need to turn that option off. Once you have figured out a way to get RAM active between 640K and 1MB (changing the Memory relocation setting may be all you need to do, or there might be additional steps required to make the memory active or to make it read/write, this depends on your system) there are UMB drivers that will make it available for DOS to use. For example "umm03.zip" does this and is available from the SIMTEL20 archives.

In general, the way upper memory works with DOS is this:

1. DOS will load device drivers, etc. into upper memory if you use the appropriate commands (DOS=HIGH,UMB, DEVICEHIGH=, LOADHIGH, etc.)
2. DOS will only do this if it thinks you have upper memory available
3. DOS finds out what upper memory is available by calling a particular XMS function
4. XMS functions are made available by loading an XMS driver such as HIMEM.SYS
5. HIMEM.SYS will by default report that no upper memory is available
6. to make HIMEM.SYS report upper memory, you need an additional driver like the one in umm03.zip
Click to expand...
Yes, but not on an 80286. This requires virtual x86 mode which the 80286 does not have. The only exception to this that I am aware of is an 80286 with a C&T chipset which can use QRAM to get UMBs.
 
Stone said:
Yes, but not on an 80286. This requires virtual x86 mode which the 80286 does not have. The only exception to this that I am aware of is an 80286 with a C&T chipset which can use QRAM to get UMBs.
Click to expand...

This is why I say "Once you have figured out a way to get RAM active between 640K and 1MB", because you need to work this out yourself. In fact, the UMM.SYS driver was written for use with a system that had a C&T chipset, on the particular machine it was written for you could go into the BIOS setup and enable upper memory in 16K chunks (this was done on the same screen you'd use to configure ROM shadowing). So what you'd do is, enable memory in every 16K area that wasn't already occupied with adapter RAM or a ROM, then load the UMM.SYS driver specifying which areas you had enabled. UMM would then pass that information on to DOS via the appropriate XMS function. This is really all UMM.SYS did, it hooked the appropriate XMS function, and it handled the bookkeeping of how much upper memory you had (and where) and how much of it had been allocated. But it didn't actually provide the memory, your motherboard had to do it.

Theoretically this was doable even without BIOS support, but you would need to add the appropriate IO register writes to configure the memory mapping. This is apparently what QRAM did, although nothing (except a lack of adequate documentation) was stopping anybody else from doing it. If my BIOS hadn't supported this, and I had had adequate documentation on how to do it myself, UMM.SYS would have done it.

-ken
 
kgober said:
This is why I say "Once you have figured out a way to get RAM active between 640K and 1MB", because you need to work this out yourself. In fact, the UMM.SYS driver was written for use with a system that had a C&T chipset,...
Click to expand...
So how does that tidbit apply here, to a 286 with a Headland chipset??? I just don't see the connection.
 
After disabling memory relocation option from BIOS, you can use USE!UMBS.SYS device driver to get access to the UMBs. You can find the driver and instructions in thread http://www.vcfed.org/forum/showthread.php?31753-Loading-dos-high-on-a-XT/page3

Also, The last byte memory manager probably didn't work as expected before if you've tried with memory relocation option as enabled, disable and try it again.
 
Stone said:
So how does that tidbit apply here, to a 286 with a Headland chipset??? I just don't see the connection.
Click to expand...

While UMM.SYS was written for use with a C&T chipset, it doesn't require one. It doesn't do anything chipset-specific, it assumes that has been done already (in my case, it was done via BIOS Setup).

Since this system with a Headland chipset obviously knows about unused shadow RAM, and has an option to prevent moving it above 1MB, it is entirely possible that if you leave the unused shadow RAM unmapped you will be able to use it as upper memory (as long as you have the software required to advise DOS that upper memory exists and is usable, which is what HIMEM+UMM together do).

UMB's don't require you to have an 80386 or QRAM, those are just the most common ways to do it. The actual requirements are:

1. addressable RAM between 640K and 1MB (real or virtual, doesn't matter)
2. XMS knows about it and advertises it via the appropriate XMS function call
3. a version of DOS that supports UMBs

If you can take care of #1, them HIMEM.SYS + UMM.SYS can take care of #2.

-ken
 
Sadly I did not manage to work with the system today so I have nothing to report yet. All input is welcome and I will test everything :)
I seem to remember there was a "umb tester?" program that reported back which regions at the 640~1024kb were free and safe to use, most likely it came bundled with some memory manager...? does that ring a bell to anyone? I think it will come handy when specifying UMB range.
 
keropi said:
Sadly I did not manage to work with the system today so I have nothing to report yet. All input is welcome and I will test everything :)
I seem to remember there was a "umb tester?" program that reported back which regions at the 640~1024kb were free and safe to use, most likely it came bundled with some memory manager...? does that ring a bell to anyone? I think it will come handy when specifying UMB range.
Click to expand...

It reminds me QRAM (QTEST.COM) or QEMM or the utility TEST!UMB.EXE
 
keropi said:
Sadly I did not manage to work with the system today so I have nothing to report yet. All input is welcome and I will test everything :)
I seem to remember there was a "umb tester?" program that reported back which regions at the 640~1024kb were free and safe to use, most likely it came bundled with some memory manager...? does that ring a bell to anyone? I think it will come handy when specifying UMB range.
Click to expand...

You can use TEST!UMB utility in USE!UMBS (it may detect VGA video memory as UMB sometimes erroneously), manifest utility in QEMM/QRAM or UMBINFO.COM (this is the one which i recommend despite it is written in german but you can easily use even if you don't speak german) You can download it from here: http://www.cubic.org/docs/download/umbinfo.com

It gives you detailed information of memory mapping. If everything is OK, you should see RAM in regions B000-B7FF and C800-EFFF region if your computer has VGA card and no any additional disk drive adapter with own BIOS. If you see these regions as Frei (free) then it means that there is no RAM available to use as UMB using generic ways (USE!UMBS.SYS driver for example) so it may require device specific driver).

HIMEM.SYS of DR-DOS 7 is also provides access to UMB's in 808X and 80286 machines if there is physical RAM in UMB regions. Don't confuse with HIMEM.SYS of MS/PC-DOS, it works entirely different. You can also use it in MS/PC-DOS too.
 
allright, time for an update

I disabled "memory relocation" and "BIOS Shadow" options . TLB still hard-locks the machine, there is noway for CHIPSET.EXE to complete it's job and add the config.sys lines.

Here is what UMBINFO.COM reports:



here is QRAM's MFT.EXE (don't really want to use qram at all, it expects an EMS driver to be loaded and I would like to have UMBs with XMS)



and finally TEST!UMB



so now I will try and use USE!UMBS with this command: DEVICE=USE!UMBS.SYS C800-EFFF , if it works it will be more than enough - based on QRAM's findings that I find easier to understand
 
Sadly I don't have a free isa slot to add more cards... I am using a slim 286 with a riser that offers 4 slots - all are occupied.

Also USE!UMBS just hangs when booting:



at least this time NUM-LOCK is working - unlike TLB that nothing works :lol:
I have tried these ranges: C800-EFFF , D800-EFFF , D800-E800 and B000-B7FF and they all behave the same.
 
keropi said:
Sadly I don't have a free isa slot to add more cards... I am using a slim 286 with a riser that offers 4 slots - all are occupied.
Click to expand...
I've got some five slot risers:


attachment.php



attachment.php




P8050290.jpgP8050289.jpg
 
You must log in or register to reply here.
Back
Top