Oldskooler Ramblings

the unlikely child born of the home computer wars

Archive for the ‘MobyGames’ Category

The first 256-color game on the IBM PC

Posted by Trixter on October 1, 2017

In April of 1987, IBM announced the PS/2 line of systems. This was their advancement of the PC standard, but also an attempt come up with a new architecture that could not be cloned without paying a license fee. Of the new features announced, one of the most significant was the addition of MCGA, which created the 256-color mode 13h that we are so familiar with today. VGA was announced at the same time, which emulated all previous color standards including MCGA’s mode 13h.

This background is necessary to answer the following question: What was the first 256-color game on the PC? This was posed recently on a vintage gaming group on Facebook, but it’s a loaded question because it isn’t specific enough. It could mean any of the following:

  • What was the first PC game to use MCGA’s 256-color video mode (ie. mode 13h)?
  • What was the first PC game to use mode 13h to display more than 16 colors onscreen simultaneously? (Many early MCGA games physically used mode 13h only to reproduce the existing EGA/Tandy 16-color graphics the game shipped with, instead of taking full advantage of the extra colors mode 13h provided.)
  • What was the first PC game to fully take advantage of mode 13h to show (nearly) 256 colors onscreen simultaneously?

The aforementioned facebook group conversation devolved into relying on memories and friendly arguments. This is always dangerous, because our minds are not static records. To get an answer out of memories, you need a very large group of people coming to a consensus; even then, that’s not guaranteed to be the correct answer, just an agreed-upon answer. (Some historians would argue that collective memory is the only record that matters, but a discussion of archiving history is out of scope for this article.) In that facebook conversation, and previously reported in various places like Wikipedia, the answer was 688 Attack Sub. The latest executable file date in that game is 1989-03-04. (For reference, all dates in this article are of the format YYYY-MM-DD). That seemed a little late to me; tech adoption moved a little more slowly back then, but even still, it seemed odd that it would take two years for the first game to come out to take advantage of a new graphics standard. Was 688 Attack Sub really the first to support the 256-color mode provided by MCGA and VGA?


Thanks to MobyGames and various archives floating around the internet, we can perform actual research to answer these questions, instead of relying on memory and friendly arguments (which is what the facebook conversation eventually devolved into). I co-founded MobyGames for many reasons, but the biggest reason was to answer questions like this, so I immediately took up the task. Here was my methodology:

  1. I started at MobyGames by looking up all games that support VGA and MCGA in the years 1987, 1988, and 1989. Because MobyGames contributors are awesome, all of the search results provided screenshots, so it was easy to weed out any game that claimed VGA/MCGA support but was just displaying the same EGA 16-color graphics the game already had. In other words, for a game to be considered truly taking advantage of mode 13h, it had to display something other than the stock 16-color EGA/Tandy palette.
  2. I then analyzed screenshots to determine the number of unique colors in the screenshot. This was mostly used to determine if a game was actually displaying more than 16 colors, or just showing 16 and changing the palette via VGA color registers.
  3. Once I had a list of candidates, I then grabbed all revisions of the games in question and compared file dates of the executables, and used the latest file date as a “supported here first” date. (This is not the same as the game’s release date, ie. the date that the game was distributed by the publisher — those are much harder to verify due to lack of archived software publishing trade information, and besides that’s not the question I’m answering. I’m answering “who was first to support the tech”, not “who got their game into customer’s hands the quickest”.)
  4. Finally, I discarded everything after 1989-03-04, the executable file date of 688 Attack Sub, our known control point.

Here’s what I found, in chronological file date order:

1987-06-08: Thexder‘s earliest shipped revision shows a date of 1987-06-08 on a file named MAINPS, which is the executable overlay that provides “PS/2 graphics support” (ie. MCGA, ie mode 13h). This was surprising to learn, as I assumed Sierra’s AGI games would have supported it first, but the first AGI games to support mode 13h to display graphics of any sort have VG_GRAF.OVL file dates of 1987-11-16 or later. Thexder uses mode 13h to display graphics using 16 custom colors chosen to approximate how the game looks when running in its “best” mode, EGA 640×200.


1987-12-16: Rockford: The Arcade Game displays 32 colors onscreen at once. (32 is significant; see Conclusions at the end of this article for an explanation.)


