Upgrading an IBM PC/XT Motherboard with 1MB of RAM

Introduction#

I have an IBM 5155 Portable Personal Computer in excellent, fully working condition. The 5155 has no motherboard of its own: it uses the early “64-256KB” version of the IBM 5160 (PC XT) system board. Mine came with 256KB, four banks of 64K chips. I wanted to fill it with as much memory as the board can hold: 1MB of chips, giving 640KB of conventional memory plus up to 256KB of “high memory” above 640KB.

The mod is based on Cy Atkinson’s 1989 text 928K HOW2 and its HIMEMV2 decoder PROM. In 2011 members of the VCFed forum rebuilt the useful part of that PROM as a GAL16V8. Most of the work is swapping socketed chips, and on the early board you also plug one extra chip into an empty socket.

Which boards this applies to#

Two warnings:

• The mod depends on the IBM XT board design. It is not for the IBM 5150 PC, and you should not try it on XT clones (see clones).
• On some late 256-640KB boards U44 is soldered in, not socketed, and has to be desoldered first. pcdata76 on VCFed warns that the power and ground pins need a lot of heat and that the pads lift easily.

My board also has an NEC V20 in place of the 8088. Its BIOS ROMs, 1501512 and 5000027, are the original 11/08/82 XT BIOS. Neither one matters for this mod.

Bill of Materials (BOM)#

Each bank has nine chips: eight data bits and one parity bit. IBM specifies 200 ns RAM (access time 200 ns, cycle time 345 ns), so 70 ns parts are much faster than needed. Speed is not an issue for the GAL either: the TBP24S10 PROM it replaces has a maximum access time of 55 ns, and even the slowest GAL16V8 grade is faster.

Tools:

• XGecu TL866II Plus programmer with minipro
• ESD wrist strap and grounded mat. Old DRAMs and TTL parts are easily damaged by static.

High memory on the PC/XT#

The 8088 has 20 address lines and can address 1MB. Cy’s text splits that 1MB into sixteen 64K blocks and calls them “segments” 0 to F, after the first hex digit of the address. IBM gave the first 640K (segments 0–9) to DOS and programs. The remaining 384K (segments A–F) is reserved for video memory, adapter ROMs and the system ROM. Cy calls the part of that area you can reclaim “HIGH MEMORY”. DOS 5 and later call the same thing the upper memory area, or UMBs. It is not the same as the HMA, which only exists on 286 and later CPUs.

So at most 640K + A + C + D + E = 896K is usable without overlapping anything. The “928K” in Cy’s title also counts the lower half of segment B (see first table set).

How the decoding works#

The U44 decoder PROM#

U44 is a TI TBP24S10, a 256 × 4 bit Schottky PROM with 3-state outputs. For every 64K segment it tells the board whether there is RAM on the system board, and if so, in which bank.

Its 8 address inputs are made up like this (from sheet 3 of the system board logic diagrams):

E2 pads 1 and 3 go to ground. A6 and A7 are pulled up by 8.2 kΩ resistors (RN2), so a fitted jumper reads as 0. The switches work the same way. A7–A4 select one of 16 tables: the two E2 jumpers pick one of four sets, and switches 4 and 3 pick a table within the set. A3–A0, the segment number, select the entry in that table.

Outputs (Q3 is not connected):

Q2 and Q1 are the bank number. Q0 (pin 12) is the segment enable and goes to U24 pin 4. Pins 13 and 14 are the PROM’s active-low chip enables (/G1, /G2). They are tied to ground on the board. Keep that in mind for the GAL.

The 74LS158 in U84 and the 0-4-8-C rule#

A 41256 has nine address lines instead of the 4164’s eight, so each bank needs one more multiplexed address bit, MA8. On the XT board, U84 (a 74LS158 quad 2-to-1 selector) switches XA16 and XA17 onto MA8 for the row and column phases. MA8 goes to pin 1 (A8) of every RAM chip in all four banks. On the 64-256KB board the U84 socket is empty, because a 4164 doesn’t use pin 1. Use the 74LS158 that IBM specifies: its outputs are inverted, unlike the 74LS157’s.

Because A16 and A17 choose one of four 64K quarters inside a 256K chip, a bank can hold at most one segment from each of the groups 0-4-8-C, 1-5-9-D, 2-6-A-E and 3-7-B-F. Every table below follows this rule.

