IBM Blue Lightning: World’s Fastest 386?

One of the OS/2 Museum’s vintage boards is a genuine Made in U.S.A. Alaris Cougar. These boards were produced by IBM for Alaris and are a bit unusual: There’s a small IBM DLC3 processor in plastic package soldered on board, and there’s also a Socket 2 which accepts regular 5-Volt 486DX/SX processors or a Pentium OverDrive. If a standard ceramic-packaged 486 or OverDrive processor is installed, the on-board DLC3 is disabled.

Alaris Cougar

The IBM DLC3, sometimes designated as BL3 and better known as Blue Lightning, has an aluminum heatsink glued on but requires no fan. After 20 years, the information whether it’s the 75MHz or 100 MHz variant has been lost, but the board is stable when the processor runs at 100 MHz (3 x 33 MHz). And incidentally, the OPTi chipset and notably the Adaptec VL-bus IDE controller are quite good performers, often doing better than newer PCI-based 486 systems.

The Blue Lightning CPU is an interesting beast. There is not a whole lot of information about what the processor really is, but it can be pieced together from various scraps of information. Around 1990, IBM needed low-power 32-bit processors with good performance for its portable systems, but no one offered such CPUs yet. IBM licensed the 386SX core from Intel and turned it into the IBM 386SLC processor (SLC reportedly stood for “Super Little Chip”).

Later on, IBM updated the processor to support 486 instructions. It is worth noting that there were still the SLC variants available—nominally a 486, but with a 16-bit bus.

The licensing conditions reportedly prevented IBM from selling the SLC processors on the free market. They were only available in IBM-built systems and always(?) as QFP soldered on a board.

One of the more notable users of the 486SLC and SLC2 processors was IBM’s first ThinkPad laptop series, the 700C (25 MHz SLC, upgradable) and 720C (50 MHz SLC2) from 1992 and 1993, respectively. Blue Lightning processors were also used in some IBM PS/2 desktops.

IBM SLC2 Upgrade

The Cougar board of course sports a DLC3, i.e. a clock-tripled variant with 32-bit bus. This processor is very interesting: It’s essentially a 386 core, updated to handle 486 instructions (there weren’t too many), and equipped with a whopping 16KB of write-back L1 cache.

The 386-ness of the Blue Lightning is most apparent with regard to FPU architecture. The CPU itself has no built-in coprocessor, and most software recognizes it as a 486SX. However, unlike a 486SX, the Blue Lightning can use a regular 387 coprocessor (with the accompanying poor performance relative to a 486DX).

The Cougar is equipped with a 387 socket right next to the soldered CPU. The board came with a Cyrix FasMath coprocessor… which sadly appears to be fried. When the FPU is inserted, the board doesn’t boot at all. Without the coprocessor it works fine. Another FasMath in OS/2 Museum’s has corroded(?) pins which have a tendency to fall off, but after finding a functioning FPU, the system does work and is usually recognized as a 486DX by software.

Performance

Characterizing the Blue Lightning performance is tricky, as it doesn’t much resemble the standard Intel or AMD 486s. The processor core still largely behaves as a 386, which means that performance per clock cycle isn’t great. The catch is that it’s a 386 which a) runs at up to 100MHz, and b) is equipped with superb L1 cache.

Once again, it’s 16KB of write-back L1 cache. Of the common 486s, only the late-model Intel DX4 processors and AMD’s Am5x86 CPUs had L1 cache that was both 16KB and write-back (there were Intel DX4s with 16K write-through cache, and some AMD CPUs with 8K write-back cache).

This impacts the CPU performance in interesting ways. When comparing a 100 MHz IBM DLC3 to a typical Intel DX4 with write-through cache, two things are immediately apparent. First, the 486 core of a DX4 is noticeably faster at reading from the cache, and achieves about 95MB/s bandwidth, compared to approximately 63MB/s on the DLC3. However, the DLC3 can also write at 63MB/s, while the DX4 massively drops to just 31MB/s. The cache behavior is strongly influenced by the fact that the 486 uses 16-byte cache lines while the DLC3 only uses 4-byte cache lines.

The net result is that the DLC3 performance varied depending on exactly what it was used for. In general, it was slower than a DX4 at the same clock speed, but in certain cases it could be faster. It certainly did achieve 486-class performance and a 100 MHz blue lightning was comparable to or slightly better than a 66 MHz 486DX2.

