Under The Cover

The new IBM Micro Channel as seen from inside the PS/2 Model 50

Author: Steve Ciarcia
Source: BYTE Magazine, Aug 1987 page 101+

What would you say if someone asked you to pull the covers off a new IBM Personal System/2 Model 50, crawl around inside, and report on what it's like in there? Even I couldn't resist, though I've been known to berate IBM for a thing or two. I succumbed to curiosity and agreed when BYTE asked me to look at the PS/2's Micro Channel from the view of an engineer, one who needs to know more than what's given in the typical glossy descriptions on the new box. I didn't want a single opinion to dominate the conclusions, so I formed a team that included members of the Circuit Cellar research staff. Together we designed our tests, performed them, and came to our conclusions. Our approach differed from that of usual reviewers; ours was an engineering perspective. We were more interested in whether the Micro Channel would be useful for intelligent I/O devices and data acquisition than whether and how fast Lotus 1-2-3 would run.

We evaluated a Model 50 with an 8513 color display using the PS/2 Hardware Technical Reference Manual to find some of the information and an oscilloscope to dig out the rest. Unfortunately, the machine we received had no expansion boards other than the hard disk controller, so we couldn't test some of its more involved features.

We wrote some assembler routines to check out interrupt-response times and direct memory address (DMA) loading and compared the 10-MHz Model 50's results with those of an 8-MHz PC AT. Please accept this for what it is: our first look at a new machine.

Untouched by Human Hands

Photo 1. Overall view of the interior of the Model 50 with its outer case off

The first impression you get when you pull the cover off the Model 50 is that the insides have been untouched by human hands (see Photo 1). Everything slides into place, snap-locks without screws, and connects without wires. (More details of disassembly are covered in "The IBM PS/2 Model 50" in the July BYTE.)

Photo 2. A disassembled view of the Model 50 with its parts spread out.

In the disassembled system unit (see Photo 2), the motherboard uses surface mount ICs for everything except the EPROMs, keyboard controller, VLSI processors, and several gate arrays. You won't be able to fix this one with standard TTL parts; they just won't fit. Notice the shiny aluminum component packages produced by IBM. Cloners take note: These won't be easy to crack.

There were a few engineering-change wires on the top of the motherboard. Given its complexity and the fact that it's at the 01 revision level, that's not bad at all. It always takes a few passes to get it right.

Distribution of Power

The motherboard has internal power and ground planes to carry the power-supply voltages. The power connector on the edge of the board devotes 24 of its 50 pins to ground and 17 more to +5 volts. The sticker on the power supply states that the current is limited to 760 milliamperes per pin for +5 volts, which works out to about 13 amps total.

The PS/2 power supply will work with no load although the regulation is poor, and, not surprisingly, the "power good" signal might indicate that the power isn't alright. This is a pleasant change from the original IBM PC power supply, which could be ruined if it was operated below a minimum load, and an improvement over the PC AT's power supply, which requires a dummy load on the unused hard disk power connector.

Each card connector can draw a maximum of 1.6 amps from the +5-volt power supply. The typical current is limited to 1.4 amps, and a set of formulas in the technical reference manual describes precisely how to calculate these values. The logic power supply is regulated to 5 volts, +5 or -4.5 percent, at the connector, just before the actual pins to the card. You can calculate the actual voltage on your card based on the connector-pin resistance and the current through each power pin.