Refresh#

The XT refreshes its DRAM with timer channel 1 and DMA channel 0. About every 15 µs (every 72 clocks) a dummy DMA read cycles through the addresses. A refresh cycle takes 4 clocks, about 7% of the bus bandwidth. The KM41C256 needs 256 refresh cycles every 4 ms, and its datasheet lists A8 as “don’t care” for RAS-only refresh. That means the XT’s existing refresh is enough: 256 × ~15.1 µs ≈ 3.9 ms. minuszerodegrees confirms that the 256-640KB board uses 8 refresh address bits for its 41256 chips.

IBM’s original U44 tables#

Rows are U44 inputs A7–A4 (E2 jumpers and switches), columns are segments.

Seg#             0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F

Both E2 jumpers fitted (up to 4 banks of 128K chips)
             0 = 9  9  E  E  E  E  E  E  E  E  E  E  E  E  E  E  = 128K
             1 = 9  9  B  B  E  E  E  E  E  E  E  E  E  E  E  E  = 256K
             2 = 9  9  B  B  D  D  E  E  E  E  E  E  E  E  E  E  = 384K
             3 = 9  9  B  B  D  D  F  F  E  E  E  E  E  E  E  E  = 512K

E2 3-4 only (1 bank of 64K chips in bank 3)
             4 = F  E  E  E  E  E  E  E  E  E  E  E  E  E  E  E  = 64K
             5 = F  E  E  E  E  E  E  E  E  E  E  E  E  E  E  E  = 64K
             6 = F  E  E  E  E  E  E  E  E  E  E  E  E  E  E  E  = 64K
             7 = F  E  E  E  E  E  E  E  E  E  E  E  E  E  E  E  = 64K

E2 1-2 only (2 banks of 256K and 2 banks of 64K)
             8 = 9  9  9  9  E  E  E  E  E  E  E  E  E  E  E  E  = 256K
             9 = 9  9  9  9  B  B  B  B  E  E  E  E  E  E  E  E  = 512K
             A = 9  9  9  9  B  B  B  B  D  E  E  E  E  E  E  E  = 576K
             B = 9  9  9  9  B  B  B  B  D  F  E  E  E  E  E  E  = 640K

No E2 jumpers (up to 4 banks of 64K chips)
             C = 9  E  E  E  E  E  E  E  E  E  E  E  E  E  E  E  = 64K
             D = 9  B  E  E  E  E  E  E  E  E  E  E  E  E  E  E  = 128K
             E = 9  B  D  E  E  E  E  E  E  E  E  E  E  E  E  E  = 192K
             F = 9  B  D  F  E  E  E  E  E  E  E  E  E  E  E  E  = 256K

The 64-256KB board ships without E2 jumpers and uses tables C–F. The 256-640KB board has E2 1–2 fitted and uses tables 8–B. Table B, with both switches OFF, is the standard 640K setup. According to Cy, the 128K chips that the first set was made for were never commercially available.

This also explains IBM’s own 640K upgrade for the 64-256KB board, as described by Scott Mueller and minuszerodegrees:

1. Put 256K chips in banks 0 and 1.
2. Plug a 74LS158 into U84.
3. Fit a jumper on E2 1–2, or join U44 pins 1 and 8.
4. Set switches 3 and 4 OFF.

What the GAL16V8 replacement implements#

Cy’s HIMEMV2 PROM had all 16 tables. The GAL version (U44V2M, by Chuck(G) on VCFed) implements only the first and third sets. I checked this by evaluating its equations for all 256 inputs and comparing the result with Cy’s HIMEMV2 listing. The GAL also ignores A6 (E2 1–2) completely: the equations don’t use it, and the assembler log lists pin 1 as “unused”. So with the GAL:

• E2 3–4 open: third set, whether or not E2 1–2 is fitted. This is the normal choice.
• E2 3–4 fitted: first set (segment B overlap), whether or not E2 1–2 is fitted.

I still recommend fitting E2 1–2 on a 64-256KB board. It does no harm with the GAL, and if you ever put an original IBM PROM back in, the board will be set up like a standard 256-640KB board.

Third set: E2 3-4 open (recommended)#

