Thursday, May 15, 2014

Arithmetic Games Set 1: a Peek into One of the First-Ever IBM PC Games

For whatever reason, I'm a sucker for "firsts", and the earliest games on the IBM PC platform hold special interest for me, with an extra touch of morbid curiosity reserved for stuff like BASIC games (and for IBM's own offerings). Thus, I was quite intrigued when I recently came across something that answers all these criteria: a disk dump of Arithmetic Games Set 1, developed by Science Research Associates, Inc. and published by IBM.

There was zero coverage of this particular game online, even at the usual suspect places, but (to quote a certain bunch of mean, green, caterpillar-like alien overlords) you will note that this oversight has been rectified: I added a MobyGames entry for it. This post won't cover AGS1's qualities as a game (or as a pair of games), so if you fancy some screenshots and a general description, head on over there.

What got my attention first was the time-frame. Have a look at this (and keep in mind that the IBM PC was officially introduced on August 12, 1981):

Arithmetic Games Set 1: directory listing

If all the meaningful file dates are from '81, what's with the 1983 BASICA.COM, you might ask? The answer is in the two batch files (one for single-floppy and one for dual-floppy systems), intended to make the original disk bootable by copying the system and BASIC interpreter over from a DOS disk; evidently, they've been used. As for why someone might do something back-asswards like that, that's because the original disk is copy-protected... but more on that later.

The BASIC files are themselves "protected" too - you know, the type that cannot be listed or edited. But since there are known ways of getting around that, we can look inside, and see some more interesting timestamps:

These date strings place the game right around the time of the PC's launch date, and the .BIN files (just some graphics data for the title screen) are even older. What do we make of this?

SRA was an educational subsidiary of IBM, having been acquired by Big Blue "several years ago" as of 1982 (see Infoworld, 23 Aug. 1982). A web search turned up this resume by Richard Cavagnol, who worked at IBM/SRA until Dec. 1980, and "managed the contract programming teams that developed [...] a set of arithmetic games for the first IBM PC under development" (the same person later worked at WICAT Systems, *also* mentioned in the BASIC comments seen above - probably the origin of these porgramming teams).

So, yep - we're looking at the result of experimental development done on the PC when it was still a prototype. Which makes it one of the first PC games ever, perhaps beaten to the punch only by Microsoft Adventure (and/or by Bill Gates' infamous Donkey, if that one counts)!
Of course, this meant that I had to poke around a little and see what makes it tick. This is where things get a little strange.


COLOR.BAS, the first program that runs on launch, has some code to detect a CGA card (or, to use its imposing regnal title, a Color/Graphics Monitor Adapter). If it's satisfied that one is present, it does this odd little thing:

COLOR.BAS excerpt

This routine revectors interrupt 1D - the pointer to the Video Parameter Table (normally in ROM), which holds the raw video register values used by the BIOS to set video modes. Here it's relocated to 0000:0490 (inside the read/write BIOS data area!), and this location is populated with a near-facsimile of the real table from ROM. The only difference is the hsync position for graphics and 40-column text modes, which is 0x2C instead of 0x2D (this changes the horizontal centering of the image by a single character width).

Beats me what they were trying to achieve with that - changing a single value hardly seems to justify duplicating the entire table. The target location is problematic, too: it might have been unused in the original 5150 PC, but later BIOSes use e.g. 0000:0496 for keyboard flags. As a result, running the unmodified game on a later PC (or in DOSBox) makes the keyboard freak out: hit Ctrl or Alt at any point in the game, and you'll freeze the machine.

Next up is LOGO.BAS, responsible for (you guessed it) the logo and title screen. But before it does any of that, it executes this machine language routine:

LOGO.BAS excerpt

Here's that copy protection we were talking about. Disassembling it shows that it tries to verify a disk sector, expects it to fail, and drops out of BASIC if it doesn't. Easily bypassed, but once again, the routine is POKEd right into the BIOS data area (this time at 0x4D0, a reserved area AFAIK). I suppose that doing this offered some advantage on early PCs, which came with a maximum of 64KB of RAM on board; between the overhead of DOS, the Advanced BASIC interpreter, and the program itself, this area might have been the only place they could trust to remain free for machine language routines!

For a final quirk, you have the error handlers, and the messages they print:

LOGO.BAS error handler

I especially like the message in lines 65050-65070... but the real mystery is line 65175: it seems to pay extra-special attention to error code 241, urging you to call SRA and report it immediately(!). BASICA, however, does not define error codes greater than 70-ish (not according to available documentation, that is). It's possible to trigger user-defined errors, with a statement such as ERROR 241, but the game doesn't do this at any point in the code.

