Slashdot Mirror
The 1991 "X-Box"
Jim Hall writes "Back in college (1991), I wondered why no one had bothered to make a DOS-based game console.
One day, in the back of a notebook, I made some notes about how you might go about creating a DOS-based game console. (I even called it an "X-Box", but really the "X" was there because I didn't know what else to call it. Microsoft's current "XBox" console is completely different, and I don't claim any rights to the "X-Box" name.)
I've posted some scans of my notes, and a discussion about how you would create a DOS-based game console."
Full text below.
... my then-girlfriend's (now, wife's) brother had two of them. And of course, I had an Atari 2600 when I was growing up.
.BIN ... can we hack to use different extension?) which is the game. If audio CD, runs music player program.
...) We could create an SDK that turns those into "P1_UP", and so on.
... a 386SX-40. Yeah, no mathco, but still a nice box. I think I had a whopping 4MB of memory, too. I played a lot of DOS games on this 386, and was the first box that ran Commander Keen.
... at the time, I was a big Microsoft junkie. (I'm much better now, thank you.) And a ton of games were being written for MS-DOS, so what better platform to build a game console?
... in fact, you find a lot of games at the time specified a minimum of MS-DOS 3.3. So we're okay there.
... those are the cheesy "bleep bloop" sounds you probably remember so well.
... something about how a similar PC-based game console might be built. Basically, it's given me a huge insight to why Microsoft built their XBox the way they did. I understand why they implemented digitally signed media. It's the only way to make $$ on these consoles. You need to be able to guarantee that what runs on the XBox was compiled against your SDK, and then you license the SDK.
The 1991 X-Box
I went to college in the fall of 1990, and by Spring semester 1991, I was enrolled at the University of Wisconsin-River Falls. I lived in the dorms, and in hanging out with my other friends I began to notice the popularity of game consoles. It seemed like every third dorm room in my building had a Nintendo in it. I'd seen consoles before
But my game interests were with DOS-based games of the time, such as Commander Keen. Even Commander Keen 1 was better than most of the games available for the Nintendo, at least as far as I could see. So I wondered why no one had bothered to make a DOS-based game console.
One day, in the back of a notebook, I made some notes about how you might go about creating a DOS-based game console. (I even called it an "X-Box", but really the "X" was there because I didn't know what else to call it. Microsoft's current "XBox" console is completely different, and I don't claim any rights to the "X-Box" name.)
Page 1 (1299x1712, 136k)
Shows a diagram of a controller, with 4 directional buttons + 4 game buttons (A, B, L, R) + 2 system buttons ("Opt" and "Start").
Sends events to console using keyboard events. (What about using 2 Gravis game pads on the game port?)
Game saves: 1.44MB floppy
System boot: flash memory system (C:) - 2MB?
Games: CD-ROM (also plays music)
2 controllers enter system through keyboard combinator. (Looks like keyboard.)
Always boots from C: (never from A: or D:). After boot, DOS displays some game system logo, then waits for CD-ROM event. At CD-ROM load, checks for certain directory structure to determine if game disk. Then exec's XBOX.EXE (or
SDK defines P1 and P2 input [the controllers], and game exit chains exec back to main system program. SDK's init should determine if this is a game system.
Need program to format floppy.
Page 2 (1299x1712, 268k)
Diagrams of how to assemble and organize the console hardware, including an inventive way to install the peripheral cards at an angle to save vertical space.
Page 3 (1299x1712, 244k)
SDK:
Save game files should always be in the format game ID.001 (iterate).
What can we do to enforce this? API to list, save, and delete save games? Maybe only list/save, and only allow delete from the main program?
init() will check that this is a game system, and chain back via exit() if not.
SDK has #define's for keys: P1_UP, P1_DOWN, P1_LEFT, P1_RIGHT, P1_A, P1_B, P1_L, P1_R, P1_OPT, P1_SEL, and again for P2.
How to keep people from running just any DOS program from the game console?
My friend Larry and I had planned this out. Larry had a huge interest in electronics and had the idea of the keyboard "combinator" device. It solved a lot of problems. In addition to sending one "keystroke" to the output at a time (emulating a keyboard) you were free to use non-keyboard input, and the combinator would be able to translate that into keyboard output. As long as the output was a key from a keyboard, it didn't matter ("A", "$", "9", "Keypad_3",
Shortly after that, I dropped the idea. I was pretty busy in classes at the time, and didn't have a lot of time to devote to thinking about such side projects. But could such a design have actually worked? More to the point, could you build it at a reasonable price? And if you did build it, would people buy it?
CPU
First, you have to start with the microprocessor. In 1982, Intel released the 286 Microprocessor. The 286, also known as the 80286, was the first Intel processor that could run all the software written for its predecessor. This software compatibility remains a hallmark of Intel's family of microprocessors. Within 6 years of it release, there were an estimated 15 million 286-based personal computers installed around the world. What hamstrung the 286, though, was that they messed up multi-tasking. Really, they implemented a nice task-swapping feature, but hardly the same as true multi-tasking.
In 1985, Intel sold the 386 Microprocessor. The Intel386 microprocessor featured 275,000 transistors--more than 100times as many as the original 4004. It was a 32-bit chip and was "multi tasking," meaning it could run multiple programs at the same time. That's what I had in my PC
In 1989, Intel released the 486DX CPU Microprocessor The 486 processor generation really meant you go from a command-level computer into point-and-click computing. The Intel486 processor was the first to offer a built-in math coprocessor, which speeds up computing because it offloads complex math functions from the central processor. That was the fastest-available CPU that you could get in 1991.
If you were going to build a DOS-based game console in 1991, you might try to build a 486 system at a cheap price. Although at the time, a 386 system might have been less expensive, and as a startup game company the 386 is probably more realistic. Let's assume a 386.
DOS
I hadn't created FreeDOS yet, although you can guess that I was pretty "into" DOS. MS-DOS was the flavor to run
By 1990, MS-DOS would have been ROMable, so you could have had MS-DOS boot from a ROM on a console system, the same as MS-DOS booted from ROM on certain laptops. The recent timeline for MS-DOS at the time looked something like this: Version Date Description
3.30 PC-DOS April 1987 For PS/2 series, 1.44 meg support, multiple DOS partition support, code page switching, improved foreign language support, some new function calls, support for the AT's CMOS clock.
3.31 MS-DOS November 1987 Over-32 meg DOS partitions. Different versions from different OEMs (not Micro$oft). Compaq and Wyse are most common.
3.40 PC-DOS - 1988 Internal IBM - not released (4.0 development).
2.11R MS-DOS - 1988 Bootable ROM DOS for Tandy machines.
4.00 PC-DOS August 1988 32mb disk limit officially broken, minor EMS support, more new function calls, enhanced network support for external commands. PCjr support dropped.
4.01 MS-DOS December 1988 Micro$oft version with some bugfixes.
3.21R MS-DOS September 1989 DOS in ROM, Flash File System for laptops.
3.3R MS-DOS - 1990 DOS in ROM, introduced for TI laptops.
5.00 MS-DOS June 1991 High memory support, uses up to 8 hard disks, command line editor and aliasing, 2.88 floppies, ROMable OEM kit available.
So while MS-DOS 5 was on desktops everywhere by Summer 1991, the easiest way to put MS-DOS in a game console was to burn it to ROM. So for this DOS-based game console, we'll have to use MS-DOS 3.3R. But DOS games still run great on MS-DOS 3.3
Video
Any game console is worthless unless you can pipe the output to your television set. Most normal GUI environments of the time (think MS-Windows) would do 640x480, or even 800x600 if you had a good system. Unfortunately, you can't expect your television to show the same quality as a VGA monitor. Your television can do only about 320x240.
Also, you have the problem that your television doesn't do VGA. It uses NTSC. By its nature, NTSC is a single wire transmision system. It minimaly has luminance (brightness) information for black and white. It has a fixed horizontal frequency of about 15.7khz with a vertical of 60hz. VGA cards just cannot do this. VGA controllers seem to have a low limit of arround 30khz for hsync. For color NTSC things get tricky. The RGB is encoded as 2 subcarriers in quadrature to eachother each 3.58mhz above baseband. There is additional 3.58mhz signal that must occur during sync. This is called the "burst". To prevent beat frequency artifacts on the screen you should adjust the vertical to the color standard of 59.94hz.
So, would a DOS-based game console been impossible? Not really. These days, it's pretty easy to find a video card that supports TV-out. But in 1991, such video cards weren't so common. Or were they?
I didn't investigate it at the time, but with the USENET archives on Google I was able to do some research. In 1995, video cards that supported TV-out were high-end cards like: S3 ViRGE, Rage All in Wonder, Rage Fury, Canopus, 3dfx Voodoo 3 3000, and G400 Max.
So one solution is to supply the game console with one of these cards. That might be expensive, though. The cheapest ISA card I was able to find was a "Multi-Mode EGA/CGA/MDA(TTL) / NTSC (RCA/composite)" for $50. And EGA is right about where we want to be, to match the resolution of a television set.
Is there another way to get NTSC video at higher resolutions? Yes, but it would have cost more.
At the time, there was a gadget called "Game Blaster", which you could pick up at places like Egghead for about $150 (???). It seems to convert VGA to NTSC video. That's just what our system needs.
Also available was a device called "PC2TV". It was $189 and well worth the money. It will also output to S-VHS (the Game Blaster will too) which makes a huge difference in picture quality and contrast. It also needs no driver under 640x480 at 60hz. PC2TV is also true color, and the Game Blaster is not. It will also do 800x600 with some ET400 cards.
So I guess the answer is: yes, you could have had a VGA to NTSC converter at low res (acceptable for DOS games) for less than $150. But the DOS games available in 1991 were typically EGA, so a first-generation game console would be better off to stick with EGA, and let the next-generation console extend into VGA.
Sound
Sound is important. Even the Atari 2600 had very basic sound
From Google newsgroups, the earliest mention of the Soundblaster card was Sep 25 1990, and in 1992 the SB was sold for $75. So in 1991, you should have been able to get a sound card for a reasonable price.
Games
No game console can succeed unless it has games to support it. At the time, I don't think I realized the importance to a console maker of having game exclusives. But ah well. Let's at least look at what DOS games we had around 1991.
The first-person shooter titled Wolfenstein 3D was originally released for DOS in 1992 by ID Software. So this would have been a good title to run on a DOS game console, but that's too late for our system.
Let's just look at it for a moment, though. Would Wolfenstein 3D have been a good console title? Oh yeah - There was also a Super Nintendo version of Wolfenstein 3D released; it was a cross between the PC and Mac versions. For example, the flamethrower and rocket launcher from the Mac version are present as is the ability to sneak up on enemies from the PC version. Unfortunately, it was extremely censored through the changing of the guard dogs into rats and removal of the Nazi symbols. But if you had the uncensored game available for a game console, it would have been kick-ass!
So what would have been the killer game to release on a DOS-based game console? I've already mentioned it: Commander Keen. On December 14, 1990, Episode 1 of Commander Keen forever changed PC computing. Commander Keen was id Software's first big game, and along with the original Duke Nukem (released in 1991), Apogee Software was recognized as the place to go to for hot, shareware games.
Even better, all of the 7 Keen games out there are EGA titles, and Keens 4-6 also had a separate additional CGA version produced. Although CGA looked like purple shit.
Price
So, let's take a moment to add up the components that we've assembled so far: Item Price
Intel 386 CPU + motherboard $399
IDE/floppy/serial controller $70
1MB memory $5
1.44MB floppy drive $30
CD-ROM drive ??
Flash ROM C: drive $20
MS-DOS 3.3R runtime license ??
Multi-Mode EGA/CGA/MDA(TTL) / NTSC (RCA/composite) video card $50
Soundblaster card $75
Of course, these are estimates, but they seem to be pretty good ones.
The Competition
Could such a DOS-based system have been competitive with other game consoles of the era. It's kind of late now to think of "might have beens" but this is an interesting one. Let's compare this "X-Box" to the other consoles of the time:
In 1985, Nintendo started to sell the U.S. version of Family Computer Nintendo Entertainment System (NES) in America. The system included R.O.B. (Robotic Operating Buddy) and the games Duck Hunt and Super Mario Bros. Mario and Luigi became as big a hit as the NES. However, in 1989, Sega stepped in to take their piece of the pie. They released Sega Genesis, a system with a 16bit computer that could produce better graphics than the NES.
So in 1991, Nintendo introduced the 16-bit Super Nintendo Entertainment System (SNES) along with Super Mario World and released it in the U.S. The SNES was one of the most powerful 16-bit consoles. The SNES used an extremely powerful graphics coprocessor able of generating real-time effects like scaling and transparency. The SNES immediately it raised the bar for video game designers around the globe. Featuring true stereo sound, multiple scrolling backgrounds and almost twice the internal memory as its competition, the SNES was home to the biggest, baddest games of its day. The original SNES set, with two controllers and Super Mario World, sold for $200 when it was first released. In a few months, the price dropped, as all console systems' prices do after initial release, to $150.
To be a player, this "X-Box" game console would have had to retail for $200 or less. The price list above has a total retail price of $650. But that's retail. How much would you have been able to buy all that at wholesale price? I don't really know, but in cases like this the "rule of 2" seems to get me pretty far. So we'll assume wholesale would be roughly half the cost: about $325. And that doesn't even cover the cost of the game controllers and the R&D work to create the combinator circuit and custom "A/V out" cabling.
And you have the MS-DOS license fees. I don't have a price for MS-DOS in 1991, but Digital Research Inc. released DR-DOS 6.0 in 1991 for $100. So you might assume MS-DOS was around the same price, since DR-DOS needed to stay competitive. If you use the "rule of 2" you may have been able to license MS-DOS for an embedded system for $50 or less since this would be sold in high volume, not a few at a time.
But the game console business is pretty cutthroat. Even today, game consoles almost never pay for themselves. You sell the system at a loss, and make up for it from SDK license fees. I even saw that back in 1991. So to sell this X-Box at $200 would mean a loss of at least $125 per box. That's pretty steep. You'd have to become an overnight success to justify that kind of loss. With launch titles such as an "X-Box" exclusive full version of Commander Keen, and some other hot DOS titles, you would have had a fair chance. With id's release of Wolfenstein 3D a year later, a DOS-based game console would have been the killer system. But it's still a huge gamble.
On top of that, PC hardware is very expensive if you need the specs to remain completely static over a long run. Game consoles like the Nintendo and today's PlayStation are able to absorb their R&D costs over a long product lifecycle. Basically, because they control the technology behind the system, the consoles actually become less expensive to produce after a few years. Now let's jump back to this "X-Box". When the Pentium is released, try asking Intel to still produce 386 hardware in quantity. If you don't have the same speed CPU in there, games that work well on the original "X-Box" might become unplayable when the CPU speed doubles. You might offset that, though, by running a TSR that slowed the system down to compare to the 386 CPU. Just don't interfere with the games. In any case, that adds up to extra cost, whether you get Intel to continue producing 386 CPUs or if you use software. This "X-Box" becomes more expensive to produce after a few years.
So it's probably a good thing I never went any further with this "X-Box" idea.
Building it today
(note done yet)
I went to Pricewatch this morning, and vaguely looked at some current prices to build a decent game console today. Comparitive prices have come down quite a lot since 1991. But I didn't really do a full pricing on the thing. Maybe I'll look into it later.
One thing I didn't mention in my page (but maybe I should add it?) was that if you're going to build a game console, the case really can't be any bigger than a VCR. I think Tivo is about the size of a VCR. If it's any bigger than that, people will think it's too much like a PC stuck on top of your TV, and they won't buy it. The Morex Cubid 2699 looks about the right size, but of course it wouldn't have been available in 1991. See also the ATC-600 case.
Microsoft's XBox
(not done yet)
Since putting up this web page, I've been thinking about writing a related article
Microsoft did make a mistake on the XBox controllers, though. They made huge controllers, probably designed by someone with huge hands. Their controllers are about as big as a grizzly bear.
nope, the "DX" in the 386 was different than in the 486 line. the 386SX used a 32 bit core but communicated to the system and memory through a 16 bit bus. the DX had a true 32 bit bus to system and ram. for a math coprocessor for either you needed to install a 387.
as you know, the SX and DX designations on the 486 line signified the presense of an onboard coprocessor.
http://robotiq.com/content/1.html
Nothing strange to see here, move along...
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
386DX = 386 with full 32 bit front-side bus
386SX = 386 with 16-bit FSB
486DX = 486 with math coprocessor
486SX = 486 with math coprocessor disabled
487SX = 486 with math coprocessor and slightly different pinout so it wouldn't work in the 486SX/DX socket, and which disabled the 486SX at startup
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I'm pretty sure the 386DX (with a built-in math copro) came out before the 486.
The DX tag did not indicate the presence of an on-chip math coprocessor. The 386DX is different from the 386SX because the 386SX has a 16bit address bus and thus a lower pin count and cost. Both could support a math coprocessor, but this required at motherboard with a socket for an 80387(SX *or* DX). The 386SX was introduced in 1988.
This guy says that according to USENET archives, the Voodoo 3 was available in 1995? umm no
I was wondering about that myself. I just recently retired my two Voodoo3 3000s, and when I got them in 1998 they were top-of-the-line.
And, the Voodoo with TV-Out was the 3500, not the 3000 that he mentions.
Hell, in 1995 I believe 3D cards were of the "pass-thru cable" variety -- I don't think any 2D/3D combo cards were even out yet. The original Voodoo might have been out, but certainly not the Voodoo3...
And I don't believe TV-Out was easily available except through an expensive "scan converter"...
Anyway, much of what he says is conflicting even with the other things he says, and then there are a few technical and chronological problems.
I won't say it's bullshit, but I am pretty skeptical (not to mention X-Box -- I don't think people called a PC a "box" back then, and he has no real reasoning for having come up with the name...)
NGWave - Fast Sound Editor for Windows
My thoughts exactly. The author is either misinformed, has an extremely bad memory, or is making it up. As for which I believe to be true, well, those papers look a little too well preserved to have been created in 1991 IMHO (how many of you keep doodlings you made 12 years ago?).
:(
CD-ROM drives in 1991 were OUTRAGEOUSLY expensive, as were sound cards. Flash ROM? In 1991? Affordable? Please...
An EGA card that can also output NTSC video (whether s-video or composite) would have been unheard of, namely because there wouldn't have been any point: EGA cards could do 640x200, but only in black & white (1-bit color). They could do up to 16 colors (4-bit color) in a different video mode, but only at 320x200. Yeah, that's right, 320x200, not 320x240. Oops, did somebody just get caught?
And the Voodoo 3 3000 was most certainly NOT available in 1995! Perhaps some cards based on the Voodoo 1 chipset, but the Voodoo 3 chipset wouldn't hit the scene until the late '90s.
The 286 had multitasking and protected mode, just like the 386. The real problem with it (as opposed to the "problem" the author states) was that, being a 16-bit machine (although the address space had been increased to 24-bit), it still had to use segments to be able to access all of its address space, and to handle programs with more than 64K of code and data.
As for the 286 being the first Intel processor that was backwardly compatible: no. No no no no no. The 8086 was "backward" compatible with the 8088 (in fact, they were exactly the same, except for the 8088 sacrificed some speed to cut down motherboard costs by only having 8 data lines instead of the 8086's 16, but made up for it (which is where the slowness comes in) by doing two reads in succession), the 80186 (yes, there was a 186, but it sold very poorly) was backwardly compatible with the 8088 and 8086, etc.
As for the SNES, both it and the Genesis probably had about equal market penetration. The SNES had better RPGs IIRC, but the Genesis had better sidescrolling action & platform games thanks to its faster processor. Yeah, the SNES had Mario, but the Genesis had Sonic The Hedgehog, Jurassic Park (the Genesis version of Jurassic Park was light years better than all the other versions and even had better graphics too; not coincidentally, the Genesis version was made by a different company than the one that did all the other versions), Vectorman, etc. "The SNES had the biggest, baddest games of its day." Not quite. When it first came out, most of the games sucked. Even for games where the same company made both a Genesis and an SNES version, the Genesis version was usually better. Take a look at Earthworm Jim if you don't believe me. It wasn't until games like StarFox and Donkey Kong Country came out that the SNES started to reach critical mass, but even then it always carried Nintendo's "kiddie" reputation thanks to the boatloads of games with cutesy characters (Mario, Yoshi, Kirby, etc.) that Nintendo churned out. Genesis remained the hardcore gamer's platform of choice for many years.
I'd like to think that this guy is just badly misinformed or looking at the past through a set of (highly revisionist) rose-colored glasses, but my honest oppinion is that he made this up. I could understand calling it System X, Console X, etc., but X Box? Howww conveeeenient...
To add to the info someone else replied with, the 387 mathco was indeed a separate chip, and entirely optional. Most 386DX machines didn't have one.
~REZ~ #43301. Who'd fake being me anyway?
MS-DOS is an operating system. Since no Atari system has ever run it, nor did the Colecovision (correct spelling), those systems aren't DOS systems.
Pedantic perhaps, but in the interests of accuracy I should point out that Atari did have a line of IBM PC-compatibles that ran DOS. Here's an example of one.
Commodore, another name know primarily for its proprietary systems also made its share of PC clones.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Yeah, I remember the whole 487 thing. What a scam.
Basically, the 486SX was the 486 with the math co-processor disabled. Motherboards at the time often had an extra socket for a math co-processor in case you wanted to get one but didn't want to pay for a whole new CPU that had one on-chip.
Intel's math co-processors for the 386 (all of them on a separate chip) were called 387s. Since Intel made two versions of the 386 (the DX and the cheaper but slower SX), they decided to make the 486 have two versions too, and again used the DX/SX suffixes.
The 486DX had an on-chip math co-processor, whereas the 486SX did not (or so Intel told everyone). They decided to make a separate math co-processor for the 486SX, and called it the 487SX.
What Intel didn't tell anybody was that, IIRC, the 486SX actually did have an on-chip math co-processor, but it was merely disabled. Additionally, they didn't bother to tell anybody that the 487SX was actually a 486DX (the one with the math co-processor enabled) that just had a different pin layout than either the 486DX or 486SX.
What's more, when installed as a math co-processor (which was the only option, the different pin layout meant it wouldn't fit in either a 486SX or 486DX slot), it merely disabled the 486SX, taking over its job, and acted like the 486DX that it actually was (CPU + math co-processor).
Later we would see the 486DX2, 486DX4, etc.
Fujitsu did it. It was called the FM-Towns Marty and was only in Japan. Powered by a 386, and later a 486. Had a healthy collection of Hentai Games. You can even run Linux on it!
SX2/DX2 = 486 SX/DX with internal clock doubling. The DX4 was not an Intel product, AMD only. If memory serves me correctly, it could run as a clock-quadrupled 25MHz product or clock-tripled 33MHz product.
So, the DX-50 was 50MHz internal and 50MHz external; the DX2-66 was 33MHz external and 66 MHz internal. In certain applications, the DX2-50 would outperform DX2-66 based systems, because of the difference in I/O throughput. The DX-50 was problematic with VESA Local Bus systems, however -- VLB was never meant to run faster than 33 MHz, so you would wind up overclocking the I/O and video cards.
A good compromise was the AMD DX2-80 chip; with a 40 MHz external bus I/O boards tended to be more reliable (esp QD6580 chipset based boards). In almost all circumstances, DX2-80 systems would outperform DX-50 systems.
Oh, it was fun building and upgrading systems back in those days. You really had to know your parts, since the VLB and CPU clock speeds were tied together. For that matter, upgrading the CPUs often meant having to get faster cache chips (many 486SX-25s shipped with 25ns cache -- too slow for 40+ MHz FSB!). Hell, Packard Smell systems from those days shipped without *any* L2 cache, and some of them had a really hard to dig up dirty tag chip; you'd need 8x 61256 chips, a 6164, and something else that was tough to source in small quantities..
Do daemons dream of electric sleep()?