Intel 420TX Chipset

The OS/2 Museum recently obtained a somewhat unusual board: A 1993 vintage 486 PCI/ISA board equipped with the Intel 420TX chipset.

J-Bond PCI400C-AThe 420TX chipset, codenamed Saturn, was probably Intel’s first PCI chipset available to customers. It was probably first sold in 1992. The 420TX consisted of three chips. 82423TX and 82424TX together formed what would later be called a northbridge, and 82378IB was the southbridge.

Identifying the board took a little while but in the end wasn’t too difficult as it has several very unusual features. A Socket 2 486 board with PCI slots, onboard SCSI controller, but no onboard IDE or floppy—that is a rare sight indeed.

The board is a J-Bond PCI400C-A. In some materials it may be referred to as a J-Bond PCI 486. It is equipped with a dizzying array of jumpers, quite unusual for a board which only supports two frequencies and three or four different CPU type.

There is 256K cache on the board; as with many later chipsets, 256K is the best compromise between size and performance because 256K is divided into two banks, while a larger 512K cache would only consist of a single bank and thus be slower.

The board designers were kind enough to not solder the Dallas-style RTC onto the board. That should make replacements easy, although the original 1993 Benchmarq RTC still works—after 22 years!

PCI Support

As it turns out, the board was made in the good bad old days before Plug and Play became friends with PCI.

The board supports up to 4 PCI devices: The onboard SCSI controller and three slots. For the two pairs of slot 1/slot 2 and slot 3/onboard SCSI, only one device in each pair can be a PCI master; jumpers determine which. For each of the three slots, jumpers choose which IRQ should correspond to PCI INTA#. The choice is one of IRQ 3, 5, 10, 11, 14, 15.

Additionally, the BIOS setup determines whether a PCI device will be enabled.

420TX PCI BIOS SetupGiven that the board is very, very old and only supports PCI 2.0 (not even 2.1), compatibility problems are to be expected. But the onboard SCSI PCI HBA appears to work (not fully tested), and at least some PCI graphics cards work as well.

Two randomly chosen PCI graphics cards were tested: An ELSA WINNER 2000 (Permedia 2, 1997) and an ATI Graphics Pro Turbo (mach64, 1995). The former showed the POST sign-on message and hung. The latter worked.

OverDrive, or maybe not?

Being a Socket 2 board, the PCI400C-A supports Pentium OverDrive upgrades. Except all attempts to install a known working Pentium OverDrive processor (two different ones) were utter failures—the board didn’t even start booting.

The jumper settings for Pentium OverDrive operation are all silkscreened on the board itself, so those should be correct. The catch is that the board was made in 1993 and the Pentium OverDrive wasn’t available until 1995 (a big reason for why it was a failure). It’s entirely plausible that the Pentium OverDrive simply doesn’t work in the board. It certainly couldn’t have been tested when the board was designed or produced.

Fortunately at least 486 OverDrive CPUs work well in the board. With a DX2ODPR66 OverDrive the board performs reasonably well, and it should support 100 MHz DX4 OverDrive processors as well. (This is to be tested soon.)

Performance

The performance of the chipset/board is… odd. With a 66 MHz Intel DX2 processor, Norton Sysinfo shows score of 129.0. That is markedly low for that CPU in a board with 256K L2 cache. The same CPU scores slightly over 140 in other boards, for example 143.6 in an Alaris Cougar board (OPTi 499 chipset).

Other benchmarks tell a different story. CACHECHK suggests and SYSBENCH confirms that the board has good memory throughput, in fact much better than the OPTi 499. The system memory read/write/move speeds are 28.1 MB/2, 41.6 MB/s, and 21.7 MB/s on the 420TX board. On the OPTi 499 board it’s only 20.2 MB/s, 32.0 MB/s, and 10.3 MB/s. In both cases this is with the fastest timings available in the BIOS setup and with FPM RAM.

A “real world” benchmark (DOOM) confirms this. With the same CPU and graphics card, timedemo 3 completes in 1979 ticks with the OPTi 499 chipset and only 1553 ticks on the 420TX.

It is currently unclear why the 420TX scores poorly in Sysinfo. But there is every indication that the chipset is not a bad performer and the Sysinfo score is an aberration.

