Sunday, August 9, 2015

101 Monochrome Mazes: why not color?

[ Note: this post is here to supplement a discussion on MobyGames, because it's simply easier to present the info in this format.  Plus, it'll stay accessible in case someone needs a source for the trivia later on, because nobody expects the Spanish Mobyite Inquisition. ;-) ]

One Hundred and One Monochrome Mazes was a 1983 IBM release, part of its 'Personally Developed Software' line of PC titles created by outside authors.  Rather unusually for a game, it's not just monochrome - it's so monochrome that it won't run on a color card at all.  Indeed, a rather amusing review in PC Magazine gloated in mock smugness about how "sobersided, industrious monochromers" finally have a game just for themselves, lording it over those "frivolous, irresponsible colorists" who got left out in the cold.

Question is, why would they limit their potential audience with such a restriction?  After all, the only thing a monochrome adapter ever does is show 80x25 text using a fixed character set (we're talking about IBM's original MDA, not the Hercules or other such advanced hardware).  Color cards - CGA and descendants - do the exact same thing just fine, so there doesn't seem to be a very good reason not to support them.  There's a plausible technical explanation however, and oddly enough it has to do with how the game maps are stored.

In PC text modes, the video memory map is a sequence of character bytes interleaved with attribute bytes.  IBM's mono adapter uses these attributes for character formatting (underline, intensity etc.), but there are less than 256 possible combinations, so a bunch of them end up looking exactly the same101 Mono Mazes exploits these identical-looking attributes for its own nefarious purposes - it uses them to define invisible obstacles, like hidden walls and trapdoors, which can't be distinguished from the surrounding floor until you clumsily wander on top of them.

For instance, maze 77 looks like this:

Those floor tiles (grey) all look the same, but if you examine the contents of video RAM, several locations can be spotted which contain different attribute bytes.  Here's a binary dump of the framebuffer with two such spots highlighted:

The difference isn't visible on screen, and that's how the locations of those traps are designated.  On CGA however, each attribute defines a different background and foreground color (plus blinking if enabled), and if we load the exact same data into CGA memory, we get this:

While that does look kind of cool, our invisible traps are suddenly not so well-hidden: the trapdoors now sport a swanky blue tint, while the hidden walls can be seen rocking a suave and stylish green.  Supporting CGA would've simply spoiled all those nasty little surprises, which is probably why those poor underprivileged "multichromers" got the cold shoulder on this one.  (I had a mono monitor connected to a combo CGA/MDA card that had no problems displaying both modes on it, but that was clone hardware; naturally such an unorthodox, chimeric contraption could never have been conceived of at IBM.)

No comments: