Content © Alfred Arnold, 2002 (original HERE). Modified by Major Tom.
SCSI has been the disk interface of choice for most of IBM's Micro Channel
PS/2 machines, except the first generation that either used ST-506 or ESDI
disks or some late desktop models with IDE. IBM quickly targeted them to
the high-end and server market since the Micro Channel was not successful
in the mass market. This and the fact that IBM has always put an emphasis
on 'balanced systems' with an I/O performance growing with the CPU's power
drove the development of SCSI controllers with separate cache memory.
One common example is the 'SCSI Controller with Cache', also known by its
code name 'Spock'. It is a 32-bit busmaster with 512 Kbytes of local
cache RAM, organized as two 30-pin SIMMs of 256Kx9. The RAM is controlled
by a local 80188 or 80186 microprocessor. A rarely known fact is that the
controller can be extended to 2 Mbytes by replacing the SIMMs with 1M
types. So you simply take two SIMMs out of your junkbox, put them in,
and...typically get a glorious error message and nothing works.
Of course it would have been too simple for IBM to take 'industry standard'
SIMMs. They used SIMMs with a different parity pinout and additional
presence detection pins. The latter ones allow the computer to detect a
SIMM's size automatically, without having to probe all possible sizes.
In detail, there are the following differences between the standard and
|2 ||Data CAS ||Data&Parity CAS|
|24 ||Not Connected ||Presence Detect|
|26 ||Parity Data Out ||Presence Detect|
|28 ||Parity CAS ||Not Connected|
|29 ||Parity Data In ||Parity Data In/Out|
The two presence detect pins allow the following combinations:
|Pin 24||Pin 26||Capacity|
|open ||open ||no module inserted|
These modules have not only been used for the cached SCSI controller, but
also in some early PS/2 machines for main memory, namely in the ISA-based
Model 30-286, and the MCA-based 50/60 (not the newer 50Z which
already uses 72-pin modules). Watch out however to use the correct type
of modules for this purpose, see below!
Warm Up Your Soldering Iron!
So to convert an industry-standard SIMM to an IBM-style SIMM, the
following has to be done:
- cut the connection between SIMM pin 26 and the parity chip's DataOut
- connect the parity chip's DataOut pin to SIMM pin 29;
- cut the connection between SIMM pin 28 and the parity chip's CAS
- connect the parity chip's CAS pin to SIMM pin 2;
- connect both SIMM pins 26 and 24 to SIMM pin 22 (GND).
In my experience, these modifications are simpler if you use 1M SIMMs
built with 3 chips instead of 9; the three chips occupy less space on
the module's PCB, and it is easier to get access to the connections.
However, if you are going to modify modules to extend a Model 30 or
50, you will have to use 9-chip modules; The memory controllers of
these old systems do not provide enough refresh address lines for the
higher-capacity 1Mx4 chips on a 3-chip module, and you will experience
strange memory errors with them. Not all 9-chip modules can be modified;
the high chip density leads to a complex layout, and some of the traces
that have to be cut might be located in inner layers...
Shown below are two SIMMs; one unmodified and a SIMM that has been modified
according to the instructions above.
Click here or click onto the
photo for a full size version of this picture.
These modules are typical for 3-chip industry-standard SIMMs. They consist
of two 1Mx4 chips for the data (the 514400 chips) and an extra 1Mx1 chip
(the 531000 in this case) for the extra parity bit. This in sum makes the
usual 1Mx9 people are talking about...the names of the individual chips may
vary wildly from module to module since the DRAM manufacturers are quite
creative at this :-)
Luckily, there are ANSI standards for RAM chip pinouts, so I can give you
a schematic rewiring plan here, both for 3-chip and 9-chip modules. The
red lines show connections to be added, while the fat double red lines
symbolize connections to be cut. Of course, there are more traces on a
SIMM than the ones shown, but I left the ones out that need not be modified
to make things a bit simpler.
The pinouts of the individual chips apply only to your SIMMs
if the chips are housed in the same case type (called 'SOJ') as for my
After two modules have been modified in this manner, it is time to insert
the modified modules into the SCSI controller and to power it up. Of
course, such operations always bear a risk and - as you might guess - I
disclaim all responsibility for controllers that break...if this is your
one-and-only Micro Channel SCSI controller, it might be wiser to buy the
correct modules from IBM (or scavenge them from a Model 30-286 or
Model 50/60). If everything went right, your PS/2 should boot up as usual
and report an error 174 (equipment change). After the usual
autoconfiguration, it's time to make some measurements. I used
cthdben, a DOS program from the German computer magazine c't that
measures the data rate for linear and random accesses. Since Spock's
cache is write-through, there are only improvements for read accesses with
a working set smaller than the cache size. The PS/2 used for the measurements
is a PS/2 8595-AKF upgraded to a 486DX2 CPU (66 MHz). The disk is an old
HP 1 Gig monster (5,25 inch, full height) that maxes out at approximately
2 Mbytes/s. The first figure shows the average data rate for random
accesses with 1/10th of the total file size:
For file sizes smaller than 256 Kbytes or larger than 2 MBytes, the results
do not differ: Either the working set fits into both sizes, or it is to
large for both. The differences in the area between these margins is however
remarkable: They result both from the higher RAM-to-RAM than Disk-to-RAM data
rate and from the lower access time (the half rotation needed in average
before the first data sector comes by is eliminated plus the SCSI protocol
overhead). One can extrapolate that for a larger cache, the curve could well
extend into the range of 5 to 10 Mbytes per second. However, Spock has no
provisions to use 4 Mbyte modules; honestly said, I was already surprised that
2 MByte cache work. The 80188 processor only has a 1 MByte address space so
there must be some sort of bank switching mechanism on the controller's
memory interface; this wouldn't have been necessary for a 512K-only design.
Looking at linear accesses, the differences are not as impressive, but still
Though the cache cannot avoid repeated disk accesses to the same disk sectors,
there is still a gain from the cache due to its read ahead capability:
the controller reads data in larger chunks than the main CPU really requests
them, and when the next chunk is requested, the controller can already deliver
its beginning without overhead. Operation with no or too few cache is not as
bad as in the random case as the drive's head only have to move by one
These are only synthetic benchmarks; your mileage in practical applications
may vary. Modern operating systems like Linux or NT already have dynamic disk
caches that automatically use free main memory, and of course copying in main
memory is even faster than transferring data over the MCA bus. I'd say it is
a nice extension if you have 30-pin SIMMs collecting dust otherwise and if
you have fun in hardware hacking. If you'd have to buy the modules, better
invest the money in main memory ;-)