Tables 8, 9 and A need 256K chips in all four banks. With table B, bank 3 may keep 64K chips. The last row has the same switch setting as IBM’s standard 640K configuration. On a 256-640KB board, the only changes are the GAL and 256K chips in bank 2 (and bank 3 if you like).

First set: E2 3-4 fitted (segment B overlap)#

This set maps system board RAM into segment B, underneath the video adapter’s screen buffer. Cy says it only works with an MDA or a CGA, not both. He used table 1 with a CGA and a hard disk to get a 736K DOS region: 640K plus segment A plus the lower half of B. He also warns that some software finds RAM in the lower half of segment B, assumes there is an MDA, and overwrites itself or COMMAND.COM. Test every program you use if you choose this set.

The second set (testing) and the fourth set (old boards with 64K chips soldered into bank 0) are in Cy’s text but not in the GAL.

Seg#             0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F

E2 3-4 fitted (first set)
             0 = 9  9  9  9  B  B  B  B  D  D  D  D  F  F  F  E
             1 = 9  9  9  9  B  B  B  B  D  D  D  D  E  F  F  E
             2 = 9  9  9  9  B  B  B  B  D  D  D  D  E  E  F  E
             3 = 9  9  9  9  B  B  B  B  D  D  D  D  E  F  E  E

E2 3-4 open (third set)
             8 = 9  9  9  9  B  B  B  B  D  D  F  E  F  F  D  E
             9 = 9  9  9  9  B  B  B  B  D  D  F  E  E  F  D  E
             A = 9  9  9  9  B  B  B  B  D  D  E  E  F  F  D  E
             B = 9  9  9  9  B  B  B  B  D  D  E  E  E  F  D  E

Step by step#

1. Program the GAL#

The JEDEC, EQN and LOG files are in U44V2M.ZIP. I programmed a GAL16V8D with an XGecu TL866II Plus and minipro:

[robert@gram U44V2M]$ minipro -p GAL16V8D -w U44V2M.JED
Found TL866II+ 04.2.86 (0x256)
Warning: Firmware is out of date.
  Expected  04.2.131 (0x283)
  Found     04.2.86 (0x256)

VPP=16V
Declared fuse checksum: 0x2A7F Calculated: 0x2A7F ... OK
Declared file checksum: 0x0000 Calculated: 0xC083 ... Mismatch!
JED file parsed OK

Use -P to skip write protect

Erasing... 0.82Sec OK
Writing jedec file...  3.52Sec  OK
Reading device...  0.19Sec  OK
Writing lock bit... 0.25Sec OK
Verification OK

The file checksum mismatch is harmless. The assembler wrote 0000 as the file’s transmission checksum. The fuse checksum, which covers the actual fuse map, matches.

My 2023 version of minipro set the lock bit automatically. Current minipro versions only lock the device when you pass -P. If you leave it unlocked, you can check the chip again later:

minipro -p GAL16V8D -m U44V2M.JED

These are the equations inside the GAL:

CHIP MEMV2 GAL16V8

;       GAL programming for PCXT U44 Memory expansion.
;       Only the first and third tables of the HIMEMV2 ROM are implemented.

gnd=10 A6=1 A5=2 A4=3 A3=4 A2=7 A1=6 A0=5 A7=19
Vcc=20 Q2=14 Q1=15 Q0=16

@UES Sydex

EQUATIONS

/Q2 =
        /A3

/Q1 =
        A7*A3*A2*A1*/A0 +
        /A3*/A2 + /A2*/A1 + /A7*/A2

/Q0 =
        /A7*A5*/A4*A3*A2*/A1 +
        /A7*A5*A4*A3*A2*/A0 +
        A4*A3*A2*/A1*/A0 +
        A7*A5*A3*/A2*A1 +
        A7*A3*A1*A0 +
        A3*A2*A1*A0

A GAL16V8 has room for only 8 product terms per output, so the other table sets were left out.

2. Fit the GAL into the 16-pin U44 socket#

The GAL is a 20-pin part and U44 is a 16-pin socket. Put it in with GAL pin 1 in socket pin 1, so four GAL pins hang over the end of the socket:

