Type 4 Complex

Rf90954a.exe Reference disk for Type 4 Complexes
Rd9095a.exe Common Diagnostics for all 859x / 959x Systems

"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
Complex BIOS
   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
"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 (Ed. Ceramic Column Grid Array - CCGA) 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 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.

Complex BIOS

BIOS stored in Flash memory.
Flash ROM updates available down below.

BIOS Updates

   BIOS revision 10 is for systems with the single serial / single parallel port planars and all Model 90s that have been upgraded to a Type 4 complex (486DX2-66, P60, P66, or P90). Servers with the dual serial / dual parallel port planars (e.g. 9595A and PC Server 500) with a Type 4 processor should continue to use BIOS revision 8; BIOS revision 9 will provide NO enhancements for these systems.

Flash BIOS Update Revisions:

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. 02-23-94)
   This was a first "quick & dirty" attempt to fix it - which was not that successful.
   Added support for 32MB ECC SIMMs.

Level 03 (rel. 09-15-94)
   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. 02-28-95)
   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. 03-22-95) (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. 10-27-95)
   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. 01-16-96)
   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. -funny- 01-16-96 still)
   Now, as it seems, this is the last rev. (Level 08) with integrated Y2K rollover fix.

Level 10 (rel. 04-30-99)
   Resolves an ABIOS time/date defect for OS/2 ONLY. But-. 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).

   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 -xPx), 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. Default bank is selected by JMP5 (BSP signal), Alternate-Bank - the bank which is not initially selected - is activated 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 position of JMP5 during the last Flash ROM update (it affects layout of the POST/BIOS image across the two banks). 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.

Tom adds:
   As Peter mentioned IBM originally wanted to implement what we know as "Dual BIOS" on modern motherboards - two flash ROM banks, and two independent BIOS images. Should something happen to one image (flash procedure failure, data rot...), the user would be able to switch to the other bank (using the JMP5 jumper), boot to the flash update utility, and try reflashing contents of the other (corrupted) bank. System like this improves reliability of the system, and makes the flash process less risky.

The bank switching system is present on all T4 complexes and is fully functional, yet IBM decided to abandon the feature... why? Well, there is one very obvious reason - size of the POST/BIOS image. The SurePath firmware consists of 4 blocks/segments, each 64 KB in size:

  • Seg. 1: POST Stage 1, splash-screen (mapped to 0xE0000 during Stage 1)
  • Seg. 2: Compatible BIOS (normally mapped to 0xF0000)
  • Seg. 3: POST Stage 2, additional fonts (mapped to 0xE0000 during Stage 2 & boot)
  • Seg. 4: Advanced BIOS, localization strings

All 4 segments together weight 256 KB, and while there is some unused space in most segments, and some size optimizations could certainly be made, the firmware would still be too large to fit into a single 128 KB bank. And well, that's pretty much it, our beloved SurePath BIOS is simply too fat to fit into just one bank. *Ba dun tss*

The first two segments are normally mapped to Bank A, and the other two to Bank B. However this may not always be the case. The actual layout will be affected by position of JMP5 during the flash update process. So the contents of Bank A and B may be swapped.

As mentioned before the bank switching is still operational. But since the Dual BIOS feature was dropped, and a single BIOS image now takes both banks, IBM effectively overrides the JMP5 setting from the SW side. For the system to POST we need Seg. 1 and 2 (Bank A) to be active after power on (no matter what the position of JMP5 is), as it contains the first stage of the POST code. Seg. 2 (Bank A) and Seg. 4 (Bank B) each has an unique "bank signature" word, which is used by the initial POST routine (present in both banks) to detect which bank is currently active. If it's not Bank A (containing POST Stage 1), the Alternate-Bank (ALTBANK) line is toggled from SW, and the system is restarted. The "bank signature" word is checked again, and now we expect to see signature of Bank A. If that's the case, the actual Stage 1 POST code is executed next. Once the first POST stage is finished, the system toggles the ALTBANK signal, copies Stage 2 from Bank B to RAM, toggles the line back again, and starts executing the second POST stage (from RAM).

Please note that I've simplified things a bit in the paragraph above to make it easier to understand. In reality the POST process has multiple sub-stages,and the system is restarted more than once. The POST code also does some additional bank switching during the POST process, namely to load the localization strings from Seg. 4, to load alternative fonts from Seg. 3 (if necessary), and more.

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.
(Ed.: low-res version here)

   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.

* Trademark of IBM Corp.

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")

   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.

SDL POST Diag Output

   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 - Device at I/O addr. 54h, 55h (memory ctrl.?) registers post-reset value check
   Error codes: 01295061
CP: 0150
CP: 0151
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 - Device at I/O addr. 54h, 55h (memory ctrl.?) register set tests
CP: 0220

The expected checkpoint sequence (cold boot):

CP: 0120 -> 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)

(Ed.: low-res version here)

   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 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 M bit technology DRAMs.
   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), 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 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.

* Trademark of IBM Corp.

Personal Computer Processor Upgrading

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

(Ed.: low-res version here)

   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.

* Trademark of IBM Corp.
** Trademark of Intel Corporation.

"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.

9595 Main Page