Oldskooler Ramblings

the unlikely child born of the home computer wars

Archive for the ‘Gaming’ 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?

Research!

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.

Thexder-MCGA-mode


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.)

Rockford-title


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.

DeluxePaint-256


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.

Dream-Zone-brother-room


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.

f19-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.

688-Attack-Sub-Title688-Attack-Sub-Soviet

Conclusions

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.

Disclaimers

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.

Advertisements

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

The failure of the Dreamcast

Posted by Trixter on March 22, 2017

The Dreamcast had a very short life; officially less than 3 years, although it felt like 4 because the Dreamcast continued to be sold in the US after it was officially discontinued.  I was recently part of a discussion where someone asserted that piracy was the major contributing factor to the failure of the Dreamcast, and I disagree.  The Dreamcast failed to achieve long-term acceptance, in my opinion, primarily because of the competition of the PS2.

The PS2 followed a long, very successful run of the PS1 and had more pull with Sony fans (Dreamcast sales dropped sharply in the USA when the PS2 USA launch date was announced).  Additionally, the PS2 was backward compatible with PS1 games, and was also a DVD player, both of which were very appealing.  Finally, some major developers and publishers did not support the platform (most notably Electronic Arts and Squaresoft), having been burned by Sega’s mismanagement of various aspects of prior consoles (such as announcing the Saturn early, which killed 32X sales, and also by the Saturn being very difficult to write code for due to its use of multiple processors).

If you were a brand-agnostic consumer with a choice between the PS2 and the Dreamcast, and you were trying to figure out which one was more special, you had a choice between a console that could play games on the internet (something only computer gamers cared about in 1999), or a console that could play hundreds of the previous generation’s games as well as DVDs. That was a one-two punch that the Dreamcast could only overcome through brand loyalty to SEGA, and it did so, admirably, for 3 rough years. Piracy was a problem for Dreamcast only after the Dreamcast was already on its way out, not the other way around.

I don’t view the Dreamcast as a complete and utter failure, but rather as a console that had a shorter-than-expected lifespan.

Posted in Gaming | 4 Comments »

Beyond Economic Recovery

Posted by Trixter on January 11, 2016

The phrase “Beyond Economic Recovery” is one of my favorite phrases because it succinctly describes how to determine if you can safely share an old program, manual, game, etc. online.  Please note that safe != legal.  It is always illegal to share things you don’t own and you are responsible for any repercussions if you break your country’s laws.  This post isn’t about whether it is legal.  This post is about whether or not you should be overly worried that you will be pursued by some IP holder’s legal department and sued into the ground.

This would be a good time to mention that I am not a lawyer, and this is not legal advice.

Unless you are a large-scale pirating operation already under government investigation, what usually happens when infringement is discovered is that the infringing party is notified through a cease and desist letter.  Quick compliance with the terms of the letter is almost always enough to avoid further action.  But what if you are on a Quixote-like mission to share this rare vintage content with the world and really, REALLY want it to stay publicly available?  That’s when you apply The Phrase.

“Beyond Economic Recovery” isn’t my phrase; it was uttered to me in more than one interview I’ve had with lawyers on this specific subject.  Here’s how to use it:  Let’s say you want to share a 30-year-old game on the web for others to grab.  If you’re worried about legal repercussions, perform some due diligence and research if the company is actively using the work (the code, its trademarks, its intellectual property, etc.) to earn money, or has immediate or announced plans to do so. If so, such as in the case of Super Mario Brothers, don’t share it. But if not, as in the case of something like Space Strike, you have almost nothing to worry about.  When a company is made aware of infringement (usually discovered via automated google searches and machine learning), they perform a quick check of whether or not they would lose money sending the infringing party a cease and desist letter.  The average cost of a C&D letter, accounting for all time and services rendered, is roughly $4000.  If the company has an internal legal department or prepares communication in batches (or both), that number can be a little less, but it’s still thousands of dollars. So the mental check is essentially “Can we make more than $4000 on the asset or intellectual property this person is threatening to dilute by giving it away for free?” If the answer is “no”, they don’t bother sending a C&D letter.