1. Join GAL pins 8 and 10. This connects the GAL’s ground (pin 10) to socket pin 8 (GND). Pin 9 can be part of the bridge. DIP pins are counted from the notch along one row (1–10) and back along the other (11–20), so both pins are on the pin-1 row, at the end that hangs over the socket.
2. Make sure GAL pins 17 and 18 don’t touch the socket. The JEDEC file configures them as outputs that always drive high, and they line up with socket pins 13 and 14, the PROM’s grounded enables. If they made contact, two outputs would be shorted to ground for as long as the machine is on. Lattice rates a short for one output at a time and for no longer than one second. In my build, pins 17 and 18 sit outside the 16-pin socket and touch nothing, so the original JEDEC file is fine. Check this on your adapter before you power up.
3. Trim or insulate the overhanging pins so they can’t touch the neighbouring chip or the resistor network next to U44.

Check with a meter that nothing is shorted before you power on.

3. Fit U84 and E2 (64-256KB board only)#

1. Plug the 74LS158 into the empty socket U84. Check pin 1 against the board’s silkscreen.
2. Solder a 2-pin header into E2 pads 1–2 and fit a jumper (or bridge the pads with wire).
3. Leave E2 3–4 open unless you really want the first set.

4. Replace the RAM#

Take out the 4164 chips and fit 41256 chips in all four banks (on a 256-640KB board, in banks 2 and 3). Watch the pin 1 orientation. With table B (both switches OFF), bank 3 may keep 64K chips.

Use an anti-static wrist strap and a grounded ESD mat.

5. Set switches 3 and 4#

The single 8-position switch block is printed SW1 on my board, which is also what minuszerodegrees and Mueller call it. Cy’s text calls it SW2. Pick a row from the third set table that fits your adapters. ON means closed.

On a stock board, switches 3 and 4 tell the board how many banks are fitted. After the mod they only select the U44 table. The BIOS doesn’t need them to count memory, because it probes RAM in 16K steps up to 640K.

Verifying the upgrade#

1. POST and 640K. The POST probes memory only up to A0000 and zeroes what it finds, so it will count 640K and nothing above. In DOS, CHKDSK (or MEM on DOS 5+) should report 655,360 bytes of total conventional memory. Less than that points to a bad chip or a wrong table.

2. Initialise high memory before reading it. The BIOS never writes above 640K, so the parity bits there are random, and the first read can stop the machine with PARITY CHECK 1. Write every high memory block before anything reads it. The VCFed threads use CLEARMEM.SYS as the first line of CONFIG.SYS, one line per contiguous block (USE!UMBS v2.2 has this built in):

   DEVICE=C:\UMB\CLEARMEM.SYS A000 1000
   DEVICE=C:\UMB\CLEARMEM.SYS D000 2000
   

3. Quick manual check with DEBUG. Fill a segment with a pattern and read it back. Pick a segment your table maps and that no adapter uses; segment D is a safe choice on the recommended tables. Never do this to segment B or to a segment where an adapter ROM or video memory lives.

   C:\> DEBUG
   -F D000:0000 FFFF 55
   -D D000:0000 L 80
   -D D000:FF80 L 80
   -F D000:0000 FFFF AA
   -D D000:0000 L 80
   -Q
   

   Every byte should read back 55 and then AA.

4. Memory test tool. On VCFed, ibmapc used CheckIt 3, which found and passed 128K of “Hi RAM” at D000–F000 with this GAL. pcdata76’s USE!UMBS package includes a test utility, and UMBINFO shows the resulting upper memory map.

Using high memory#

Upper memory blocks (DOS 5 and later)#

The most useful approach today is to turn high memory into upper memory blocks and load drivers and parts of DOS there. pcdata76 describes a working setup with PC DOS 6 and MS-DOS 6.22. MS-DOS 3.1 hung with the UMB driver loaded.

DEVICE=C:\UMB\USE!UMBS.SYS A000-B000 D000-F000
DOS=UMB
DEVICEHIGH=...

The address ranges have to match the U44 table you picked with SW1. The example is for 640K plus A, D and E. ibmapc got 128K of UMBs this way and had 576K of conventional memory free after loading drivers high. DOSMAX, SHELLMAX, HIGHUMM.SYS and LASTBYTE.SYS are alternatives mentioned in the same thread.

Lid lifters and RAM disk: LIFT704, LIFT736, HIDISK#

Cy’s text mentions two kinds of programs for high memory:

