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

Defining the invisible

When we last left off, I was trying to figure out what all the bits did in the room definition attribute byte:

;Offset 4 : Bits 5-0 : Playfield Control                                                                           
;            Bit 6 : True if right thin wall wanted.                                                               
;            Bit 7 : True if left thin wall wanted.  

In the disassembly I was looking at (created in 2006 or earlier), it did not go in to details about what “Playfield Control” was for. By some trial, I was about to work out which bits represented the right half of a room to be drawn Mirrored or Reversed, as well as the bits that defined drawing a thing left or right wall line:

Bit 0 - Right half of screen is Reversed.
Bit 1 - ?
Bit 2 - ?
Bit 3 - Right half of screen Mirrored.
Bit 4 - ?
Bit 5 - ?
Bit 6 - Thin right wall.
Bit 7 - Thin left wall.

There were a few bits left over, and I knew the game had rooms that where “invisible” mazes where you only saw the portion of the maze directly around the player:

This screenshot is from game variation 2 and 3, and it is below the room to the left of the easter egg room (or, from the yellow castle, down, right, then down). By roaming around the room, and trying to match up its shape with the source code, I believe it is this location:

MazeEntry:
  .byte $F0,$FF,$0F ;XXXXXXXXXXXXXXXX        RRRRRRRRRRRRRRRR
  .byte $00,$30,$00 ;      XX                        RR
  .byte $F0,$30,$FF ;XXXX  XX    XXXXXXXXRRRRRRRRR   RR  RRRR
  .byte $00,$30,$C0 ;      XX          XXRR          RR
  .byte $F0,$F3,$C0 ;XXXXXXXX  XX      XXRR      RR  RRRRRRRR
  .byte $00,$03,$C0 ;          XX      XXRR      RR
  .byte $F0,$FF,$CC ;XXXXXXXXXXXX  XX  XXRR  RR  RRRRRRRRRRRR

By looking at the room definition data for an entry that uses these graphics, I find room 10:

LFE75: .byte <MazeEntry,>MazeEntry,$08,$08,$25,$03,$09,$09,$09

Its attributes are $25, which is the bit pattern 00101001. Bit 5 is being used, and it wasn’t in my earlier room examples, so I believe that is for “invisible”:

Bit 0 - Right half of screen is Reversed.
Bit 1 - ?
Bit 2 - ?
Bit 3 - Right half of screen Mirrored.
Bit 4 - ?
Bit 5 - Invisible.
Bit 6 - Thin right wall.
Bit 7 - Thin left wall.

For all 30 rooms defined in the ROM, I only see bits 0, 3, 5, 6 and 7 ever used. (Distinct attribute values are: $21, $24, $25, $61, and $a1. Bits 0-3 can be $1=0001, $4=1000 or $5=1001, and bits 4-7 can be $2=0010, $6=0110 or $a=1010. It seems to check out, but please double check me. I make many mistakes when writing these things and could be a … bit … off.)

This gives me five types of rooms to render.

Color me bad

There is also a color value (when in Color mode) and a black and white color value (when in Black and White mode). The Atari had a switch to alter the colors the games used so they were easier to view on a black and white TV set. Later in the console’s life, not all games continued to support this switch.

For Adventure, I see various values in the ROM, but no reference to what color they generate. Some are in definitions called “Yellow Castle” or “Red Maze”, but most are not described with a color. Instead, I look at the translated translated Adventure code by Peter David Hirschberg:

https://github.com/peterhirschberg/adventure/blob/master/src/adventure.ts

Yes, translates translated. Back around 2006, he converted the Adventure assembly code to C++ and wrote wrapper code to allow it to run on a modern PC under the title “Adventure: Revisited.” More recently, he took that converted C code and converted it to TypeScript. (I had to look up just what that was. It’s a Microsoft superset of JavaScript.) Because of this, you can now play his conversion inside a web browser:

http://peterhirschberg.com/#/AdventurePlay

In his TypeScript source, he fills in some of the gaps with new comments including this nice color table:

