In a discussion on a previous post, Richard Wells suggested that an ATI VGA Wonder-16, a 16-bit ISA VGA card, should be able to operate in an 8-bit slot. I can confirm that yes, it does:
ATI VGA Wonder-16 in 8-bit slot
Note that the card does not require any reconfiguration, it detects that it’s running in an 8-bit slot and acts accordingly. A wonder indeed. Continue reading
The other day I attacked an old and long forgotten 286 PC stashed away in the basement. The PC is dead because the power supply blew years ago and the motherboard has a non-standard power connector.
But the case was packed with goodies like this one:
ATI VGA Wonder-16
An ATI VGA Wonder graphics card from early 1989 (most chips made in 1988). This was one of the very early SuperVGA adapters with 512 KB video memory and support for 800×600 and 1024×768 resolutions. Continue reading
After almost 30 years, several disks with ancient builds of OS/2 surfaced. In this context, “ancient” means older than the May 1987 release of the first MS OS/2 SDK. In fact these disks are so old that the one thing that cannot be found on them is any mention of OS/2 whatsoever.
For clarity and simplicity, the operating system on these disks will be referred to as “proto-OS/2”. Why not just use whatever name the OS referred to itself as back then? Because there were too many! The naming was so schizophrenic that it’s impossible to choose. Continue reading
The default processor limits of Windows NT 3.x are surprisingly difficult to establish. Quite possibly because although SMP was a big selling point of NT, in reality only a tiny fraction of PCs in the mid-1990s supported SMP, and of those, most only had two processors.
After some poking around, it appears that the default for NT Workstation is two CPUs of all NT 3.x releases (and NT 4 as well). A notable exception is the checked build which for whatever reason defaults to four CPUs.
For the (Advanced) Server version, the default is four CPUs; however, the server uses the same kernel/HAL and to get beyond the defaults, the registry must be modified. For the server versions, the modification happens during installation.
In Windows NT 3.1, if the standard Microsoft installer finds the ProductType being LanmanNT (i.e. it is Advanced Server rather than Workstation, whose ProductType is WinNt), it adds a DWORD key called HKLM\System\CurrentControlSet\Control\Session Manager\RegisteredProcessors and sets it to 4. This is plainly visible in a file called REGISTRY.INF. Continue reading
It is common knowledge that Windows NT 3.1 only recognizes up to 64 MB RAM, unlike NT 3.5 and later versions. This statement can be found in various places, including this blog. The limitation was empirically determined by installing NT 3.1 on various physical or emulated platforms.
It is easy to accept this as a fact since it is well known that even NT 3.1’s minimum requirement of 16 MB RAM was quite high when it was released in 1993, and systems with 64 MB memory (let alone more) were practically unheard of.
Imagine my surprise when I installed the original build 511 of NT 3.1 on a 1995 Intel server board (that’s a whole another story) and saw the full 128 MB RAM being recognized. Clearly “common knowledge” is not the same as actual facts.
Finding official statements on the maximum memory supported by Windows NT 3.1 is difficult. Key information is available from Microsoft in KB117373, but with an important caveat. The KB article talks about INT 15h/E820h usage but does not mention that NT 3.1 does not support that interface. NT 3.5 does and that is in fact why it has no trouble detecting more than 64 MB RAM on typical systems. So what’s the real story with NT 3.1? Continue reading
Generic x86 multiprocessing, Summer 1994 edition. There’s not much to say:
Yep, that’s NT 3.1 running in a VM, and it sees two processors. Remember, you saw it here first! Continue reading
I recently came across hints suggesting that in the 1987 timeframe, Microsoft contemplated the use of the 386 LOADALL instruction in OS/2. As far as I know, no released version of OS/2 (including the SDK betas) utilized the 386 LOADALL.
But it got me wondering. Did anyone use it in commercial software? And which 386 CPUs support LOADALL?
To be clear, the 386 LOADALL instruction is very similar to its infamous 286 sibling but it’s not compatible (even the opcode is different). On the 286, LOADALL could accomplish things that were not otherwise possible, but on the 386 there is little that LOADALL can do that can’t be done using documented interfaces (and that retail software would want to do).
Robert Collins has an excellent writeup on both LOADALL flavors with lots of details and test programs. The article contains the following rather interesting statement: “Very few people at Intel will acknowledge that LOADALL even exists in the 80386 mask. The official Intel line is that, due to U.S. Military pressure, LOADALL was removed from the 80386 mask over a year ago. However, running the program in Listing-2 demonstrates that LOADALL is alive, well, and still available on the latest stepping of the 80386.”
So LOADALL was supposedly removed from 386s… except it maybe wasn’t. And it was top secret? Further searching revealed a surprising fact: The existence of 386 LOADALL instruction became a matter of public record no later than September 1, 1992 when Compaq’s U.S patent 5,144,551 was published. Continue reading
I’ve been trying to complete my archive of Intel SDM documents circa 2000 and later. I have most of the editions archived but a few are missing. Readers of this blog could have something stashed away too, so perhaps someone could help? I’m looking for original PDFs with no modifications, at least not obvious ones. Continue reading
While researching the history of 486s for a previous article, I came across a fascinating Wikipedia entry and its associated talk page. It’s a nice showcase of inmates running the asylum, and a reminder that Wikipedia can’t be considered an authoritative source of information because the quality of encyclopedia entries is wildly uneven. It’s not all bad, and it could be argued that the average is quite good, but there’s no minimum quality guarantee.
Even now the 486SX article contains demonstrably incorrect claims such as this: The FPU upgrade device was shipped as the i487, which was a full blown i486DX chip with an extra pin. The i487 was installed in an upgrade socket and the extra pin was either a power or ground pin that indicated that the i487 was installed. That signal was used to disable the i486SX when the i487 was installed.
Well, no—there is an extra pin, but it has no electrical function whatsoever. It merely prevents the chip from being installed incorrectly. And there is a pin (NC#) indicating that an upgrade processor is present designed to “shut off” the original CPU, but it is one of the standard 168 pins. The text conflates facts and turns them into a falsehood. The pins are publicly documented in Intel datasheets and it’s not so hard to find the actual information. Continue reading
Intel had a long history of offering retail processor upgrades for PCs. The last and by far the best known of those were the Intel OverDrive processors. But let’s start with the earlier history.
In 1987, Intel released the Inboard 386/AT, an ISA card with a 386 CPU used to upgrade existing PC/AT systems to 386s. In 1988 the Inboard 386/PC followed, a similar card for upgrading 8086-based PCs.
In 1992, Intel offered RapidCAD, a two-chip (for the CPU and FPU sockets) upgrade for 386 systems. The RapidCAD used a somewhat crippled 486 core with integrated FPU and although it didn’t greatly improve integer performance, it did significantly increase the floating-point power (70% improvement according to Intel) to overtake any discrete 387.
When Intel introduced the i486 in 1989, the benefits (for Intel) of segmenting the market with SX and DX variants were well understood. Whereas the 386DX (1985) used a 32-bit external interface and the 386SX (1988) a 16-bit one, the 486DX and 486SX were almost identical in terms of external interface. The DX variant included a built-in FPU, the SX did not.
Early i486SX Processor
The 486SX was introduced in mid-1991, and its main purpose was to compete with faster 386 systems, especially those from AMD. At that time, the vast majority of software did not require a FPU, and most software didn’t use one even if available. Although the 486 had considerably better performance per clock, a 40 MHz 386 compared quite favorably to a much more expensive 25 MHz 486. The 486SX was intended to get OEMs to roll out 486 CPUs (which only Intel produced at the time) in larger numbers, understandably at prices lower than the top-of-the-line DX variants. Continue reading