The Internet Archive enjoys both non-profit status and various DMCA exemptions, which allows them to make various historically-relevant software works available online — but a DMCA exemption doesn’t prevent companies from sending them C&D letters to protect their trademarks or intellectual property.  (It also doesn’t succinctly define what is covered under the exemption, as it uses words like “obsolete” without defining what time period “obsolete” refers to.)  Some works that used to be public on the IA have since been hidden at the request of the IP holder.  For everything else that is still public there, The Phrase is the principle that “protects” those software portions of The Internet Archive; they are simply Beyond Economic Recovery.

Posted in Gaming, Software Piracy, Vintage Computing | 1 Comment »

Comedy gold in the Handy specification

Posted by Trixter on August 12, 2015

The Atari Lynx is my favorite handheld console.  Planning and design started in 1986, long before the Nintendo Game Boy, but development took long enough that it was actually released half a year after the Game Boy.  Whether or not that makes it the first or second handheld console is up for discussion, but it was definitely one of the first two.

History shows that the Lynx had an unsuccessful run compared to other handheld consoles of the time, which includes the Game Boy, Game Gear, and TurboExpress.  Lynx’s failure in the market was split fairly evenly between three culprits:

  1. Price: $179 vs. Game Boy’s $100
  2. Battery life: It took 6 AAs to power the unit for only 4 hours
  3. A lack of compelling licensed or original titles

The first hardware revision was also somewhat large, but as a guy with large hands, that never bothered me.

There were some killer arcade ports to the Lynx that really showcased what the system was capable of, such as Road Blasters, Stun Runner, and Klax.  But these were ports of Atari games; Lynx never got the “big” licensees such as Mortal Kombat or Street Fighter (a double shame considering the Lynx supported true hardware multiplayer linkups).

I recently sought out the Lynx hardware specification so that I could reminisce, sadly, about all of the untapped power Lynx had that was never realized.  The Lynx was so powerful that it shamed other handhelds for nearly a decade after it was discontinued:

  • 4096-color palette
  • Unlimited sprites with scaling, clipping, and collision (multiple modes!) all performed in hardware
  • 4-channel stereo sound supporting both algorithmic and sampled waveforms (in other words, it could play both pure-hardware chiptunes and Amiga mods)
  • Multiplayer cable connections up to 8 simultaneous players/units
  • Supported left-handed play via the ability to flip the screen

There were other cool bits for the time it came out too, like a limited 32-bit math-coprocessor (used for some true 3-D polygon games like Hard Drivin’ and Steel Talons).  It wasn’t perfect; the system would slow down if you pushed it too hard (too many sprites, too many sampled sounds playing simultaneously), but it was creative and ambitious.

The Lynx started life as a hardware project by Epyx, initially called “Handy” (because it was to be the first handheld console).  Ex-Amigans RJ Mical and Dave Needle were involved in the design, which is why Handy feels like a tiny Amiga.  The initial specification was written in June of 1987 by Dave Needle.  Reading through it, two things are immediately evident:

  1. The designers of Handy had a passion for creating a fun device with as many progammer assists as possible
  2. Dave had a wry sense of humor

I will now reproduce for you some of the comedy gold hiding in the Handy specification.  I’ve truncated some sequences for brevity, but the words are all Dave’s:

The human input controls consist of a 4 switch (8 position) joy stick, two sets of 2 independent fire buttons, game pause button, 2 flablode buttons. power on, and power off….Flablode is a Jovian word meaning a device or function that we know is required or desired but for which we don’t have an actual definition (noun: flabloden, verb: to flablode).

3. Software Related Hardware Perniciousness
(or why some software people hate some hardware people)

There are certain things that the software ought not to do to the hardware. While these things are not physically destructive on their own, they will cause the hardware to act unpredictably strange, which may cause the user to be physically destructive. While we certainly could have protected the system from many of the following problems, I doubt that we would have found them all. In addition, the act of software doing one of these things means that there is a problem in the software anyway and the intended function would probably not happen. Additionally, this is only a toy. If this unit were a bio-medical device I would have found a safer solution.

