See also: part 1, part 2, part 3, part 4 … and more to come…

I have been on an Atari Adventure kick lately, which started after I played the game on a friend’s ATGames Legends Ultimate Arcade awhile back. Ignoring the weirdness of playing an Atari VCS game on something that resembles a 1980s arcade machine, it was like stepping back in time to when I lived in Mesquite, Texas (around 1980) and got to play it on a friend’s Atari.

Side note 1: I’ll be sharing the tale of growing up during the video game revolution of the 70s and 80s in a upcoming lengthy article series.

Side note 2: I also have an upcoming series about trying to code the Adventure game logic in Color BASIC on the CoCo.

Since that first exposure to Adventure on an actual Atari, I’d seen the game a few other times.

Indenture for the PC

There was the Indenture clone for PCs in the early 1990s. You can play it in a browser here:

https://archive.org/details/IndentureV1.71996CraigPellAdventure

It was a nice flashback after not seeing the game in over a decade. The author, Craig Pell, even added new levels with many more rooms. The original had 29 screens (well, 30 counting a hidden one) but Indenture has a level with 300.

Since it was a recreation, it does not accurately recreate the gameplay of the original. But, it’s still great fun.

Stella Atari emulator

Next was an encounter with an early DOS version of the Atari emulator Stella. This allowed a modern computer to play the game pretty much exactly as it was on an original Atari. (Though, without using an Atari joystick, it never felt quite real.)

https://stella-emu.github.io/

Atari Flashback 2

When I learned about the Atari Flashback 2 machine coming out, I was intrigued enough with this mini recreation of the Atari to actually buy one. Unlike the original Flashback unit, which was a Nintendo NES chipset with reprogrammed Atari games, the Flashback 2 was an actual re-engineered Atari machine. It could even be hacked to add a cartridge connector and play real Atari cartridges! And, it game with Adventure. Though I really only powered it on a handful of times before donating it to the Glenside Color Computer Club to be auctioned off at a CoCoFEST!

Atari’s Greatest Hits

In the years that followed, various software packages were released containing officially licensed Atari games running in some form of emulator. Atari’s Greatest Hits was sold for many consoles and computers. I had the edition that came out for iPhone and iPads:

It was great fun to play Adventure again, but a pain to do so using virtual touch controls on a tablet screen. Fortunately, the iOS version supported the iCade controllers and I even hacked up an interface to use a “real” Atari joystick on it (the joystick from my Atari Flashback 2). Here is is on my original first generation iPad:

That, and the Flashback 2, were the closest I’ve come to the real Adventure experience, due to accurate emulation and a real (replica) controller.

Warren Robinett speaks

My recent re-interest in Adventure was enhanced after watching this 2015 presentation by the game’s original author, Warren Robinett. He details the history of how the game was designed, and some insights in to how the code worked:

It was this video that got me interested in howthe game worked, rather than just how to play it.

Adventure Revisited port

I was unable to find any dedicated “Everything You Want To Know About How Atari Adventure Worked” website, but I did find a 2006 version (winventure.zip) by Peter Hirschberg. In contained a disassembly of the original Atari Adventure assembly code. He also translated that assembly into C++ and wrote new code to emulate machine-specific things like collision detection and the display. I don’t know where I found the original zip file, but here is the current version:

https://sourceforge.net/projects/adventurerevisited/

Because this version was based on the actual ROM assembly code, it should play much more accurately than the Indenture rewrite from 1991. I haven’t tested this myself since I’ve been busy playing it in an Atari emulator.

Side note: I just realized this is the guy who did the Adventure game for the iPhone back in 2008!

Dissecting Adventure

Thanks to the disassembly of the original source, and the rewritten version in C++, I was able to start looking at how the game worked. The first thing I did was look at how all the game levels we represented. Each screen was represented by 21 bytes of ROM code!