So 241 isn't a predefined BASIC error, nor a user-defined error - what is it, then? Merely a forgotten leftover from development/testing? Or does this seemingly-innocuous number hide something altogether more sinister and undocumented? And most importantly, will Arithmetic Games Set 2 ever turn up?

Perhaps a future installment of 8088MPH shall hold the answers one day. Until that happens...

...Beware the fumblings of Stanley Stickyfingers!


Anonymous said...

Thanks for a fantastic review of the code! I remember playing these at school around 1985, and to think they were one of the first games ever created for the IBM really blows my mind. I have found the .VFD of Arithmetic Games, and would really like to play these games again. I am having a real hard time trying to get them to work on a modern PC via emulation (DosBox, PCXT emulator, etc). Not sure if its something i am doing wrong, or maybe the protection. Are you able to point me in the right direction to get these working again? Thanks in advance - Justin.

VR said...

Well, it would help to have more details about the specific issue you're having. But to get it to work in DOSBox, the first step is to replace the BASIC interpreter; BASICA.COM won't work as-is, since it requires the original IBM ROM BASIC to be present. GW-BASIC should do the trick - if you mount the disk as drive A:, start it from there as "[path_to_gwbasic]\GWBASIC.EXE COLOR", and you'll at least have the game in a playable state.

(And remember to set machine=cga in DOSBox!)

Anonymous said...

Hey VR, thanks for your response! Unfortunately, it's still not working for me. I'll list the steps exactly as i do them:

1. Download image file

2. Extract contents of image file to C:\arithmetic (using WinImage)

3. Download GWBASIC.EXE

4. Copy GWBASIC.EXE (tried different versions) to same folder as above C:\arithmetic

5. Open DosBox conf file. Change "machine=cga" and "mount A C:\arithmetic"

6. Run DosBox, change to A: drive, and type command "gwbasic color".

All i get is the an A:> prompt with a large text. Not sure if i have a corrupted file of some sort, or if i am doing something wrong. If you could have a look at the files above, and possibly post links to the files you've got working. I've spent days on this trying different settings and different emulators. I would be very grateful, if you could let me know.

PS. How do you read the .BAS files? I cant open them with a text editor.

Best regards,

VR said...

Hi Justin,

Posting links to the files here isn't the best idea, but I think I can assist.
One effect of the protection I mentioned is that the game wants to be run from a floppy; mounting a folder as "A" in DOSBox is often not enough. Instead of extracting the files from the image, it's easiest to mount the image file itself as a floppy disk, and start the game from there.
Let's say you have GWBASIC.EXE in "C:\basic" (put it wherever is convenient; same for the .vfd). In DOSBox the procedure would be:

mount C c:\basic
imgmount A path_to_vfd\image.vfd -t floppy
C:\gwbasic color

As for reading the .BAS files: back then they'd normally be saved in a tokenized binary format (for space reasons). Usually, this can be converted to plain ASCII text by LOADing the file in GWBASIC and typing SAVE "filename",a . However, since this game uses the "protected" .BAS format, there's an extra step before you can do that... "unpbas11" is a good search term. :)

If you do get the files to an editable state, it's also possible to bypass the weird stuff that this game does and allow it to run outside the floppy image; just REM out lines 170-250 in COLOR.BAS and 212-217 in LOGO.BAS. But if you simply want to play the game, the above method is easiest.

Hope this helps!

Anonymous said...

Hi VR,

Sorry about the links! However, GOOD NEWS! IT WORKED....30 years later and I'm playing these games again. Your instructions were great, and really helped me understand. Thank you very much for your persistence with assisting me to get this working.

Now for my next challenge.....trying to open, read and save the .BAS file to remove the protection you mentioned above. I'll follow your instructions above, but if you have any further tips they would be greatly appreciated.

Much appreciated, and all the best,

Anonymous said...

Hey VR,

I followed your instructions and unprotected the files, and edited them using an editor is GWBASIC.
I "REM"ed out the lines your mentioned above and saved the files.
When i try to run the program by typing GWBASIC COLOR, i get an "DIRECT STATEMENT IN FILE" error.
Do i have to re-protect the files for them to run? If so, what do i use to re-protect them?
As always, any help would be greatly appreciated.

Thanks in advance,

VR said...

Just make sure that your "REM"s are still preceded by the original line numbers (if a line doesn't begin with a number, BASIC treats it as a "direct" statement, which is indeed not allowed in a program file).

Anonymous said...

That was it! Thanks VR. I had REM'd out the number as well. I am very much thankful for your assistance, and appreciative of the learning lesson i have attained. Best wishes, Justin.

Anonymous said...

And remember... never finger 5.25" floppy disks!