Type 4 Complex

rf90954a.exe Reference Disk Type 4 Processor Complex v1.34 (zipped image)
rd9095a.exe Diagnostic Disk Type 1 - 4 Processor Complex v2.33 (zipped image)

"N" 486DX2 66 MHz (61G2343)
"P" / Upgrade Pentium 60 MHz (52G9362, 06H7324)
"Q" / Upgrade Pentium 66 MHz (92F0120, 06H7317)
"Y" / Upgrade Pentium 90 MHz (06H3739, 06H7095)
Upgrade Pentium 100 MHz (06H5884, unreleased)

US5826075 Automated programmable firmware store for a personal computer system
US5878256 Method and apparatus for providing updated firmware in a data processing system

SynchroStream Controller
   Key Advantages of the SynchroStream
System Firmware
   BIOS Updates
   BIOS Levels
   Flashing to BIOS 05 and up from 03 or Lower
   BIOS 09 Trivia
FDIV Replacement
Diagnostic LEDs
   POST Diagnostic LED
   Alternate-Bank LED
Flash ROM Bank (JMP5)
Debug Port (card edge)
Serial Diagnostic Link (SDL) (6-pin header)
   SDL POST Diag Jumper
   SDL POST Diag Output
Method to Extend Personal Computer System Memory
Personal Computer Processor Upgrading
"Bad" Memory Reported in Same Positions
Support for Convenience Partition on >3.94 GB Drives


   2, 4, and 8 MB parity SIMMs for a max of 64 MB.
   2, 4, 8, 16 and 32 MB ECC SIMMs for a max of 256 MB.

   L1: 8 KB (486DX2), 16 KB (Pentium 60, 66, 90)
   L2: 128 KB write-back ("N"), 256 KB write-back ("P", "Q", and "Y")


SynchroStream Controller

SynchroStream controllers use IBM's most advanced technology packaging to integrate 5 major chips - memory, I/O (Micro Channel), DMA controllers, FIFO buffers, and ECC logic - into a single chip with a RISC-like architecture. This technology allows the high-speed interconnects and large streaming pipes that form the SynchroStream engine to provide state-of-the-art performance.

The SynchroSteam controller synchronizes data traveling between major subsystems and allows it to stream in parallel, at full bandwidth, to each subsystem concurrently.

At the heart of the computer, data is moving continually between processor, cache, main memory and the Micro Channel. Typically there is a single path to memory, so fast devices like processors have to wait for much slower I/O devices, slowing down the performance of the entire system to the speed of the slowest device. The IBM SynchroStream controller was designed to overcome this problem. It synchronizes the operation of fast and slow devices and streams data to these devices to ensure all devices work at their data at their optimum levels of performance.

SynchroStream is an intelligent device in that it predicts what data the devices will need and loads it from memory before it is requested. When the device wants the data, it is presented to it from the IBM SynchroStream controller and the device can continue working immediately, as it does not have to wait for the data to be collected from memory. When devices are moving data into memory, the IBM SynchroStream controller holds the data, and writes it to memory when it is most efficient to do so. Since devices are not moving data to and from memory directly, but to the SynchroStream controller, each device has its own logical path to memory. Devices do not have to wait for other slower devices.

The SynchroStream engine operates by using a spinning valve that continuously forms different connections between pipes. Once a connection is made, data is streamed to the Micro Channel or processor at the highest possible rates. Parallel paths allow data to stream to multiple sources at the same time. The pipes even continue to stream after the connection is changed. Data is always streaming to the Micro Channel and processor, allowing them to operate at full bandwidth.

The IBM SynchroStream controller is located on all Type 4 processor complexes, in the Server 95 and Server 95 Array systems. Implementation on the processor complex means that current PS/2 Server 95 and PS/2 Model 90 users can easily upgrade their machines to have IBM SynchroStream controller functions.

The package used to encapsulate the SynchroStream controller is called "Ceramic Column Grid Array" or CCGA. It features 625 solder columns organized in a 25 x 25 grid.

P/N 50G8192
(Type 4 "N" Complex)

P/N 8190587
(Type 4 "Y" Complex)

P/N 50G6871
(Reply TurboBoard 60/80)

The part number is either 50G8192 (older?) or 8190587 (newer?). These two variants seems to be interchangeable and it's not known whether there are any internal differences between the two. From the software point of view the two are fully compatible.

The SynchroStream controller can be also found on the Reply PowerBoard upgrade for Models 60/65/80. This part marked as 50G6871 seems to be mostly (or perhaps completely) software compatible with the variant(s) used on the Type 4 platform, hardware compatibility is however unknown currently.

The later 9576 and 9577 systems that are based on the Lacuna platform have a different type of highly integrated system controller chip that is sometimes also called the SynchroStream controller. This chip is located directly on the planar board and implements a subset of the Type 4 SSC functionality.

Key Advantages of the SynchroStream

Fast single chip implementation - Competitive designs are multi-chip and have the performance overhead of moving information between chips. SynchroStream technology provides a Zero Wait State Pentium implementation.

