Ardent Tool of Capitalism

Type 4 Processor 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)

SynchroStream Controller

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

Specifications
   Memory
   Features
System Firmware
   BIOS Updates
   BIOS Changes
   Flashing to BIOS 05 and up from 03 or Lower
   BIOS 09 Trivia
C5/C8 Cache Chipset
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

Memory

RAM

• 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

Cache

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

Features

• SynchroStream Controller
• 40 MB/s streaming data transfer
• Error Checking and Correcting (ECC) memory controller
• 20 MHz 32-bit DMA (can address all memory directly), SCB support
• Faster bus arbitration (than Type 1) for busmaster performance
• Enhanced Dual Path Memory
• Subsystem Control Block (SCB) enabled
• Vital Product Data (VPD) support
• Synchronous Channel Check support
• Data bus parity support
• Logging facility (for ECC or system errors)

System Firmware (POST & BIOS)

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

BIOS Updates

Flash BIOS Update Disks:

Level 10 (ver. 1.28) Self-extracting executable, latest (IMA) (readme)
Level 09 (ver. 1.26) Self-extracting executable (IMA) (readme)
Level 08 (ver. 1.26) Self-extracting executable (alt EXE) (IMA)
Level 05 (ver. 1.24) Self-extracting executable (IMA)
Level 03 (ver. 1.21) EMT format, image utility needed (IMA)
Level 02 (ver. 1.10) Self-extracting executable (DSK) (IMA)

BIOS Changes (sources: H126229, Level 09 readme, Level 10 readme, flash images)

Level 01

Initially shipped with the 9595 models xNx, xPx and xQx.
Supports 16 MB (ECC) memory SIMMs.

Level 02 (23 Feb 1994)

Identical to version 1.00, except support for 32 MB (ECC) memory SIMMs was added.

Level 03 (15 Sep 1994)

Note: Version 3.00 BIOS requires the Reference Diskette to be at version 1.31 and the Diagnostic Diskette to be at version 2.31 or higher.

OS/2 2.0X requires a new SCSI Device Driver (IBM2SCSI.ADD) with version 3.00 flash BIOS.

Support was added for the following enhancements:

1. 90 MHz processor card, FRU P/N 06H3739, for 9595 & 8641.
2. CD-ROM as a bootable device.

Level 04

This version was released, but immediately superseded by version 5.00, which is the preferred replacement.

Level 05 (22 Mar 1995)

Note: Version 5.00 BIOS requires the Reference Diskette to be at version 1.33 and the Diagnostic Diskette to be at version 2.32 or higher.

Support was added for the following enhancements:

1. Provides support for the 4 GB (gigabyte) hardfile.
2. Enables the VPD (Vital Product Data) to display the processor ID and Step level, thereby enabling a clear determination of whether a Pentium processor with the floating point divide (FDIV) fix is installed.
3. Allows disabling of the error reporting log POST error, which is useful during RIPL under some conditions.

Resolves the following problems:

1. Corrects problems encountered with the bootable CD-ROM attached to the RAID controller, when an additional non-RAID SCSI adapter is installed.
2. Fixes diagnostic problems related to the CD-ROM being attached to the RAID controller.
3. Fixes problems encountered while running SCSI fixed disk diagnostics with the "read verify" option selected.

Level 07 (27 Oct 1995 or 28 Nov 1995?)

Support was added for the following enhancement:

1. BIOS code was added to support switching a single keyboard and monitor between multiple systems.

Level 08 (16 Jan 1996)

Resolves the following problems:

1. Corrects Date and Time not set problem that only occurs when running OS/2.

Level 09 (26 Mar 1998)

This version of the POST/BIOS includes all previous fixes and enhancements as well as BIOS support for Year 2000 rollover. Support has been added to the BIOS Int 1Ah functions to correctly handle the transition into the next century.

Level 10 (30 Apr 1999)

BIOS level 10 resolves an ABIOS time/date defect for OS/2 users ONLY. The problem will only be seen on systems that have been upgraded from a Type 1, 2 or Type 3 processor card to a Type 4 processor card. (Ed. Systems with the older 1S1P planar and the Type 4 processor complex installed.)

Note: This version of BIOS should be used with Reference Diskette version 1.34 and Diagnostic Diskette version 2.33.

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.

Y2K Issues

Got a 8595-0KD 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 OS/2 when upgrading a 8595 Type 1 or 2 complex to a Type 4.

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

C5/C8 Cache Chipset

All Type 4 complexes use a variant of the Intel C5/C8 cache chipset. The P5/P54 microprocessor, C5 cache controller, and the C8 cache memory (SRAM) can be combined to form a chip set or enhanced design. The two cache devices connect to the system bus and a memory bus controller interfaces to the microprocessor and cache devices. The individual C8 chips contain the SRAM, as well as data buffers and some additional logic.

The table below lists the different C5/C8 variants.

Because the Type 4 processor complex does not use standalone SRAMs you cannot quote a typical RAM speed (such as the PC Server 300 which uses 15 ns SRAMs). You should quote a cache hit speed which is much more representative of the actual performance you get. So, the L2 cache size on a Type 4 complex is 128 KB (486) or 256 KB (Pentium) with write-back policy and 0 - 1 wait state. Cache is matched to processor speed i.e. 60 MHz with the Pentium 90/60, and given a 90% cache hit speed is 33.3 ns and 0 wait state.

If this machine did use standard SRAMs, an access speed of around 10 ns would be required to run in 0 wait states. 25 ns access SRAM is used for machines based upon Intel 486's running at 33 MHz external frequency, such as a 486DX-33 or a 486DX2-66.

Note: The behavior of the P5/P54 microprocessor is affected when operating in Chip Set mode. At least some P55 (MMX) CPUs still have the same capability, but most, if not all, of these chips were not tested for operation in the Chip Set mode - see HERE (search for "No Kit"). Together with the clock input no longer being 5 V-tolerant this may be behind the general instability of these later chips when used with the Type 4 platform.

References:

• Intel 82496/82497/82498 Cache Controller and 82491/82492/82493 Cache SRAM manual
• Intel486 DX CPU Cache Chipset datasheet
• Technical specifications - PC Server 500 (8641 - 0YR)
• IBM TDB - Personal Computer Processor Upgrading
• Tektronix TMS 109 - P54 & P55 Microprocessor Support
• Tektronix TMS 109A - Socket 7 Microprocessor Support

Diagnostic LEDs (by Major Tom)

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 (JTAG) (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 below).

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

Notes:

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

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
TOP:
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.

Actual code examples can be found HERE.
For info about the Op Panel side 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 decimal numbers. The regular (later) CP codes are 2-digit hex numbers.

A list of the individual SDL CP codes and the expected code sequence can be found HERE.

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 eight 8 MB 70 ns 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 (edited):
   This may sound odd, but... replace the CMOS backup battery and toggle the "Clear Power On Password" jumper once you do that. Pull out the battery, wait at least 20 minutes, toggle the jumper, and install the new battery. Fire the thing up, reconfigure, etc.

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.