IBM 5110 RWS (Read/Write Storage, aka RAM) Modern-Make Replacement

While I was on travel to VCFMW20 over the weekend, a shipment from Canada had arrived for me back home: a set of modern-make replacement RWS cards to be tested on an IBM 5110.

Mark this day! Sept 18th, 2025 – the test has gone well. Each of the replacement cards works equal to the original IBM RWS cards, I can find no fault in their operation.

As I had not operated my IBM 5110 in a few months, first I tested the “as-is” condition. You can run the system with the “clam shell” top cover opened. I tested with the single 32KB board (16KB + 16KB) and then a pair of cards (for a total of 64KB). No issues, all worked as expected with the original equipment. This also let me “dial in” and practice what kind of BASIC test program I wanted to use for the replacement RWS cards.

That program is as follows:

NOTE: Adjust as follows depending on the RWS configuration being used… (both line 10 and 20)
16KB, N=1400
32KB, N=3400
48KB, N=5500
64KB, N=7500

10 N=5500
20 DIM A(5500)
30 FOR I = 1 TO N
40 A(I) = 999999999999999         <-- that's 15x nines
50 NEXT I
60 FOR I = N TO (N-10) STEP -1   <-- observe end of the writes
70 PRINT A(I);
80 NEXT I

The max number length in this BASIC is 18 (or maybe 17, I forget exactly, which is why I just picked 15 in the program above — enough to ensure the 8-byte packed equivalent won’t have any words filled with zeros). There is a way to override RUN to use single-precision instead of double-precision. But by default, each numeric variable in this BASIC consumes 8-bytes (as opposed to the 5-bytes more commonly found in the Microsoft-derived BASIC’s). This sample program with 64KB was about 45 seconds, or with 48KB was about 33 seconds of runtime (with the default double-precision mode of regular “RUN”).

The sequence of “999999999999999” (15 nine’s) is encoded in hex as C7FF F04D 38D7 EA4C. Note, it may actually be reverse from this (starting with “4CEA”, I’m not entirely sure) — all I’m looking for is that whatever numeric value is decided, a consistent packing is observed all across the RWS address space.

So, in order to verify the results, you use the DCP (Diagnostic Control Program). To enter the DCP, press HOLD followed by CMD KEYPAD + while at the BASIC prompt. Do not enter the DCP DIAG mode (which would be CMD KEYPAD *). If you enter DCP DIAG, you cannot return back to BASIC.

At the DCP prompt, do something like “D B000” to display the contents at address B000 (the DCP works only in values as hex). As a quick memory map summary:

The SYSTEM uses about 4KB.  This includes the 128 bytes of memory-map registers, screen text-mode address at 0200h, and various buffers (like for tape read/write) and some support routines copied to RWS (such as for supporting the interactive-operation of BASIC).  The users BASIC code starts at 120Eh.  That's why on startup, the bottom right remaining RWS (memory) value will be total capacity minus 4624 (decimal) bytes.

The BASIC workspace will then be all of the remaining RWS.  The amount of "test memory" will depend on how large your test-program is (as stored starting at 120Eh in tokenized-BASIC form).

16KB      0 to 3FFFh  [ max DIM 1467 ]
32KB   4000 to 7FFFh  [ max DIM 3515 ]
48KB   8000 to BFFFh  [ max DIM 5563 ]
64KB   C000 to FFFFh  [ max DIM 7611 ]

( 0 to 1210h is SYSTEM reserved; BASIC programs don't have to worry about specific addresses, but this explains why 4KB is essentially "consumed" by the system in that first 16KB slot )

( "max DIM" above means when using a minimal BASIC program; the DIM size you can use is reduced relative to the size of the BASIC program keyed in; each DIM numeric entry consumes 8 bytes )

NOTE: Some limitations about this BASIC - in comparison to most more modern BASIC implementations...
- No support for ":" to make compound statements
- DIM arrays are indexed starting at 1 instead of 0, with no override option
- DIM A(x), x must be a numeric (not a variable)

Here is what the DCP activation from BASIC should look like (after issuing the “D B000” command, for Display Address):

On the above example, I was setup using a 48KB RWS configuration. So “D C000” (display C000 hex) would be beyond available RWS capacity (so it would just wrap back to 0). Instead, using “D B000” shows the expected values (at around 44KB into the RWS address space). Use up and down arrows to show the values are consistent. Use ATTN key to exit the RWS Display monitor. Then use CMD KEYPAD – (minus) to return to BASIC (if want to adjust the program, such as to store a different value into the array).

I tested with just 16KB installed, then 32KB, then 48KB, then 64KB. I each case, the expected values in RWS were observed in the DCP monitor. As far as I can tell, these RWS replacements truly do work as replacements to the IBM original parts.

So, what do these new fancy boards look like? They look great! The only complication in making them in welding on a compatible 24-pin-interface at the bottom (that is, compatible with the non-standard IBM A1 board). The easiest solution is trimming these pins and the plastic enclosure off from a non-working card of that era (such as from System/3 cards), or from non-working peripherals like the 5114 disk drive (the data-interface cables use this style of connector) or a non-working 5106 external tape drive (which has 3 cards inside of it).

The plastic enclosure case isn’t the issue (it can be replicated). The issue is the particular bend in the 24-pin are flexed (then held by the plastic enclosure piece) to be friction-pressed into the connector slot. So, if you come across those boards, keep them for that unusual pin-claps and not just the green plastic caps.

Then I also wanted to compare the power-usage (or heat) difference between these and the original. As you can see in the FLIR results below, it’s no contest – I put a single RWS-replacement module in what would be the “48KB” slot, and an original IBM RWS module in the 32KB slots. The original IBM RWS modules light up substantially, meaning relative to all other components they are probably consuming more power.

On the 2nd image (or right) the top-left component is the systems AC/DC power converter. To the lower right of that is the external-port adapter in the A-slot of the A1-board.

Incredible work! To learn more details about the journey, refer to:

IBM 5110 RAM timings | Vintage Computer Federation Forums

Leave a Reply