Intelligence - IBM SynchroStream is intelligent in that it predictively loads data from memory so that requesting devices are not kept waiting. In addition, writes to memory are stored within the IBM SynchroStream controller and written to memory to optimize memory utilization.

RISC-like architecture - Pipelines are used to move data in a fast, efficient manner between memory and the requesting device.

Stream data to Micro Channel devices - SynchroStream can stream data to Micro Channel devices at 40 MB/s.

Upgradable system implementation - Competitive system designs do not have the unique Upgradable Processor Complex design so you cannot upgrade to SynchroStream-like functions from earlier models.

System Firmware (POST & BIOS)

BIOS stored in Flash memory. IML image not required (or provided).

BIOS Updates

Flash BIOS Update Disks:

Level 10 version 1.28, Resolves an ABIOS time/date defect for OS/2 ONLY. (IMA)
Level 09 version 1.27, Seems to have an OS/2 bug. Pulled from PCBBS... (IMA)
Level 08 version 1.26 (alt EXE) (IMA)
Level 05 version ? (IMA)
Level 03 version 1.20, EMT format, image utility needed (IMA)
Level 02 version 1.10 (DSK) (IMA)

Got a 8595-OKD that came with a Type 4 (P60) complex. Every time I start it up, Win 95 comes up with the 1980 date. I can take the ref disk and use "Set Time and Date" and it will show the correct day and month, but the year will be 2799. Is that Y2K compliant or what? You can change the date and exit back to the Main Menu, then go right back in Set Date and Time and it is back to the "2799" thing. It has revision 08 BIOS. Any ideas?
   Level 10 cured the problem. It seems Win 95, at least SR2, has the same date problem as OS2 when upgrading a 8595 Type 1 or 2 complex to a Type 4 (P60/66).

BIOS Levels (based on THIS document)

What is each BIOS level actually supposed to fix?

   Ugh, have some trouble to recall the changes. The earlier levels (prior to 03) were designed for the original P60 / P66 and "enhanced 486DX2" Type 4 platforms.

Level 00 / 01
   This was the first shipment level but had some trouble with the SCSI adapters (F/W SCSI-2 and Server 95 RAID), especially under OS/2.
   Supports 16MB Memory SIMMs.

Level 02 (rel. 23 Feb 1994)
   This was a first "quick & dirty" attempt to fix it - which was not that successful.
   Added support for 32MB ECC SIMMs.

Level 03 (rel. 15 Sep 1994)
   This revision finally got it, but had other trouble (can't remember). OS/2 2.0 required new IBM2SCSI.ADD and DELIVERY.SYS for support of the Server 95 RAID adapter. Older IBM2SCSI trap the system if used with Level 03 and above (no longer a topic anyways). This level adds Fast/Wide SCSI-2 support within the OS/2 drivers.
   Supports the 90 MHz complex, FRU P/N06H3739, for 9595 & 8641 and CD-ROMs as a bootable device.
Note: Requires Refdisk ver. 1.31 and Diags version 2.31+.

Level 04 (rel. 28 Feb 1995)
   04 was supposed to fix all RAID, Time/Date, FDD and CD-ROM (boot) problems under OS/2 - but had a major problem with the memory - was withdrawn and replaced by Level 05 within a month.

Level 05 (rel. 22 Mar 1995) (called "Version 1.24 Level 05")
   This revision had some major changes, especially for OS/2 2.x and required a new, later reference / diags disk version. Level 05 was the first level to support the Y complex regularly. (previous levels might display wrong CPU info in diags / setup).
   Supports 4 GB hardfile, Enables the VPD to display the processor ID and Step level (shows if a Pentium processor with the FDIV fix is installed). Allows disabling of the error reporting log POST error which is useful during RIPL under some conditions.
   Resolves the following problems:
Bootable CD-ROM attached to the RAID controller, with an additional non-RAID SCSI adapter installed. diagnostic problems related to the CD-ROM being attached to the RAID controller. running SCSI fixed disk diagnostics with the "read verify" option selected.
Note: Requires Refdisk ver. 1.33 and Diags ver. 2.32+.

Level 06
   Never seen. Either not issued or superseded before release.

Level 07 (rel. 27 Oct 1995)
   No idea. Has been an intermediate release May have contained a "work-around" for the P90 FPU-bug (not sure).
   BIOS code was added to support switching a single keyboard and monitor between multiple systems.

Level 08 (rel. 16 Jan 1996)
   Came to fix "various problems" with the P90 platform and the IBM Fast / Wide Streaming RAID Adapter /A - which came with the Server 500. Level 08 was mainly intended to be used with the 8641 (Server 500) only, since the F/W-SR was not generally announced for the 9595A (but works though - the number of drives however was limited to 3 due to power- and heat-problems).
   The Level 08 might have various sublevels (avoided to write "subversions" ... some people might get that wrong :-) ), which differ by date of announcement but aren't explained anywhere. Most likely they fix some typo-errors / different language support.