About 25 percent of the card-connector pins are dedicated to power and ground supplies. No signal is more than 0.1 inch from a ground point (either a digital ground or a power supply that's bypassed to ground). The card-design guidelines give specific suggestions to reduce electromagnetic interference (EMI) from high-speed clock and handshaking signals on each card.

EMI Attack

IBM has given a great deal of attention to reducing EMI in the Model 50. (EMI is caused by radio-frequency radiation from electrical equipment. The FCC sets strict standards to limit the intensity of that radiation from computers.) While its case and internal subchassis are both molded plastic, they're sprayed with conductive metal to form a continuous EMI shield. The top cover is metal and has EMI gaskets mating with the case along critical sections. The seal is so good that only two thumbscrews are needed to hold the two tightly together.

There is a lock on the case to secure the top cover. Given that the case is plastic, I'm not convinced that this is particularly secure, but it augments the thumbscrews. Unlike the PC AT, the Model 50 has no electrical connection to the lock. It has a keyboard password program, but it's easy enough to defeat: Just remove the battery and let the CMOS RAM forget.

Photo 3. The bottom of the motherboard. The square metallic grids match up with support posts on the outer case.

Square metallic grids on the bottom of the motherboard (see Photo 3) match up with support posts molded into the bottom of the case. Embedded in each post is a small patch of conductive "fuzz" to ensure a solid electrical connection between the board's ground plane and the case's metallic interior. In addition, the board's ground plane is segmented to isolate the high-speed video and high-current I/O devices from the rest of the logic. The I/O connectors on the back panel are electrically attached to a metal sheet that makes solid contact with the metallic-coated case. The spring fingers ensure contact at many points, regardless of manufacturing tolerances.

A side benefit of EMI control is that it will make it easier to ensure that cards work correctly. A clean power supply, solid signals, and quiet ground connections go a long way toward eliminating those glitches that occur often enough to make you tear your hair out, but not often enough to be tracked down and solved.

The Micro Channel

IBM has ended its practice of supplying schematics of the system hardware, but it is now giving a much more detailed description of the interface between the cards and the system. Although this will make it tough for cloners to duplicate the system, it's a boon for those of us attempting to build cards that actually work.

Figure 1: The pin-outs for the various sections of the Micro Channel.

The Micro Channel isn't compatible with either the PC's or the PC AT's bus, so none of your old boards will fit the new 68-pin connectors. The connectors have pins on 50-mil (0.05-inch) centers and are divided into three parts: an 8-bit section that has 24 address lines, 8 data lines, and most of the controls; a 16-bit extension with 8 more data lines and some additional interrupts; and a video extension that gives access to the onboard video hardware. Only one connector has the video extension. Figure 1 shows the pin-outs for the various sections and gives an idea of the scale involved.

You could omit the 16-bit part of the connector to get an 8-bit version of the Micro Channel. Perhaps this means that IBM will introduce a low-cost PS/2 system. More likely, however, it's simply a holdover from an original design based on the 8088 motherboard. The dimension drawings show that even 8-bit cards need a tab to fit into the 16-bit extension socket; the implication is that IBM will provide no 8-bit sockets in the PS/2 line.

The Micro Channel has a 32-bit bus extension to accommodate the 80386 processor in the PS/2 Model 80. I couldn't get any information on this, but it seems a reasonable way to get a wider data path. The 16-bit (and, presumably, 8-bit) cards should work fine in the wider bus.

The video-extension connector allows one card to take over the motherboard's video circuitry and provide enhanced video output. Those of you who still aren't satisfied with the new standard 640- by 480-pixel by 16-color output should take a look at the new IBM 8514/A: its resolution is 1024 by 768 pixels with 256 colors.

I/O devices now have a full 16-bit address instead of the 10-bit address used in the PC and PC AT. Each card must decode the full address; partial decoding that ignores some high-order bits is not allowed. Those 1,024 addresses in the PC and PC AT were pretty much filled up, so having 65,536 addresses to play with in the PS/2 is a definite improvement. Of course, they will fill up soon enough.

Photo 4. The PC AT's hard and floppy disk controller (top) versus the Model 50's hard disk controller (bottom).

In addition to the normal digital wiring, the Micro Channel includes an audio line to a linear power amplifier driving the speaker. This allows any card to generate an analog sound and add it to whatever's already on that line. For example, a modem card can now pipe the phoneline audio to the speaker without suppressing the normal audio beeps and boops from the programs. The quality is low-fidelity, but entirely adequate. Photo 4 shows the PC AT's combined hard and floppy disk controller above the new Model 50's hard disk controller.

If I May Interrupt...

A continuing nuisance in the PC and PC AT buses is the fact that two or more cards can't share interrupt lines. The lines are active high, and the cards pull them up with an active driver. If two cards are trying to pull the same interrupt line in different directions, at least one will lose. This is, in fact, a good way to burn out a bus driver or two: Short them between the power supply and the ground.

The PC and PC AT interrupt lines are also edge-triggered, so you get an interrupt when the line goes from low to high. Unfortunately, it's easy to miss an interrupt if you have interrupts masked off and you reset the interrupt controller at the wrong time.

The PS/2 Micro Channel defines the interrupt lines as level-sensitive and active in the low state. The motherboard includes pull-up resistors for each of the interrupt lines, so a line that's not connected to anything is in an inactive state. Several cards can request an interrupt on any line by pulling it low with an open connector driver (existing cards don't fit in the connectors, so there's no conflict between old and new cards).

Existing PC AT software might try to reprogram the interrupt-controller ICs to the rising edge-triggered mode, so external hardware on the motherboard suppresses those commands. The PS/2 uses the same Intel 8259 Programmable Interrupt Controller as the PC AT, albeit in a new surface-mount package.

Because the PC AT hardware prevents interrupt sharing, hardware interrupt handler routines don't have to worry about anyone else using their interrupt. The PS/2 technical reference manual states that all interrupt handlers for both hardware and software interrupts on the Model 50 must daisy-chain control along to the next handler in sequence. Only if the handler has processed the interrupt can it break the chain.

Each interrupt vector starts out initialized to 0000:0000 hexadecimal, so the chain of interrupt handlers stops when the last one detects that it's about to pass control to 0000:0000 (not a valid address for an interrupt handler). Software interrupt handlers should indicate the error by returning with the carry-flag set. Hardware interrupt handlers should include a routine that handles stray interrupts.

For example, suppose we set up several serial cards to share interrupt line -IRQ4. When one of them receives a character, it pulls -IRQ4 low and activates the interrupt handler. The handler must check each of the cards to see which one has the character, process the character, reset the interrupt latch on the card, and exit. If another card receives a character, it also pulls -IRQ4 low to indicate that it needs service. Suppose the second card receives the character after the interrupt handler has checked it. When the handler is done, it performs a normal end-of-interrupt but is then restarted because the -IRQ4 line is still active. The handler then checks each card again and extracts the new character from the second card.

But things can get more complicated. Suppose we have a few parallel ports (the PS/2 supports bidirectional parallel ports) connected to some gadgetry, with all the cards sharing -IRQ4 with the serial cards. If the serial interrupt handler finds no serial cards active, it must pass control to the parallel handler. This way, you can daisy-chain many interrupt handlers together, with each one aware only of its own existence and that of the next one in the chain. The same logic applies to software interrupts, which should eliminate a good deal of the confusion caused by software interrupt handlers "swallowing" interrupts and disrupting the chain.

Of course, as more devices share a given interrupt line, it takes more time to figure out which one is presenting the interrupts. For critical applications (are there ever any noncritical applications?), you might want to have only one device on an IRQ line. But now you've got the flexibility to choose how to solve the problem.

Submitting to Arbitration

Although the PC AT bus allows other cards to take control of the bus lines, it isn't easy to have two bus masters sharing control. The Micro Channel includes a set of lines that allows several competing devices to share the address, data, and control lines without conflict. This process is called bus arbitration.

Under normal circumstances, the processor will use the Micro Channel for memory and I/O accesses without worrying about other devices. In this case, the processor supplies the address values and synchronizes the control signals, while the devices responding to that address may either accept or generate the data value. The processor is called the bus master because it supplies the control information. The processor must relinquish control of the bus lines when a DMA transfer occurs. The DMA controller supplies both the address and control lines, manages the data transfer, and returns control to the processor when it's done. During the transfer, the DMA controller is a temporary bus master.

The PS/2 extends this notion by requiring any device that wants to use the Micro Channel to submit to arbitration before taking control. Arbitration starts when any device activates the -Preempt line (see Figure 1) to request control from the active master. The motherboard includes a circuit called the Central Arbitration Control Point (CACP), which handles the Micro Channel's arbitration functions. When -Preempt becomes active, the CACP sets the Arb/-Gnt line to Arb to begin a new arbitration cycle.

Each device that wants control of the Micro Channel puts its 4-bit arbitration level (essentially a priority) onto the ARB0 through ARB3 lines. The details are a little tricky, but basically all the devices drive the lines at once and check for mismatches between their data and the resulting value of the common ARB lines. The winning device continues to drive the lines, while the losing devices disable their drivers. As a result, everyone knows who won immediately. The CACP then drives Arb/-Gnt to -Gnt to allow the winner to take control of the Micro Channel.

Devices that transfer data in bursts, like hard disk drives and so forth, can assert the -Burst line to indicate that they will be using the Micro Channel for awhile. However, -Preempt overrides -Burst, and the CACP will terminate the bursting device by starting a new Arb/-Gnt cycle. If the bursting device doesn't relinquish control within 7.8 microseconds (us) of a -Preempt, the Micro Channel times out and causes an error.

The nonmaskable interrupt (NMI) is assigned an arbitration level higher than any programmable device on the Micro Channel. This ensures that a critical error will be recognized, no matter what else is going on. Unfortunately, RAM -Refresh is still handled on the Micro Channel and is assigned a priority even higher than the NMI. Thus, DMA transfers will "burp" every 15 us or so when -Refresh occurs. The technical reference manual notes that about 7 percent of the Micro Channel's bandwidth is dedicated to -Refresh. I'd be happy to pay more for a RAM controller to get -Refresh off the Micro Channel in exchange for smooth DMA transfers. Maybe next time... in the PS/3.


The PS/2 includes a new feature called Programmable Option Select (POS), which allows you to set up all configuration information with software rather than with DIP switches or jumpers. In fact, the technical reference manual specifically prohibits DIP switches and jumpers on cards. The Power-On Self Test (POST) software initializes the cards when the power is turned on, so you're assured of the right setup every time. You can also display which cards are installed in which connectors, which ports they're configured to use, which interrupts are active, and so forth, right on the screen without removing the machine' s cover. Even better, you can change the configuration from the keyboard without having to figure out which switch is which.

The line called -CD Setup (Card Setup) forces the card to a mode where it responds to I/O operations at addresses 100 to 107 hexadecimal, regardless of its normal addressing. There is a separate -CD Setup line for each Micro Channel connector, another for the video hardware, and another for the rest of the motherboard hardware. As you might expect, only one of the -CD Setup lines can be active at a time, because all the hardware responds to I/O at the same addresses during setup.

The POST code first determines what hardware is installed and then verifies that it matches the configuration information stored in CMOS RAM. If everything matches, the cards are initialized by writing configuration data into their registers. If you decide to change the cards, the POST code tells you to run the System Configuration program to create a new configuration file. You can't use the PS/2 until all the hardware is correctly initialized.

Listing 1.: A sample Adapter Definition File (ADF).

Both the POST code and the System Configuration program read a pair of identification (ID) bytes from each card. The hexadecimal representation of these bytes specifies an Adapter Definition File (ADF) on disk that defines all the possible setup variations for that card. For example, the ID bytes for the IBM Dual Async Adapter card are EE and FF hexadecimal, so the ADF filename is @EEFF.ADF. Listing 1 shows the contents of that file. Note that serial ports 2 through 8 share -IRQ3.

Because the system we received didn't have any additional cards installed, we couldn't fiddle around with the System Configuration program as much as I wanted to, but the principle is excellent. For the first time, it's possible to give online help to a user trying to resolve conflicts between various cards in the system, and that's a step in the right direction.

One possible snag: IBM is assigning unique IDs only for its own cards. The rest of us are on our own, so you can rest assured that two companies will introduce two different cards with the same ID. How this will be resolved is up in the air, but I'm sure one of the two will have to install a jumper block to select the card ID. That's the way it goes.

Note: There was an issue with the early POSID automated phone system, callers thought they could give their firm’s info and card info, then hung up. In reality, the phone system had to go to another option and no call was returned...

I'm quite sure that the automatic configuration works, because I used it after taking the system completely apart. The configuration data is stored in a battery backed CMOS RAM on the motherboard. The battery is located on the subchassis just over the speaker. After about 15 minutes, the data in the CMOS RAM evaporates. Of course, I didn't think of that when the PS/2 didn't power up correctly. I could only imagine how annoyed BYTE was going to be when I returned a dead loaner.

Having nothing to lose, I booted up the Reference Disk. A utility automatically deciphered the error numbers into plain English: The CMOS date and time were invalid, and the battery was dead. It reminded me that this will happen whenever the battery is dead or freshly installed. I reset the date and time and then let the utility automatically identify the hardware. It reloaded the CMOS RAM and rebooted the PS/2. Elapsed time: under 5 minutes. Whew!

Opening Night Performance

It's difficult to decide what to test on a machine that's so new you don't even have cards that fit the sockets. I decided to run some timing exercises to measure how well the PS/2 could handle interrupts. I make no pretensions that these are comprehensive tests; the code is certainly not optimized.

Figure 2. Our interrupt test hardware. We replaced the standard interrupt handler for the PS/2's parallel printer port with a specialized one. We measured the interrupt time delays by connecting a dual-trace oscilloscope to both the Ack line and an output-port bit controlled by the interrupt handler.

The parallel printer ports on the PC AT and PS/2 can generate a hardware interrupt from a pulse on the Ack line. We replaced the standard interrupt handler with a specialized one for these tests. An oscilloscope connected to the Ack line and an output-port bit controlled by the interrupt handler allowed us to measure the time delays (see Figure 2).

Because the test programs were written on the PC AT, I got some first-hand experience with the IBM PS/2 Data Migration Facility. The DMF is an adapter that connects a PC AT (or PC) printer cable to the PS/2's printer port. The COPY35 program (on a 5 1/4-inch disk) sends files from the PC AT's disk to RECV35 (on 3 1/2-inch disk), which receives the file and stores it on the PS/2's disk. Sounds simple enough.

There was, of course, a slight complication. The PS/2's POST decided that when the parallel printer port had the DMF adapter installed, it wasn't a printer port, so it omitted the port address from the BIOS data area. Our test programs read the port address from that area, as all good programs should, rather than hardcoding the addresses as constants. After a little team discussion, we wrote a tiny Debug script to force the right address back into RAM. Mutter. Grumble.

Figure 3. The interrupt test program: 3a shows a general outline of the main program's operations; 3b contains the functions performed by the program's interrupt-handler section, detailed in listing 2.

Listing 2. The IRQTEST.ASM interrupt handler.

Figure 3 shows the general outline of the test program, and Listing 2 shows the interrupt-handler section. The program assumes that it's running on an 80286, but it will run unchanged on either a PC AT or a PS/2 system. We needed some interesting tricks to use the new level-sensitive interrupt hardware. For example, the interrupt handler reads the printer-status port. If several cards are sharing the hardware-interrupt line, there is a test to make sure that the printer port caused the interrupt. If you don't read the status port, the hardware won't reset the interrupt-pending bit, and the PS/2 will hang in a tight loop, responding to a stuck interrupt. It's easy to spot on the scope, but the technical reference manual makes no mention of that requirement.

Time Trials

Figure 4. The interrupt timings. The delay equates to the interrupt-response time, or the length of time between presenting the interrupt and the response of the interrupt handler.

Photo 5. An oscilloscope shot of a simple interrupt response on the Model 50.

First, we measured interrupt-response time (see Figure 4) with a minimal system load. The PS/2's timings (see Photo 5) registered a minimum of a 15-us delay from the rising edge of the Ack line to the first interrupt-response output. The PC AT weighed in at about 20 us (see Photo 6). The 10-MHz Model 50 runs about 25 percent faster than an 8-MHz AT-simply the ratio of the clock frequencies.

Photo 6. An oscilloscope shot of a simple interrupt response on the PC AT.

The PS/2's printer port produces much cleaner pulses than the PC AT's. Although the specifications say that both ports use the same pull-up resistor, it must be that the PS/2 has an active pullup, the monochrome card on our test PC AT had some problems, or the difference is the result of the PS/2's better shielding and busing.

If the processors are busy with a non-interruptible task when the interrupt is presented, you get a variation in response times. For example, the hardware-timer interrupt occurs 18.2 times per second and can't be interrupted by the lower-priority printer interrupt. The DOS call I used to check for a key press might also disable interrupts occasionally.

The longest delay on the PS/2 was about 60 us, compared to the PC AT's 80 us. Again, these are roughly proportional to the clock ratio, so I wasn't surprised. Some of the interrupts are lengthened because a timer interrupt occurs while they are active. There was no easy way to measure the increased time, but it seemed to be roughly 10 to 20 us.

Listing 3. The IRQTEST.ASM main test loop.

I wanted to measure the effect of the new Micro Channel arbitration on the interrupt- response time, so we added a DOS call to read a disk file while the interrupts were active. Listing 3 shows the main loop. When the bus load is not zero, the DOS calls are assembled. Each read pulls in 10,000 bytes of data from the file. For the sake of simplicity, we used COMMAND.COM as the test file. The latency remains about 60 us, but the longest delay grew to over 300 us. You can stretch the interrupt to more than 200 us with Micro Channel operations that have a higher priority.

What's going on is that the printer-port interrupt is now contending with the disk controller data transfers. It appears that the controller is using a DMA transfer with a higher priority than the printer port interrupt. The delays and stretched interrupts are due to that arbitration.

For comparison, if you run the same program on the PC AT, there is absolutely no interference from the disk. A quick check of the PC AT BIOS listing will tell you that the PC AT doesn't use DMA for the hard disk; it uses a program loop to transfer sectors from the controller card to RAM. And those transfer loops are interruptible by the printer port. Surprised?

More Value Than Aggravation

IBM is preparing for a multitasking operating system (the long-awaited OS/2), so many of the decisions in the BIOS are made on that basis. Using DMA to transfer the data lets the new hardware arbitrate on a cycle-by-cycle basis between contending Micro Channel users. It's your job to match the hardware and BIOS functions to the task at hand. Make sure that you measure the system under real-life conditions to avoid surprises.

If all you're doing is running spreadsheets, there are cheaper ways to get 25 percent more speed than buying a PS/2 machine. But if you're building systems that get down to the bare metal, the Micro Channel will make your life a lot easier. One complication is that the BIOS listings aren't around to bail you out of tight spots. You have to depend on the published interfaces. Time will tell if all the critical details show up in the manuals.

Only IBM could introduce a new PC system with an incompatible bus, different video adapters and displays, yet another keyboard interface, and a pair of incompatible floppy disk formats and still call it PC-compatible. Anyone else trying to pull this off would suffer The Death of 10,000 Paper Cuts in the published reviews. But the IBM people define what they mean by PC-compatible, so they can get away with it as long as the product supplies more value than aggravation. The PCjr, Portable PC, and PC Convertible didn't, but the PS/2 does. IBM doesn't have to apologize for this one.

I'm most impressed with the level of care and attention that's gone into defining and specifying the requirements for new Micro Channel cards and programs. The Micro Channel allows simple, automated device setup, has the potential to support intelligent I/O subsystems, and has room for growth. The PS/2 looks good, and I'm looking forward to some interesting projects with it.

Special thanks to Ed Nisley for his collaboration on this article.

Steve Ciarcia (pronounced "see-ARE-see-ah") is an electronics engineer and computer consultant with experience in process control, digital design, nuclear instrumentation, and product development. The author of several books on electronics, he can be reached at P.O. Box 582, Glastonbury, CT 06033.

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

Ardent Tool of Capitalism is maintained by Tomáš Slavotínek.
Last update: 08 May 2024 - Changelog | About | Legal & Contact