;Castle Definition                                                                                                 
 CastleDef:
  .byte $F0,$FE,$15  ;XXXXXXXXXXX X X X      R R R RRRRRRRRRRR
  .byte $30,$03,$1F  ;XX        XXXXXXX      RRRRRRR        RR
  .byte $30,$03,$FF  ;XX        XXXXXXXXXXRRRRRRRRRR        RR
  .byte $30,$00,$FF  ;XX          XXXXXXXXRRRRRRRR          RR
  .byte $30,$00,$3F  ;XX          XXXXXX    RRRRRR          RR
  .byte $30,$00,$00  ;XX                                    RR
  .byte $F0,$FF,$0F  ;XXXXXXXXXXXXXX            RRRRRRRRRRRRRR

Above is the data that is used to draw the castles in the game (yellow, white and black). There was another table that defined which set of graphics data to use, as well as what attributes such as “how” to draw it (more on that in a moment), what color to draw it, and what screens were connected to it on each side (up, right, down and left).

The screen was represented by 20 bits stored as three 8-bit bytes with four unused bits. Those bits represent the left side of the screen, then they are either reversed to create the other half of a symmetrical screen, or they are mirrored (draw the left side on the right) which was used in some of the mazes). It is amazing that the entire screen was defined by only 21 bytes! (And, since there were four unused bits for each three bytes, it could have been compressed further down to 17 bytes, though the extra code needed to handle this might not have fit in to the 2K of ROM space the game used.)

Decoding the data in C

For fun, I thought I’d try to convert those data bytes in to a C program and see if I could decode and display them. Here is the castle:

My first attempt at the decoder wasn’t perfect (note that it’s missing the floor of the castle room), but it showed I was on the right track.

Decoding the data in Color BASIC

I next converted the bytes into Color BASIC DATA statements, then wrote a similar program to decode them:

The CoCo 1’s 32-column screen isn’t wide enough to display 40 ASCII characters, so I was only drawing half the image as a proof-of-concept.

I next converted the PRINT text to SET(x,y,c) plotting commands. This would let me draw on the low-resolution 64×32 8-color screen.

I made a simple program that let me enter a room number and then it would plot the data on the screen. Above is a screen shot from an Atari emulator on the left, and the CoCo screen on the right. Though the aspect ration doesn’t match, at least it shows the graphics are accurate.

This 64×32 “graphics” mode is actually made up of special text characters that represent a 2×2 graphics block. Those blocks can contain one color plus a black background. Because of this limitation, a screen block can either be the green/orange background color with or without a text character on it, or a black block with 1-4 of it’s 2×2 pixels set to a single color. Because of this limitation, graphics need to be specifically designed.

Since each Adventure screen used only one color for the graphics, I thought this might work out well. But, if I wanted to change the background color, that might present a problem since unless the graphics took up a full character block, they would always have the unused pixels set to black. I did a quick test and it looked like this:

Above you can see that certain blocks of the castle do not use up a full 2×2 block, so the unused pixels are set to black. I think this gives it a rather interesting 3-D effect, though that was not the intent. Here’s one of the mazes:

I think it looks pretty cool, though not accurate to the original.

The ROM code also contains the data that makes up the objects in the game, such as the dragons. Here’s a dragon with its mouth open:

;Object 6 : State FF : Graphic
 GfxDrag1:
  .byte $80                  ;X
  .byte $40                  ; X
  .byte $26                  ;  X  XX
  .byte $1F                  ;   XXXXX
  .byte $0B                  ;    X XX
  .byte $0E                  ;    XXX
  .byte $1E                  ;   XXXX
  .byte $24                  ;  X  X
  .byte $44                  ; X   X
  .byte $8E                  ;X   XXX
  .byte $1E                  ;   XXXX
  .byte $3F                  ;  XXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $7F                  ; XXXXXXX
  .byte $3E                  ;  XXXXX
  .byte $1C                  ;   XXX
  .byte $08                  ;    X
  .byte $F8                  ;XXXXX
  .byte $80                  ;X
  .byte $E0                  ;XXX
  .byte $00

When I get some time, my next goal is to render all of those game characters, similarly to how I displayed my old VIC-20 game’s customer character set.

To be continued…