Level 09 (rel. 26 May 1998)
   Now, as it seems, this is the last rev. (Level 08) with integrated Y2K rollover fix.

Level 10 (rel. 30 Apr 1999)
   Resolves a time/date defect for systems with the older 1S1P planar and OS/2 installed. But it seems that Win 95 (at least OSR2), has the same date problem as OS2 when upgrading a 8595 Type 1 or 2 complex to a Type 4.

Would say that Level 05 was the first BIOS that really worked. If your machine has a downlevel BIOS - use at least 05 if you have an IBM Fast/Wide SCSI-2 Adapter /A or the IBM SCSI adapter with cache /A. If your machine has the Server 95 RAID Adapter /A (codename "Passplay" without external port) or the IBM Fast/Wide Streaming RAID Adapter /A (codename "Cheetah" with external port) you should have Level 08.

Note: The (rel. mm-dd-yy) date refers to the "last modified" attribute of the $000x000.IML image files.

Flashing to BIOS 05 and up from 03 or Lower

If you need to flash a complex, you can use either 08 or 10. You do not need to configure the complex with a refdisk before flashing it. Boot with the BIOS update disk, flash it, and when the update is complete, you can use the latest refdisk and diags disk to configure the system.

BIOS 09 Trivia

If BIOS revision 9 is being used in a OS/2 system, the system date is required to correct manually every time the system is shutdown and restarted during the year of 1999. It works fine in year 2000 and beyond. Use the System Setup utility to set the correct date.

Details: A defect in the ABIOS within BIOS 8 and 9 could cause invalid system date when boot to OS/2; the defect is caused by mis-handling of Real Time Clock register's information, and it affects only OS/2. Update to BIOS 10 will fix the problem. Although it's not required, BIOS 10 can be installed in systems using other supported operating systems beside OS/2.

FDIV Processor Replacement

If you have a -xPx or -xQx complex (even the mighty -xYx), chances are it has the FDIV bug. Intel will swap out your processor with a like processor. Same speed. No upgrade for the FDIV chip is available. Read the stuff on this link. It will give you the phone# and the requirements for swapping the chip out (Includes the CPUID program to identify the presence of the FDIV bug). You will have to give them a credit card number.
   They will send out a non-FDIV chip and a pre-paid shipping envelope. You pop the old chip out and return it to Intel. If they do not receive the old chip within 30 days they will charge the credit card number.
   I had my replacement in under a week of my call...

Pentium Processor Replacement (FDIV) Information

Diagnostic LEDs

   I've looked into what these LEDs actually mean and how they behave. Read on if you want to know more...

The Type 4 processor boards have two diagnostic SMD LEDs - one in position CR1, and one in CR2. Unfortunately IBM swapped the designators for the Pentium-based boards when compared to the 486-based "N" complex, which makes things a bit confusing.

POST Diagnostic LED (CR2 on "N"; CR1 on "P", "Q", & "Y")

This LED is lit only during the very early portion of the POST process. The LED should come up almost immediately after applying power - together with the Power Good LED. It goes off some 1.5 seconds* later, shortly before the first 2-digit checkpoint code appears on the Op Panel. From that point on the LED should stay off until the system is rebooted. The LED flashes very briefly (~0.1 s*) during a "warm" reboot, prior to the first 2-digit CP code being displayed on the Op Panel.

The LED is controlled by bit 3 of port E6h. I can't confirm whether this bit controls just the LED, or if it controls some support logic on the processor complex, which in turn drives the LED to indicate its status. Toggling the bit during normal operation will turn the LED on and off. Doing so doesn't seem to have any side-effects - the system doesn't freeze, everything stays operational, there is no measurable performance impact or anything else. So maybe it indeed is just a standalone diagnostic LED...

(* - measurements taken on the "N" complex with stock 486DX2 @ 66 MHz)

Alternate-Bank LED (CR1 on "N"; CR2 on "P", "Q", & "Y")

This LED indicates the current state of the "Alternate-Bank" (ALTBANK) signal. ALTBANK is controlled by software, and it allows the system to switch between the two Flash ROM banks on the fly. The default bank is selected by the JMP5 jumper (BSP signal). Alternate-Bank - the bank which is not initially selected - can be activated on-the-fly by toggling the ALTBANK signal.

As explained HERE, the SurePath POST/BIOS code is spread across both Flash ROM banks. To access code and data that are stored in the Alternate-Bank, the POST code will toggle the ALTBANK line, copy the required block to RAM, and toggle the line again. As a result of this, the LED will briefly change its state every now and then during the POST process.

Initial state of the LED depends on two factors. Current position of the JMP5 jumper, and the layout of the firmware image inside the two flash modules (more info HERE). So depending on these conditions the LED will be either lit most of the time and only go off when the Alternate-Bank is being accessed. Or it will be off initially, and will briefly flash when accessing the Alternate-Bank.

The LED will also change its state couple times (for a prolonged period) during the flash update process. This is because the update routine has to rewrite contents of both Flash ROM banks.