1988-02-04: DeluxePaint added support for MCGA 256-color graphics in a version with an executable file date of 1988-02-04. While this isn’t a game, it played a large part in mode 13h support in games afterwards.


1988-10-05: Dream Zone uses digitized 16-gray-shade graphics as part of gameplay, then managed to eek out using one additional color when drawing the interface, for a total of 17 colors onscreen. This game is included here not because it is a serious contender in our research, but rather because it was the earliest PC game I could find that used digitized graphics that also used the MCGA palette registers to create a custom color palette — or, at the very least, used any of the default 256 colors that are created when mode 13h is initialized. (This beats out Moebius on the PC which has a later executable date.) Dream Zone is also notable in that it was created by the founders of Naughty Dog when they were 20 years old.


1988-10-15: F-19 Stealth Fighter rasterizes the 3-D graphics using mostly the same 16 colors as as EGA during action gameplay, but when playing the game using MCGA, it uses the extra colors to draw the cockpit graphics using many color shades. This brings the number of colors up to 52 onscreen at once in typical gameplay.


1989-03-04: 688 Attack Sub starts off with a 210-color title screen and then uses many colors throughout gameplay: The Soviet control room (also pictured below) uses 73 colors; other screens produce a 16-color interface while an additional 16-element grayscale digitized picture is also shown; all elements of gameplay use a custom palette.



Based on the above, let’s answer the questions we originally posed:

  • What was the first PC game to use MCGA’s 256-color video mode (ie. mode 13h)? Answer: Thexder.
  • What was the first PC game to use mode 13h to display more than 16 colors onscreen simultaneously? Answer: Rockford: The Arcade Game.
  • What was the first PC game to fully take advantage of mode 13h to show (nearly) 256 colors onscreen simultaneously? Answer: 688 Attack Sub.

Historical Context

Based on the above research, and my personal experience during this time period (if my own memory can be trusted), I can expand on these results with a little historical context. Consider this the “trivia” section of the article.

The “VGA” support in Thexder is truly MCGA support; this is reflected in the name of the graphics overlay, MAINPS, the PS part referring to mode 13h support as “PS/2 graphics” before the rest of the industry just started calling mode 13h “VGA graphics”. But if VGA also supports mode 13h, why don’t you see MCGA graphics when running Thexder on VGA systems? This is because the game is programmed to prefer EGA graphics over other display standards. Thexder’s native graphics are 640×200 in 8 colors as ported over from the original NEC PC-8801 version, which the developer emulated by running the game in EGA 640x200x16 mode. The developer felt the game looked best in its original graphics, so it shows the game that way on any system that can support EGA — and early PS/2 systems didn’t support VGA, only MCGA. So, the only way you can see the MCGA code/colors kick in is if you run it on an IBM PS/2 Model 25 or Model 30-8086, the only systems with MCGA graphics. If you don’t have one of these systems, you can force MCGA graphics to kick in by making a copy of your disk and then copying MAINPS to MAINEG, which will replace the EGA graphics code with the MCGA graphics code.

Rockford: The Arcade Game uses exactly 32 colors. Why is this interesting? Because it shows that the graphics were composed on an Amiga (most Amiga games were 32 colors), and instead of downconverting them to 16 colors like most PC ports did in the 1980s (see Airball for a typical example), the developer decided to support mode 13h so that all 32 colors could be displayed exactly. (Interestingly, the Amiga version of Rockford was released after the PC version.)

F-19 only barely supported mode 13h. It was a nice touch to draw the instrument panel using 32 shades of gray, but this is the only place in the game where additional colors are used. It serves the letter of the law, but not the spirit of the law.

688 Attack Sub makes use of DeluxePaint fonts on all versions of its title screen, which means it used DeluxePaint during development. Also, an earlier demo of the game while it was still being developed (date is 1988) shows that it originally did not support 256-color graphics. Was support of mode 13h in 688 Attack Sub considered only after a paint program existed they could use to create such graphics? Hopefully John Ratcliff, Michael Kosaka, or Wilfredo Aguilar can clarify the development timeline.