3.1 Don’t Do These Things.

If you do any of the things that I tell you not to do, the hardware will act unpredictably and will not be expected to recover without a complete system initialization. So don’t do them.

3.1.5 Palettes and Page Breaks

This one is an actual hardware bug of mine…(much technical info removed)…Pen index numbers C,D,E, and F will be incorrectly unchanged. Sometimes I am such a jerk.

3.2 Please Don’t Do These Things.

There are also things that software people do that merely annoy the hardware people rather than annoy the end user. This includes seemingly harmless activities like sub-decoding bit values from byte descriptions (sprite types, for instance), or assuming address continuity between areas of hardware…Please don’t do them. It would be difficult to list all of the possibilities, so I will list the general considerations and ask you to be sensible about them. In addition, please feel free to submit a request for an exemption-on a specific case. If it is granted, we will change the specification so as to make the special case forever legal. The price will be small.

3.3 Do It This Way

Some of the hardware functions, as designed by us mindless brutes, require special handling. As we discover these requirements, I will list them here.

4.3 CPU Sleep

BIG NOTE: Sleep is broken in Mikey. The CPU will NOT remain asleep unless Suzy is using the bus. There is no point in putting the CPU to sleep unless you expect Suzy to take the bus. We will figure out how to save power some other way.

All hardware collision detection is done with the data in the collision buffer, not the data in the video buffer. This has obvious advantages and will be explained at seminars and in newsletters forever….In addition, the software can either do its own collision detection, or use the contents of the collision buffer for some weird collision detection algorithm. In either event, I will be mortally offended.

In addition, this means that when some of the bytes are not reloaded, the length of the SCB will be smaller by the number of bytes not used. If I have said this in a confusing manner, then I have.

Well, I finally found the bug that required a pad byte of 0 at the end of each scan line of data. But, It is actually 2 bugs. I have fixed one of them, but the other requires an extensive change. Too bad, I am out of time. Therefore: There is a bug in the hardware that requires that the last meaningful bit of the data packet at the end of a scan line does not occur in the last bit of a byte (bit 0). This means that the data packet creation process must check for this case, and if found, must pad this data packet with a byte of all Os. Don’t forget to adjust the offset to include this pad byte. Since this will only happen in 1/8 of the scan lines, it is not enough overhead to force me to try to fix the bug. Sorry.

This bit can be used to pause the sprite engine. The ‘unsafe’ condition of the internal registers is not directly affected by this bit.

I need to think about how to use it.

Receive parity error can not be disabled. If you don’t want it, don’t read it….We have just discovered that the calculation for parity includes the parity bit itself. Most of us don’t like that, but it is too late to change it.

11.7 Unusual Interrupt Condition

Well, we did screw something up after all. Both the transmit and receive interrupts are ‘level’ sensitive, rather than ‘edge’ sensitive. This means that an interrupt will be continuously generated as long as it is enabled and its UART buffer is ready. As a result, the software must disable the interrupt prior to clearing it. Sorry.

11.8 left out

I left something out. I know what it is but by the next time I revise this spec, I may have forgotten.

I have forgotten.

12.1.4 Bugs in Mathland

BIG NOTE: There are several bugs in the multiply and divide hardware. Lets hope that we do not get a chance to fix them.
1. In signed multiply, the hardware thinks that 8000 is a positive number.
2. In divide, the remainder will have 2 possible errors, depending on its actual value. No point in explaining the errors here, just don’t use it. Thank You VTI.

12.4 Qbert Root

As a compromise between the square root and qube root desires of the software people, and the schedule desires of the management, we have decided to incorporate the function of QbertRoot. The required steps are:
1. Start a 16 by 16 multiply.
2. Immediately write to ‘E’ which will try to start a divide.
3. Read the result from “D,C,B,A’.

(editor’s note:  I can’t tell if QbertRoot is an actual function, or trolling.)

16. Known Variances From Anticipated Optimums
This is a list of the known bugs in the hardware.