const COLOR_BLACK=0
const COLOR_LTGRAY=1
const COLOR_WHITE=2
const COLOR_YELLOW=3
const COLOR_ORANGE=4
const COLOR_RED=5
const COLOR_PURPLE=6
const COLOR_BLUE=7
const COLOR_LTCYAN=8
const COLOR_CYAN=9
const COLOR_DKGREEN=10
const COLOR_LIMEGREEN=11
const COLOR_OLIVEGREEN=12
const COLOR_TAN=13
const COLOR_FLASH=14

But, since the original ROM code used hardware-specific values, these numbers do not map to what the assembly code used for those colors. If I wanted to parse the actual data bytes in the ROM code (rather than converting it to a modern enumerated lookup table), I’d need to know which value represented which color. Fortunately, he also updated the room definition structures to use the above labels so it’s obvious:

let roomDefs: ROOM[] = [
  { graphicsData: roomGfxNumberRoom,
    flags: ROOMFLAG_NONE,
    color: COLOR_PURPLE,
    roomUp: 0x00, roomRight: 0x00,
    roomDown: 0x00, roomLeft: 0x00 }, // 0 - Number Room

  { graphicsData: roomGfxBelowYellowCastle,
    flags: ROOMFLAG_LEFTTHINWALL,
    color: COLOR_OLIVEGREEN,
    roomUp: 0x08, roomRight: 0x02,
    roomDown: 0x80, roomLeft: 0x03 }, // 1 - Top Access

  { graphicsData: roomGfxBelowYellowCastle, flags: ROOMFLAG_NONE,
    color: COLOR_LIMEGREEN,
    roomUp: 0x11, roomRight: 0x03,
    roomDown: 0x83, roomLeft: 0x01 }, // 2 - Top Access
...

Compare those three entries with the same three in the disassembly (and note the order is a bit different):

RoomDataTable:                                                                                                                   
LFE1B: .byte <NumberRoom,>NumberRoom,$66,$0A,$21,$00,$00,$00,$00   

LFE24: .byte <BelowYellowCastle,>BelowYellowCastle,$D8,$0A,$A1,$08,$02,$80,$03                   

LFE2D: .byte <BelowYellowCastle,>BelowYellowCastle,  $C8,$0A,$21,$11,$03,$83,$01

And we can assume that $66 is PURPLE, $DB is OLIVE GREEN, and $C8 is LIME GREEN. This would let us do our own Atari VCS to Whatever color table for displaying that data.

Of course… I could have just played the game and gone to each room, looked at the color on the screen, then figured it out that way, but he already did the work and I was lazy.

And I know what some of you are thinking… I could have just looked at his source code to figure out the attributes bits. But, alas, I could not. He already converted them. He translated those down to just:

const ROOMFLAG_NONE          = 0x00
const ROOMFLAG_MIRROR        = 0x01 // bit 0 - 1 if graphics are mirrored, 0 for reversed
const ROOMFLAG_LEFTTHINWALL  = 0x02 // bit 1 - 1 for left thin wall
const ROOMFLAG_RIGHTTHINWALL = 0x04 // bit 2 - 1 for right thin wall

…and he must have figured out that Invisible rooms all use a specific color, because he handles the invisible rooms this way:

function Surround()
{
  // get the playfield data
  const currentRoom: ROOM = roomDefs[objectBall.room]
  if (currentRoom.color == COLOR_LTGRAY)
  {
    // Put it in the same room as the ball (player) and center it under the ball
    objectSurround.room = objectBall.room
    objectSurround.x = (objectBall.x-0x1E)/2
    objectSurround.y = (objectBall.y+0x18)/2
  }
  ...

He rewrote the game in a manner that makes sense, rather than trying to do a literal translation of machine-specific assembly code in to C. Not that anyone would ever try such a literal translation…

It doesn’t look like he bothered to support Black and White color mode, either ;-) and neither will I.

With the graphics data, room attributes, and colors figured out, the only thing left in the room definition structure are the room exits. As I mentioned in the previous installment, those don’t all seem to be obvious.

We’ll kick that can down the road a bit, since there are a few more fun things to do before having to think again.

Until next time…