I referred to 256-color mode as “mode 13h” because that’s the exact MCGA video mode in use for all games listed above. Later games used VGA’s flexibility to create 256-color modes in higher resolutions, or with multiple video pages, or split-screen, etc. but these were truly limited to VGA, and didn’t show up until 1990 or later. So I chose the exact technical term because it defined a consistent scope to use for comparisons. (If you want to do your own research down the rabbit hole of “What was the first game to tweak VGA into new video modes?” then you can use MobyGames to start that journey.

All of these answers are to the letter of the law, but not necessarily to the spirit of the law. In my completely subjective and unscientific opinion, the first PC game to truly show off MCGA with 200+ colors on every single screen is Mean Streets (because most of the screens were digitized in some way). Coupled with crude video sequences, and the ability to run at a decent speed on an IBM PS/2 Model 25, it’s a great early game to show off what MCGA was capable of.

MobyGames information may not be complete for the time periods researched. Given the nature of recording history, it may never be complete. If you feel I missed something, please contribute the missing game(s) to MobyGames so that future research can be more accurate.


Posted in Gaming, MobyGames, Vintage Computing | 6 Comments »

Journey’s End

Posted by Trixter on April 21, 2013

I was part of the first wave of people tackling the gigantic task of preserving personal computing gaming history in the early 1990s.  (I suppose pirating software in the 1980s counts too, but scanning materials and interviewing people began, for me, in the 1990s.)  Without connecting to others or knowing what was out there, I started to hoard software and hardware where financially possible and appropriate.  I collected software I considered hidden gems, that should be given their due in some public forum before being forgotten.  I grabbed many Tandy 1000s and other early PCs to ensure various works could be run and studied.  I was an original member of the abandonware movement.  I wrote articles on how to get old software running on modern machines, and contributed to software that did the same.  I co-founded the world’s largest gaming database so that information about these works could be consumed and researched by millions.

I did this all before Y2K.  When you’re the only guy shouting in a crowd, you tend to look the lunatic, and that’s pretty much how most of my friends and family saw me.

Look around the preservation landscape today and much of what I was working towards for years has come to pass.  There are many vintage hardware and software museums, both physical and virtual, including some dedicated to gaming.  There are some wonderful emulators that get closer and closer to the real thing each year.  There are even some curated collections online.  (There are many more curated collections offline, orders of magnitude larger than what is online, but in a decade or so I believe these will move online as well.)  Most importantly, there are established communities that support these efforts.  All in all, I’m pretty happy with how things have turned out.

Looking around all of my possessions inside my home, I see the fallout of what I was trying to accomplish many years ago.  I see no less than five PCjrs, three identical Tandy 1000s, three identical IBM PC 5150s, and multiples of Macs, Apples, C64s, and Amigas.  I see crates and bookshelves and closets filled with hardware and software.  I see clutter where there should be a nice desk for displaying a computer in a respectful way, or an easy chair for reading or watching TV.  It’s too much.  It’s time to let most of it go, and focus like a laser on the things that are the most important.  I will be disseminating most of my collection, both software and hardware, in the following year.

What I will continue to do, however, is archive and preserve software, as there is still a ton of IBM PC software from the 1980s that has not yet been released into the wild.  I am also committed to creating the “sound card museum” project I keep threatening to do.  To those ends, I will retain a few systems that will allow me to achieve both of those goals.

So, I’ll still keep buying and collecting vintage software — the difference is, I won’t retain the software after preserving it.  Consider me a vintage personal computing clearing house.

Posted in Family, Gaming, Home Ownership, Lifehacks, MobyGames, Software Piracy, Vintage Computing | Tagged: , , | 11 Comments »

If you focus your energy like a laser, you can do anything!

Posted by Trixter on December 13, 2009

It has taken me decades to understand my own behavior.  Saving you the lengthy self-analysis, I can sum up most of my actions as a reaction to negative stimuli.  No control over my social environment?  Learn to program computers, who always do what I say.  Can’t afford games?  Get a job at the local software store, then learn to crack and courier warez.  And so on.  Most of my hobbies can be traced to events like this.

So what happens when the negative stimulus is gone?  It depends on the hobby.  I don’t pirate (new) games; like movies, I can now afford to purchase or rent them.  I’ve stopped collecting hardware and software because I no longer have a need for the comfort and security that familiar things bring.  As I get older, I find I am finally able to let go of everything that gave me short-term benefits but led to longer-term detriment (collecting software is easy; collecting hardware takes up a ton of space!)

Finally, some of my championed causes have come to fruition and matured:  MobyGames remains the only organized, normalized database of computer and videogames, run by many volunteers.  MindCandy 1 and 2 have taken a small slice of hidden skill and wit and preserved it forever.  DOSBOX exists, and does a (nearly) fantastic job of making DOS games playable, and my efforts combined with others have gotten the games out there.  I’ve made some of my friends laugh with my programming ideas.  That’s a lot of personal accomplishment for someone who has to put family first and work first, and I’m happy thus far.

So.  The time has arrived to shore up and buttress the hobbies.  Here’s the Trixter 5-year pledge, to me as much as to you, in order of project start date:

  1. Finish up MindCandy 3.  Four hours of home theater showcase material on tasty Blu-ray (DVD too).  It’s 80% done and should be ready by March or April.
  2. Complete The Oldskool PC Benchmark, a project I’ve been tossing around for a while.  I’m unhappy that no PC emulator is cycle-exact for any model, not even known fixed targets like the 5150/5160, so this benchmark should help emulator authors get that taken care of.  It will maintain a database of systems that have been tested, so that users and authors of emulators can target a specific model to run programs in.  As each system I own is benchmarked, it will be donated back into the collector community, save for a handful of machines that I need for further development work (see below).
  3. Gutting and rewriting MONOTONE.  Adding features people actually need (like volume and frequency envelopes, or an interface that doesn’t suck ass) as well as a few only I need, like flexible hardware routing.  Remember, kids: You’re never going to wow the pants off of people unless you can drive seven(*) completely different soundcard technologies all at the same time.
  4. Bootable diskette PCjr demo, using the PCjr’s enhanced graphics and sound.  Hopefully presented at a euro party.  You best step aside, son.
  5. Build the Soundcard Museum, another project I’ve been tossing around for quite a while.  (Now you see why MONOTONE enhancements came before this.)  This will take up many months of free time, but I promise it will be worth it for the soundcard otaku.
  6. …and that’s it.  I have nothing else planned.  If they’ll have me, I’ll return to working at MobyGames, with maybe another MindCandy project in the works, if the project doesn’t run out of money.

And between all of these projects, I will play longform games that I’ve been meaning to get to (Mass Effect, Red Faction: Guerrilla, Fallout 3, etc.).  Because I’m good enough, I’m smart enough, and doggone it, people like me.

A keyboard exclusively for programming in binary

Air-cooled coding keyboard for professional use

(*) It is technically possible to put a Sound Blaster 1.0/1.5 (CMS+Adlib), Bank Street Music Writer card (essentially a PC Mockingboard), LAPC-1, IBM Music Feature Card, and SCC-1 into a Tandy 1000-series computer if you take the cover and metal frontplate off to allow room for the full-length cards and configure the LAPC-1 and SCC-1 so that they don’t share the same port and IRQ.   That’s six technologies — the seventh is the Tandy 1000 itself, with its SN76496 3-voice squawker.  If I had a 5161 expansion unit for the 5160, I could become more evil — it adds 7 additional ISA slots to the 7 already in the 5160.  I’d lose the 3-voice Tandy, but the additional slots would allow for adding up to three more IBM Music feature cards and an additional Sound Blaster Pro 2.0, and maybe even an additional SCC-1 (I’d have to check what settings it supports).  But I don’t have a 5161; they’re ludicrously difficult to find complete.  And besides, once you have two SCC-1s in a machine, what is the point of driving anything else?

Posted in Demoscene, Digital Video, Gaming, Lifehacks, MindCandy, MobyGames, Programming, Vintage Computing | 11 Comments »

Using A Sharper Stick

Posted by Trixter on November 22, 2007

I met with Brian the other day to help out with some MobyGames infrastructure activities and we rekindled the idea of allowing video submissions. These could be actual videos of gameplay, or video reviews, or commercials… but before we work all that out, we have to work out how feasible it is from a technical standpoint. Which gives me yet another excuse to toy with video :-)