See patent US5878256 for theory of operation and block diagram of the flash ROM subsystem.

Flash ROM Bank (JMP5)

This jumper on the processor complex is used to select which bank of flash memory is accessed as ROM. The ROM subsystem consists of 256 KB of flash memory in two banks of 128 KB. If the jumper is in position 0 when the system is powered on, bank A is mapped to addresses hex 000E0000 to 000FFFFF and hex FFFE0000 to FFFFFFFF. The system is shipped with the jumper in position 0 (bank A selected).

Note: Don't move jumper while system is powered-on; unpredictable operation will occur.

Access to ROM or RAM at address space hex 000E0000 to 000FFFFF is controlled by the bits in the memory controller registers. When ROM is enabled, it is not parity checked. If the jumper is in position 1, bank B is mapped to these addresses.

See patent US5878256 for theory of operation and block diagram of the flash ROM subsystem.

Peter said:
   Originally planned for a sort of "emergency mode". Once you screwed up the flash BIOS you could toggle the bank, insert any working flash update in the FDD A: and restart the machine, which takes the flash-image from the floppy drive and recovers (as it can be done on the 704 in the "BIOS recovery mode"). However, the base boot BIOS lacked the required routines to delete the loused up bank of the flash ROM and as far as I know the loading of an image from floppy does not work. Another useless feature. (Ed. not really, read below)

Tom says:
   The recovery feature described by Peter is actually implemented and fully functional. To understand how exactly all this works we have to first know what information is stored in the flash memory, and how is it laid out. The flash subsystem on the complex consists of two 128 KB modules that contain the system firmware. The firmware itself is then divided into 4 blocks (segments) - each 64 KB in size. So we get the following arrangement:

  • Bank A (one flash module):
    • Seg. 1: POST Stage 1, splash-screen (mapped to 0xE0000 during Stage 1)
    • Seg. 2: POST Entry, (C)BIOS (mapped to 0xF0000)
  • Bank B (the other flash module):
    • Seg. 3: POST Stage 2, additional fonts (mapped to 0xE0000 during Stage 2)
    • Seg. 4: Dummy POST Entry, ABIOS, error strings (copied to RAM on demand)

When the computer is powered on, the CPU starts executing code at address FFFF0h. This location should contain a jump instruction that points to the beginning of the POST code. The logic on the processor complex makes sure that flash memory with the system firmware is accessed by default when the E0000 - FFFFFh address range is requested (including the FFFF0h reset vector). Which of the two individual flash modules (banks) gets accessed depends on multiple factors. For now, let's just assume that flash Bank A gets accessed first. This bank contains the POST entry point (in seg. 2) and also the first half of the POST code itself - POST Stage 1 (in seg. 1). At the very end of Stage 1, there's a piece of code that switches the active flash bank to Bank B by toggling the Alternate-Bank (ALTBANK) line. The entire POST Stage 2 (seg. 3) is copied to RAM and then executed from there. If no critical errors occur the POST ends by invoking the bootloader code from the first boot device.

We now understand how the system operates under the ideal circumstances and how it switches from Bank A to Bank B during the POST process.

Now let's talk about the JMP5 jumper and its effects on the flash subsystem. The jumper determines which of the two flash modules will be active when the power is applied. The example above assumed that the first module is active on power-on - the one that in our cause contains Bank A with the POST Stage 1 code. What happens if JMP5 is set to the other position where the other module containing Bank B is active by default? From the user's perspective, everything seems to be the same - the computer POSTs as it normally would. However, under the hood, the process slightly differs. Bank B is now the default bank, and it contains (among other things) the second POST stage (instead of Stage 1 which must be executed first). To ensure that the system can recover from this scenario Bank B is equipped with its own "dummy" POST entry point. Address FFFF0h contains a jump but this time not to the start of the POST, but instead, it points to a short routine that simply toggles the ALTBANK line, which makes Bank A active, and then the routine jumps back to address FFFF0h. After these corrective measures, the address now contains a jump to the beginning of the actual POST code. From this point on, the execution continues normally, as we have discussed earlier.

We know how the jumper works and how it affects the POST process - not much. In fact, the JMP5 jumper may seem rather useless, but that's not quite the case. We have to look at how the flash update process works to understand why the jumper actually exists.

To update the system firmware the system must be booted from a special flash update diskette (write access to the flash memory is locked out otherwise). Once the flash update program is loaded it will check whether any of the supplied images are compatible with the given system, and after confirmation from the user, it writes the new image to the flash memory. However, the update process is not as straightforward as one may expect. It first checks the flash memory to see the layout of the existing image.

If it detects Bank A in the first module, it will erase the other (second) module first and write the updated Bank A to it instead. So at this point, the flash memory contains two copies of Bank A at the same time - the original one, and the new one - one in each of the two banks. This is intentional - should the flash update process fail or get interrupted (power loss, HW problem...), the system will still have at least one copy of Bank A with Stage 1 POST code and (C)BIOS available to it. Bank A is all that's necessary for the system to boot from the flash update diskette and retry the process... (the system only attempts this early flash update boot if it detects that the second bank is corrupted - indicated by error 0129 4042). This is quite similar to the Stage 1 "mini-POST" process on the earlier IML systems.

