The other day I was asked an interesting question: What was the first BIOS with support for ROM shadowing? In the 1990s, ROM shadowing was common, at first as a pure performance enhancement and later as a functional requirement; newer firmware is stored compressed in ROM and must be decompressed into RAM first, and firmware may also rely on writing to itself before being locked down and write protected.
Old PCs did not use ROM shadowing because it made no sense. ROMs were only marginally slower than RAM, if at all, and RAM was too precious to waste on mirroring the contents of existing ROMs. Over the years, RAM speeds shot up while ROM remained slow. By about 1990, executing BIOS code from ROM incurred a noticeable performance penalty, and at the same time devoting 64 or 128 KB to ROM shadowing was no longer prohibitively expensive.
But who did it first?
Researching BIOS history is quite difficult. Neither clone BIOSes nor major OEM BIOSes (IBM, Compaq, Dell, HP) are particularly well documented, and obtaining samples is tricky.
ROM shadowing requires chipset support, so I thought I’d start with looking at datasheets. Picking a few random Chips & Technologies datasheets, I established that ROM shadowing was common circa 1990, and advertised as such. The earliest C&T example was the CS8221 NEAT chipset. In 1987, C&T touted “Shadow RAM for BIOS to improve system performance” in their CS8221 data book.
On the other hand, the older CS8220 chipset from 1985 or 1986 did not offer any such functionality. Which means that in the clone PC market, where C&T was a major player at the time, BIOS ROM shadowing probably started being used sometime in 1988. It remains an open question which BIOS vendor did that first.
But what about other OEMs? It is possible that some other vendor like IBM or Compaq or ALR might have done it first. I was fairly certain that IBM did not have ROM shadowing prior to the PS/2 line in 1987, and if someone else had it, it would have been likely earlier.
I started looking at Compaq advertising materials and found no mention of ROM shadowing. I searched Compaq technical references and found no mention of shadowing whatsoever. But I didn’t stop searching because I had a vague memory that the Compaq Deskpro 386 had some kind of ROM shadowing support, at least in later iterations.
And sure enough, it did. Not only in later iterations but the very first 16 MHz Compaq Deskpro 386 from 1986 already had ROM shadowing. Except Compaq didn’t call it that.
The Compaq Deskpro 386 Technical Reference Guide from September 1986 contains the following text on page 3-5:
Of the 384 KB of additional memory available in the standard memory configuration, the last 128 KB contain a number of special addressing features. This 128-KB block, starting at address FE0000, can be relocated (mapped) via special hardware map registers to replace the 128-KB area normally assigned to the system ROMs (0E0000 to 0FFFFF). When mapped, the 128-KB RAM block normally located at FE0000 can be addressed at either FE0000 or 0E0000. The ROM devices are not accessible while the RAM is mapped to the address space normally occupied by the ROMs.
That certainly sounds an awful lot like ROM shadowing! The 1986 Deskpro 386 Tech Ref and more can be found here.
While newer designs usually control how reads and writes are treated for the ROM area, Compaq did it a little differently. Of the built-in 1 MB, Compaq mapped 384 KB just below 16 MB; some of it was usable as Compaq Built-In Memory or BIM. Compaq set aside 128 KB at the very top of the 16 MB address space to provide an alternative mapping of the shadow RAM. To enable ROM shadowing, the BIOS had to copy (typically) 64 KB of memory from 0F0000h to FF0000h and then reprogram the RAM relocation register to write-protect the RAM and map it to the ROM range.
While the original Deskpro 386 hardware was clearly capable of ROM shadowing, I was not certain if the earliest BIOS actually used it. Fortunately Jeff Parsons from pcjs.org was able to clear that question for me. Yes, the Deskpro 386 BIOS from September 1986 already enabled ROM shadowing. The feature does not appear to have been user controllable, the BIOS simply always did it.
ROM shadowing was therefore provably used in 1986 by the Compaq Deskpro 386. It is quite likely that the Deskpro 386 was the first PC with ROM shadowing, for several reasons. One reason was that the Deskpro 386 came with 1 MB RAM standard — not 512 KB, not 640 KB, but a full 1 MB. That gave Compaq the option to use some of the extra memory for speeding things up.
The other reason is that the Deskpro 386 was almost certainly the first PC where ROM shadowing made a real difference. The Deskpro 386 had 32-bit RAM, significantly faster than 16-bit ROMs. That was not the case with 16-bit PC/AT compatibles with slower CPUs, slower RAM, and a 16-bit data path to both RAM and ROM. On the Deskpro 386, the system RAM was likely several times faster than ROM, and that’s what made ROM shadowing desirable.
In the absence of other evidence, it’s impossible to prove that Compaq implemented ROM shadowing first. Circumstantial evidence indicates that it is very likely.
I don’t know if this qualifies or not, but Atari 8-bit machines would copy the code from the ROM bank in the upper 16K to the hidden RAM bank at the same address and then switch to using the RAM because access was faster.
Also, this allowed programs to use the holes in the ROM programs to store extra data, though of course that was fraught with danger if they ever changed the ROM.
Amusingly enough ROM shadowing is mentioned in the comments on your “Deskpro 386 at 30” article: https://www.os2museum.com/wp/deskpro-386-at-30/
In practice I suspect that ROM shadowing did not really become common until the DRAM shortage ended in 1989.
Though I wonder how many PC vendors were shipping PCs with 1MB vs 640k vs 512k.
So it is, but it doesn’t really even hint that the Deskpro 386 was probably the first PC to do that.
That’s interesting, I would think that the RAM was much more valuable as user accessible memory. Though I guess it couldn’t really be addressed so why not.
Do you know which machines did that? Atari 800 or so?
HIMEM.SYS (at least from DOS 6.22 and some versions of Windows 95) can automatically reconfigure a Deskpro 386 to use the shadow RAM as ordinary RAM. It’s not able to do that for any other PC.
In the newly rediscovered NABU PC, writes to the ROM address space wrote into the underlying RAM, and the the RAM and ROM were software switchable and the ROM would get shadowed into RAM at boot and then run from RAM.
See page 44, “Data Buffers and PHANTOM”:
https://bitsavers.org/pdf/nabu/Nabu_1100_Technical_Guide_1981.pdf
The Micronics EISA VL/2 board does something similar to the Compaq when ROM shadowing is enabled. It maps the shadowed ROMs to just below 16MB rendering any RAM above that point unusable unless you turn shadowing off! Not a problem for a 286 or 386SX, but it’s an issue on a high end 486 board that can take 64MB of RAM!
The machine uses a Phoenix BIOS was a circa 1988 core date. Curious for a board from 1992-93. When shadowing is turned off, its really really slow. I think the BIOS also runs the machine in de-turbo mode during POST too.
Since the Atari 800 was mentioned, the Apple II could also do ROM shadowing dating to the introduction of the “Language Card” in 1979. This was a 16k memory extension that originally was meant to let you switch between the original Integer BASIC ROM and the later Applesoft BASIC rom, basically by having 16k of RAM that you copy the ROM you wanted in and a switch to disable reading from ROM and read from RAM instead.
This language card extension became standard/built in with the introduction of the Apple IIe in 1983.
PC Magazine of June 27, 1989 lists the Dataworld 286-20 as having shadow RAM (BIOS and video) with an Award BIOS from November 1985.
Sometime, in 1986 or 87, the price of 256kb chips was lower than the price of 64 kbit chips. There was no benefit to building a computer with 640 KB instead of 1 MB unless the computer design could not take 4 rows of 256 kbit chips. It did take some time to work out how to deal with the 384 KB block of memory instead of IBM’s insistence on having extended memory only start at 512 KB intervals. Note that a few years earlier, C64 and Spectrum 128 had inefficient memory utilization because 64 kbit chips were cheaper than 16kbit chips and leaving some RAM unusable was a side effect of the money saved.
The cheap large capacity ROMs were very slow. It was possible to obtain faster ROMs but those needed more pins and cost a lot more. Anyone who suffered from sticker shock when buying a graphing calculator in the 1990s will recognize the costs of really large ROMs that needed to be somewhat fast. Many of the TI-83 and 84 models used 70 ns ROMs.
Replacing ROM addresses with RAM was fairly common with Apple’s language card being an early example. Copying the ROM to high speed was available on minis like the VAX early on. Shadowing ROM made a bit less sense on high end PCs going with protected mode operating systems that largely ignored the ROM. There were some fairly irate Usenet threads about the fact that 10% of memory was wasted on shadowing.
On the other hand, the 1988 DRAM shortages affected EPROMs a lot less.
@Michal Necasek: The 800XL, which came with 64K of RAM. You could also load a previous version of the OS into the RAM under the ROM if the software you wanted to use made undocumented calls that were no longer supported.
Two other factors:
Before DOS 5 and Windows 3 there wasn’t much use of having more than 640k, so shadowing probably seemed like the best option. Sure, there were applications and OS:es that could use extended memory (and also expanded memory) but those weren’t that common. It’s really unfortunate that the DOS=UMB, DEVICEHIGH and LOADHIGH things didn’t appear early enough. If they had been a thing earlier on I would assume that most chipsets for 286 and higher would had been able to map parts of the 384k as UMB (in addition to being used for shadowing). I’ve seen third party driver for some Chips’n’technologies chip set that would let you do this. Back in the days I had some other Chips’n’technologies chip set that unfortunately wasn’t supported by that driver. TBH I think it would had been a nice gesture to existing users if Chips’n’technologies would had released that kind of driver for all their chip set (that could support it) for free when UMB started becoming a thing.
When SIMMs (and similar packages) became the most common memory type, there wasn’t even any way to have exactly 640k.
Re the side track of 8-bit computers with more memory than the 64k the processor could address: In practice more or less all commercial software that needed that much memory would had been written in assembler or similar and thus would easily had been able to bank switch the memory.
The Deskpro 386 could use the extra memory for a disk cache and/or CEMM (later known as EMM386). I’m pretty sure the ROM shadowing was done because the RAM was much, much faster than ROM.
A 20 MHz 286 with ROM shadowing sounds very plausible. But such a system with a BIOS from 1985 does not. A typo? Misprint?
And yes, large/fast ROMs are expensive. I’m sure it was a major factor in the cost of wavetable sound cards; those 1/2/4MB ROMs had to be somewhat fast.
With the original Deskpro 386 there was no way to add even 16 MB, so their scheme made some sense. In a much newer system that supported far more than 16 MB… yeah that’s strange.
What was the max for the original Deskpro/386? IIRC there is a RAM expansion card that in turn takes smaller cards with iirc 1M or 4M each. Can’t remember if there is space for four such smaller cards, or if there is space for three and 1M is soldered directly to the large mother board? If the latter is the case, then 13M would be the max, otherwise not.
But either way – is all memory above 1M always decoded to the special Compaq memory thingies or is it technically possible to use a 16-bit ISA card to add memory? If the latter is the case, then it would be possible to add 16M. Any collision with the built in 384k part wouldn’t matter though, as the decoding can’t access both the built in fast memory and ISA memory at the same time unless the timing is slow enough for ISA bus cycles.
Btw, why did all those sound cards have the sounds stored in ROM? Would any sensible person use them on a floppy-only system or on a system with a hard disk that wouldn’t have enough free space?
(As someone who used Amigas before using any PC sound card, everything with sound cards in PCs seems so backwards until the point in time when everything were done in ram and software (in the computers main processor and/or on some type of DSP on the sound card). Sure, on the oldest slowest PCs a typicak “8-bit” style sound card like the Adlib with a synthesizer chip makes sense, but later on it would had been better if the sound cards would just play a few channels of digital audio using DMA from the computers main memory. That is how all sound playback worked on the Amiga. (Well, almost, I think that you could technically turn off DMA and have the audio hardware repeat two samples, so you could generate a square wave without the DMA. You could probably also write data to the output registers by hand. This doesn’t really count)).
Re ROM speeds though – I don’t think that 32-bit ROM chips were ever made, so a 386DX would had required at least two chips for the ROM to appear as 32 bit wide. Not 100% sure but I think that ROMs from that time might had been able to keep up without wait states. 16-bit ROMs did exist though, but I don’t know what the price would had been if they even existed as EPROMs. In general it seems like it was only a few computer manufacturers who put their firmware in actual ROMs. I think IBM mostly did this, and Commodore for sure did this simply due to them owning their own semiconductor manufacturing so using EPROMs for anything mass produced wouldn’t had made sense.
As a side track, at the time it would probably not had been clear that software in general would use the BIOS for much in the near future. Had OS/2 or something similar caught on early on then the speed of BIOS calls wouldn’t had mattered that much.
The Amiga was a special case. The Paula chip had direct access to Chip RAM to pull samples from. The ISA bus was too slow to stream instruments for wavetable use and RAM was added cost (although the AWE32 came with 512k DRAM standard). Including a base ROM set was handy though since game vendors didn’t need to clutter disks with samples.
Perhaps the most useful thing about shadowing is using that upper 384k for UMBs as mentioned. “The Last Byte Memory Manager” supported a ton of pre-Pentium chipsets, while UMBPCI supports more recent stuff. Those UMBs are pretty special though. Don’t try doing DMA operations to them on most chipsets!
Macronix had a 32-bit mask ROM with good access times. The chip was provided in a 70 pin package. Those interested can find a datasheet for the MX23L3222. There may have been other 32-bit mask ROMs but those are not listed in the references I can find.
AST released the Premium 286 in late 1986 which supported EEMS. EEMS should provide for ROM copying into RAM. AST has a lot of tech bulletins involving how shadow ram works but nothing that proves if the first Premium used the technique. The second generation Premium (286-12) is listed as having shadow RAM.
For many systems, the alternate use of 384 KB as 64 K HMA and 320 KB disk cache would be better than using it to shadow the ROMs.
Shadowing was also used in non-PC embedded systems, but I dont know if this was common practice or just done with my example:
I’ve drawn the schematics and disassembled the 8051 code of a industrial display controller years ago.
This was a small system using a 8051, a huge CPLD and one of those SP14Q002 displays along with a (crappy) touchscreen.
I’ve just searched through my notes, but can’t find that stuff anymore. I think it’s gone, so this is from my vague rememberings.
Normally the 8051 has different data and code spaces. There was a thing where you could connect the PSEN (“Program Storage Enable”) pin somehow with RW lines and very little logic to store code in dataspace and execute from there.
A lot of monitor programs for the 8051 did that for development, also.
This display controller had a 8kB ROM and 64k RAM. The RAM was banked in 16k increments and the first 16k were always accessible for code and font storage.
Upon booting the ROM copies itself (at least partially) to RAM, gets font into right location and fills the RAM with a test pattern. It jumps to RAM code and from now on there is no more access to ROM. I’ve verified by pulling the ROM chip after it has booted.
I’ve never totally understood what they did, also because I dont know what the CPLD exactly does. I stopped disassembling when I understood the overall working.
If I understood correctly, the banking mechanism was to implement a double/triple buffer.
One for incoming display pages, two for quickly switching between them. The incoming buffer was always copied to one of the others when the command came in via serial. This seemed to me like a show-stopper as copying takes a huge amount of time. Why not write to a currently not shown buffer and then just switch banks?
I’ve seen this 8051+CPLD+display combination a few times, always related to industrial controllers used by German compancy “krones”.
I think either their first design worked like this or one of their key-engineers loved this principle.
Yes, many wavetable cards used Macronix ROMs. I assume the 32-bit data path did a lot to even out the relatively slow access times.
Any idea what chipset the AST Premium used?
Totally agree that the shadow RAM can be used better on many systems. Of course when the Deskpro 386 came out, there was no high memory, no XMS, no UMBs. And 640K was still a decent amount of memory.
The original Deskpro 386 came with 1 MB RAM on board and that could be expanded to 2 MB. It was possible to plug in one 32-bit memory expansion board, and the biggest was 8 MB. It was therefore possible to have up to 10 MB fast 32-bit memory. Yes, it was also possible to add slow 16-bit memory on the ISA bus of course, but that couldn’t go over 16 MB in any case.
As for sound cards — the samples had to be on the sound card, so the card had to have either ROM or RAM. And there were RAM-only cards, like the Gravis Ultrasound. But the samples did take quite a bit of disk space (by early 1990s standards), and the required software added a lot of complexity for end users.
The classic WaveBlaster compatible add-on modules were effectively MIDI-connected musical instruments. Many of the designs were something that might be found in a standalone MIDI module with no hard disk and no OS. The samples had to be in ROM, and once you have that, RAM is pointless. Technically there was no reason why a WB module couldn’t have RAM, an some did, but the MIDI interface was quite slow, so uploading 1-2 MB of samples was impractical.
I don’t think the RAM was vastly cheaper than ROM, and if the vendors wanted to only use RAM, they had to ship disks to end users, with both the samples and some kind of software. Which may not have been any cheaper in the end, and it was definitely harder to use for end users.
The samples-in-RAM case would seem to resemble a GUS.
The MX23L3222 datasheets I could find has a first release (ver 1.8) of 1998. Maybe there’s a gap in the record, but that seems late to be an option for an AWE32 or Deskpro 386.
There were x16 EPROMS from the mid- to late-80s, at least the 27c1024.
The AST Premium 286 used a Chips & Technologies with a Phoenix BIOS. The FASTRAM memory cards used by AST had a lot of additional components similar in number to those found on the Rampage 286 thus the support of EEMS may not have been in the C&T chipset yet. The FASTRAM cards had an extra connector which allowed them to conduct 32-bit memory access once the 386 upgrade card was added.
Compaq, especially with the Deskpro, was aiming for maximum performance with little consideration to cost while AST was trying for better performance while keeping to the same price range as other AT clones. Compaq’s management came from TI and TI was obsessed with the fastest memory possible.
UMBs did exist and were used in 1985. EEMS would have been useless if it wasn’t taking advantage of UMB even if the name wasn’t in use yet. HMA was in the future but the use of extended memory for a disk cache was known. Disk caches really became useful once the 128 KB FATs were introduced. Keep the FAT in cache and read ahead of the track would net most of the possible performance gains.
Bitsavers has the IC Master data books which cover many different chips including the various speeds and capacities for ROMs. The ones at Bitsavers end with the 1984 release but that should provide a benchmark as to what was available when AST and Compaq were doing their designs.
Those 32-bit ROMs were maybe mid-1990s, definitely nothing that existed in the Deskpro 386 times. If you look at Deskpro 386 photos, they used the standard technique of wiring two 8-bit ROM chips in parallel. In theory they could have wired four of them together but I can only assume that shadow RAM was preferable for various reasons.
Shadow ROM does make a performance difference in 32-bit OS/2 when running virtual DOS machines. This was pretty important for most users.
In the OS/2 1.x era, shadow ROM was even more important, since the DOS boxes would rely on a CPU reset and running the ROM POST every time it timesliced to the DOS box. The 80286 PS/2s all shadowed ROM (and there wasn’t an easy way to turn it off, either). OS/2 relied on this for patching ABIOS bugs, too, as it would directly replace sections of ROM.
Later PS/2s came with a very cut down BIOS that couldn’t do much except access a diskette drive or fixed disk and run the display. It would load the bulk of the BIOS from a hidden partition on the first (SCSI) fixed disk. Presumably IBM did this to save on the cost of large ROM chips.
For the completely opposite approach, look at early Macintosh computers, which came with humongous ROMs that got as big as 4MB and did not shadow at all. (The first Mac had a 64k ROM and 128k of RAM, somewhat comparable to an IBM PC, and admittedly much more functional.)
@Richard Wells: You could utilize all 64 kB on the C-64 and many commercial software titles (especially games) did so by banking in RAM instead of the KERNAL, BASIC and character ROMs as they had no need for them.
Putting in 64 kB was both a practical choice (it was easy to wire up 8 chips * 64 kbit DRAM chips as each was responsible for one bit of a byte, rather than trying to assemble a motley combination of 16 and 32 kbit chips to achieve 48 kB for example) as well as a marketing and a future proofing one (while DRAM was pricey in the early 1980s when the C-64 was introduced, prices were falling fast and within a couple of years the price was peanuts).
The point about large/fast ROMs being expensive was certainly still a factor in the early 90s with the SNES, where companies would skimp on manufacturing cost and insist on using SlowROM (which was clocked only at 2.68 MHz) instead of FastROM (3.58 MHz). Rebecca Heineman ran into this problem when porting Another World (Out of this World) to the SNES, and ended up running her polygon renderer inner loop out of the SNES graphics chip’s (PPU) memory mapped registers (altogether you could fit 32 bytes of code in there), which were clocked at 3.58 MHz even though the CPU could only read instructions from the ROM at 2.68 MHz. Crazy stuff.
vince: One thing worth noting though, is there was absolutely no benefit to exactly shadowing ROM on an Apple II, as ROM was the same speed as RAM.
(However, if you had an original Apple II (with Integer BASIC ROMs), and didn’t have, say, Programmer’s Aid #1, you could load Apple’s Integer BASIC image which had it, and switch to that.)
Chris M.: Hey, my employer was shipping new models of machine with a copyright 1988 Phoenix BIOS as late as 2018, I believe. (Maybe 2019?) Granted, only as the CSM, running on top of a modern UEFI, but they were using it directly on the metal in the Core 2 era.
bhtooefr: The Accelerator IIe had 80KB of RAM installed with 16KB used as a language card so the system could access 64K of RAM and the other 16KB being used to shadow the ROM BASIC for maximum performance in BASIC. A truly strange and expensive device but sadly the performance wasn’t much better than the caching accelerator cards that used the Apple II’s original RAM and ROM.
I was working at Zenith Data Systems in the late 1980’s/early 1990’s and we definitely did it (and advertised it as a performance boost / differentiating feature). Cant remember the exact models.
Garrett says:
>In the newly rediscovered NABU PC
Speaking of NABU. Turns out NABU terminal was designed by Benny Lau, one of ATI co-founders.
“Oral History of Benny Lau and Lee Lau” by Computer History Museum https://www.youtube.com/watch?v=tajOAUl2xsE
“I went to a company called anti-com which at that time they were acquired
by a bigger company called Nabu which they developed they were ahead of
their time they were actually developed developing a terminal and that is
a computer that hooked up to a the cable through a cable modem so the idea
was that there wasn’t any internet at the time so they were they have this
idea of oh how about like that the head end of the cable company they
store all the news and stocks quotes and games that people if you buy this
terminal hook up to your cable and you can download this game news and
whatever and then you can then play with it and use it
so I developed that
terminal for them and like they are they basically almost like the shell
company they acquire a lot like say they acquired a company in ottawa that
specializes in making cable modem and anti-com specialize in designing
computers so they acquire all this company with expertise in different
pieces and they put them into together to provide to provide such a service
but the problem with the company at that time was they they spend money as
quickly as they they raise the money the company the little company has
about 40 something vice presidents i don’t know why when they go to a
convention in toronto they send 40 vps so they’re burning money like crazy
so so uh at that time my my like my manager and some of the people at
anticon they decided to quit”
What is not really mentioned in this whole discussion, is that there’s very little actually useful software in PC ROMs. DOS was loaded from disk (except in some early PC luggables that had it in ROM), and therefore in RAM. Video BIOS was in ROM (INT 10H), but wasn’t used that much except for mode-switching, and speed of gfx memory was more important to the performance than the code itself. Disk access code was in ROM as well (INT 16h), but disks are so terribly slow, that the speed of the software definitely didn’t matter. So I really somewhat doubt whether shadowing your ROM on a PC mattered that much, if at all. And as for earlier 8-bit machines, in the late 70s and early 80s, ROM was actually _faster_ than RAM, so shadowing ROM in those days was rather counter-productive (also RAM was way more expensive back then).
It mattered because benchmarks published in magazines measured things like the performance of the video BIOS for outputting text and scrolling. You may think it’s silly but PC buyers of the era did not, and since they were the ones spending money, their opinion mattered, and yours did not 🙂
In the era we’re talking about (late 1980s) RAMs were faster than ROMs, and more so in systems like the Deskpro 386 where the RAM data path was 32-bit and ROM only 16-bit.
I don’t know if ROM shadowing makes a difference for any applications, but it definitely speeds up POST.
Kilian Hekhuis:
Afaik the BIOS ROM was used quite a lot for basic text mode video output.
Sure, any full screen applications probably used their own code to write directly to the video memory, and I would assume that ANSI.SYS would also replace the bios video display code, but still?
—–
side track: RSS indicates that there are additional comments that I’m not seeing :O
Weird. Now that I’ve already posted I can see the posts that I couldn’t see a second ago, and of course they already contain what I wrote but with better wording 🙂
The Compaq was aimed at a workstation market. A lot of Fortran code used the BIOS functions so a test run was limited by the speed of the BIOS text output. Easy marketing technique since with a lot of old mainframe code, a 386 was so fast that most of the program run time was in the print routines. Conversely, with some precise timing BIOS routines, shadowing the ROM would prevent correct operation.
Multitaskers benefited from having BIOS copied into RAM.
To respond to the comment above that ‘before DOS 5 extended/expanded memory wasn’t very useful because few programs used it’ that’s simply not true. It was pretty much essential for Lotus 1-2-3 especially when using graphs, I’d be reasonably certain (but can’t remember) if Wordperfect used it, and it was definitely used by a number of games. Not to mention Windows earlier than version 3.11.
640KB became an issue within quite a short space of time, and expanded or extended memory was the only game in town before DPMI came along, and protected mode operating systems were the norm.
Agreed. Especially expanded memory has a long history and it was very widely used, and yes WordPerfect could use it too.
While more than 640 was useful in some cases before DOS 5 and whatnot, my impression is that it was only in certain special cases that users had more than 640k. It’s probably similar to having a maths co processor, a great thing in certain cases but something most users probably didn’t have.
Don’t mix 640K and EMS. Expanded memory existed long before 640K RAM was standard. In fact because EMS so old, there were various schemes mapping variable amounts of EMS between motherboard RAM (often 256K to 512K) and 640K.
Yes, in some ways EMS was like an FPU. If you need it, you really need it, and it’s worth the extra investment. Because it makes the difference between getting something done quickly and getting it done very slowly or not at all.
From what I’ve been able to find, Michal is correct about the CS8220 chipset not being able to support “shadowing”; I examined its datasheets and found nothing related to the topic. The CS8221 (“NEAT”) link Michal referenced has many “BIOS shadowing” hits; see page 44, “Shadow RAM Feature”. There’s also the “CS8230: 386/AT CHIPSet” from 1988 with more details on how this is done. I had asked the question of Michal but also here: https://forum.vcfed.org/index.php?threads/what-was-the-first-pc-bios-that-copied-itself-from-rom-into-ram.1242734/ [I agree with Michal’s comment: “Neither clone BIOSes nor major OEM BIOSes (IBM, Compaq, Dell, HP) are particularly well documented” in relation to the history of BIOS code from the first that did CMOS and then “shadowing” and every later feature; not earlier IBM PCs of course.]
In fact, I tried to contact major BIOS companies (mostly a ‘bust’) after discovering that NONE of them have any kind “history” of what they did in the past! Unlike Intel, which has many pages about their ‘milestones’ and advancements in computing, BIOS code at times seems like trying to get the NSA to admit to whatever really great “tools” they had invented in the past… knowing only about them due to “leaks” on the Dark Web!
I was able to contact Phoenix Technologies, but no one there seems to have ever even thought about writing a history of all the ‘features’ they introduced in the past; only what will _sell_ today! I was actually advised by someone there to contact INTEL for more information! So, we’re left to ourselves to piece together whatever we can from advertising pages of various ‘Clones’ and old tech manuals, etc.
That’s just sad. And the worst part is that it’s not even very surprising.
Most corporations have amazingly bad institutional memory. Things they did 20-30 years ago simply do not exist anymore. There are exceptions, like IBM and Intel, at least to some extent.
Reading through the Compaq manual Michal linked to, I found that one of the reasons it would be impossible to turn-off the “shadowing” into RAM is because Compaq used at least one (probably more?) ROM location (F000:FFE0) to store how much Memory the unit had; which of course could only be changed by the BIOS code in RAM. That’s on page “4-25” (PDF page 227/359) discussing its “Built-in Memory Data Structure”.
On a different topic: It appears at first to be an outright error, where it states about “Power-on System Initialization” (page “4-22”), “Upon reset, the system begins execution starting at the reset address FFFFF0h. This address corresponds to the entry point of the power-on system initialization code in the system ROM.” Whereas according to all the INTEL docs for an i386, that should be just below 4 GiB; not 16 MiB. Did Compaq do some hard-wiring on the motherboard? Or is this only referring to where they “shadowed” the ROM? On page “2-64” they have: “The ROMs are addressed via the 16-bit bus at address F00000h. An image of the ROMs is doubly mapped at F80000”. Yet the map on page “3-5” shows the ROMs as if they were physically located at addresses under 1 MiB. Apparently, this manual only refers to the physical ROM chips with addresses they are seen as having AFTER the i386 goes into its initial “Real Mode” (switching from FFFFFFF0H to only FFFF0H), but then uses full 16-MiB addresses when it talks about where it shadows the ROM to. HOWEVER, the PC comes with only 1 MiB of Memory on the board, so is some of that 1 MiB of RAM “mapped” to high addresses just under 16 MiB? I’m still somewhat confused.
I should have added above: We know that the Intel 80286 CPU at RESET fetches its first instruction “from absolute address FFFFF0H,” so I can’t help but wonder if Compaq’s writer thought the i386 did the same; unless there’s a 386 CPU I’m unaware of that also did so?!
The 386 certainly fetched from absolute address FFFFFFF0h, not FFFFF0h, although it could be a leftover from Compaq’s earlier 286 specific manuals. Looking at figure 3-7 on page 3-10 of the original Deskpro 386 Tech Ref, it’s obvious that the motherboard memory connector had 32 bit data lines but only 24 address lines. Most likely the high byte was ignored for memory accesses, which would mean that after reset the CPU did really access memory at FFFFF0h in effect.
An yes, some of the RAM below 1MB was in fact remapped just below 16MB, that was Compaq’s BIM aka Built-In Memory. See figures 3-2 and 3-3 in the Tech Ref which show how the memory was mapped when the machine was configured for 640K or 512K base memory, respectively.
Thank you for clearing things up about how Memory was addressed on the DeskPro 386 motherboard. It was basically a ‘yes’ to my question “Did Compaq do some hard-wiring on the motherboard?” but due to NOT including all the address traces! If effect as you noted causing the i386 CPU’s machine code with any address just below 4 GiB such as the FFFFFFF0H I mentioned above to instead reference FFFFF0H on the motherboard.
More importantly for this article: Everyone should read this page at PCjs:
https://www.pcjs.org/machines/pcx86/compaq/deskpro386/rom/
in which its author was able to discuss the Compaq DeskPro 386 with some of the engineers who created it and the ROM code! And in regards to “firsts” in relation to the PC Industry, searching for “timelines” may also be helpful, such as, Ken Polsson’s “Chronology of Personal Computers” from just after WWII (1947) to 2010 using 2,672 references (mostly magazines): http://kpolsson.com/comphist/