The OS/2 Museum recently obtained a somewhat unusual board: A 1993 vintage 486 PCI/ISA board equipped with the Intel 420TX chipset.
The 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 types.
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.
Given 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.
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
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.
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.
On the Pentium OverDrive, I remember that there was also an interposer to resolve cache problems.
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.
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.
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.
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.
“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).
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 😉
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.
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.
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.
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.
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.
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.
The SCSI Connector Of The Month Club(tm) didn’t help either.
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.
I found this on the difference between the 420TX and 420ZX: http://web.archive.org/web/19990421045433/http://support.intel.com/support/chipsets/420/8511.htm
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…
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.
> Except all attempts to install a known working Pentium OverDrive processor (two different ones) were utter failures—the board didn’t even start booting.
With all the known copies of the BIOS, I have the opposite problem – it boots with a Pentium OverDrive but hangs with a 486, and I suspect it’s a bit flip that turned a JNC into a JC – it calls INT 15h, AH=C9h to query the CPU type, whcih returns carry set on error, yet because of that one JC, it takes the correct path on error, but the wrong path (where it doesn’t move the required data to segment 8000h that it then jumps to) on no error, which can’t possibly be the correct behavior.
Since you attest that your board in fact behaves the opposite way, I hereby reiterate Darkstar’s request for you to dump your BIOS so we have at least one proper copy.
Now that I look even more into this, I’m now even more convinced the BIOS floating around has been deliberately patched to work on Pentium OverDrive, breaking 486 in the process. The BIOS checksums itself, so a simple accidental bit flip would break it completely, the only way it can still work is if some other byte was also patched to make the checksum match.
Also, I would like to request a dump of the Alaris Cougar BIOS, as I can’t find it anywhere.
The dump is now at here.
Hmm, so you’re saying this was one of the broken boards which supported the Pentium ODP in theory but because they couldn’t test it, they managed to screw up the BIOS. It’s plausible that someone hacked the BIOS and adjusted the checksum, but instead of correcting the real problem they just flipped it around.
The dump of my board’s EPROM chip (also includes SCSI BIOS) is now here. Please let me know how exactly it differs from yours.
I was able to see them by looking at the page source.
Anyway, the J-Bond plot thickens. Your BIOS seems to be completely different from the other one, but it also hangs on a 486 on the emulator, but I need to see if it does the same stupidity as the other one, which was doing a CALL FAR to 8000:0000 but, on a 486, never actually transferring any data there (but instead, doing weird stuff with the TR registers). And, again unlike your real hardware experience, it works just fine on a Pentium OverDrive. This is getting really bizarre. I’m going to have to investigate further to get to the bottom of this.
In any case, thanks!
Whoa. So what does “completely different” mean here? And is there an image of your BIOS somewhere?
The BIOS seems to copy two short routines to 8000:0 while it’s measuring the CPU speed. It looks like it’s trying to flush caches and such, and yes it does do something with TR3/4/5 but I haven’t tried to figure out what. Looking at the logic there it sure looks like it’s broken, if the CPU is not a 486, nothing gets copied to 8000:0 and the BIOS will predictably hang during POST.
In my BIOS, there’s a JMP instruction at offset 7B4Bh in the F000h segment which looks like it shouldn’t be there. It skips over copying code to 8000:0 which looks very wrong because the caller clearly assumes that calling 8000:0 is safe.
It’s actually probably even worse because on a Pentium, I think the BIOS will try to execute the TR3/4/5 code which will GP-fault. I can’t tell off hand if the code accessing TR3/4/5 is meant for a 386 or a 486.
Actually I think I misread the code… nothing gets copied to 8000:0 if the CPU is a 486. That’s a little weird because my board definitely works with a 486. The problematic code is CPU speed detection, and it looks like the code twiddling TR3/4/5 is meant to run only on a 486.
This is more than a bit strange.
Yes, on a Pentium OverDrive, it skips that TR stuff completely and instead copies the stuff to 8000:0000, then goes there. Interesting that you have a hang on a Pentium OverDrive, while on the emulator, it actually works there. Perhaps on a real Pentium OverDrive, 8000:0000 is already cached at that point, which makes it execute the invalid stuff that’s in cache instead of the correct code.
Your point about the GPF is interesting – perhaps it expects a GPF which happens on a real 486 but not on the emulator, and the GPF handler copies the stuff to 8000:0000? I actually need to test that.
Also, your BIOS has enough differences from the one I have that FC /B was spewing a never-ending wall of them. I have uploaded it here now: http://citadel.ringoflightning.net/pci400c.zip .
I just found an AMD (but I assume this is the same for Intel) reference about the TR registers, and it appears TR3, 4, and 5 are used for cache testing, including an ability to write directly to the cache. I am now certain the BIOS uses that to write the cache for 8000:0000 in advance before jumping there. The reason it hangs on the emulator is because that stuff is not implemented at all!
Your BIOS is a couple months newer, even if most of the dates are the same; mine has “PCI400C-A Oct.05,1993” in it, yours has “PCI400C-A MAR.14,1994”. The differences are probably not huge but yes, a binary compare shows tons of differences.
The TRs are test registers, only implemented on 386 and 486, and different across models. The Pentium has no TRs anymore but has MSRs instead. Intel documented the TRs too, for example the 1992 Intel 486 Programmer’s Reference.
In your emulator, what exactly is going to be in word at offset BCh in the BDA, i.e. the word at address 0:4BC?
Hmm yes… the routine at offset 7B61h in the F000h segment in my BIOS copies data straight into the on-CPU cache. It writes dwords from memory to the TR3 (data) register, first setting up the cache fill buffer and then writing (using TR4/TR5) the cache line corresponding to 8000:0. The CPU speed test code then runs straight out of the cache while caching is otherwise disabled.
Interestingly the alternative ‘rep movsb’ just copies 128 bytes, while the code path using test registers fills 2KB of cache data. The whole code looks a bit weird, it may have been copied from somewhere without necessarily being fully understood (the documentation is not that great).
So yeah, if the emulator does not implement the TR3/4/5 cache access behavior, the BIOS will hang with a 486. And now I’m left wondering why my board doesn’t seem to work with a Pentium OverDrive…
> In your emulator, what exactly is going to be in word at offset BCh in the BDA, i.e. the word at address 0:4BC?
I haven’t yet logged that, but I will now.
> Hmm yes… the routine at offset 7B61h in the F000h segment in my BIOS copies data straight into the on-CPU cache. It writes dwords from memory to the TR3 (data) register, first setting up the cache fill buffer and then writing (using TR4/TR5) the cache line corresponding to 8000:0. The CPU speed test code then runs straight out of the cache while caching is otherwise disabled.
For what is worth, the BIOS I provided does the exact same (I actually looked at the disassembled code) so that part has remained unchanged. I have now implemented this TR cache stuff in a sort of roundabout way so the BIOS no longer hangs on a 486.
But, I still have no idea why it hangs on your real Pentium OverDrive, while on the emulator, it works just fine on one. I am at a complete loss as to what could be different, aside from the cache, or perhaps there’s more instructions that the BIOS executes that on real hardware work on a 486 but not on a Pentium OverDrive, but on the emulator, work on both.
My board could have some hardware problem preventing a POD from working. The POD was not available before 1995, and my board is from 1993, so who knows.
The software support for the OverDrive in the BIOS looks a bit sketchy too. For example there’s an entry for “Pentium(TM)” in the CPU string table, but I doubt a POD will be found because the CPU ID won’t quite match. OTOH the routine that sets up the deturbo support in the chipset does look for the right ID (153xh) so who knows. At any rate, I don’t think either the hardware or the BIOS could have been tested with a POD.
With a PODP, my board dies with POST code D1h. That’s right before it starts hitting the PCI controller registers.
I thought there might be some problem with WB cache but the board works with a DX4-100 OverDrive. That said, the DX4-100 CPU doesn’t seem to be working in WB mode even when it’s enabled… so who knows.
Interestingly another one of the differences is support for APM and SMI/SMM, which was required for Energy Star.
I wonder why VESA even bothered with VESA local bus
Because there was a big market for it, I’d say. VLB was out there in 1992, circa two years before PCI, much simpler and cheaper. Performance wise, I don’t think PCI offered any advantage over VLB. Software could barely see any difference between ISA a VLB, which made the VLB rollout that much easier.
Don’t get me wrong, PCI was a good thing, and it was not tied to a specific x86 processor like VLB. But VLB was a real solution for real problems of the time.
Only one year, not two.
VLB was a great solution for a couple reasons:
– It was a lot cheaper than PCI, EISA, or MCA and required significantly less supporting chipsets on the motherboard.
– Most logic was pushed onto the card, so the cost of a complex high performance card like a bus-master SCSI adapter was reflected in the card price.
– It required little or no BIOS changes and no device driver changes either. From the software perspective, it just looks like fast ISA.
– It did not try to implement plug and play, which was implemented in a ham-fisted way otherwise (MCA required starting from a floppy disk and then swapping with an option disk, for example).
– It was limited to 2 or 3 cards which was not a major limitation (the 486 PCI board shown only has 3 PCI slots). A typical user would just have 1 VLB card for video, somewhat analogous to AGP years later. 2 slot operation would usually be something like a high performance SCSI card or a multi-IO card.
– It achieved maximum theoretical performance of a 486. Since basically every computer being shipped was a 486, this was a benefit.
– It paired an ISA connector which meant reengineering existing ISA cards was a lot simpler, versus the significant engineering effort to make an MCA or a PCI card.
You could outfit a 486DX2/66 with a nice VLB motherboard with L2 cache, a high performance graphics card, and a bus mastering BusLogic SCSI card for around ⅓ the cost of a PS/2 Model 95 with equivalent performance. And the setup and drivers would be significantly simpler. And you could use commodity ISA cards for things like a sound card or even a second monitor.
All very good points. I will also add that for the same reasons, VLB was very useful for onboard graphics (and, much less common, networking or SCSI). The graphics chip could just sit on the CPU’s data bus, with no additional logic making things slower and more expensive, and such graphics chips were widely available.
I believe that in some laptops, VLB graphics survived well into the PCI era because basically PCI didn’t solve any problem there.
Also because Intel didn’t join the laptop chipset market until the 430MX.