If the first bank was successfully erased and updated, the system continues by verifying its contents against the source image. Only then it toggles the ALTBANK line, erases the old Bank A (Stage 1 and BIOS) contents, and attempts to write the new Bank B with Stage 2 POST and ABIOS. If this part of the process fails, the system can POST from the updated Bank A, boot from the update floppy, and try again...

If both banks were successfully updated the system now has the entire updated firmware available to it. With one additional difference - the contents of the two flash modules have been swapped. The first module contains Bank B (Stage 2), and the second one contains Bank A (Stage 1) - and this is the main reason why the "dummy" POST entry point exists in Bank B - so the user doesn't have to move the JMP5 jumper after each flash update. It's only necessary to move the jumper if the update process fails, and the first flash chip doesn't contain a valid Bank A or Bank B image and thus can't reach the Stage 1 code in any way. By moving the jumper to the other position, the module that contains functional Bank A (Stage 1) becomes active on power-on, and the system can attempt flash recovery.

This mechanism makes the flash update procedure significantly safer as it's almost impossible to "brick" the complex if the flash update gets interrupted. However, if the contents of the Bank A module get corrupted by some other means (failing flash memory) the complex won't POST at all. An external programmer must be used to write a valid image to the corrupted module to recover the complex. From this point of view, the feature isn't as reliable as the so-called "Dual BIOS" approach where the flash memory contains two complete copies of the system firmware.

The information provided here is based on the analysis of the T4 firmware and on an actual testing (yes, it was physically painful for me to power the system down in the middle of the flash update procedure... wegh).

Debug Port (card edge; J4 on "N"; J5 on "P", "Q" & "Y")

The Debug Port allows a debugger (external hardware and software) to interface to the processor's debug hooks. It provides access to the probe mode interface and a few other signals without affecting any high speed CPU signals. This will ensure that the system can operate at full speed with the debugger attached.

It would have been used during the prototyping stage to debug the Type 4 platform, and perhaps to test the boards during manufacturing.

IBM didn't quite follow the sample implementation described in the Developer's Manual (see pages 314 and 570), if this documentation even was available when the Type 4 platform was designed. IBM's debug port uses a completely different connector, different pinout, and the wiring itself is somewhat simplified. Nonetheless it should be a functional equivalent to the "Minimal Debug Port Implementation" described in the documentation (perhaps aside from the DBRESET signal).

The debug port consists of a JTAG interface - signals TDI, TDO, TCK, TMS and -TRST, and some additional lines. Multiple ground connections are provided to allow for proper grounding and shielding. On the debug port cable every other wire would be ground, or the signal lines would be individually shielded.

The port is based on the standard JTAG/IEEE 1149 interface, however without the special JTAG adapter and matching software its use will be probably very limited. However it could still prove useful when reviving dead T4 boards in the future...

Note: Not all debug signals and features are available on the 486DX2-based Type 4 "N" platform (see notes bellow).

The connector used is a 2 x 13 pin card edge connector. 1.27 mm contact pitch. For the table bellow we assume that Pin 1 is located closer to the cache SRAM chips (the end with a slightly cut corner).

Side B (solder)Pin #Side A (component)
INIT 102Ground
Unknown 504Ground
TMS (cache) 206Ground
-TRST 207Ground
TMS (CPU) 309Ground
-R/S 110Ground
+5 V (sense) 411Ground
PRDY 113Ground


  1. The "N" complex has a provision for this signal, but it's not usable. This is because the signal is wired to the outer pin row of the Socket 3, and the production boards come equipped with socket that lacks the outer row - Socket 1. Further, the R/S# and PRDY signals are not documented in the Pentium Overdrive datasheets, and may not be functional at all.
  2. The signal is not available on the "N" complex.
  3. The signal is not wired to the Debug Port on the "N" complex. Instead it's tied to Vcc via a pullup resistor (always high).
  4. The pin is wired to +5 V through a resistor (470 Ω on "N", 100 Ω on "Y"). The debugger would use this signal to sense that the system power is on. Don't use it as a power source.
  5. Unknown purpose. The signal goes to the small 52G9403 PAL (U66 on N, U31 on Y) and the line is equipped with a 4.7 KΩ pullup resistor. When tied low, the system hangs. Doesn't seems to be a system reset input (DBRESET).

Original theory by Peter:
   The "serial link" was (as far as I know) intended for the use with an earlier system management adapter, which didn't made it to the salesroom. The idea was to supply a sort of status link to the processor complex and the SCSI adapter(s) and the (possible) backplanes on the later servers.

Ed. Tom: It's unlikely that any system management adapter would use this low-level debug interface for anything...

Serial Diagnostic Link for PS/2 Model 95 Processor Cards (6-pin header)

From IBM Technical Disclosure Bulletin (Nov. 1994) (delphion.com, priorart.ip.com)

