

           Twinstar UMB driver for UMC UM82C330 / UM82C336F chipsets

                 by Mateusz Viste -- http://mateusz.fr/twinumb


Twinstar UMB (TWINUMB) is a device driver that unlocks Upper Memory Blocks
(UMBs) on PCs equipped with the UMC UM82C330 / UM82C336F chipset. This chipset,
often referred to as "Twinstar", is found in certain 386SX systems manufactured
around 1990-1991.

TWINUMB activates the shadow RAM feature managed by the chipset, repurposing it
as usable UMB space that can then be enabled via tools like USE!UMBS.

This driver functions as an initializer, meaning it does not remain resident
in memory. It is a device driver, hence you need to load it using a "DEVICE="
directive in your CONFIG.SYS file:

DEVICE=TWINUMB.SYS


=== [ THE STORY ] =============================================================

I own a 386SX PC equipped with the UM82C336F chipset. After testing several UMB
drivers without success, I decided to develop my own solution. Unfortunately,
documentation for this chipset was nowhere to be found - so I had to dump and
disassemble the system BIOS of my PC to understand how the chipset operates.

What I discovered is that the UM82C330 manages 128 KB of shadow RAM. Half of
this memory is permanently mapped to the BIOS segment at 0xF000, making it
unusable as UMB. The remaining 64 KB, however, is divided into four 16 KB
blocks: C000-C3FF, C400-C7FF, C800-CBFF and CC00-CFFF.

Each block can be independently enabled and is controlled by two bits within an
8-bit register at I/O port 0x80AF: one bit enables write access, the other
enables read access.

During POST, the BIOS briefly enables write access to these regions to copy ROM
data there, and then switches them to read-only. TWINUMB overrides this
behavior by reprogramming the register, allowing these regions to be both read
from and written to - effectively turning them into usable conventional RAM.


=== [ SHADOW RAM REGIONS ] ====================================================

The UM82C330 chipset has 64K of shadow RAM hard-wired to 4x 16 KB regions:
C000-C3FF, C400-C7FF, C800-CBFF and CC00-CFFF.

These regions may be partially or fully occupied by BIOS extensions, which
would make them unavailable for use as UMB. Most commonly, the first two blocks
(C000-C3FF and C400-C7FF) are used by the VGA BIOS. However, if you're using an
early EGA card, the C400-C7FF region might be free and could potentially be
repurposed as UMB. The C000-C3FF region is inoccupied only if you have a
BIOS-less video card, like an MDA, Hercules, CGA or MCGA.

The remaining regions - C800-CBFF and CC00-CFFF - are typically unoccupied and
available for UMB use, unless you have a specialized expansion card installed,
such as an advanced hard disk controller, which might claim one of these areas.


=== [ SYNTAX AND USAGE ] ======================================================

The general syntax is:

  DEVICE=TWINUMB.SYS [0][1][2][3][!]

Each digit corresponds to a 16KB shadow RAM region:
0=C000-C3FF   1=C400-C7FF   2=C800-CBFF   3=CC00-CFFF

Example:
To unlock the memory range from C800 to CFFF, run:

  DEVICE=TWINUMB.SYS 23

If you pass no region digit in argument, then TWINUMB attempts to autodetect
and unlock regions that are not occupied by any ROM data.

Before reprogramming the chipset, TWINUMB verifies whether the system BIOS
matches a known signature associated with the UMC UM82C330 chipset. If the BIOS
is not recognized, the program will refuse to operate.

If you're certain your PC uses the UM82C330 / UM82C336F chipset but TWINUMB
doesn't recognize the BIOS, you can force execution using the ! flag:

  DEVICE=TWINUMB.SYS 23!

Some of the memory regions may be occupied by option ROMs. TWINUMB will refuse
to unlock such regions. Again, if you know exactly what you are doing you may
force it using the '!' argument.

In practice you will likely want to execute TWINUMB before loading an UMB
enabler like USE!UMBS, and follow it with a DOS=UMB directive to let DOS
move part of itself into UMB. CONFIG.SYS example:

  DEVICE=TWINUMB.SYS 23
  DEVICE=USE!UMBS.SYS C800-CFFF
  DOS=UMB
  DOSDATA=UMB


=== [ ABOUT BIOS SETTINGS ] ===================================================

While experimenting with my mainboard, I observed that the amount of shadow RAM
is consistently subtracted from the available extended memory - even when
shadowing is disabled in the BIOS. In effect, it does not matter to TWINUMB
wheter shadow RAM is enabled or not in the BIOS. This is true for my mainboard,
but I obviously cannot vouch for other models.

My recommendation: ALWAYS enable RAM shadowing in your BIOS for regions you
plan to repurpose as UMBs. This ensures the BIOS takes all the necessary steps
to prepare the shadow RAM, taking in account any specificities your maiboard
might have. TWINUMB can then just flip the proper READ+WRITE bits and be done.


=== [ VERSIONS ] ==============================================================

TWINUMB v1.1 (20 AUG 2025):
 - now implemented as a proper SYS device driver
 - autodetects suitable regions when no region is specified in arguments
 - zeroes unlocked shadow regions to prevent parity faults

TWINUMB v1.0 (14 AUG 2025):
 - initial public release


=== [ LICENSE ] ===============================================================

TWINUMB is published under the terms of the MIT license.

Copyright 2025 Mateusz Viste

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

======================================================================[ EOF ]==
