Here is a VR walkthrough of the Branson location:
And here is a video from last year of their original location in Springfield:
One of these locations has the coolest bathroom in the world.
The other just has a boring bathroom.
From a post on CompuServe, as shared by former coworker Eric. C to myself and some other coworkers, including one who formerly worked for Atari during the Jaguar days.
From 75300.1267@CompuServe.COM Sat Oct 5 02:38 CDT 1996
Date: 05 Oct 96 03:32:43 EDT
From: "Donald A. Thomas, Jr." <75300.1267@CompuServe.COM>
To: BlindCopyReceiver:;
Subject: Did you say "Goodbye"?
Content-Type: text
Content-Length: 14739
Did you hear anyone say "Goodbye"?
==================================
by Donald A. Thomas, Jr. (10/4/96)
It's odd to imagine an institution, which was as big and as powerful as Atari
once was, to have been shut down in recent days. The real amazement for me is
that it was all accomplished without a measurable flinch from within or outside
the gaming industry. I can understand that gamers wanted to push Pong out the
door early in the timeline. I can appreciate that the classics such as Missile
Command and Asteroids do not push 32-bit and 64-bit systems to any technological
limits. I know all these things intellectually, but the heart cannot face the
truth that the world and the corporate machine known as Atari could not find an
amicable way to coexist.
On Tuesday, July 30, 1996, Atari Corporation took each and every share of it's
company (ATC), wrapped them all in a tight bundle and presented them to JTS
Corporation; a maker and distributor of hard disk drives. On Wednesday, the
shares were traded under the symbol of JTS. Within a few weeks, the remaining
staff of Atari that were not dismissed or did not resign, moved to JTS'
headquarters in San Jose, California. The three people were assigned to
different areas of the building and all that really remains of the Atari
namesake is a Santa Clara warehouse full of unsold Jaguar and Lynx products.
It was only as long ago as mid '95 that Atari executives and staff believed
things were finally taking a better turn. Wal*Mart had agreed to place Jaguar
game systems in 400 of their Superstores across the country. Largely based on
this promise of new hope and the opportunities that open when such deals are
made, Atari invested heavily in the product and mechanisms required to serve the
Wal*Mart chain. But the philosophical beliefs of the Atari decision makers that
great products never need advertising or promotions, put the Wal*Mart deal
straight into a tailspin. With money tied up in the product on shelves as well
as the costs to distribute them to get there, not much was left to saturate any
marketplace with advertising. While parents rushed into stores to get their kids
Saturns or PlayStations, the few that picked up the Jaguar were chastised by
disappointed children on Christmas day.
In an effort to salvage the pending Wal*Mart situation, desperate attempts to
run infomercials across the country were activated. The programs were
professionally produced by experts in the infomercial industry and designed to
permit Atari to run slightly different offers in different markets. In spite of
the relatively low cost of running infomercials, the cost to produce them and
support them is very high. The results were disappointing. Of the few thousand
people who actually placed orders, many of them returned their purchases after
the Holidays. The kids wanted what they saw on TV during the day! They wanted
what their friends had! They wanted what the magazines were raving about!
In early 1996, Wal*Mart began returning all remaining inventory of Jaguar
products. After reversing an "advertising allowance" Atari was obligated to
accept, the net benefit Atari realized was an overflowing warehouse of inventory
in semi-crushed boxes and with firmly affixed price and security tags. Unable to
find a retailer willing to help distribute the numbers required to stay afloat,
Atari virtually discontinued operations and traded any remaining cash to JTS in
exchange for a graceful way to exit the industry's back door.
Now that JTS has "absorbed" Atari, it really doesn't know what to do with the
bulk of machines Atari hoped to sell. It's difficult to liquidate them. Even at
liquidation prices, consumers expect a minimal level of support which JTS has no
means to offer. The hundreds of calls they receive from consumers that track
them down each week are answered to the best ability of one person. Inquiries
with regard to licensing Atari classic favorites for other applications such as
handheld games are handled by Mr. John Skruch who was with Atari for over 13
years.
In spite of Nintendo's claim that their newest game system is the first 64-bit
game system on the market, Atari Corporation actually introduced the first
64-bit system just before Christmas in 1993. Since Atari couldn't afford to
launch the system nationwide, the system was introduced in the New York and San
Francisco markets first. Beating the 32-bit systems to the punch
(Saturn/PlayStation), Atari enjoyed moderate success with the Jaguar system and
managed to lure shallow promises from third-party companies to support the
system. Unfortunately, programmers grossly underestimated the time required to
develop 64-bit games. The jump from 8-bit and 16-bit was wider than anticipated.
In addition, Atari was already spread thin monetarily, but were required to
finance almost every title that was in development.
After the initial launch, it took Atari almost a year before an assortment of
games began to hit store shelves. Even then, having missed the '94 Holiday
Season, many of the planned titles were de-accelerated to minimize problems
caused by rushing things too fast. Consumers were not happy and retailers were
equally dismayed. The few ads that Atari was able to place in magazines were
often stating incorrect release dates because that information changed almost
every day although magazines deadline their issues up to 120 days in advance.
It was in 1983 that Warner Communications handed Jack Tramiel the reins of
Atari. By this time, Atari was often categorized as a household name, but few
households wanted to spend much money on new software and the systems were
lasting forever. No one needed to buy new ones. That, combined with Warner's
obscene spending, amounted to a *daily loss* of over $2 million. Atari was
physically spread all over the Silicon Valley with personnel and equipment in
literally 80 separate buildings; not considering international offices and
manufacturing facilities. Mr. Tramiel took only the home consumer branch of
Atari and forced Warner to deal with the arcade division separately. Within a
few years, Jack took the company public, introduced an innovative new line of
affordable 16-bit computers and released the 7800 video game system.
To accomplish these miracles for Atari, Jack implemented his "business is war"
policies. While people who publicly quoted his statement often felt that policy
meant being extremely aggressive in the marketplace, the meaning actually had
closer ties to Tramiel's experience as a concentration camp survivor. Of the 80
buildings in Sunnyvale, Santa Clara and Milpitas, almost every one of them were
amputated from Atari's body of liabilities. The people, the work, the heritage,
the history were fired or liquidated. Those who survived were unsympathetically
required to fill in the gaps and while most tried, few actually found a way to
be successfully do what a dozen people before them did. Atop the mountain, Jack
pressed with an iron thumb. All Fed/Ex mailings were required to be pre-approved
by one of a handful of people. "Unsigned" purchase orders went unpaid regardless
of the urgencies that inspired their creation. Employees found themselves
spending valuable time trying to find ways around the system to accomplish their
jobs. Many of them lost their jobs for bending the rules or never finding a way
to make things work. As horrible as it all sounds, it actually was the only way
to protect Atari as a company and give it a chance to survive as it did and did
very well.
Jack's introduction of the 16-bit computer was initially hearty in the United
States but it went extremely well in Europe. Europeans were not accustomed to
"affordable" technology and although the Atari computers were not IBM
compatible, it didn't matter because people could afford them. Jacks' private
laugh was that the computers were sold at prices much higher in Europe than
Americans were willing to pay. As a result, most of the machines made were being
shipped to European destinations to capture the higher margin. This enraged the
people in the United States that had been Atari loyalists. While waiting months
for stores to take delivery domestically, international magazines were touting
ample supplies. Those in the know within the U.S. became dismayed. The remainder
never knew Atari was slowly abandoning the value of Atari's name recognition as
it became easier and easier to forget some assuming Atari had long filed for
bankruptcy.
On a technical level, Atari 16-bit computers were designed beyond their time.
For less than $1,000, consumers could enjoy "multimedia" before the phrase was
ever really widely used. The icon-based working environment proceeded Windows
popularity although the essential attributes of the two environments were very
similar. MIDI was built-in and became an instant hit in the high-end music
industry. Tasks were activated and manipulated with a mouse and the system
accepted industry standard peripherals such as printers, modems and diskettes.
With all the genius that went into the technology of the machines, very little
of equivalent genius went into the promoting and marketing the machines. Mr.
Tramiel was the founder of Commodore Business Machines. When he introduced the
PET computer in 1977, Jack discovered he didn't have to call a single
publication. Instead they all flocked to his door demanding an opportunity to
see the product. News magazines. Science Journals. Business newsletters.
Newspaper reporters. They were all there with microphone, camera and pen in
hand. And they kept coming back. Adding a switch, announcing a new 4K
application or signing a new retailer were all big stories the press wanted to
handle.
Today, a new video game announcement may generate a request from any of the
dozens of gaming magazines for a press release, but a lot of costly work has to
be done to assure fair or better coverage. Editorial people are literally
swamped with technical news. Samples are mailed regularly to their attention.
Faxes fly in through the phone lines and e-mail jams up their hard drives. It
takes a lot to grab their attention.
While Atari retained hopes to be successful with the Jaguar, Atari's marketing
people were fighting established standards in the industry with severe
handicaps. Since cartridges (the Jaguar was/is primarily a cartridge-based
system) were so expensive, editorial people were required to return them before
new ones would be sent. Editorial people like to assign review projects. So
finding cartridges they sent out was not always easy to do. Additionally,
reviewers often love their work because they get to keep what they write about.
Regardless, the few magazines willing to cover Atari products were more often
turned away because of a lack of programmable cartridges or any number of other
indecisive barriers. In-store signs and posters were sometimes created, but many
retail chains charge premiums to manufacturers that want to display them. Some
direct mail campaigns were implemented, but Atari often could not afford to keep
those things being advertised on schedule. Therefore, the advertisements were
published and distributed, but the product was not available.
Clearly, Jack's experience with the world beating a path to the door of a
company making a better mousetrap no longer applied. The world had revolved a
few times beneath him and he never noticed. The tactics used to successfully
sell Commodore computers were simply antiquated notions from the past.
Meanwhile, Sony launches the PlayStation with over $500 million in marketing
funds. Today, the PlayStation is considered the most successful next-generation
gaming machine throughout the world. Sony bought the market. Tramiel's Atari
never learned how to do that. Actually, they never could afford it anyway.
After the 1990's got underway, Europe as well as the rest of the world,
discovered that IBM-compatible computers were becoming more powerful and more
affordable. The world always did want computers at home just like in the office
and companies like Dell and Gateway exemplified the industry's trend toward
home-based office computers. As a result, companies like Commodore, Atari and
Next couldn't compete any longer. While the dedicated user base of each of them
felt abandoned by these companies having to leave the computer market, the
inevitable prevailed. Commodore jumped ship, Next changed business goals
completely and Atari invested what they had left in the Jaguar game system. Even
today, Apple is kicking and screaming. As good as Apple was at creating a huge
niche for themselves, they focused more heavily on education. When kids grow up
and get jobs, they want business machines. IBM was always the business standard.
When one examines the history of Atari, an appreciation can grow for how many
businesses and people were a part of the game over the years. Chuck E. Cheese
Pizza was started by Atari's founder, Mr. Nolan Bushnell. Apple Computer was
born in a garage by ex-Atari employees. Activision was founded by Ace Atari
programmers. The list goes on and on.
But for some pathetic reason Atari's final days came and went with no tribute,
no fanfare and no dignified farewells. Why? Where did all the talent go? Where
are all the archives? Where are the vaults? Where are the unpublished games and
where are the originals of those that were? Why has no company stepped forward
to adopt the remaining attributes Atari has to offer? Where are the creditors?
What has happened to all the properties and sites? Where are the databases,
warranty cards, promotional items, notes on meetings, unanswered mail? Who owns
P.O. Box 61657? Who goes to work in Atari's old offices? Where do consumers have
their systems fixed? Who is publishing new games? Who still sells Atari
products? Why are there still a lot of people talking about Atari on-line?
I'm an ex-Atari employee and proud to have been. I'm still an Atari devotee and
proud to be. To me, these are questions which all deserve an answer, but who
will ask them?
The best people to ask these questions are those who have exposure to the
public. If you believe Atari left us without saying goodbye, contact Dateline at
dateline@nbc.com. If you REALLY believe, then send this article to 10 of your
friends in e-mail. AND if YOU REALLY, REALLY believe, mail a few to newspapers
or other news programs. A letter in your own words would be great!
I'd spend money for a thorough retrospect on Atari. Wouldn't you?
Wouldn't it at least be nice to say "Goodbye"?
--Don Thomas
75300.1267@compuserve.com
209/239-3898
Permission is granted to freely reprint this article in it's entirety provided
the author is duly credited.
My all-time favorite arcade game was TRON, probably due to its connection with the Disney movie. I do not know if I played it much when it first came out, but during the time I lived in Broaddus, Texas (1985-1986 era) the local cafe had a TRON machine. I would walk home from school, stop in to get a .25 iced tea, and play TRON. I do not know how good I was at it, but I remember playing past enough levels that the game seemed to repeat and slow down.
Since then, I have only encountered TRON a few times. After moving to Des Moines, Iowa in 1995, I found a TRON in an arcade at our local Adventureland amusement park. I recall playing it there, but the joystick or spinner was in pretty bad shape.
I remember attending an arcade auction and a TRON game came up, but I stopped bidding at $250. I really wish I hadn’t, since years later, a TRON machine was for sale locally … for $1500.
My real interest in TRON came when a local bar-arcade opened and had a machine. I would stop by on my way home from work most days and play until I beat my previous score. Eventually, I had one “perfect” game where I got the score all the way up to where it would flip back over to 0 … and died on purpose. I was concerned that if I rolled the game back to 0, I wouldn’t get to enter my initials ;-)
This earned me a place on Up-Down’s wall of fame.
To the best of my knowledge, that photo is still there, though the TRON machine died not too long after. They did get a TRON back a few times, but they all had issues — spinners that didn’t work, joystick that wouldn’t go in all directions, sound didn’t work, messed up screen, etc. I am very glad I got to play on a “good” machine all those times.
Recently, I came across a video for a CoCo game called ElecTRON. I had forgotten about this TRON clone!
Then, I accidentally came across another CoCo game called KRON, which was another clone of TRON.
I now recall seeing both of these “back in the day” (and I likely had a “borrowed” copy of both of them at some point), but neither was a very good home version of TRON. It’s hard to replicate a game that needs a spinner and flight stick with a trigger ;-)
I just thought I’d share my TRON story, so there it is.
You can play these games online here:
Have fun! But probably not…
I remember the excitement surrounding Pac-Man being released for the Atari VCS (the machine later renamed to the 2600). I was in junior high school and living in Houston, Texas at the time. I recall full page newspaper ads for this cartridge.
I had played Pac-Man in the arcades a few times, but I was not good at it and therefore it was not one of my favorite games to spend a quarter on. A quarter in 1980 would be about $1 today, according to a U.S. government inflation calculator. (And yowza to that. When the Up-Down bar-arcade opened in Des Moines, Iowa about ten years ago, the inflation rate made that quarter worth about .72 then.)
No wonder my grandmother wasn’t keen on me spending money at arcades ;-)
The Pac-Man conversion was very different from the arcade original. Some of the changes made to the game were due to limitations of the hardware — such as the “dots” being replaced by “video wafers” (so said the manual) that looked like dashes. The power pills were squares. This is understandable, though future Atari ports of Pac-Man games such as Ms. Pac-Man and Jr. Pac-Man looked much better, thanks to using twice as much cartridge ROM as the original Atari Pac-Man.
However, other changes to the game — such as playing a tune that was NOT the Pac-Man tune, and having the tunnels at the top and bottom of the screen rather than the sides, along with a maze that did not at all resemble the arcade original, seemed … just wrong. It was “Pac-Man in name only.”
It dawns on me that many of this “in name only” ports were more “inspired by”– new games using elements inspired by the original. This is much like how movies based on books are made–changing the plot so much it is barely recognizable except for some character names and general concepts.
The more movies I see that are quite different than their source material, the more I understand the 1982 Atari Pac-Man.
After all, we have seen modern programmers use the same 4K ROM size and create a much more faithful Pac-man (see video below) though I do not know if they could have written this in the same time constraints the Atari programmer had to do his version in…
For an interesting history on the original Atari Pac-Man, check out this video:
Until next time…
A few years back, Color Computer community member Rietveld Rietveld took an Arcade1Up Rampage cabinet and converted it so I could run other software — such as emulators. Images have been shown of it running the Color Computer emulator and software.
Now, with the official 1.0 release of the NitrOS9 “Ease of Use”, that has been installed on this arcade machine and, by request, my OS-9 game Invaders09 has been ran on it.
I never imagined that my “arcade” game would eventually be running on a (sorta) arcade machine. Thanks, Rietveld!
In this 13 minute video, I discuss a bit about my 1994 video game, Invaders09, including game features and details on the cheat mode.
I have posted the source code to my 1994 CoCo 3 OS-9 Space Invaders-style game to GitHub:
https://github.com/allenhuffman/Invaders09
Current version is 1.04, from 2015.
Maybe one day I’ll do a 1.05. I never did get around to adding High Scores or a Demo Mode.
See also: part 1, part 2, part 3, part 4 … and more to come…
Welcome back to the world of Atari Adventure! After spending some time figuring out how the rooms were drawn, it’s time to look at how the game objects are drawn.
Adventure contains many objects that can be displayed:
Some objects have multiple frames. For instance, the bat has two: wings up, and wings down. The dragon has three: open mouth, closed mouth, dead. The dragons can also be drawn facing left, or facing right.
I also found an entry for something called “Surround,” which appears to be the the square around the player in the invisible mazes.
In the ROM disassembly, it looks like these objects are just stored as bytes that represent them:
GfxChallise: .byte $81 ;X X .byte $81 ;X X .byte $C3 ;XX XX .byte $7E ; XXXXXX .byte $7E ; XXXXXX .byte $3C ; XXXX .byte $18 ; XX .byte $18 ; XX .byte $7E ; XXXXXX .byte $00
Above, the game-winning chalice appears to be 8×9.
The dragon is much larger:
GfxDrag0: .byte $06 ; XX .byte $0F ; XXXX .byte $F3 ;XXXX XX .byte $FE ;XXXXXXX .byte $0E ; XXX .byte $04 ; X .byte $04 ; X .byte $1E ; XXXX .byte $3F ; XXXXXX .byte $7F ; XXXXXXX .byte $E3 ;XXX XX .byte $C3 ;XX XX .byte $C3 ;XX XX .byte $C7 ;XX XXX .byte $FF ;XXXXXXXX .byte $3C ; XXXX .byte $08 ; X .byte $8F ;X XXXX .byte $E1 ;XXX X .byte $3F ; XXXXXX .byte $00
But it is still represented as 8 pixels wide. The code to display it must magnify it to make it larger on screen.
Even the bridge, the widest object displayed in the game, is represented as 8-bits wide. This is the first thing we will need to dig in to… What controls how large these small object representations are drawn?
Also, it appears every object is terminated with a $00 rather than having the length at the start. For example, instead of this:
10 READ N:FOR I=1 TO N:READ A$:PRINT A$:NEXT:END 20 DATA 10,a,b,c,d,e,f,g,h,i,j
…it works like this:
10 READ A$:IF A$="0" THEN END ELSE PRINT A$:GOTO 10:END 20 DATA a,b,c,d,e,f,g,h,i,0
Since both would have taken the same amount of data storage space in the ROM, I am betting the code to parse that data may have been smaller to loop and check for 0 versus loading a size and counting down.
Also, this presents a restriction for the graphics — none can contain an “empty” row in the graphic ($00). Because of this, each line (byte) must have at least one pixel set. This explains the dots in the easter egg signature!
;Object #4 : State FF : Graphic GfxAuthor: .byte $F0 ;XXXX .byte $80 ;X .byte $80 ;X .byte $80 ;X .byte $F4 ;XXXX X .byte $04 ; X .byte $87 ;X XXX .byte $E5 ;XXX X X .byte $87 ;X XXX .byte $80 ;X .byte $05 ; X X .byte $E5 ;XXX X X .byte $A7 ;X X XXX .byte $E1 ;XXX X .byte $87 ;X XXX .byte $E0 ;XXX .byte $01 ; X .byte $E0 ;XXX .byte $A0 ;X X .byte $F0 ;XXXX .byte $01 ; X .byte $40 ; X .byte $E0 ;XXX .byte $40 ; X .byte $40 ; X .byte $40 ; X .byte $01 ; X .byte $E0 ;XXX .byte $A0 ;X X .byte $E0 ;XXX .byte $80 ;X .byte $E0 ;XXX .byte $01 ; X .byte $20 ; X .byte $20 ; X .byte $E0 ;XXX .byte $A0 ;X X .byte $E0 ;XXX .byte $01 ; X .byte $01 ; X .byte $01 ; X .byte $88 ; X X .byte $A8 ;X X X .byte $A8 ;X X X .byte $A8 ;X X X .byte $F8 ;XXXXX .byte $01 ; X .byte $E0 ;XXX .byte $A0 ;X X .byte $F0 ;XXXX .byte $01 ; X .byte $80 ;X .byte $E0 ;XXX .byte $8F ;X XXXX .byte $89 ;X X X .byte $0F ; XXXX .byte $8A ;X X X .byte $E9 ;XXX X X .byte $80 ;X .byte $8E ;X XXX .byte $0A ; X X .byte $EE ;XXX XXX .byte $A0 ;X X .byte $E8 ;XXX X .byte $88 ;X X .byte $EE ;XXX XXX .byte $0A ; X X .byte $8E ;X XXX .byte $E0 ;XXX .byte $A4 ;X X X .byte $A4 ;X X X .byte $04 ; X .byte $80 ;X .byte $08 ; X .byte $0E ; XXX .byte $0A ; X X .byte $0A ; X X .byte $80 ;X .byte $0E ; XXX .byte $0A ; X X .byte $0E ; XXX .byte $08 ; X .byte $0E ; XXX .byte $80 ;X .byte $04 ; X .byte $0E ; XXX .byte $04 ; X .byte $04 ; X .byte $04 ; X .byte $80 ;X .byte $04 ; X .byte $0E ; XXX .byte $04 ; X .byte $04 ; X .byte $04 ; X .byte $00
Those rows would have been empty, but having a $00 there would have prevented there rest from being drawn. Interesting!
For today’s installment, I’ll be using Color BASIC on a CoCo emulator to write a simple program to plot these objects on the screen. I copied all of the assembly definitions into an editor then did a search and replace to turn those .byte instructions into incredibly inefficient one-number-per-line DATA statements like this:
2830 ' Object #10 : State FF : Graphic
2840 ' GfxChallise:
2850 DATA &H81 ' X X
2860 DATA &H81 ' X X
2870 DATA &HC3 ' XX XX
2880 DATA &H7E ' XXXXXX
2890 DATA &H7E ' XXXXXX
2900 DATA &H3C ' XXXX
2910 DATA &H18 ' XX
2920 DATA &H18 ' XX
2930 DATA &H7E ' XXXXXX
2940 DATA &H00Unfortunately, READ/DATA in Color BASIC does not allow that. It will READ the first value, then give an ?SN ERROR when it tries to read the next because the parser doesn’t handle the apostrophe “REM” marker!
So I changed it to this:
2830 ' Object #10 : State FF : Graphic
2840 ' GfxChallise:
2850 DATA &H81:REM X X
2860 DATA &H81:REM X X
2870 DATA &HC3:REM XX XX
2880 DATA &H7E:REM XXXXXX
2890 DATA &H7E:REM XXXXXX
2900 DATA &H3C:REM XXXX
2910 DATA &H18:REM XX
2920 DATA &H18:REM XX
2930 DATA &H7E:REM XXXXXX
2940 DATA &H00This also fails — and is a problem I only recently discovered when writing my Base-64 articles.
I guess I can’t have this code be as bulky and inefficient as I wanted. I removed them so it was just the DATA statements:
2830 ' Object #10 : State FF : Graphic
2840 ' GfxChallise:
2850 DATA &H81
2860 DATA &H81
2870 DATA &HC3
2880 DATA &H7E
2890 DATA &H7E
2900 DATA &H3C
2910 DATA &H18
2920 DATA &H18
2930 DATA &H7E
2940 DATA &H00Oh well. Who needs comments anyway — especially in BASIC where they just bloat the code and slow it down.
A quick-and-dirty routine allowed me to see it was working:
…but there was no way I was going to be able to fit the “Created by Warren Robinett” graphic on a low-res 64×32 screen. To solve this, I hacked together a version that used a “high resolution” screen:
It looks like the data is pretty straight forward. The dragons would have to be drawn reversed to make them face right, and the bridge looks like it needs an X scaling factor added to make it as wide as it is in the game. But, not bad for a first attempt.
Just for fun, here is the brute-force hacky nasty Color BASIC code I quickly put together to do this:
10 REM AdvObjs.bas
20 POKE 65395,0
30 FOR A=0 TO 7:BT(A)=2^A:NEXT
40 CLS0:XS=1:YS=1:Y=1
50 PMODE 1,1:PCLS:SCREEN 1,0
60 READ V:IF V=-1 THEN 120 ELSE IF V=0 THEN 90
70 X=XS:FOR A=7 TO 0 STEP-1:IF V AND BT(A) THEN PSET(X*2,Y*2,C)
80 X=X+1:NEXT:Y=Y+1:GOTO 60
90 XS=XS+9:IF XS>120 THEN XS=1:YS=YS+32
100 C=C+1:IF C=1 THEN C=2 ELSE IF C>3 THEN C=0
110 Y=YS:GOTO 60
120 GOTO 120
130 ' Object #0A : State FF : Graphic
140 ' GfxBridge:
150 DATA &HC3
160 DATA &HC3
170 DATA &HC3
180 DATA &HC3
190 DATA &H42
200 DATA &H42
210 DATA &H42
220 DATA &H42
230 DATA &H42
240 DATA &H42
250 DATA &H42
260 DATA &H42
270 DATA &H42
280 DATA &H42
290 DATA &H42
300 DATA &H42
310 DATA &H42
320 DATA &H42
330 DATA &H42
340 DATA &H42
350 DATA &HC3
360 DATA &HC3
370 DATA &HC3
380 DATA &HC3
390 DATA &H00
400 ' Object #5 State #1 Graphic :'1'
410 ' GfxNum1:
420 DATA &H04
430 DATA &H0C
440 DATA &H04
450 DATA &H04
460 DATA &H04
470 DATA &H04
480 DATA &H0E
490 DATA &H00
500 ' Object #0B : State FF : Graphic
510 ' GfxKey:
520 DATA &H07
530 DATA &HFD
540 DATA &HA7
550 DATA &H00
560 ' Object #5 State #2 Grphic :
570 ' GfxNum2:
580 DATA &H0E
590 DATA &H11
600 DATA &H01
610 DATA &H02
620 DATA &H04
630 DATA &H08
640 DATA &H1F
650 DATA &H00
660 ' Object #5 State #3 Graphic :'3'
670 ' GfxNum3:
680 DATA &H0E
690 DATA &H11
700 DATA &H01
710 DATA &H06
720 DATA &H01
730 DATA &H11
740 DATA &H0E
750 DATA &H00
760 ' Object #0E : State 03 : Graphic
770 ' GfxBat1:
780 DATA &H81
790 DATA &H81
800 DATA &HC3
810 DATA &HC3
820 DATA &HFF
830 DATA &H5A
840 DATA &H66
850 DATA &H00
860 ' Object #0E : State FF : Graphic
870 ' GfxBat2:
880 DATA &H01
890 DATA &H80
900 DATA &H01
910 DATA &H80
920 DATA &H3C
930 DATA &H5A
940 DATA &H66
950 DATA &HC3
960 DATA &H81
970 DATA &H81
980 DATA &H81
990 DATA &H00
1000 ' Object #6 : State #00 : Graphic
1010 ' GfxDrag0:
1020 DATA &H06
1030 DATA &H0F
1040 DATA &HF3
1050 DATA &HFE
1060 DATA &H0E
1070 DATA &H04
1080 DATA &H04
1090 DATA &H1E
1100 DATA &H3F
1110 DATA &H7F
1120 DATA &HE3
1130 DATA &HC3
1140 DATA &HC3
1150 DATA &HC7
1160 DATA &HFF
1170 DATA &H3C
1180 DATA &H08
1190 DATA &H8F
1200 DATA &HE1
1210 DATA &H3F
1220 DATA &H00
1230 ' Object 6 : State FF : Graphic
1240 ' GfxDrag1:
1250 DATA &H80
1260 DATA &H40
1270 DATA &H26
1280 DATA &H1F
1290 DATA &H0B
1300 DATA &H0E
1310 DATA &H1E
1320 DATA &H24
1330 DATA &H44
1340 DATA &H8E
1350 DATA &H1E
1360 DATA &H3F
1370 DATA &H7F
1380 DATA &H7F
1390 DATA &H7F
1400 DATA &H7F
1410 DATA &H3E
1420 DATA &H1C
1430 DATA &H08
1440 DATA &HF8
1450 DATA &H80
1460 DATA &HE0
1470 DATA &H00
1480 ' Object 6 : State 02 : Graphic
1490 ' GfxDrag2:
1500 DATA &H0C
1510 DATA &H0C
1520 DATA &H0C
1530 DATA &H0E
1540 DATA &H1B
1550 DATA &H7F
1560 DATA &HCE
1570 DATA &H80
1580 DATA &HFC
1590 DATA &HFE
1600 DATA &HFE
1610 DATA &H7E
1620 DATA &H78
1630 DATA &H20
1640 DATA &H6E
1650 DATA &H42
1660 DATA &H7E
1670 DATA &H00
1680 ' Object #9 : State FF : Graphics
1690 ' GfxSword:
1700 DATA &H20
1710 DATA &H40
1720 DATA &HFF
1730 DATA &H40
1740 DATA &H20
1750 DATA &H00
1760 ' Object #0F : State FF : Graphic
1770 ' GfxDot:
1780 DATA &H80
1790 DATA &H00
1800 ' Object #4 : State FF : Graphic
1810 ' GfxAuthor:
1820 DATA &HF0
1830 DATA &H80
1840 DATA &H80
1850 DATA &H80
1860 DATA &HF4
1870 DATA &H04
1880 DATA &H87
1890 DATA &HE5
1900 DATA &H87
1910 DATA &H80
1920 DATA &H05
1930 DATA &HE5
1940 DATA &HA7
1950 DATA &HE1
1960 DATA &H87
1970 DATA &HE0
1980 DATA &H01
1990 DATA &HE0
2000 DATA &HA0
2010 DATA &HF0
2020 DATA &H01
2030 DATA &H40
2040 DATA &HE0
2050 DATA &H40
2060 DATA &H40
2070 DATA &H40
2080 DATA &H01
2090 DATA &HE0
2100 DATA &HA0
2110 DATA &HE0
2120 DATA &H80
2130 DATA &HE0
2140 DATA &H01
2150 DATA &H20
2160 DATA &H20
2170 DATA &HE0
2180 DATA &HA0
2190 DATA &HE0
2200 DATA &H01
2210 DATA &H01
2220 DATA &H01
2230 DATA &H88
2240 DATA &HA8
2250 DATA &HA8
2260 DATA &HA8
2270 DATA &HF8
2280 DATA &H01
2290 DATA &HE0
2300 DATA &HA0
2310 DATA &HF0
2320 DATA &H01
2330 DATA &H80
2340 DATA &HE0
2350 DATA &H8F
2360 DATA &H89
2370 DATA &H0F
2380 DATA &H8A
2390 DATA &HE9
2400 DATA &H80
2410 DATA &H8E
2420 DATA &H0A
2430 DATA &HEE
2440 DATA &HA0
2450 DATA &HE8
2460 DATA &H88
2470 DATA &HEE
2480 DATA &H0A
2490 DATA &H8E
2500 DATA &HE0
2510 DATA &HA4
2520 DATA &HA4
2530 DATA &H04
2540 DATA &H80
2550 DATA &H08
2560 DATA &H0E
2570 DATA &H0A
2580 DATA &H0A
2590 DATA &H80
2600 DATA &H0E
2610 DATA &H0A
2620 DATA &H0E
2630 DATA &H08
2640 DATA &H0E
2650 DATA &H80
2660 DATA &H04
2670 DATA &H0E
2680 DATA &H04
2690 DATA &H04
2700 DATA &H04
2710 DATA &H80
2720 DATA &H04
2730 DATA &H0E
2740 DATA &H04
2750 DATA &H04
2760 DATA &H04
2770 DATA &H00
2780 ' Object #10 : State FF : Graphic
2790 ' GfxChallise:
2800 DATA &H81
2810 DATA &H81
2820 DATA &HC3
2830 DATA &H7E
2840 DATA &H7E
2850 DATA &H3C
2860 DATA &H18
2870 DATA &H18
2880 DATA &H7E
2890 DATA &H00
2900 ' Object #11 : State FF : Graphic
2910 ' GfxMagnet:
2920 DATA &H3C
2930 DATA &H7E
2940 DATA &HE7
2950 DATA &HC3
2960 DATA &HC3
2970 DATA &HC3
2980 DATA &HC3
2990 DATA &HC3
3000 DATA &H00
3010 ' Object #1 States 940FF (Graphic)
3020 ' GfxPort01:
3030 DATA &HFE
3040 DATA &HAA
3050 'GfxPort02:
3060 DATA &HFE
3070 DATA &HAA
3080 'GfxPort03:
3090 DATA &HFE
3100 DATA &HAA
3110 'GfxPort04:
3120 DATA &HFE
3130 DATA &HAA
3140 'GfxPort05:
3150 DATA &HFE
3160 DATA &HAA
3170 'GfxPort06:
3180 DATA &HFE
3190 DATA &HAA
3200 'GfxPort07:
3210 DATA &HFE
3220 DATA &HAA
3230 'GfxPort08:
3240 DATA &HFE
3250 DATA &HAA
3260 'GfxPort09:
3270 DATA &H00
3280 DATA -1It ain’t pretty, but it’s mine!
I suppose next I should get back to looking at how the rooms are connected. And there’s some interesting stuff in here, including rooms that “change” as the game is played.
Stay tuned…
See also: part 1, part 2, part 3, part 4 … and more to come…
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.
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=14But, 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…
See also: part 1, part 2, part 3, part 4 … and more to come…
In the previous installment, I introduced how the playfields were encoded in the Atari Adventure game. I had converted the assembly data into C code and made a command-line program that would print out the room graphics.
I then recreated the process in Microsoft Color BASIC on a Radio Shack Color Computer emulator.
My command-line C program was displaying on an 80-column Windows command prompt window (or Mac OS X terminal) so it had plenty of room to render the 40 pixel wide playfields. The CoCo’s 32-column screen could not, so I changed the BASIC version to use low-resolution (64×32) text-mode graphics. This also let me use colors, though the CoCo only had 8 foreground colors to work with in this mode, with some restrictions from the Motorola MC6847 video display chip.
The end result was a proof-of-concept showing I was decoding the cartridge data properly, even if I couldn’t render it exactly as the Atari VCS/2600 would have.
There is much more I need to explore. For instance, each room has a definition data structure that describes things like which graphics data to use, how it is displayed (right half of the screen reversed vs mirrored, thin line on the left or white wall), its color, as well as which rooms are connected to it (Up, Left, Down and Right). Here is an example of the yellow castle data structure bytes:
LFEB4: .byte <CastleDef,>CastleDef,$1A,$0A,$21,$06,$03,$02,$01
The first entry (CastleDef) is a two byte pointer to the graphics data elsewhere in the ROM:
;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
Note that the comments above are misleading. The graphics data only describes the left side of the images (the “X” characters in the comment). The right is created as the room is displayed, based on a bit in the fourth byte of the data. Here are what all the bytes mean:
;Room Data ;Offset 0 : Low byte room graphics data. ;Offset 1 : High byte room graphics data ;Offset 2 : Color ;Offset 3 : B&W Color ;Offset 4 : Bits 5-0 : Playfield Control ; Bit 6 : True if right thin wall wanted. ; Bit 7 : True if left thin wall wanted. ;Offset 5 : Room Above ;Offset 6 : Room Left ;Offset 7 : Room Down ;Offset 8 : Room Right
Looking at that data again, we can describe is as:
This early disassembly did not specifically describe what offset 4’s bits 5-0 mean, but one of them makes the room mirror (both sides look the same) versus the default of reversed. (Odd description. To me, a mirror reverses an image. It’s more like Duplicate versus Mirror in my mind. But I digress…)
The castle is a standard Reversed room:
XXXXXXXXXXX X X X R R R RRRRRRRRRRR XX XXXXXXX RRRRRRR RR XX XXXXXXXXXXRRRRRRRRRR RR XX XXXXXXXXRRRRRRRR RR XX XXXXXX RRRRRR RR XX RR XXXXXXXXXXXXXX RRRRRRRRRRRRRR
It’s attributes of $21 are the bit pattern 00100001.
One of the black castle mazes is Mirrored. Here is the room that contains the secret “dot” which is used to access the hidden easter egg room:
;Black Maze #3 BlackMaze3: .byte $F0,$F0,$FF ;XXXXXXXX XXXXXXXXMMMMMMMM MMMMMMMM .byte $30,$00,$00 ;XX MM .byte $30,$3F,$FF ;XX XXXXXXXXXXXXXXMM MMMMMMMMMMMMMM .byte $00,$30,$00 ; XX MM .byte $F0,$F0,$FF ;XXXXXXXX XXXXXXXXMMMMMMMM MMMMMMMM .byte $30,$00,$03 ;XX XX MM MM .byte $F0,$F0,$FF ;XXXXXXXX XXXXXXXXMMMMMMMM MMMMMMMM
Note how that “box” is made up by the Mirroring of the left half. Neat! That room is defined as:
LFED8: .byte <BlackMaze3,>BlackMaze3,$08,$08,$24,$13,$16,$13,$14
Its attribute of $24 is the bit pattern of 00101000.
And in the game, the room below and to the right of the castle has a thin right wall:
If I understand which room this it, this is the data that draws it:
;Left of Name Room LeftOfName: .byte $F0,$FF,$FF ;XXXXXXXXXXXXXXXXXXXXRRRRRRRRRRRRRRRRRRRRRRRR .byte $00,$00,$00 .byte $00,$00,$00 .byte $00,$00,$00 .byte $00,$00,$00 .byte $00,$00,$00 ;Below Yellow Castle BelowYellowCastle: .byte $F0,$FF,$0F ;XXXXXXXXXXXXXXXX RRRRRRRRRRRRRRRRRRRR **Line Shared With Above Room ----^
Note a clever technique programmer Warren Robinett used to save three bytes of ROM space. The room definition points to the “LeftOfName” data and a room is 21 bytes. The bottom of that room (a wall with an opening in the middle) is the same as the top of another room, so the definition uses three bytes for the next room data for the last three bytes of the first room. Clever!
The definition of the “Left Of Name” room (because the hidden easter egg room with Mr. Robinett’s name is to the right of this room) is:
LFE36: .byte <LeftOfName,>LeftOfName,$E8,$0A,$61,$06,$01,$86,$02
Its attribute of $61 is the bit pattern 01100001.
And down and to the left of the castle is a room with a thin left wall:
Grrr. That Yorgel the yellow dragon ate me while I was trying to take this screen shot.
If I am reading things correctly, I believe this uses the same graphics data as the room below the yellow castle (opening at top, wall at bottom, no walls on left or right):
LFE24: .byte <BelowYellowCastle,>BelowYellowCastle,$D8,$0A,$A1,$08,$02,$80,$03
And its attributes of $A1 is the bit pattern 11000001.
So we have:
Thus, looking back at the bit definitions:
;Offset 4 : Bits 5-0 : Playfield Control ; Bit 6 : True if right thin wall wanted. ; Bit 7 : True if left thin wall wanted.
It looks like we have:
It will take some more code exploring to see what bits 1, 2, 4 and 4 are used for, but understanding what controls Reverse and Mirrored was needed to properly draw the screens. One of those bits is probably used for rendering the “invisible” mazes, but I haven’t gotten to those yet.
Query: What happens if both bit 0 (Reverse) and bit 3 (Mirrored) are on? Why would those be separate bits? Perhaps there was an efficiency reason for checking for a set bit (less instructions than checking for a clear bit?) or perhaps bit 3 is something else. I guess I need to do more checking in to this, too.
The last bit of data (I’m assuming you can figure out “Color” and “B&W Color” entries) is the bytes that show which room is up, left, down or right. This is used by the game engine so it knows which room to display when the player moves off the current screen.
I’ll discuss that in a future installment. It’s not as straightforward as it seems. Here’s a quick teaser:
The “LeftOfName” room (solid walls with an opening at the bottom) is defined as:
LFE36: .byte <LeftOfName,>LeftOfName,$E8,$0A,$61,$06,$01,$86,$02
The room exists are defined as up ($06), left ($01), down ($86) and right ($02). But there are only 30 rooms ($00 to $1e) so there can be no room $86 (134). Maybe it actually means $06 with the high bit set (100000110). But room $06 is commented as “Bottom of Blue Maze” and looks like this:
BlueMazeBottom:
XXXXXXXX XX XX RR RR RRRRRRRR
XX XX XX RR RR RR
XXXX XXXXXXXXXX RRRRRRRRRR RRRR
XXXX RRRR
XXXXXXXX RRRRRRRR
XX RR
XXXXXXXXXXXXXXXXXXXXRRRRRRRRRRRRRRRRRRRR
…and that most definitely isn’t the room below the “Left of Name” room.
And, this room is different between game 1 (“Small Kingdom”) and games 2 and 3. In game 1, it’s a room with an opening at the top, and in games 2 and 3 it is part of an invisible maze.
This will have to be figured out.
Until then…