This document contains drawings, formulas, and/or symbols that will not appear on line. Request hardcopy from ITIRC for complete article.
   Disclosed is a Serial Diagnostic Link (SDL) for the PS/2 Model 90 and 95 information panel, allowing the main system processor direct access to the alphanumeric display. This display is used during Power-On Self-Test and during error conditions, as information regarding the execution of the processor is reported to the user. With the SDL, the main processor does not have to rely on the operational condition of any other system function to display information on the alphanumeric display. Without the SDL, the Model 95 information panel interface can be used by the main processor only when the Micro Channel, the planar board VLSI, and the processor complex card interface are the functional.
   The SDL is a three-signal interface. Output signals from the processor card, which are input signals to the information panel used to program the alphanumeric display, are DISPLAY_STROBE, and DISPLAY_RESET. The DISPLAY_SENSE signal is an input to the processor card from the information panel, which is the logical NOT of the DISPLAY_STROBE. The DISPLAY_SENSE signal is used by the processor to determine the presence of the SDL and to provide a real-time mechanism for monitoring the SDL itself. The interface is operated in a uni-directional mode, with all information emanating from the processor card.

Fig. 1 is a schematic diagram showing the address/write control logic and the read back latch used to provide this function.

Fig. 2 is a schematic diagram showing the data deserializer used to provide this function.
(Ed. reverse-engineered schematic here)

The support hardware on the processor card and on the information panel for this function is minimal. On the processor card, this logic provides two bits in an I/O WRITE port, corresponding to the DISPLAY_STROBE and DISPLAY_RESET signals, and one bit in an I/O READ port, corresponding to the DISPLAY_SENSE signal. The operation of these signals by the processor is done entirely with software. On the display panel, logic transforms the incoming SDL bit stream into the existing parallel interface to remain compatible with the alphanumeric display.
   Fig. 3 is a timing chart showing the timing of each signal to display a character on the alphanumeric display. The duration of signal levels for this interface are defined only by minimums. Since these minimums are less than the times available in processor card bus cycles, in effect these signals are timing-independent. No clocking mechanisms are required for this interface.
   While the timing of the signals is thus independent, the sequence of their operation is not. As shown in Fig. 2, five stages must be performed in the following order - initial, count/latch, validate/reset, write character, and validate/hold. The initial stage is entered on a high-to-low transition of the DISPLAY_RESET signal. The state of DISPLAY_STROBE is a "don't care" condition when entering this stage. Upon entering this stage, all logic on the information panel and processor card is reset, awaiting the transmission of the output character information. The count/latch stage is entered when the processor produces a high-to-low transition of the DISPLAY_STROBE signal. In this stage, every high-to-low transition is considered a "count," and every low-to-high transition is considered a "latch." The logic on the information panel sequences the "counts" through a 74F393 ripple counter, the outputs of which are defined as the parallel interface signals necessary to operate the alphanumeric display. In this way, a simple serial to parallel interface conversion is performed by the ripple counter. The "latch" is used to latch the previous parallel output of the ripple counter into a 74F373 register, so that the ripple counter may be reset in the next stage without destroying the "count" data.
   The write character stage is entered on a high-to-low transition of DISPLAY_STROBE while DISPLAY_RESET is high. Upon entering this stage, the data is written to the display, and a character appears at the correct address location. The validate/hold stage is entered on the low-to-high transition of the DISPLAY_STROBE signal while DISPLAY_RESET is high. Upon entering this stage, the data is written to the display, and a character appears at the correct address location. The initial stage is re-entered from the validate/hold stage by the high-to-low transition of the DISPLAY_RESET signal. At this point, the SDL and information panel are ready for the next output character.
   Programming, by the system code, for the stages described above is straightforward. The following pseudo code shows the general flow of the stages, with character data values necessary to display ASCII characters at each address location of the alphanumeric display:

OUT DISPLAY_STROBE,1     ; Power on reset
OUT DISPLAY_RESET,1      ; These three statements are done at first
OUT DISPLAY_RESET,0      ; power on to get into the initial stage
Move CX, Character       ; place the data to be displayed in a
Begin:                   ; decrement register.  Enter Count/Latch
                         ; stage first time thru loop.
OUT DISPLAY_STROBE,0     ; Provide a "count"
OUT DISPLAY_STROBE,1     ; Provide a "latch"
LOOP Begin               ; Decrement the data, loop until done.
OUT DISPLAY_RESET,1      ; Enter validate/reset stage
OUT DISPLAY_STROBE,0     ; Enter write character stage
OUT DISPLAY_STROBE,1     ; Enter validate/hold stage
OUT DISPLAY_RESET,0      ; Enter initial stage
; Go to TOP to output the next character.

Ed. Please note that this just a pseudocode and as such it doesn't match the actual implementation. See the link below for a functional code samples.