• Lid lifters. Segment A and the lower half of B sit directly above 640K, so they can be added to DOS’s own memory. Cy’s SET704K and SET736K raised DOS’s limit from 640K to 704K or 736K. They were non-resident device drivers that did their job and removed themselves.
• RAM disks. The rest of high memory isn’t contiguous with conventional memory, so DOS can’t use it directly. Cy’s HIRAMDSK turned it into a RAM disk and could combine it with normal memory for a RAM disk of up to 500K.

I haven’t been able to find copies of SET704K, SET736K or HIRAMDSK. So I wrote my own: LIFT704, LIFT736 and HIDISK. They have new names so nobody mistakes them for Cy’s originals. They are written in 8086 assembly (NASM), and the download contains the binaries, the source, a README and the MIT licence: xt-himem-tools.zip. The source, the build script and the DOSBox-X and FreeDOS tests are also on Gitea.

LIFT704 and LIFT736#

LIFT704.COM raises the DOS memory limit to 704K by adding segment A (A000–AFFF). LIFT736.COM raises it to 736K by also adding B000–B7FF, the RAM just below the CGA screen buffer. LIFT.COM is the same program and takes 704 or 736 as an argument.

LIFT704 needs a table with segment A and no EGA or VGA. LIFT736 needs the first table set and a CGA, and nothing else in segment B.

Run it as one of the first lines of AUTOEXEC.BAT, before any TSR is loaded:

@ECHO OFF
C:\UTIL\LIFT736
IF ERRORLEVEL 1 ECHO Memory limit stays at 640K

It can also be run at the DOS prompt. The output looks like this:

LIFT736 1.0 - raise the DOS memory limit to 736K
Copyright (c) 2026 Robert Zaage, MIT licence
DOS version 5.00
Testing RAM at A000-B7FF... OK
Memory limit raised from 640K to 736K.

The trick is the same one the old lid lifters used. DOS gives a program the largest free memory block, which is normally the last block in the memory chain, ending at A000. While LIFT runs, it owns that block. It makes the block 64K or 96K longer and sets the BIOS memory size to 704K or 736K. When LIFT exits, DOS frees the block with its new size, and the extra memory is free for every program that runs afterwards. COMMAND.COM reloads its transient part from disk whenever a program has overwritten it, as usual. The change lasts until the next reboot.

Running it a second time just reports that the limit is already raised.

HIDISK.SYS#

HIDISK.SYS is a device driver for CONFIG.SYS that turns segments C, D and E into a RAM disk:

DEVICE=C:\UTIL\HIDISK.SYS

By default it looks for usable 64K segments in C000–EFFF. It never touches segment B or F, and it leaves out segment A so that LIFT can still use it. You can give it a range such as D000-EFFF, and /V makes it report every segment. With /V and an option ROM at C800, as with an XT hard disk controller, it prints for example:

HIDISK 1.0 - high memory RAM disk for the IBM PC/XT
Copyright (c) 2026 Robert Zaage, MIT licence
  A000h: not in range
  B000h: never used (video)
  C000h: option ROM signature found, skipped
  D000h: RAM OK, used
  E000h: RAM OK, used
RAM disk: 128K in segments D000 E000, drive D:

The driver formats the disk when it starts, so there’s no need to run FORMAT. The disk is FAT12 with 512-byte sectors, one sector per cluster and the volume label HIDISK. The segments don’t have to be next to each other. The resident part is 331 bytes. If no usable high memory is found, the driver says so and DOS doesn’t install it.

Safety checks#

Both tools check before they change anything, and refuse instead of guessing.

LIFT checks:

• DOS 2 or later.
• The BIOS reports exactly 640K (or 704K when you go on to 736K).
• No EGA or VGA. For 736K, no MDA or Hercules either.
• An 8088, 8086 or V20 CPU. On an AT, port A0h is the second interrupt controller and not the NMI mask.
• The DOS memory chain is intact and ends exactly at the current top of memory, and no upper memory blocks are in use.
• HIDISK isn’t using the memory.

HIDISK skips a segment if an option ROM signature (55 AA) appears at any 2K boundary, if it overlaps an EMS page frame or upper memory blocks, if it is segment A and an EGA or VGA is installed, or if it is below the BIOS memory size.