One possible explanation is that the L2 cache works differently on the 420TX chipset. SYSBENCH indicates that memory moves within L1 are significantly faster on the OPTi 499 board, even though the 420TX is generally somewhat or much faster.

Documentation?

The PCI400C-A itself is commendable for having almost every jumper setting silkscreened on the board itself. A good thing, too, given how many jumpers there are. The BIOS has likewise good built-in help explaining the various settings.

Unfortunately there appears to be very little information about the 420TX chipset available. There is a brief overview of the 420TX chipset, but no documentation of the chipset’s registers.

That is too bad, since the 420TX is an interesting piece of computing history, a true PCI pioneer.

Update: The 82378IB datasheet has been hiding in plain sight. Unfortunately the “northbridge” datasheets are still nowhere to be found. The 82378IB documentation confirms that there is no PCI IRQ steering whatsoever, so the board must have jumpers or some external means of translating PCI interrupts to 8259A IRQs. A related problem is that the 82378IB does not have any way to select level- vs. edge-triggered interrupts for individual IRQ lines. That most likely precludes any IRQ sharing, and might prevent some PCI devices from working.

This entry was posted in 486, Intel, PC hardware, PCI. Bookmark the permalink.

21 Responses to Intel 420TX Chipset

  1. Darkstar says:

    And again a very interesting read! I like these old hardware tidbits.

    Any chance you could dump the ROM and upload it somewhere? Would probably be interesting to preserve for helping to emulate the chipset

  2. Michal Necasek says:

    I could dump it, but it would be a waste of effort… because a newer version can be found here: ftp://ftp.cosy.sbg.ac.at/pub/mirror/ct/pci/ (it’s pci400c.zip, also mentioned in the index file). The board is old enough to not have flash EPROM so I can’t update the BIOS easily. It might solve the Pentium OverDrive incompatibility — or it might not.

  3. crazyc says:

    I’ve got a Micronics 420EX PCI/ISA board. It’s more typical though with a CMD PCI IDE controller and a SMC FDC. Oddly though, it’s got 3 PCI slots but only 2 of them can be bus masters which mean only a very limited number of PCI devices will actually work in the slave slot. Emulating would be a bit difficult as the datasheets for these 486 PCI chipsets are hard to find.

  4. Yuhong Bao says:

    On the Pentium OverDrive, I remember that there was also an interposer to resolve cache problems.

  5. Andreas Kohl says:

    From my memories only Intel 486DX2 or DX4 (mostly) worked correctly with write-back caching in Saturn boards, for everything else it should better be changed to write-through mode.

  6. Michal Necasek says:

    That’s write-back of the L2 cache on the board or the CPU’s L1 cache (if it supports WB)?

    At any rate, I tried various cache settings and could not get the Pentium OverDrive to work with any of them. No problem with a Cyrix DX2 or the Intel DX2 OverDrive.

  7. Chris M. says:

    Whoa, setting PCI IRQs with jumpers, that is pretty odd given that both EISA and MCA boards already supported software selection of resources. I wonder if that cruddy Phoenix BIOS is to blame? What does the CMOS setup look like in terms of options? I have a Micronics EISA/VLB 486 board here with a Phoenix BIOS that has the single screen setup panel straight out of a 286! That same board has a partial implementation of Intel’s 82350DT EISA chipset. Micronics opted for their own memory interface “north bridge”.

    I always found the Intel 486 PCI chipsets interesting since it was their first mass market push into that market (the 82350 wasn’t all that popular and was high end), but people never had anything good to say about them. Did any PCI 1.x boards actually made it to market?

    @crazyc The SiS496/497 datasheets were located and PCEm has a 486 PCI machine as a target.

  8. Michal Necasek says:

    The BIOS wouldn’t be to blame… the board designers put the jumpers on, not the BIOS supplier. It is possible that the 420TX did not have programmable PCI IRQ steering, but without a datasheet that is just a wild guess. The BIOS is definitely not some quickly hacked up 286/386 thing, it was designed for PCI support and all that.

    Apropos BIOS, I forgot to add a picture of the BIOS setup screen with PCI settings to the article; thanks for reminding me! The article is now updated.

    I don’t know about PCI 1.x boards. But the thing is that PCI 1.x did not yet specify the slot/connector, so a PCI 1.x board would have at most something like an onboard SCSI HBA.

    As for the 420TX, it doesn’t seem to be awful but I didn’t test it extensively. It actually seems to have very respectable memory bandwidth. It definitely has compatibility issues with newer PCI boards… but that is hardly surprising because when it came out, there was basically nothing out there yet in PCI form factor.

  9. Yuhong Bao says:

    “It is possible that the 420TX did not have programmable PCI IRQ steering, but without a datasheet that is just a wild guess. ”
    Looks like this uses the 82378IB southbridge, which don’t (the 82378ZB does).

  10. ths says:

    I vaguely remember in the 486 days when PCI was designed there was some press release that IDE was to be dropped and SCSI should be used exclusively .
    I’ve seen quite some boards which had only SCSI controllers onboard, and that was fine so far – you could connect 7 devices to an adapter.
    For cheapo guys of course there were IDE adapters, and then vendors started adding IDE chips soon again to follow customers’ wishes for cheapo HD drives.
    I very much regretted that at the time because lots of IDE chips had strange quirks which the device driver had to compensate for (CMD 640 comes to mind).
    I loved running OS/2 on my ASUS 486 board without IDE in PROTECTONLY mode 😉

  11. Michal Necasek says:

    I don’t think there was ever anyone who could make IDE go away, but it would have saved us a lot of headaches in the long run. Early IDE was terrible, with tons of compatibility problems and lackluster performance. But it was cheap so everyone bought it anyway. With bus-mastering, IDE was finally able to do what SCSI HBAs had been able to do years earlier, and that was pretty much the end of SCSI on desktops.

  12. Yuhong Bao says:

    Ah, the CMD640 and RZ1000. If OS/2 2.x had actually replaced DOS/Windows instead of turning into a fiasco, it is unlikely that they would be able to get away with shipping these chips with the problems they had.

  13. Richard Wells says:

    SCSI had its own set of flaky chips and strange noncompliance with standards. I had a NEC CD-ROM which had issues with some controllers. Adaptec and Corel could not correct for everything.

    SCSI manufacturers could have made IDE go away by trading lower margins for greater volume. SCSI devices became cheap to build in the mid-90s as all the inexpensive parallel port drives and scanners built by attaching a parallel to SCSI adapter to a much high priced SCSI device showed. Those lower prices never showed up if the device had a SCSI connector exposed.

  14. Chris M. says:

    SCSI was never cheap though. Oddly IDE was cheap and easy enough to implement on non-x86 platforms despite being a form of the ISA bus. Commodore ditched SCSI in later Amigas, and Apple switched to it for hard drives in 1994 with the LC/Quadra/Performa 630 series.

    As for PCI, it was the opposite. It always seemed out of place on PCs, particularly with regards to IRQs. Other platforms (ex: PowerPC) had much less headaches (IRQ sharing, ugh) with the bus in the early days. That finally changed when APIC became standard on x86 machines.

  15. Yuhong Bao says:

    http://www.osronline.com/showThread.cfm?link=21604

    I wonder would have happened if they decided the other way back in 1999, say six months before Win2000 RTMed.

  16. Michal Necasek says:

    Sure, SCSI had its issues, but on the whole it was a lot more flexible and powerful… the ability to attach a bunch of disks, CD-ROMs, tape drives, scanners, etc. was something where IDE took a long time to catch up, and even then not quite.

    I think the story of SCSI is one of classic short-sightedness. The SCSI guys were too busy fighting each other to realize that IDE was going to eat them all. And I do think that for many, putting “SCSI” on a product automatically meant much higher margins. That only works when there are no reasonable alternatives.

    From my perspective, one major problem with SCSI was the lack of a register level standard like AHCI. That was a major problem for storage controllers (the #1 use of SCSI) where extra drivers always meant a lot of hassle, even if you had them in the first place.

  17. Chad Page says:

    The SCSI Connector Of The Month Club(tm) didn’t help either.

  18. Wolfgang k. says:

    I have a board here which seems to be similar to the one above but it doesn’t have a scsi connector. On the last isa slots there is a sticker that says 486icp-2. gericom.
    From my research it could be a chaintech board because at th99 i found one that has exactly the same jumpers as mine. But the chaintech has a special slot which mine is lacking. There are only solder dots where the special slot should be. The bios is exactly the one as the board above. Chaintech board is called chaintech 486icp so i guess mine is a minor version of that board. I use a spea mirage p64 pci grafic card.

  19. MiaM says:

    This is probably well known information, but atleast on some of theese RTC:s with built in battery it’s actually possible to replace the battery. It looks a bit hard on this specific model but for example on those found in old Sun Sparcstations (IPX, SS2 e.t.c.) you usually just put the RTC in a vise and crush the upper part of the chip, exposing the battery connections and dismembering the battery from the actual IC. Then you just solder on two AA batteries in series and put a bit of tape around the batteries and then around both the batteries and the remaining IC. 🙂

    P.S. regaring SCSI v.s. IDE i agree with most comments, but:
    IDE were almost always better than what it was ment to replace, i.e. MFM/ST506 drives. The only thing that actually caused more problems with IDE than with MFM/ST-506 were using two drives on the same interface. DASP, PSEL, manual or automatic detection of the presence of a slave, cables with and without cable select e.t.c.
    Having two newly purchased IDE units “always” worked from arount the time CD ROM readers had reached 4x speed, i.e. when IDE became the common interface on CD ROM:s and the proprietary interfaces had faded out.

    SCSI had it’s problems.

    Slightly off-topic, but associated with the comparision between SCSI and IDE:
    I semi-recently aquired an old Panasonic Senior Partner “portable” XT class PC with integrated 9″ monochrome CRT (but CGA graphics) and a thermo printer (!). As I don’t have any old MFM disks or controllers lying around any more and no XT IDE controller I poked around my stash of ISA cards and found an old NEC/Trantor T128 SCSI controller. It turns out that the on bord bios uses OP codes only found on NEC V20 or 286+ processors so it doesen’t work on an 8088 CPU. The CPU is socketed in this computer so theretically it would be easy to swap in a V20 CPU. However the BIOS is soldered directly to the board and the BIOS won’t boot with a V20. Bummer.
    Booting from floppy and loading the SCSI drivers from disk works, but it’s not only slow but painful on free memory as this machine only has 128k ram.
    Some day I will probably find a 512k SRAM chip, solder onto a prototyping board and solder wires onto the ISA end of an ISA multi i/o board, giving me 640k ram and the possibility to use half the capacity of an IDE drive. The machine has two ISA sockets so the other could contain an 8-bit ISA ethernet card with XT IDE bios in the boot rom socket.

    Except for what the retro computer scene have done, there were not many possibilites to use IDE on 8-bit ISA machines. There were some 8-bit IDE modes but they seemed incompatible. I actually tried to combine the 8-bit IDE interface of Commodore Amiga A590 disk controller with some Seagate IDE disk that were supposed to have some kind of 8-bit IDE mode but that didn’t work. (The Seagate disk worked in 16-bit mode on a standard PC and the A590 worked with it’s original slow 8-bit IDE drive).

    I’ve also seen stuff like tape backup streamers “working” but returning garbage data in some SCSI fields, i.e. “version -47” or similar

    Re standard registers for SCSI controllers – Asus made some motherboards and SCSI cards where the SCSI bios was contained on the motherboard. Of course it did only work with a specific SCSI controller. If that had caught on we could probably have had standard registers atleast for bringing up the machine enough to load better drivers from disk. If intel had wanted this to happend they could probably have required SCSI bios on the motherboards as a term for buying the (more recent 430**) chips. But that would have required Intel to either have an own SCSI controller PCI chip suitable for mass production or selecting some of the existing from their competition…

  20. Michal Necasek says:

    Re RTCs — I’ve done a similar conversion on a 286 board. The other option is desoldering the chip, soldering on a proper socket, and using a nice socketed RTC.

    Re 8-bit IDE — CompactFlash devices should support 8-bit transfers because it’s a requirement for PCMCIA.

    I think it wasn’t just ASUS with the semi-built-in SCSI. The BIOS was for NCR/Symbios chips. And now that you mention it… SCSI is one area that Intel never really got into.

Leave a Reply

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