Tom adds:
   Originally I thought that the SDL link was an alternative path to the Op Panel, that if connected would be used as the preferred, and more reliable channel for ALL communications. This however, is not the case. The SDL link is a completely separate channel, that is ONLY used during the very early steps of the POST process. Later CP codes, error codes, and other status info is not directed to the SDL port, and is sent only over the original planar Op Panel interface. It's however possible to use the SDL link to display custom information if desired.

For an actual code examples see THIS page.
For info about the Op Panel portion of the SDL interface go HERE.

SDL POST Diag Jumper (unmarked on "N", J6 on "Q" & "Y") (by Major Tom)

Another mystery solved! The jumper right next to the SDL pin header activates early POST diagnostic output that is fed to the Op Panel logic through the SDL connection.

To activate this feature put the jumper to position "1" for the "N" complex, and to "0" for the "Q" and "Y" complex (not sure why it's marked the other way around on these boards). The "P" complex doesn't have this jumper (I have no way of checking whether is the diag. output always enabled or not available at all on this board).

For info about the early POST diagnostic output go HERE.
For more info about the SDL interface itself go HERE.

The current state of the jumper can be obtained by testing bit 3 of port E7h. (0: diag. output enabled, 1: disabled)

Note: The jumper only determines whether the POST routine should output the early diagnostic info or not. It doesn't disable/enable the SDL port itself. You can use the line to output custom info to the Op Panel even if the early diag info is disabled. See HERE.

SDL POST Diag Output (by Major Tom)

If you enable the SDL diag output, you will be rewarded with some early checkpoint codes. These early CP codes are easily recognizable, since they are printed as 4-digit numbers. The regular (later) CP codes are 2-digit hex numbers.

List of the individual SDL CP codes:

CP: 0120 - BIOS checksum checks
   Error codes: 01294041
CP: 0130 - Memory controller registers post-reset value check
   Error codes: 01295071
CP: 0131 - Bus interface unit (MCA BIU) registers post-reset value check
   Error codes: 01295061
CP: 0150
CP: 0151 - Verify complex interconnect (2S2P planar only)
CP: 0180 - Memory controller register set tests
   Error codes: 01295070
CP: 0190 - DMA controller tests
   Error codes: 01290050
CP: 0191 - DMA controller tests
   Error codes: 01290051, 01290052
CP: 0192 - DMA controller init
CP: 0210 - Bus interface unit (MCA BIU) register set tests
CP: 0220

The expected checkpoint sequence (cold boot):

CP: 0120 -> 0130 -> 0131 -> 0190 -> 0150 -> 0180 -> 0191 -> 0210 -> 0220 -> 0192 -> 0151

Note: Only CP: 0192 is displayed during a warm boot.

Note: The above sequence is for the "N" complex with BIOS level 10. It should be mostly the same for the other platforms and BIOS revisions.

Once this sequence is finished, the POST routine starts using the planar (parallel) Op Panel interface, and begins the 2-digit CP code sequence.

The POST routine may also use the SDL link to output early error codes. These are always printed, even if the early diag. output is disabled. They use the traditional error code format. List of known error codes can be found HERE.

Method to Extend Personal Computer System Memory

From IBM Technical Disclosure Bulletin (Aug. 1994) (delphion.com, priorart.ip.com)

Described is a hardware implementation to enable Personal Computers (PCs), such as the IBM PS/2 Models 90 and 95, to extend its memory capability from 64 megabyte (MB) to 256 MB of system memory.
   In prior art, PCs, such as the IBM Models 90 and 95, were designed with a common planar board and a separate and upgradable Central Electronics Complex (CEC). The planar board contained the memory socket positions and the CEC contained the memory logic. The common interface between the planar board and the CEC was limited to ten memory address lines for supporting a maximum of 10 x 10 addressing positions. This limited the Dynamic Random Access Memory (DRAM) support to a one and four Mbit technology, which in turn limited system support to 1/2/4 and 8 MB types memory modules.
   With the advent of 16 Mbit DRAMs, 16 and 32 MB memory modules became available to enable the extension of system memory. 16 Mbit DRAMs require either 11x11 or 12x10 addressing, while the common interface supports only 10x10 addressing. This restriction had the effect of limiting PCs, such as the IBM PS/2 Models 90 and 95 systems, to supporting a maximum of 64 MB of planar memory, where each planar supported up to eight memory modules. By supporting 11x11 and 12x10 addressing, PCs, such as the Models 90 and 95, could support up to 256 MB of planar memory.
   The concept described herein is designed to extend the PC system's memory capabilities by including 11x11 and 12x10 addressing. It also includes a method of decoding from the memory controller, multiplexing logic and a non-standard memory module pinout. As a result, the method will support 40 bit Error Checking and Correcting (ECC) or 36 bit parity modules, utilizing 1 Mbit and 4 Mbit technology DRAMs, or 39 bit ECC modules utilizing 16 Mbit technology DRAMs.

(Click on the picture for a hi-res version)

The Figure shows the circuit configuration for the multiplexing logic implementation to attain the memory extension. An added decode output is required from the memory controller unit (not shown) to determine if the current memory request is to a memory module utilizing 16 Mbit technology.
   The decoded output can switch at any time, other than a period before and after RAS going active, so as to be sufficient to guarantee the row address setup and hold operations. This decoded output is referred to as EN_MUX#. The multiplexing logic resides on the CEC card which is an upgradable option to the PC, such as the IBM Model 90/95. The multiplexing logic dynamically multiplexes Memory Address 10 (MA10), used by the 39 bit ECC memory modules, with CASP, used by the 36 bit parity memory modules, on the planar net dedicated to CASP and dynamically multiplexed Memory Address 11 (MA11), used by 39 bit ECC memory modules, with Data Select 3 (DS3) Block Select 3 (BS3), used by 36 bit parity memory modules, or with data bit 39 (DQ39), used by 40 bit ECC memory modules on the planar net dedicated to BS3. The primary chip used in this implementation only requires 39 bits of data in the ECC mode, 32 data bits and 7 check bits. Therefore, the only support required for DQ39 in this implementation is to tri-state the multiplexed logic outputs when a 40 bit ECC memory module is being addressed. This prevents contention at the DRAM's output on DQ39.
   By supporting the dynamic multiplexing of MA10 with CASP and MA11 with DS3 BS3 or DQ39, the system can support a mix of memory utilizing 1, 4, and 16 Mbit DRAMs in 1, 2, 4, 8, 16 and 32 MB ECC modules, while retaining support for 1, 2, 4 and 8 MB parity modules. This allows a user to use pre-existing memory modules when upgrading to a processor CEC which supports 16 Mbit DRAMs. To take advantage of the additional support for 16 Mbit DRAMs, the user must configure the system with ECC memory.

Personal Computer Processor Upgrading

From IBM Technical Disclosure Bulletin (July 1994) (delphion.com, priorart.ip.com)

This document contains drawings, formulas, and/or symbols that will not appear on line. Request hardcopy from ITIRC for complete article.
   Described is a hardware implementation to provide a means of upgrading a Personal Computer (PC) system to attain improved performance by using newer technologies. The implementation involves changing the processor card so as to enable users to upgrade a PC system, such as the IBM Model 90 and 95, to attain the improved performance.
   The upgrading involves the revision of the processor card so that the card will contain a 486DX microprocessor operating at an internal frequency of 66 MHz with an external bus frequency of 33 MHz. In addition, a second element includes a store-in cache utilizing the Intel C5/C8 chipset which operates in a serial path between the microprocessor and the remaining elements of the processor card. A third element, the BIU logic, is incorporated to interface with the Intel store-in cache to a Very Large Semiconductor Integrated (VLSI) component containing a common interface that is used to support the SIMM memory interface and the Micro Channel (MC) interface. The Figure shows a block diagram of the key elements contained in the processor card upgrading for the IBM Mod 90 and 95.

"Bad" Memory Reported in Same Slots

David Dietz said:
   Recently put a T4 P66 complex in my previously functional 8595. Used to have 64M of RAM using 8 8M 70ns parity SIMMs.
   After using the T4 refdisk to get it to recognize the new complex it said there was a memory error. Ran the long test and it said I had bad memory in B3 and B4. Swapped new memory into B3-B4, Ended up with another memory error and tested again. Said I had bad memory in B3 again. Took out A3 and B3 (didn't have any more to put in). Everything started working again. put 2 4M SIMMs in A3 and B3 and 2M SIMMs in A4 and B4. System came up with 44M.
   Booted fine a couple times and then came up with a memory error again. Ran long test and came up with bad memory in B3 and B4 again. I'm beginning to wonder if my new complex is burning out memory in B3 and B4.
   Any clues as to what is happening and what I should do to fix it?

Peter has a flashback and says:
   Sounds odd, but... replace the CMOS buffer battery. And toggle the "Clear Power On Password" Jumper once when you do that. Pull out the battery, wait at least 20 minutes, toggle the jumper, install the new battery and fire the thing up - reconfigure... and... ?
   I had exactly the same problem back in the mid-90s when I upgraded an 8595-AKD with a T4 P60 platform. Occasional memory errors always on the same memory connectors. We'd sprayed them - we swapped and replaced memory modules (which ran fine in e.g. a 9577 afterwards) - we did everything you could think of.
   Then we replaced the CMOS battery (that CR-2032 3 V lithium cell) ... and the error disappeared. Unexplainable otherwise and not logical.

Support for Convenience Partition on >3.94 GB Drives

I have personally installed a convenience partition on a 4.5GB drive and then ran system programs from it. This applies to all Type 4 complexes, from the 486DX2-66 "N" all the way up to the P90 "Y" complex.

Content created and/or collected by:
Louis Ohland, Peter Wendt, William Walsh, Kevin Bowling, Jim Shorney, Tim Clarke, David Beem, Tatsuo Sunagawa, Tomáš Slavotínek, and many others.

Ardent Tool of Capitalism - MAD Edition! is maintained by Tomáš Slavotínek.
Last update: 12 Jun 2021 - Changes & Credits | Legal Info & Contact