…It will be OK to write to the twentyfour 16 bit registers of the Suzy SCB PROVIDING that you only do it via the MACRO PROVIDED TO YOU BY RJ MICAL. In addition, you must understand that the contents of this macro may change if future revisions of the hardware so require. In addition, you must understand that future hardware may make the process not work and therefore the macro will be changed to be a warning that you can’t use it anymore.

Don’t cheat.

My personal favorite, saved for last:

7.3 Stereo

The 4 audio channels can be individually enabled into either of the two output drivers. This is not now in the hardware. It may never get into the hardware. After all, I hate music. However, since I acknowledge that I am wrong about some kinds of music (in the right circumstances, with me not present) I have graciously allocated one entire byte for the possible implementation of another useless and annoying sound feature.

(For the record, that feature did go into the hardware, in the second hardware revision of the Lynx.  If you have the later hardware, some audio is in true stereo.)

If all hardware/technical documentation was written this way, I’d be an embedded systems programmer by now.

I’ve scanned and OCR’d the full Handy specification for anyone wanting to learn more about the Lynx.  There’s a compo-winning demo hidden in the hardware, just waiting to be found.

Posted in Gaming, Programming, Technology, Vintage Computing | Tagged: | 1 Comment »

Gone Home’s horrifying alternate ending

Posted by Trixter on February 2, 2015

(This article spoils Gone Home, so if you haven’t played it and want to, stop reading.)

Last year I played Gone Home, and loved it — not for its gameplay (more on this later), but for its near-perfect capture of teenage girl angst in the 1990s.  It’s a wonderful mental snapshot that is difficult to evoke in more traditional visual media; it raised genuine emotion in me, which is rare for a game.

Or, rather, narrative.  Gone Home only barely qualifies as a game; it’s more of an interactive narrative where the pace is controlled by the player and can be explored non-linearly.  To qualify as a game, the user’s actions would have a bearing on the narrative; for example, actions would dictate branching paths, alter the choices given to the player, the ending would be different, etc.  The developers changed the Gone Home page at some point to describe it as “A Story Exploration Video Game”, maybe to mitigate some of the (admittedly very small) criticism from journalists and gamers who point this out.

What’s interesting is that you actually do have a single choice to make, and it can change the ending completely.

Credit for finding this one goes to my wife Melissa, who stumbled into this completely by accident.  The narrative towards the very end of the game flows essentially like this:

  1. Sam loses girlfriend
  2. Sam gets girlfriend back
  3. Sam apologies to sister that she’s leaving