Another confusing area is floating-point performance. When a 486DLC is compared to a 486SX, it does quite well. It is commonly known that a 486SX cannot be equipped with a stand-alone coprocessor, it can only be replaced by a 486DX with a built-in FPU (whether it’s called 487SX or something else).

There is simply no 486DLC variant with a built-in FPU, but a regular 387 can be added. The downside is that the math performance is then similar to a 386+387, and therefore far below that of a 486DX.

IBM intended the Blue Lightning for the typical desktop or portable user with minimal need for math computation. That covered the vast majority of users, but for math-heavy applications, the DLC3 simply wasn’t suitable.

Remarks

The SLC/DLC processors are not to be confused with IBM’s later 486 DX/DX2/DX4 processors, some of which may have been also marketed under the Blue Lightning brand and were commonly available in ceramic PGA packages. Those CPUs were built under a license from Cyrix and were more or less identical to Cx486 processors available under the Cyrix, Texas Instruments, and ST brands.

The 486DLC chips had an interesting deficiency: Despite having a 32-bit address bus and being able to access more than 16MB memory, the internal cache was limited to the first 16MB (presumably due to short cache line tags, designed for the address-space limited  SLC processors). The MSR specifying cacheable regions then only reserved 8 bits for the number of cacheable 64K blocks above 1MB. This limitation probably had little practical impact at the time, as very few systems with Blue Lightning CPUs would have sported more than 16MB RAM. However, the effect can be observed on the above mentioned Alaris Cougar board when equipped with 20MB RAM or more.

The CPUTYPE utility from Undocumented PC claims that a 100 MHz 486DLC3 runs at 104-105 MHz. This is almost certainly caused by a misconception—the utility expects 486 timings for the DIV instruction, but with a 386 core the DLC3 processor really uses 386 timings. Since the DIV instruction is in fact slightly faster on a 386 (38 vs. 40 clocks for a 32-bit register/register divide), CPUTYPE ends up overestimating the CPU frequency slightly. Some other utilities have similar trouble measuring the clock speed; SYSINFO from Norton Utilities is not one of them.

The Blue Lightning is a very interesting example of an older CPU design that modern manufacturing process is applied to. When Intel initially released the 386 in 1985, they had significant difficulties producing chips that could reliably run at 16 MHz, and on-chip cache was deliberately left out because Intel could not manufacture the die with a cache large enough that it’d make a real impact.

Several years later, IBM was able to add a significant cache and run the processors with clock doubling and tripling at frequencies almost ten times faster than the initial 12 MHz 386s. This brought the old 386 design to a point where it easily outperformed many 486s while keeping the power consumption low.

Finally, it needs to be mentioned that the IBM 386SLC was designed to solve some of the same problems as Intel’s 386SL, although the 386SL was meant to be used in conjunction with the SL chipset which IBM presumably wasn’t too interested in. But the Intel 386SL is a different story.

Documentation

No technical documentation of the 486SLC/DLC processors appears to be available. It did exist, but was likely distributed in printed form only. By the time electronic distribution of processor documentation became standard, the 486DLC was already obsolete. Any pointers to detailed Blue Lightning documentation are welcome.

This entry was posted in 386, IBM, Intel, PC hardware, PC history. Bookmark the permalink.

31 Responses to IBM Blue Lightning: World’s Fastest 386?

  1. kodabar says:

    Back in the day I was offered a bunch of IBM Blue Lightning DX4 CPUs. They were a bit grey market as they were an oversupply from some contract job. Some of the DX2 versions had “Blue Lightning” emblazoned across the top in a suitably 80s-action-movie font. But I seem to recall that the DX4 100 version (which is what I was offered) didn’t say Blue Lightning on them anywhere, but were still referred to as such. All the ones I saw were PGA. Interestingly, they were based on the Cyrix 486 and had nothing in common with the SLC/DLC Blue Lightnings.

    I also seem to recall that some of the DX4 ones followed the Intel DX4 pinouts, but others used the IBM DX2 pinouts. It’s all quite a long time ago, so I can’t be certain of that point.

    I wish I’d kept one now. It was a really nice CPU.

  2. Michal Necasek says:

    Yes, that was the other Blue Lighting which was really a Cx486.

    Your recollection about the pinouts is right. At least IBM and ST (probably TI as well, but no documentation appears to have survived) manufactured the DX4s with Intel pinouts, in addition to the original Cyrix DX4 pinout. I assume this was done for easier use in board which did not explicitly support the Cx486 pinout.

  3. Richard Wells says:

    I am not sure there ever what that much produced about the 386SLC/486DLC. A few technotes are available at http://datasheets.chipdb.org/IBM/x86/486/ which cover IBM cache design and crowing about power savings. Of course, some of the other documents there are for either other 486 versions or Cyrix 486 chips.

    I think I have the exact same model of motherboard.

  4. Michal Necasek says:

    The AMD64 documentation references the following publication: “IBM Corporation, 486SLC Microprocessor Data Sheet, IBM Corporation, Essex Junction, VT, 1993”, as well as a 486SLC2 version of the same. I’ve never seen any trace of it, but the Undocumented PC lists several 486SLC-specific MSRs which presumably came from that or a similar document.

    The motherboard is pretty good. Can run a Pentium OverDrive and any 5V 486, and it’s fast. Mine also has MR BIOS which boots quickly.

  5. Chris W. says:

    This is more information than I think I’ve ever seen about the DLC and it clears up a misconception I had – I was always under the impression that the Blue Lightning chips were essentially full-blown 486’s in 386 packaging. I didn’t realize they just tacked on the 486 instruction set. (Incidentally, what “new” instructions were added with the 486? I’m aware of XADD and CMPXCHG. Were there others?)

    The lack of a comparable FPU is a shame. Perhaps one of those IIT X2 487DLC’s could help? Of course finding them is pretty unlikely.

    I’m curious what kind of framerate you can get in Doom (Quake would be interesting too but the FPU would hold you back to 386 performance). Contrary to my own recollections, it appears a 386DX-40 is slower than a 486SX-25. I’d love to know how a 100MHz 386 performs.

    Will the DLC run all 486 software? I know NT4 throws up an error when you attempt to load it on a 386DX (Win9x is more forgiving with the /nm switch).

    Very interesting.

  6. dosfan says:

    New 486 instructions: BSWAP, CMPXCHG, INVD, INVLPG, WBINVD, XADD. 486 DX2 and DX4 chips also have CPUID (backported from the Pentium) and 486SL chips have RSM. Of course the FPU instructions were the significant addition to the 486.

    If I remember correctly the 486 was the first chip to have an A20 pin which allowed for fast A20 toggling (usually implemented via port 92h).

  7. Yuhong Bao says:

    “If I remember correctly the 486 was the first chip to have an A20 pin which allowed for fast A20 toggling (usually implemented via port 92h).”
    Yes, the 486 introduced A20M which was needed because it had an internal cache, but this has nothing to do with the external hardware used to toggle this pin that port 92h is related to.

  8. Michal Necasek says:

    It wasn’t only a few 486 instructions tacked on, it was also a big L1 cache. Especially the triple-clocked DLC3 chips had firmly 486-class performance, far beyond any 386DX. If anything, the Blue Lightning is a good example of blurring the lines between CPU generations.

    A 386DX-40 may or may not be slower than a 486SX-25, because the DX-40 should have considerably higher memory bandwidth, even if the CPU itself is overall slower. I’ll see about DOOM numbers (which may be strongly influenced by the graphics card); what I remember off the top of my head is that in Norton Sysinfo the 100MHz DLC3 is just a little bit faster than a 66MHz 486 DX2. The big cache on the DLC3 makes a lot of difference.

    The DLC should generally run 486 software, but I have not tried NT4 on mine.

  9. Michal Necasek says:

    Yes, the 486 was more or less forced to have the A20M pin because it needed to control its L1 cache. Some other chips like the 386-socket Cyrix 486DLC supported various workarounds to work in 386 boards with no A20M pin support (it amounted to either disabling caching for certain regions or flushing the cache a lot, either way a performance killer).

    But Yuhong is correct that this was unrelated to the ‘fast A20 gate’ support. There were actually two completely separate solutions, one was the PS/2 style port 92h which allowed direct A20 gate control, and the other was the chipset snooping on writes to the KBC and toggling the A20 gate itself, before the slow KBC with its firmware got around to it.

  10. Richard Wells says:

    The cache had its own problems. Software that was too big to be handled by the cache ran quite slowly knocking the budget IBM chips out of the efficient server market. Don’t need much floating point for a database after all. Blue Lightning laptops proved a bad choice as a software developing platform but were absolutely wonderful for word processing.

    I was one of the unlucky few that wrote software that crashed when installed on a Blue Lightning. Somehow, a combination of a tight loop, the specific compiler, and the over-sized cache caused failure. I implemented a fix that had no business solving the problem. Looked all over for information that explained IBM’s design to prevent a repeat and found nothing. I was writing database front ends so a slight decrease in performance didn’t matter but avoiding support calls did.

  11. Michal Necasek says:

    Do you think it was a bug in the hardware (CPU, chipset, and/or other hardware) or an obscure software bug that never happened on other systems? I’m now kind of wondering how one would have obtained the SLC/DLC documentation back in the day.

  12. Michal Necasek says:

    Just FYI, a few Norton Sysinfo CPU benchmark numbers for various CPUs, all on the same Alaris Cougar board. First with 25MHz bus speed: 25MHz 486SX: 54.1, 50MHz 486DX2: 108.3, 75MHz DLC3: 111.7, 75MHz 486DX4: 148.9.

    And with 33MHz bus speed: 33MHz 486SX: 71.8, 66MHz 486DX2: 143.6, 100MHz DLC3: 148.1, 100MHz 486DX4: 197.5

    Basically the triple-clocked DLC3 was slightly faster than a double-clocked 486, but noticeably slower than a triple-clocked 486 at the same bus speed. And a 100MHz DLC3 was very similar to a 75MHz DX4 in terms of integer performance. Unfortunately I don’t have contemporary pricing information or power consumption data.

  13. Richard Wells says:

    It is unfortunate that Computer Shopper issues from the 90s have not been archived. Would make price comparisons much easier. PC Mag had a lot fewer ads for motherboard and CPUs in the back section.

    Depending on the month looked at, the Alaris 486-75 motherboard with chip was cheaper than the 486-66 Intel chip, in other months, was priced at more than 486-66 including motherboard but much cheaper than 486-100 and finally dropped in price so Alaris Cougar cost about $20 more than decent 486 motherboards sans CPU. Basically, whichever company did the most recent price cut provided the best performance for the price for that month. AMD 486 prices were often wonderful but supplies were limited.

    Aug 1994: Dee One Systems prices include motherboard
    IBM 75MHz – $398
    IBM 66MHz – $238
    Intel 100MHz – $748
    Intel 66MHz – $318

    A year later and prices were
    66 AMD – $228
    66 Intel – $264
    100 AMD – $284
    100 Intel – $358
    Pentium 60 – $394
    Pentium 75 – $554
    The 486DLC motherboard and chip is $115 but not sure if Cyrix or IBM.

  14. Andy Oxenreider says:

    I thought the licensing terms weren’t quite for the 386SX, but was a blanket design and rights transfer license dating back to the eeeeearly PC days.

    If memory serves, it was actually a second-source (or, internal-second-source) deal in case Intel couldn’t come up with the processors IBM needed, which explains the restrictions on resale. I think it extended to the Pentium generation, but they didn’t do anything much with it past the 486es.

  15. Michal Necasek says:

    Yes, IBM manufactured Intel CPUs under a license I think up to 486 days, but being a second source did not automatically give them a license to modify Intel’s designs. As far as I’m aware, the SLC was the only instance where IBM modified an existing Intel design. What the exact terms of the license were will probably never be known, we can only guess…

    For whatever reason, when the Pentium came out, IBM and Intel seemed to have decided that they didn’t need each other anymore, and IBM went on to manufacture the Cyrix-designed Cx486, Cx5x86, 6×86 and M2 processors.

  16. Retron says:

    With regards to Doom performance…

    I’ve got an old IBM PS/2 with a “Blue Lightning” 486SLC3-75 chip in it and 8MB of RAM – it dates from 1993. Subjectively it ran like an absolute dog; by the time I acquired it I’d already upgraded my main computer from an Intel 486SX-33 to an AMD 486DX2-66. The main PC had a Cirrus Logic GD5428 local-bus graphics chip and ran Doom at 15-20 FPS, whereas the DX2 chip ran it at 25-35 FPS – not the capped 35 FPS that I’d been expecting.

    Anyway, the PS/2 with its souped-up 386 and XGA-2 graphics barely kept up with the 486SX-33 – it could manage just over 20 FPS at times, but the minimum frame rate was much lower, down as low as 10FPS. Doom was essentially unplayable unless the detail level was lowered.

  17. Michal Necasek says:

    What kind of system was the PS/2? There’s going to be a big difference between a SLC3 used as an upgrade for an old system vs. a contemporary system. Do you know how much L2 cache there was in the two systems?

    For Doom, the graphics card makes a very big difference. If the graphics card isn’t fast enough, even the fastest CPU won’t help. I don’t how how fast the VGA performance was on XGA-2 but I wouldn’t be surprised if it had been much lower than the VLB-based Cirrus Logic. How did the SLC3 compare in purely CPU/memory-bound benchmarks?

    And of course there’s going to be a big difference between a DLC3 vs. a SLC3, 32-bit vs. 16-bit bus.

  18. feipoa says:

    I have an IBM BL3 on a PGA interposer board manufactured by Buffalo for a PC-98 system. I have tried it in various 386 motherboards, e.g. SiS 310/320/330, UMC 481/482, and VIA 481/495, however if I enable the L1 cache and multiplier, I cannot load HIMEM.SYS. Are you able to load HIMEM in DOS? Otherwise, if I do not load HIMEM, the CPU works fine in DOS. What is interesting is that these three motherboards work fine with the Ti 486SXL2 and Cyrix DRx2 with HIMEM loaded (L1 cache and multiplier enabled).

  19. Michal Necasek says:

    I don’t quite remember but I think chipsets and BIOSes need to explicitly support the Blue Lightning for proper operation, possibly boards as well.

    Hmm yes, looking at the OPTi 82C499 datasheet, there’s one control bit setting specifically for the IBM 486DLC, and also a hint that the ADS# pin is used for cache snooping with the IBM processors.

    The big difference between the Cyrix and IBM 486DLC designs is that the Cyrix was meant to work as a drop-in replacement in 386 boards that have no clue about anything other than a standard Intel 386DX, but the IBM was not really meant as an upgrade CPU and assumed existing chipset/BIOS support (no doubt because IBM’s license agreement with Intel didn’t allow them to sell the CPU on the open market).

    The Cyrix does work better in boards with appropriate support because it doesn’t have to be as conservative, but it can work in old boards where the IBM can’t work at all (well, not with any caching, and then what’s the point).

    I only have one IBM Blue Lightning board, Alaris Cougar, and the CPU is soldered on. The board has an OPTi chipset; I’m not entirely sure which it is but it also handles real 486s and the Pentium OverDrive. There’s no trouble with HIMEM.SYS or anything on that board.

    In my experience, the fastest upgrade CPU for old 386 boards is the clock-doubled TI 486SLC2 (has 8K L1 cache vs. 1K in Cyrix CPUs). The Blue Lightning at 100 MHz and with 16K L1 cache is of course a good deal faster than the Cyrix/TI CPUs.

  20. feipoa says:

    The Buffalo interposer board that I have for the IBM BL3 does contain a GAL, and was meant for upgrading particular motherboards. There is another unit from IODATA which has multiple GAL chips on the interposer. A friend of mine was mentioning that he was able to use his IODATA board for upgrading his regular 386 board. He noted that there was a jumper on his unit which allowed for direct memory acces (DMA) and that solved his HIMEM issue. My Buffalo unit has only one jumper, but it did not resolve my issue. I was going to try a register manipulation program like CTCHIP to see if I can find a work around.

    My Buffalo BL3 board, unfortunately, only works up to 75 MHz. There was no sign of life using a 33 MHz FSB, not even at 1×33 MHz. It does appear to work fine without HIMEM loaded though, e.g. DOOM and Quake run and I was able to load Windows 3.11.

    If you look through the Texas Instruments SXL2 manual, there is a section which describes how to make a cache flush circuit (using gates) to add to your motherboard. There are also software programs to enable the FLUSH or BARB pins on the CPU, which I find is needed.

  21. feipoa says:

    I think I have figured out what is causing the issue with HIMEM and the A20 handler, but I need to modify specific registers for this CPU. Do you have the IBM Blue Lightening BL3 datasheet? I looked online but cannot locate it. Unfortunately, CTCHIP34 does not go into enough detail.

  22. Michal Necasek says:

    No, I don’t have the datasheet and I don’t know anyone who does. Is there something specific you’re looking for? Undocumented PC documents some of the IBM Blue Lightning registers.

  23. Michal Necasek says:

    Also, I assume trouble with HIMEM/A20 is caused by caching and A20 line switching. The 486 has an added input pin for that (A20M#), and Cyrix/TI CPUs have various solution which depend on the board/BIOS. I believe Cyrix and IBM 486DLC processors also have A20M# support, but that requires chipset/board support. Of course I don’t know what those interposer boards do.

  24. feipoa says:

    I have now tried a VIA 481/495-based motherboard with the BL3. HIMEM is still unable to control the A20 line and will not load. On all my 386 boards (VIA 481/495, UMC 481/482, CHIPS 351/355/356, SiS 460, SiS 310/320/330, VLSI 330/331/332), I have been able to get the Cyrix/TI DLC, TI SXL, TI SXL2, and Cyrix DRx2 working. If the BIOS doesn’t have proper support, there is software which can enable the A20M line, or KEN#, FLUSH#, or BARB and can set the first 64K of each 1 MB boundary as uncacheable/cacheable or the 640k to 1 MB region as uncacheable/cacheable depending on the motherboard. Some motherboards implement the FLUSH cache circuit as shown in the TI SXL manual, some do not, but work just fine without it. The more Cyrix DLC aware boards tend to have ADS# connected to Vcc through 10K-ohm, A20M# connected to Gate A20 on the KBC, and LOCK# connected to Vcc through 10K-ohm. I have already confirmed such hardware connections on the boards I am testing with the BL3.

    What I am looking for is more detail on the BL3 registers. CTCHIP34 allows for manipulation of the registers and has a configuration file for the IBM Blue Lightning BL3. Some registers are straight-forward, like a simple bit on, bit off. Other registers, particularly the Cache Region Control Registers that I am interested in, are a bit more vague. For example, the Revto486 software from Evergreen, which can be used for an IBM BL3 upgrade, sets up various registers for the CPU. It even has a /BL flag for Blue Lightning. There is another control software from Kingston. Using CTCHIP34, I have isolated the issue with HIMEM to the Cache Region Control Register 4, which is for “CMLR 1..16 MB cache Mem Limit”. For register bits 7, 6, 5, 4, 3, 2, 1, 0, the values are set to 11110000 by Revto486. Kingston sets them to 11110100. Unfortunately, I do not understand what each of those bits signify. Do you know how to determine this? Now if I set them all to 0, I do not get an issue with HIMEM, however based on the benchmark results, having them set to 0 indicates that the L1 cache is disabled. So that does not help. Is there a value between 0 and 11111111 which will work?

    Since HIMEM says it cannot control the A20 handler, I was hoping to find an A20M enable bit, like there is for the cyrix dlc/sxl software. The closest match noted in CTCHIP34 is the “Processor Operation Register Byte 0, bit 2: A20M_MASK”. Enabling it did no solve the problem though.

    Conversely, all values for the “Processor Operation Register” Bytes 0, 1, 2, 3 are spelled out bit by bit. But for the “Cache Region Control Registers” Bytes 0 thru 6, all the bits are jumbled up as bits 76543210 = some 8-bit binary number. And I suspect some of these Cache Region Control Registers set the ability to not cache the first 64K of each 1 MB boundary, which may also be where the issue lies. So what I was hoping for was some kind of explanation as to what each of these bits signify, but was unable to find an IBM Blue Lightning datasheet, although I did see reference to it on one document. So it is out there, somewhere…

    CTCHIP34 lists the 7 Cache Region Control Registers as,
    Byte 6
    Bits 76543210 = (some 8-bit binary number)
    Desc: ECMLR.. 4 GB Extended Cache Mem Limit Hi-byte

    Byte 5
    Bits 76543210 = (some 8-bit binary number)
    Desc: ECMLR.. 4 GB Extended Cache Mem Limit Lo-byte

    Byte 4
    Bits 76543210 = (some 8-bit binary number)
    Desc: CMLR 1.. 16 MB Cache Mem Limit

    Byte 3
    Bits 76543210 = (some 8-bit binary number)
    Desc: LMROR 1 Meg READ only Hi-byte

    Byte 2
    Bits 76543210 = (some 8-bit binary number)
    Desc: LMROR 1 Meg READ only Lo-byte

    Byte 1
    Bits 76543210 = (some 8-bit binary number)
    LMCR 1 Meg Cacheable hi-byte

    Byte 0
    Bits 76543210 = (some 8-bit binary number)
    LMCR 1 Meg Cacheable lo-byte

    All other registers are simple bit on/off, e.g.

    Processor Operation Register
    Byte 1
    bit 7 = (1 or 0) CNPX: cachability of NPX operands
    bit 4 = (1 or 0) XTOUT: Extended Out Instruction
    bit 3 = (1 or 0) CRLD: Cache Reload
    etc..
    Byte 0
    bit 7…
    etc.

  25. Michal Necasek says:

    So yes, the Undocumented PC has some goodies. The A20 bit (bit 2 in Processor Operation Register aka MSR 1000h) sounds like it is a control bit which has to be set by software, not something controlled by hardware! I’d guess that a BIOS with Blue Lightning support might toggle that bit in SMM in response to keyboard controller accesses. Just a guess. Actually a HIMEM.SYS A20 handler could theoretically manipulate that bit too. But anyway the point is that the bit won’t do anything on its own.

    Now the Cache Region Control register(s), also accessible as MSR 1001h. In the first 16 bits, each set bit represents a 64K region in the 1st MB that is cacheable (bit 0 represents 00000h-0FFFFh, bit 15 is F0000h-FFFFFh). In the second 16 bits, each set bit represents a 64K region in the 1st MB which is read only. If the ‘cacheable’ and ‘read only’ bits are both set for a given 64K block, writes to the memory will not update the cache (the text is not clear as to whether the write is completely discarded).

    The final 8 bits indicate the number of contiguous 64K blocks above the 1M boundary which are cacheable. Note that the Blue Lightning won’t cache more than 16M (or maybe 17M total) because of this, at least if Undocumented PC is to be believed.

    I don’t see a way to do what Cyrix allows, i.e. make the first 64K and 1M+64K uncacheable. Well, not without completely disabling caching for extended memory.

    I think the document we’re looking for is: 486SLC2 Microprocessor Data Sheet, IBM Corporation, Essex Junction, VT, 1993. I have never seen it and don’t know anyone who has.

  26. feipoa says:

    Thank you. I’ll see what I can figure out. Are you able to forward to me the relevant pages of Undocumented PC?

  27. Michal Necasek says:

    Sorry it took a while. See http://os2museum.com/files/unpc_p111.jpg (page 111) up to http://os2museum.com/files/unpc_p115.jpg — pages 111-115 from Undocumented PC, 2nd edition. That’s the most detailed information on those registers that I’ve ever seen. And sorry for the crappy quality, they’re just phone photos but it’s legible.

  28. feipoa says:

    Great – thanks a lot! It might be awhile before I can look into this in detail. My wife just gave birth to #3.

    The reference documentation I saw specifically said the title of the datasheet was IBM Blue Lightning and it was referencing the BL3 and not the PGA-168 Blue Lightning. Not sure if it matters because I cannot locate either of these documents.

  29. Michal Necasek says:

    Congratulations (and good luck)! From my own experience I know that little people are not particularly compatible with vintage hardware.

    The PGA-168 Blue Lightning is a completely different kettle of fish (as I’m sure you know), it’s the Cyrix 486-socket processor that IBM manufactured. It was called Blue Lightning just like IBM’s own 486SLC/DLC, which is an Intel 386 derivative. Great way to confuse people.

    There should be something called “BL486DX/DX2 Data Book” which deals with the PGA-168 processors. I’ve never seen it either.

  30. Spencer Gordon says:

    Hello! I’ve been looking for an IBM 486BL motherboard for some time, but they seem quite rare. Can anyone point me to some information regarding boards to keep my eyes out for? The Alaris Cougar looks perfect, but I haven’t found one yet. I’m very interested in owning a 486BL3 board to build a system around!

  31. techfury90 says:

    The GALs most likely contain A20 related logic, which is what may be causing you trouble. PC-98 A20 is toggled by poking a completely different I/O port, and PC-98s don’t have a KBC anyway.

Leave a Reply

Your email address will not be published. Required fields are marked *