Before we posed our own internal technical questions, I decided to try to figure out how YouTube was encoding their videos, so that we could have a baseline to work from in terms of user expectations. The viewing public seems to accept YouTube as generally “watchable”. If MobyGames were to implement video, it would have to be at least as decent as YouTube.

So we’ve got a few questions to answer here: What video and audio codecs is YouTube using? What parameters (approximately) is YouTube using to encode video?

Thankfully for me, my friend Mike Melanson has already answered most of these questions: It’s Flash video, using Sorensen Spark (h.263 with some limitations) for video and MP3 for audio. To determine the encoding parameters, I grabbed a few .flvs from YouTube and ran “ffmpeg -i myvideo.flv” to see what ffmpeg could glean from the file format, and it identified the audio stream as 22050Hz audio, 1 channel (mono), at 56kbps. But it couldn’t identify the video stream other than to tell me it was indeed using flv’s limited h.263. I asked Mike how he thought it was being encoded, and also what best practices were.

“No idea; I’m not really that much of an encoder guy.” Luckily, I am.

The first thing I wanted to determine was how the bitrate control was. Was it quality-based or bandwidth-based? I encoded two test videos, a simple one (few changes per frame) and a complex one (many changes per frame), both one minute in length. (By the way, I noticed a few people other than Mike and myself doing this, with names from the innocent “video quality test” to the unabashedly-named “ffmpeg FLV encoding raw audio mux test”.) After letting YouTube encode them, I sucked the end results back and immediately it was apparent that the encoder was bandwidth-based because both file sizes were identical. If it were quality-based (“constant quantization” for the encoding nerds out there), the simple file would have been substantially smaller.

