Game Font Forensics

Unless you’re a first time reader, you might have picked up on two recurring
topics around these parts: ancient PC games, and ancient bitmap
fonts.  Somehow the obvious combination between the two never came
up, but as it happens, the twain can meet.  I was recently motivated
to tackle a few riddles which had puzzled me for a while, and which
happened to involve (are you sitting down for this?) ancient games and
their fonts.

Game typography can be talked to death from any number of angles, and you can
find entire books on the subject (a while ago I was gifted a copy of Toshi
Omagari’s Arcade Game Typography, which knocks it right out of the park).  But the nice
thing is how font designs can moonlight as evidence for research – they give
us hints about the tools used to create the games, reveal unexpected
connections between seemingly unrelated games, and generally provide valuable
insight into how things were done at the time.

In many cases, what they reveal isn’t all that new or
interesting.  You could point to hundreds of games just using the
BGI fonts that came with Borland compilers, or those included with Deluxe
Paint II, Autodesk Animator and other graphics tools.  Some were
happy enough with the default video BIOS fonts, and games ported to the PC
from other systems (Amiga, Atari ST) occasionally took those machines’ system
fonts along for the ride.  Things like that can be easy enough to spot,
but in some instances, tracing the connections gets a little more complicated.

Beneath Apple Manor (Special Edition) vs. Hard Hat Mack

These two games don’t seem to have anything in common whatsoever; different
developers, different publishers – but both were released for the IBM PC
around the same time, and seem to use an identical font.  In
Beneath Apple Manor, the font in question is confined to the title screen,
where it spells out “THE SPECIAL EDITION BY Don Worth”; but Hard Hat Mack
uses it throughout the game.