Both tools then test the RAM before they use it. The RAM above 640K holds random parity bits after power-on, so the first read of an address can stop the machine with PARITY CHECK 1 (see Verifying the upgrade). So the tools mask the NMI, write zeros to the whole area without reading it, and only then write and read back 55h, AAh and two address patterns. The address patterns catch RAM that shows up twice in the address space. Where the RAM parity latch can be read, a parity error during the test also counts as a failure. At the end the area is zeroed and the NMI is enabled again. If a byte fails, LIFT prints its address and doesn’t change the memory limit, and HIDISK leaves that segment out.

Testing#

I tested both tools in DOSBox-X with machine=cga and an 8086 CPU. In that setup the BIOS reports 640K, while A000–AFFF and C000–EFFF are plain RAM, just like on my board with the GAL. DOSBox-X never puts RAM at B000–B7FF in CGA mode, so I tested LIFT736 with a one-line patch to DOSBox-X that maps RAM there. I ran the tests with DOSBox-X’s built-in DOS and with the FreeDOS 1.4 kernel. That covered LIFT704 and LIFT736 on a CGA, running them twice, and refusing on EGA, VGA, MDA and Hercules and on a machine with no RAM above 640K. For HIDISK I copied files onto the RAM disk, compared them with FC /B, filled the disk, and ran CHKDSK on it. I also checked that it skips a ROM signature that I planted at C800 and the VGA BIOS at C000, and that it doesn’t install itself when there’s no high RAM.

I haven’t tried them on my 5155 yet. No emulator can test the GAL decoding on the real board. Until I have, treat them as untested on real hardware.

Clones and XT compatibles#

The mod relies on the IBM XT board’s design: the U44 address inputs, E2, U84 and the bank wiring. Clone boards are built very differently. Cy warns that putting a decoder chip made for the IBM board into a compatible is likely to damage the chip, the board or both. A similar mod would only be possible with the clone’s full schematic and a readout of its own decoder.

Trivia#

• IBM documented the XT and the Portable in a single Technical Reference (April 1984). The main difference in that manual is the power supply: 114 W in the Portable, 130 W in the XT.
• Scott Mueller writes in Upgrading and Repairing PCs that IBM “invented this upgrade much earlier, but they held the upgrade back for several years.” Owners worked it out themselves from the schematics in the Technical Reference. Mueller calls U44 a “PAL”; IBM’s schematic shows a 24S10 PROM.
• The “928K” in Cy’s title is 640K + segment A (64K) + half of segment B (32K) + segments C, D and E (192K).
• In 1989 Cy sold the programmed HIMEMV2 PROM by mail for $9. A diskette with SET704K, SET736K, HIRAMDSK and documentation cost $5 more.
• The GAL version came out of a VCFed thread started by ibmapc in November 2011, after nobody offered to burn a PROM. Chuck(G) wrote the equations and posted U44V2M.ZIP on 3 December 2011. The JEDEC file’s user signature fuses spell SYDEX.

Sources#

• Cy Atkinson, 928K HOW2-V10: How to install up to 1 Meg on the IBM PC XT motherboard, 27 December 1989
• Chuck(G), GAL16V8 JEDEC/EQN/LOG files U44V2M.ZIP, December 2011
• IBM, Technical Reference, Personal Computer XT and Portable Personal Computer, Revised Edition, April 1984 (6361459): system memory map pp. 1-8 to 1-9, RAM and DMA pp. 1-12 to 1-13, switch settings p. 1-26, logic diagrams sheets 3, 6 and 7 (pp. 1-33, 1-36, 1-37), power supplies section 3
• Texas Instruments, The Bipolar Microcomputer Components Data Book, 3rd ed., 1981: Series 24 and 28 PROMs (TBP24S10), pp. 2-13 to 2-16
• Lattice GAL16V8 datasheet
• Samsung KM41C256 datasheet
• Texas Instruments SN74LS158 datasheet (SDLS058)
• Scott Mueller, Upgrading and Repairing PCs (Que), ch. 12, “Installing 640K on the XT Motherboard”, pp. 521–523, excerpt at minuszerodegrees.net
• minuszerodegrees.net: 5160 motherboard versions, 5155 motherboard versions, 5160 RAM (64-256KB), 5160 RAM (256-640KB), 5160 switch settings, 5160 RAM refresh, 5160 POST breakdown, 5160 BIOS revisions
• VCFed forum: HIMEMV2 or equivillent PROM (2011)
• VCFed forum: 1M memory upgrade mod for IBM PCXT 5160 and Portable 5155 (2018)
• minipro