After figuring this out, of course I had to determine what that constant bitrate setting was. After some manual binary partitioning trials, I narrowed it down to 240kb/s. Matching youtube’s 56kbps mp3 audio and encoding my originals, a setting of 240kb/s for video resulted in nearly the same filesize as the encoded YouTube .flvs.

I was happy with this until I actually viewed my encoding results, which looked substantially worse than YouTube’s files. It took a few more viewings of the “simple” example before I noticed that the YouTube video had a very long GOP (group of pictures). Meaning, a very long time went by before the entire frame was repainted with a keyframe. In my trials, my keyframe was changing every 15 frames; that’s twice a second @ 30fps. Since intraframes (keyframes) are much larger than interframes (frames where only the differences are stored), this was eating up my bandwidth, and visual quality suffered. I was able to determine YouTube’s intraframe interval by staring at a static section of the “simple” file, hitting a stopwatch when it changed, then hitting the stopwatch again when it changed again. I measured 8 seconds, which is 240 frames @ 30fps. Setting the GOP to an interval of 240 frames, my encoded files now matched YouTubes’ results. For the video encoding nerds out there, I can even see some of the same DCTs being used in the same places :-)

If you want to reproduce YouTube encoding yourself, possibly to see how your encoded video will look on YouTube without waiting for the upload+processing, grab yourself a command-line version of FFMPEG and use this syntax:

ffmpeg -i (inputfilename.whatever) -s 320x240 -b 240kb -ab 56kb -ar 22050 -ac 1 -g 240 (outputfilename.flv)

I’m sure it’s not 100% complete, but it certainly gets you 98% of the way there.

Will MobyGames improve on this? Most likely. For one thing, I didn’t agree with the decision of limiting everything to mono sound. For the typical YouTube talking head over laptop speakers, it makes perfect sense, but for stereo video game music or positional sound effects, it doesn’t. I was also not happy with the video quality at 240kb/s because, for fast-moving sources like FPS games, everything becomes a blocky mess. We will also probably come up with some convention (read: Encode It Yourself Dammit) for frame sizes over 320×240, like games that run 640×480 and are simple (ie. have very little motion or changes between frames). One of the “obvious” optimizations that turns out to be not so obvious is 2-pass encoding to spread out the bits more optimally, but this was only a benefit (in my tests) for complex sources. It actually made simple/static sources more blocky in the static parts.

After all this discovery, I was bothered by something. Check YouTube’s parameters again:

  • 240 lines (framesize is 320×240)
  • 240 kbps (video bitrate)
  • 240 frames in a GOP

I’m a big fan of Occam’s Razor, but I was depressed to apply the Razor here because, after doing so, it sure seems like the YouTube guys were taking blind stabs at encoding parameters (ie. “Hey, let’s set everything to 240 and see what happens!”).

Posted in Digital Video, MobyGames | 14 Comments »