Now, I was looking at the IBM PC versions, because that’s my wheelhouse; but
it doesn’t take rocket surgery to figure out that their true origins lie
elsewhere.  As its title so subtly implies, Beneath Apple
Manor was
originally an Apple ][ release.  Even the later Special
Edition came out for the Apple first (1982), then for the IBM PC and for
Atari’s 8-bit series (1983).

In fact, looking at the PC title screen, the picture only takes up 280 pixels
horizontally, out of the 320 available in this CGA mode: that’s a
rather fat clue that the graphic was created on the Apple and then converted
for the IBM, without so much as centering it.

As for Hard Hat Mack,
the developer credits for the various releases make it clear that the Apple
version came first.  I used to enjoy this game as a kid (much later,
I even went through the trouble of patching it to add 16-color composite
graphics on CGA), but back in those days I was completely unaware of
the original Apple game.  At some point, there emerged some pretty
convincing evidence that the PC version was machine-translated(!) from
6502 to 8088 code – I’m afraid you’ll have to take my word for it, since the
internet is written in sand, and the details have been lost to link
rot.  But that would explain why it feels a bit sluggish compared to
the original, and frankly embarrassing next to well-written native 8088
code.  I can only assume that TMQ Software, Inc. couldn’t be bothered
to optimize the code that their automated converter spewed out.

Anyway, now that we know where to look, here are the Apple ][ title
screens for both games.  Not very surprisingly, we find the
exact same font cheekily staring back at us:

Evidently the source of the font must lie somewhere in Apple land, as
well.  I can’t say I’ve ever had much experience navigating the
primordial soup of very early Apple II graphics programs, but I figured I’d
give it a shot.

The Graphics Department

Luckily, the smoking gun was found in very first source I consulted, Apple
Graphics: Tools and Techniques by Michael Callery and Roberta Schwartz (PDF
link).  It probably has more than you ever wanted to know
about the subject, and it’s sprinkled with a bunch of very nice pixel art
illustrations, but what caught my eye was this simple bar chart on page 261
(in the PDF; the actual book doesn’t number it):

Well, I’ll be damned if those chart labels don’t look exactly like the
lettering in both BAM and HHM.  “Created with The Graphics
Department“, was it?  I had never heard about that particular piece
of software, but helpfully enough there’s a section in the book discussiong
it, in which we learn that it’s a “business and presentation graphics utility”
from Sensible Software (not the later British game company), and that among
other things, it allows you to “choose lettering from twenty character fonts”.

Finding a copy of The Graphics Department was easy enough, and after a bit
of disk-shuffling in AppleWin, I was able to have a look at the included
‘Lettering Kit’.  As it happens, the suspect typeface is the
default “mono” font, and indeed we do have a match.

It’s still not precisely 1:1, however: in the program, the character cells
appear to be 8 pixels wide, while both games (in their Apple and IBM
versions!) use the more Apple-native width of 7
pixels.  The “KERN” option lets you increase the character spacing
in Department, but apparently you can’t reduce it.  Taking a
screen grab and tightening up the spacing by 1 dot, the characters fit onto a
7-pixel grid – a better match for what we see in the two games.

All that’s left to do is to compare this to what’s actually stored in the game
data.  Manor won’t help us out here, because the font is baked
into the title graphic, and isn’t used anywhere else to display actual
text.  On the other hand, Hard Hat Mack prints its text at runtime
(on the title screen as well as the in-game status display), so it has no
choice but to store its charset as an actual font.

Comparisons

The easiest way to exhume this sort of data is to view our binary blob (file
or disk image) as one large set of graphical tiles.  If no
compression is used, and if you choose the same data format used by the
display hardware, there’s a good chance you’ll ferret out some fonts, among
other things.  When we do this for both versions of Hard Hat
Mack, we can see what’s up:

The Apple version’s font may be missing the lower case portion, but the part
left over is better than what we got from The Graphics Department – TGD’s
characters are cut off past the 6th dot column, so a bunch of them are visibly
missing vertical slices on the right: m, w, #, %, ?, /, , ] and the apple
icon.  If the idea was preventing the characters from sticking
together, you could make a case for doing that; but since the program draws
its characters on 8 dot boundaries, not 7, that 7th column shouldn’t have
bothered anyone.

The game data has those characters fully formed, despite the fact that they’re
never actually used.  That means there was no reason to fix them up
by hand, so the developers must’ve had a better version of the font to start
with.  That is, there’s either a bug in the version of Department
that I found (2.03), or a problem between the chair and the keyboard… or the
font really does come from somewhere else after all.

As for the IBM PC conversion – besides the fact that the character order is
obviously reversed, we can spot a couple of other changes.  1-dot
stretches show up in alternating colors rather than white: whatever
tool was used to convert the Apple HGR data to IBM CGA format, it was likely
trying to crudely mimic the phenomenon of NTSC color artifacting (that’s very
roughly what happens to isolated pixels on the Apple; compare to that
Graphics Department shot).

The thing is, the subset that’s actually used in-game doesn’t have those
errant colors.  So that was obviously a manual fix, but they went
ahead and made a few others too: comma and period are shifted left, “Q”
doesn’t look like a “0” flipped around anymore, and the “&” has been
miracu­lously cured of its crippling
disfigure­ment.  Some­what regrettably, the apple icon
wasn’t replaced by a
“Charlie”/“Tramp”
hat… contrast with the IBM version of Beneath Apple Manor,
where the Golden Apple (the object of your quest) turns out to be something
considerably less, uh, fruity.

Flightmare vs. Ninja

Ninja is a fun sort of game if
it’s 1986 and you own a PC/XT clone (especially a Tandy 1000, which I did
not).  Not great-looking next to the
arcade/Amiga/Atari ST versions, but having so many different combat
moves was a novel thing at the time… even if the novelty may wear off when
you realize that spamming a single key combo mows down entire armies of
baddies.  And the fact that the devs left a sprite editor in the game
itself (by
mistake?) gave me one of my first “modding” experiences.

Later I came across an older game,
Flightmare (“The
Ulti­mate Expe­dition into Horror”): a ghoul­ishly difficult
shooter where you wage post-apocalyptic aerial combat against desert
warriors, vandals, and “maraudering beatnicks” (!).  On top of the
humor, and the original idea of having you control your plane on a top-down
and a side view at the same time, the author was skilled enough to
squeeze excep­tionally smooth and fast action out of a 4.77-MHz
PC.  (It also tries to pull some mightily silly tricks to fool
disassem­blers and debuggers, but that’s another story.)

Again, the two games appear completely unrelated: Flightmare may require
ninja reflexes and discipline, but it’s a shareware/user-supported
game released in 1984 by Peter Adams, for the IBM PC only; while Ninja
was a commercial game from Steve Coleman at Sculptured Software, with the IBM
PC version written by Bryan Brandenburg (“and Soft Arts”, it says
here).  So, where did they get the exact same font?

I say “font”, but Flightmare in fact has two of them.  The 8×8
charset seen above is used for almost everything, but there’s a smaller 4×8
one, which serves to keep track of lives, enemies and
time on the status display.  For this purpose the numerals (and colon) are
sufficient, and as far as can be seen in the game itself, this is all that’s
used.

But if we look at the executable’s data as tiled graphics in 2bpp CGA format,
we find full sets of alpha­numerics for both the large and the small
fonts.  Here they look kinda jumbled and junky; we could play around
with the offsets and clean things up a bit, but it’s usually easier to look at
what’s actually in RAM while the game is doing its thing.  Running
the game, dumping the data segment, and giving it the same treatment gets
us tidy renditions of both sets:

Apart from the full set of (unused) uppercase letters in the smaller charset,
both fonts have a second set of the letters A through F right after the
numerals.  That’s a neat thing to have when you want to print out
hexadecimal values, since you don’t have to bother fixing up ASCII codes, so
maybe this was used to show debug infor­mation in develop­ment builds
or something.

Ninja also has two different fonts, in FONT2.DAT and FONT2B.DAT, but that’s
because they’re intended for different video modes – the one that looks like
Flightmare is used in plain CGA (320×200 at 4 colors); the other one is used
for the Tandy 1000 mode (160×200 at 16 colors).  This mode trades
resolution for bit depth, so the more-detailed CGA font data would
have resulted in unsightly artifacts.

So yep, Ninja‘s CGA font is dot-for-dot identical to Flightmare‘s,
except that the period and comma have disappeared (and the “8” has acquired a
bonus pixel at its lower right corner).  The thing is, this .DAT
file isn’t the only place we can find it: the executable, NN.EXE, has
another copy of the CGA font at offset 0346h.

And what greets us just after this redundant copy within Ninja‘s .EXE
file?  Why, zoinks!  It’s the small 4×8 font from
Flightmare:

Ninja doesn’t use this smaller font in any way; it just got dragged along
when its larger cousin made the jump from Flightmare.  We of the
“size matters” school of thought will be appalled at the waste of space (those
two surplus fonts take up over a kilobyte… for shame!) – but that
aside, it all smells like something you’d get when the data was sourced from
the original developer, not like an unautho­rized rip or something.

So what’s the connection?

Peter Adams (author of Flightmare)
isn’t credited anywhere on Ninja, but MobyGames tells
us
that the latter’s publisher, Sculptured Software, had a Peter Adams as a
co-founder along with Bryan Brandenburg (he of Ninja‘s “IBM version
by”)… and this 1996 newspaper
article lists a few more people.  MG simply
has entries for eight different developers who go by some form of the name “Peter
Adams”; some of them may very well be the same person, but the author of
Flightmare isn’t explicitly linked to Sculptured.

Another fact missing on MG is that Adams and Brandenburg did work together
on at least one game – the Apple ][ version of Raid Over
Moscow.  And just to round out the big happy family, Ninja‘s designer
Steve Coleman shows up in the Atari port of the same game.

So it’s all a bit convoluted, and those puzzle pieces had to be picked up from
all over the place, but I think it checks out.  If I hadn’t noticed
the identical lettering, I’d never have assumed that there might be a
connection between these two games.

You may remain skeptical that the two iterations of Peter Adams (from
Flightmare and Sculptured Software) are neces­sarily the very same
person.  After all, there were a few others in the industry.  Besides,
Sculptured was supposed to be based in Salt Lake City, Utah – while
Flightmare‘s author wants you to send your “monetary thank you card” to him
in Livermore, CA.  Then again, Flightmare itself asks you at one
point: “WOULD YOU RATHER BE IN UTAH”… perhaps the programmer was
asking himself the same thing?

Poking Around in Pharaoh’s Tomb

Pharaoh’s Tomb has
been the title of several unrelated games over the years, but PC
old­skoolers would undoubtedly be thinking of the early Apogee shareware
title – and they’d be right.  This was when George Broussard made
the jump from el cheapo trivia games to action plat­formers.  Not
that a flip-screen CGA/PC speaker game did much to set the world on fire
in 1990, but it did a decent job carrying the torch for a genre that had lost
some of its commercial appeal by then; and with the ‘Apogee model’ you got
quite a lot of game for not that much money.

Games of this type normally don’t get very wordy, so most of them tend to pick
a single type­face for their lettering and stick with it.  But
Pharaoh’s Tomb goes above and beyond the call of duty, and uses four
different fonts (not including the one in the title)… sometimes all on the
same screen.

With all the lavish attention given to the appearance of text, Broussard still
managed to famously mis­spell his own name on the title screen, but that’s
neither here nor there.  What made me nose around in the game’s font
usage was a silly little bug that can show up if you run it on EGA/VGA –
depending on your system configura­tion.  Most of the text will
look just fine, but the numbers (and symbols) on the status bar will be
garbled.

As some of you may guess, the guilty party here is DISPLAY.SYS – the DOS
driver that controls code page selection on
the video hardware level, usually used along­side other drivers for
localiza­tion.  On EGA or VGA, if you use it to specify a code
page, it’ll hook the video interrupt (10h) and try to make sure that you
always see the character set you selected.  Remove it, and the
problem goes away.

Since DISPLAY.SYS relies on trapping the BIOS video service, the only
programs affected are those that use the BIOS text rendering
rou­tines.  This is what Pharaoh’s Tomb does – although as a
CGA game, it has to be tricky about it: in CGA graphics modes, only the top
(“high-ASCII”) half of the charset can be rede­fined.  The
usual work­around is to use that for your custom font, and remap your
ASCII text to those higher code points before you feed it to the BIOS
func­tions.

The BIOS needs a pointer to the font, which resides at the vector for
interrupt 1Fh.  So if we peek at the various addresses that the
game puts there, we can get at the raw fonts.  Here the memory dump
is treated as 1bpp data, since that’s what the BIOS routines use:

Woah, hold up there, Chief… who’s “Donald L. Pavia”, and what does he have
to do with this game?

If you look up the name, you’ll probably find that Donald L. Pavia authored a
few share­ware/public domain games in his time; one example is this
compilation from
1986, with educational games he wrote for his kids in Turbo
Pascal.  And if you try out a few of them, such as Alphabet Games
from that pack, you’ll actually spot one or two of these lettering styles here
and there.

You might suspect that the fonts were summarily ripped from one of those games
and stuffed into Pharaoh’s Tomb… and with the original author’s name and
address still intact, that would certainly be the more hilarious
prospect.  But none of Pavia’s games contain the full selection of
characters and styles we see in PT, and what’s there is already part of a
static image, so the fonts themselves must’ve come from somewhere else.

Turbo Paint and NewFonts

One of those games did have a clue in its README file – it mentioned that the
title graphic was created with something called TURBO PAINT, another program
by Pavia.  Turbo Paint 2.0 can be found
here,
and turns out to be a decent share­ware alter­native to PC Paint and
the likes: a mouse-driven paint program, written in Turbo Pascal
again.  The docs say that it’s been tested on the PCjr, and on EGA
cards, but it can only do 4-color CGA.

The text tool has some built-in fonts you can use, and whaddya know – those
8×8 character styles sure ring a bell:

Just like in Pharaoh’s Tomb, these fonts are upper­case-only, and
the ‘Fat’ and ‘Thin’ ones are 100% identical to what Broussard ended up
using… but those two other fonts from PT are still not accounted
for.  One of them does look like Turbo Paint‘s ‘Gothic’ font, but
it has those hollow vertical strokes filled in; and the other one (with the
small caps) there’s no sign of.

Hold on though: Turbo Paint’s documentation tells you that you can load your
own font files, and refers you to the author’s own font editor,
“NewFonts­.com“.  Is that program included on the disk, you
may ask?  But of course it isn’t – that’d be too
easy.  Pavia doesn’t tell us where to get it, either, so our little
archeolog­ical expedi­tion isn’t over just yet.  If PT’s
protagonist Nevada Smith ever stars in another game, he should definitely go
digging through old software libraries and BBS lists.

‘NewFonts’ finally turned up in the PC-SIG shareware
library
on disk 0484.  It’s a fairly straight­forward
editor, made for the specific use-case of creating 8×8 fonts for CGA graphics
mode, to be used with the BIOS routines via the above-mentioned
“high-ASCII” trick.

The disk also has some demo programs showing usage examples, a few source
files to help out, and even some code to access 16-color PCjr
graphics and CGA’s ‘lo-res’ 160×100 pseudo-mode from TP (you can use your
custom fonts in these modes, too!).  But we’re looking for fonts –
and there are no less than 19 .FNT files inc­luded.  Here are
five of them:

Sure enough, that’s pretty much exactly what we saw in the Pharaoh’s Tomb
RAM dump, complete with the author’s contact info.  The game just
moves some code points around, and adds those little icons for the status
bar.  Even the fancy Greek-patterned frame is
there.  Pavia specifically writes, “You may freely use the font
files […] in any of your own programs”, so it’s all legit.

These same fonts were later reused in a few related games: the commercial
version of PT (retitled Pharaoh’s
Pursuit), the sequel
Arctic Adventure, and
also Monuments of Mars – my personal favorite of this bunch, and a game that obviously has
much in common with the others, although it was written not by George
Broussard but by Todd J. Replogle.  Unlike Broussa(r)d, the latter
got his own name right on the title screen… but then promptly proceeded to
misspell “Scenario Software” as “Scenerio”.  Was this a
contractual requirement with Apogee, or just something in the water?