(#3 implies that she’s running away from home to be with her girlfriend again.)  These are told in the form of journal entries that you click on as you navigate the game world.  You have to find and click on them to activate them, or you’ll never read/hear them.  So what happens if you skip journal entry #2?  The narrative now becomes:

  1. Sam loses girlfriend
  2. Sam apologies to sister that she’s leaving

That last part is the end of the game, and is portrayed with the following text as somber grunge music starts to play:

Katie… I’m so sorry.
That I can’t be there to see you in person.
That I can’t tell you all this myself.
But I hope, as you read this journal, and you think back, that you’ll understand why I had to do what I did.
And that you won’t be sad and you won’t hate me, and you’ll just know…
that I am where I need to be.
I love you so much, Katie. I’ll see you again. Someday.

Without knowing why Sam is leaving, this reads like a suicide note.  Imagine the horror in my wife’s face as she missed the relevant journal entry by accident and arrived at this ending.

The good thing about this unintended consequence is that Gone Home can now officially be called a “real” game, as a player choice can result in a second ending.

Well, there’s a third ending too, but you’ll need guns.  Lots of guns.

Posted in Gaming | 1 Comment »

Fun for the feeble-minded

Posted by Trixter on October 26, 2014

As a teenager in the 1980s, I loved using computers, and also building things, and especially loved building things with computers.  Naturally, I adored Music Construction Set and Pinball Construction Set.  The version of Music Construction Set for the PC floating around in the wild was mine; it comes with 30+ tunes more than the original diskette had, mostly covers as I learned to use the program, or learned my music lessons, or transcribed tunes I heard on other computers (the “power bots” MCS tune should be familiar to Apple II owners).  My Pinball Construction Set tables were not as enjoyable, so they stayed with me.

The more I built my own tables, the more I wanted to see how other tables were built.  I acquired a copy of Night Mission Pinball from a friend, and played it for hours, jealous of how much more it did than PCS:  Sound was more “authentic”, more complicated scoring, better graphics.  I ended up playing it exclusively and stopped using PCS.

Unfortunately, I played it so much that the disk wore out and wouldn’t boot any more.  Worse, my friend no longer had a copy to make for me, and I was too broke to buy it proper.  What to do?

Build my own in Pinball Construction Set, obviously:

mynight_000

I did this from memory just from playing the original game for so many hours.  It’s not perfect, but when you compare it to the original, I think I did a pretty good job:

pinball_000

If you’d like to play the amateur horror that is Jim Leonard’s Night Mission Pinball, you can now do so.

Posted in Gaming, Vintage Computing | 1 Comment »

Hey, a podcast appearance

Posted by Trixter on September 23, 2013

I had a great time talking with Anatoly of the DOS Nostalgia Podcast a few days ago, and what do you know, I’m capable of speaking into a microphone.  We spoke mostly about the first decade of PC gaming, and conclude with some games that were notable for being so well-programmed that they perform some amazing things on your 8088 that it really has no business doing.  Snag the episode here, and let him know what you think.

Posted in Gaming, Podcast, Uncategorized, Vintage Computing | Leave a Comment »

Access Software’s Echelon

Posted by Trixter on September 7, 2013

Someone with a lot more patience and dedication than myself reviewed a game that I always felt should have some sort of coverage: Echelon.  It’s one of those games that was more of a tech demo than a game, a phenomenon that occurred often in the first 20 years of personal computer gaming.  Echelon was essentially Access flexing their programming muscles, first with a 3-D flight sim and, in a later revision, continuous digitized sound and speech from the internal PC speaker (on any 286 or higher, otherwise it pauses the system while audio is playing).  They loved this idea so much that Mean Streets was originally going to be a spiritual sequel to Echelon, with a better flight sim.  Thankfully, Mean Streets also had an adventure game built around the flight sim that was much more enjoyable, so that’s why subsequent games are known as Tex Murphy adventures and not flight sims.

Gemini’s review of Echelon is likely the only review anyone will ever see of this game, so I recommend you check it out.  And the next time you have a rainy day you should also check out the other 120 (!) episodes of his DOS-era game review show Ancient DOS Games.

Posted in Gaming, Uncategorized, Vintage Computing | Tagged: , , | Leave a Comment »

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 »

Emulation vs. the Real Thing

Posted by Trixter on September 27, 2012

A fellow vintage computer enthusiast recently asked a group of like-minded hobbyists if they use emulation (ie. running a program that simulates a vintage computer, as opposed to using a vintage computer directly) and, if so, what they use emulation for. Having used, owned, programmed on, and contributed to emulators for very many machines over a long period of time, I had a lot to say. What follows is a slightly expanded version of what I replied back to him. For the purpose of this article, I define “emulation” as “interacting with software running in a virtual environment that mimics the physical environment the software was originally designed to run under“. I also define a “work” as the software you are running in said environment, and is not limited to games (although most emulators are indeed used overwhelmingly for gaming).

For the TL;DR crowd: You need both vintage hardware and emulation to properly research something.

I’ve contributed to a few emulators in varying capacities over the last decade, and in that time, some of my emulation colleagues have expressed surprise when I mention that I have a large collection of functional vintage machinery (both personal computing as well as console gaming) hiding in my crawlspace, and that I rotate pieces in and out on a regular basis for both enjoyment and research from where I play League of Legends with Elitist Gaming. This is not a statement against emulation; some emulators are packed with features that make interacting with the original works very easy and flexible (such as DOSBox, MESS, and MAME) while others are dedicated to accuracy to extreme levels (such as bsnes). The state of most emulation scenes today is thriving and most emulators are quite stable and practical to use as a replacement for the real thing.

So if that’s the case, why maintain so many physical machines? It’s because emulation can only go so far. No matter how good the emulation is, you can’t change the fact that you are running a work on a physically different computer than what it was designed for. For most works, this is perfectly acceptable, but there will always be something missing no matter how good the emulator is. In my vintage computing research, I use a mixture of both emulation and real machines so that I can reap the benefits of both. To illustrate this, I’m going to explain the advantages of both emulators and vintage hardware.

Vintage Hardware Advantages

People who never had access to vintage hardware, and always have success running software inside their emulators, sometimes can’t understand what is missing when you emulate, even using one as hyper-accurate as bsnes. Most emualtors handle the obvious (CPU and Video display subsystem) well, because those are required for basic operation; they also handle CPU “speed” and system timing well, as mishandling them would prevent performance-sensitive software from running properly. So what’s missing? Here’s a short list:

  • Video display properties: Color temperature, screen curvature, scanlines, response time, phosphor layout, phosphor speed. All of these are important in the best gaming monitor, some more than others. Vintage game graphics were composed with all of these properties in mind, from color choices down to individual pixel placement by the artist. If you are viewing a classic game’s graphics on a progressive display, the end result can be either too bright or too dim, over-saturated or under-saturated — no matter the outcome, it’s definitely not what the artist intended. Thankfully, this is changing thanks to ever-increasing GPU power in the form of plug-in shaders.  But as awesome as modern shaders are, they can’t overdrive hardware. Anyone doing serious research on vector arcade games absolutely must see at least one in person to get a feel for just how bright and intense the vectors can be. (I personally recommend the mint-condition Asteroids currently operating at the Galloping Ghost arcadevery bright, currently no burn-in.)
  • Interface properties: Input device layout, button placement, tension/stiffness, etc. This is just as important for computer emulation than game console emulation, because computers have input devices specialized for general-purpose computing (keyboards, mice) and not gaming. For example, some games on the PC used F9 and F10 for lateral movement in games, which initially doesn’t make any sense until you look at a vintage 83-key PC keyboard and see that F9/F10 were located at the very lower-left of the keyboard — optimal placement for gaming with the left hand. And younger Mac users may wonder why classic mac games only use a single button until they physically see why. This is most easily fixed by connecting vintage input devices directly to the machine performing the emulation, although such connections can range from a commercial adapter to a homebrew wire-wrapped monstrosity. But it’s worth the effort, so that you can see why Intellivision or Colecovision games require you to quickly navigate menus using the 1, 3, 7, and 9 keys (look at the controllers, you’ll see what I mean).
  • I/O properties: Because most emulation research is in the field of gaming, little attention is paid to emulating I/O as it was on the original hardware, such as the speed of the storage subsystem, any noise it made, and so on. (In fact, most emulators attempt to speed up I/O as much as possible so that programs load much faster than they did on the original hardware.) Some emulators make noise, such as WinUAE, but the overwhelming majority do not, and I think that’s a shame. For gaming, I/O isn’t usually a concern, but for any historical research, it can provide a visceral response that would otherwise be missing.

This last one is hard to understand, so I’ll provide a real-world example: When playing the game Wizardry on a real Apple II or IBM PC, it loads from a single floppy disk frequently while the game progresses, to load new graphics, maze data, etc. due to the computer’s memory being smaller than what a floppy disk holds. Wizardry is a role-playing game, which lends itself to repetitive tasks: Enter dungeon, explore new area, fight party of monsters, etc. As you play Wizardry on these systems, you begin to recognize, either consciously or subconsciously the floppy disk access patterns — the “whirr, thunk, buzz” noises coming from the drive — for these repetitive tasks as the game runs. Open a chest, “thunk”; go down a level, “thunk-THUNK whirr thunk”, you get the idea. Now, imagine that your party is wounded and desperately heading to get to the surface to heal, while navigating an unfamiliar dungeon trying to avoid conflicts. You K)ick down a door, and instead of the familiar “whirr thunk” of finding an empty room, or “whirr buzz thunk” of finding a chest, you hear “whirr buzz thunk-thunk BUZZ THUNK THUNK-THUNK-THUNK-THUNK” and realize, with growing horror, that the game is loading a lot more data than usual because it is trying to put a bone-crushing, game-ending party of monsters behind that door. But my example doesn’t end there! Not only is the I/O subsystem contributing to a real feeling of anxiety and dread, but it is also offering you a choice: If you act quickly enough, you can “dive for the drive” and pull the floppy disk out, preventing the game from loading the data it needs to seal your party’s fate. This works because Wizardry only saves your progress at two places: When you die (which in this example is in about two seconds from now), or out of the dungeon, back in town. Ripping the disk out means you unfortunately lose your progress since the last time you saved, but more importantly it cheats death — and in Wizardry, death is (mostly) permanent, even across saved games.

Emulation Advantages

For vintage gaming research, emulation provides many benefits that the original hardware would struggle with, or in some cases, are impossible. My favorite emulation advantages are, in order of importance (to me):

  • Instant searching. Software loads quickly while emulated, so you can sample one game a minute, faster if you’re organized and a quick typist. This is great if you’re trying to blow through 50+ games looking for something (a game character, a programmer or graphics artist in the credits, a specific gameplay mechanic, etc.) Handy for answering quick historical questions.
  • Interchangeable hardware. For PC emulation, any combination of video and sound standards can be quickly loaded and tested. Trying to do this with vintage hardware is time consuming and very costly (you try buying  every single vintage sound card ever made from ebay!)  My most common use of this is listening to all of the different ways a composer tried to optimize a game score for a specific hardware device. For example, load a game that uses 8-note polyphony with a MIDI device, and then load it again with the 3-voice Tandy/PCjr audio chip and hear how the musical elements were scaled down to a drastically limited output device. This practice can also lead to some interesting discoveries, such as how Rob Hubbard bit-banged a single SN76496 channel to make it perform like a crude DAC on Tandy machines, leading to some music soundtracks you can only hear properly on that platform.
  • Easy video and audio capture. While audio/video capture is not a substitute for the real thing, it is excellent for quickly illustrating gameplay mechanics or concepts to an audience that can’t (or won’t) run emulators. Capturing video or audio from real vintage hardware ranges from “easy and high-quality” to “nearly impossible” (requiring hardware modification to tap the necessary signals for capture).
  • Expanded capabilities. Emulation can enhance your experience of a work, which can greatly increase your enjoyment or appreciation of it. My favorite example of this is playing early multiplayer serial/modem/IPX games, or even 2-player game console games, across the internet with another player. In the 1980s, if you wanted to play a console or computer game with another person, you both had to be physically present. In the case of computer hardware, you had to connect computers via a serial cable, a modem connection over phone lines, or some other wacky physical connection such as a MIDI cable. The difficulty of establishing connectivity limited the experience. Nowadays, that situation has completely flipped — connectivity is standardized and widespread across international boundaries. Emulation bridges what the vintage hardware expects with what the real world can provide, and makes it possible for two people to play the same vintage console or computer game as if they were sitting side-by-side.
  • Inspection. I absolutely love this. Many top-flight emulators have an embedded debugger that allow you to pause the emulated system, inspect memory and registers, set execution breakpoints/conditions, and more. This is an absolute boon to researchers (and preservationists, who wish to “crack” copy-protected games so that they can survive past the failure of their media). This has answered a great deal of historical questions for me, from why Galaxy Player is the fastest in the world on 8088 (answer: saturated register additions + self-modifying code), to how some vintage games manipulate a 3-D virtual space and calculate rotation and perspective transformations (answer: Just like everyone else, with matrix math and nine MULs, but with a 16.16 fixed-point worldspace and 256 degrees per circle instead of the usual 360).

So there you have it: You need both vintage hardware and emulation software to get a better picture of what you’re researching.

(Note that I didn’t say “to get the full picture”, because it’s impossible to get the “full” picture of a particular work. The “full” picture would conceivably include facets of the work that may be impossible to obtain, such as experience with the social and political direction of the time period in which the work was created, the background of the people who created the work, the business and financial pressures that led to the funding of the work and controlled its motivation and direction, etc.)

Posted in Gaming, Vintage Computing | 3 Comments »