landondyer

Correct. Both the DRI and Atari people working on TOS knew quite a bit about the Mac (through the Lisa, and early versions of Inside Macintosh). Some of the graphics development for the ST was initially done on Lisa systems. I bought a 128K Mac a couple weeks after it came out, a few months before the first TOS ROMs shipped. There was /zero/ feedback from Atari or DRI back to Apple.

Working for Jack was interesting. Very powerful personality, and I didn't really stand up to him much (just once, when I was leaving the company). In person, the Tramiels are a great bunch of people. In business relationships, my guess is that a lot of people were pretty unhappy with them. The T's seemed to think it was some kind of natural law that you had to look out for yourself in your dealings with them. (DEC used to demand cashiers checks at the door before they would do any service work on our Vaxen). In the end, I think that they didn't have the necessary product vision. Other than "dirt cheap" they couldn't offer a compelling platform story. The ST sort of muddled through, making some inroads (e.g., MIDI in the music industry), but nothing really dramatic. The staff just wasn't large enough to do both sustaining engineering and whizzy new products, and in the end the lack of something that a Mac or a PC couldn't also do killed 'em.

No, Jack bought Atari /specifically/ to do the ST. (His people -- John Feagans, Shiraz Shivji, etc., were working on the system in hotel rooms, before the Atari deal was finalized).

I liked the A8 line a lot, for playing games. Writing them, though, was a real pain. Months of work in assembly. The ST was a real computer. You could do significant work on it in a high-level language (well, C). And while it was definitely tough to get interesting graphics going, you /could/. Sound was a huge disappointment, however, and the ST should have been much better. So I like the platforms for different things, and I don't pretend that they're equivalent. The natural extension of the A8 was the Amiga, which had its own trouble. I really wish that Tramiel had had about another year to do an A8-like 68000-based machine, and that we'd had the gumption to ditch GEM and done a real software platform. (Then again, another year of ST-like pressure probably would have killed the team :-/ ). I still get upset when I think about the utter disaster that the BASIC we bought from DRI was.

Depends on the game. For instance, in Pac-Man you can overlap the ghosties just a little bit. It adds tension, it gives the player the feeling that they "got away" with something. A few bounding box checks are peanuts in comparison to doing the blitting. In A8 Robotron (which my office mate Judy Bogart wrote) we worked out a scheme where each enemy robot had some "killer color" in it; the people were done (I believe) with bounding boxes. This made collisions against many, many robots cheap (using the HW collision) and the game's color scheme fortunately allowed for it. But A8 games that use exclusive HW detection show it, and seem "harsh" and unforgiving to me. Just because the HW is there and it's cheap doesn't mean you have to use it. Users don't care how much computation you had to do, they just care if it's fun. I suppose you could add some kind of delay on top of HW detection (don't declare a hit until you have a solid 3-4 frames or so of continuous hits). That might feel all right. Like anything else, you have to play with it, and get users to play it, and listen honestly.

DK uses software collision (bounding box overlap) rather than the hardware collision registers, because use of the H/W collision registers leads to a very poor user experience. (The H/W collisions might have been used for the "prize" collection -- I don't remember). H/W collision detection is fine for some games, but Atari programmers tended to over use it, leading to horrible garbage like Caverns of Mars (where a single pixel overlap killed your ship). CoM could have been a fun game had the author not felt compelled to use that feature. Just my opinion.

I was PM'd about this. I haven't played it, but these mostly sound like improvements. (I deliberately left the introduction cartoon out of the cartridge, on the theory that it was used in the arcade version to burn up "arcade minutes," and that it would eventually be tedious for home players). Naturally I have no official capacity to approve or disapprove.

In my opinion, if you're only using a dozen or so chars per line of assembly, you're doing it wrong. While you don't necessarily need a comment on every single line, many lines should be well commented. The original Macintosh ROMs (up to the 68020/030 based sources I saw) were production assembly with comments on every single line, and they mattered. This probably matters less for video games, but you'll still thank yourself later if you leave decent comments behind. In my own Atari games (as well as in the Coin-op sources i saw) there was plenty of explaination; in my case, I had direct feedback that others had found it very helpful. (The Atari 400/800 version of Pac-Man had exactly two comments. I forget the first, but the second was "HA HA" on the line that implemented the cartridge's single piece of copy protection).

That's interesting. I know Bob Alkire pretty well (we were housemates for several years). GUMP was one of those pie-in-the-sky projects that Research was always doing. Interesting concept, using chips that were under development, but no consumer cost structure. It /might/ have been a product, given several years of development.

I was there. Jack Tramiel paid for flights for people working the booths; I wasn't chosen to go. I went with three other people from the software team; we rented a god damned big old cadillac and did a road trip to Vegas. Jack *did* pay for the hotel. We hung out at the Atari booth, watched the poor sots sweat through booth duty, had a ton of fun on the strip. I lost $35 in the slot machines. 'nuff said.

It was also an utter surprise to the software and hardware folks in Atari Sunnyvale. The folks in the UK just did a press release one day, we had /no/ clue about it. Not surprising it didn't go very far...

Mac/65 is by far the better tool. You will avoid emotional trauma if you avoid using the Asm/Ed cartridge. Although, I would personally cross-assemble and download to an emulator these days. (You can probably assemble a 16K game in under a second on modern hardware).

I liked the 8 bit for hacking games, but you *had* to program in assembly, and after a while that got to be really tiresome. (You could write stuff games in Basic -- in fact, I had a roommate who excelled at making *fun* games with primitive graphics that were ready to got in an afternoon). But ultimately the miserable I/O of the 8-bit era and the cramped address space made things less than enjoyable. The ST had its own problems, but it was a lot more fun to actually write programs on. (Wish it had had a real operating system. Oh well). However, the sound chip was pathetic, and you had to do all the blitting by hand. The ST was better for doing systems-like work.

We were told 192 scanlines. There is sample code in the official Atari hardware documentation saying that you're in "overscan" on line 192, but that 190 and 191 should be visible on most TVs. I got away with a little over 200 and nobody noticed. But marginal TVs, we were told, were . . . marginal. Things have probably improved since the late 1970s, though :-)

Making the 8-bit family better wasn't going to make that product line last much longer. If you make radical changes to a platform, you don't have a platform any more. So it's much better to simply break with the past and have a completely new product. Certainly fixing the 5200 controller would have helped. Having some kind of quality review before titles went out would have helped (note that Coin-Op already had this, in the form of field play testing -- while the consumer groups just shot out cartridges without worrying about whether they were any good or not). One serious problem: The video game industry was /tanking/, and Atari was a video game company. I think that Tramiel had essentially the right idea, in that a new platform and a complete break with the past was necessary, but a team that was far, far too small for the real job, and the work had to have been started a couple years earlier. Corporate research was full of LISP Machines and whatnot, and there were interesting projects going on there (based on the 286, for instance), and possibly some of the ideas in this group could have been turned into a product. There were top-notch engineers in Coin-op and elsewhere. A project to essentially do what the Amiga folks had started, with the vision of Alan Kay, and serious systems-level engineering that people in the company did posess might have been possible. Imagine something like the Macintosh, but with a gamer soul at its core. Atari would have had to ditch its addiction to the living room TV, and it would have had to understand how to /really/ do word processors and such (but probably could have gotten Microsoft interested in a project of this scope). It's always easy to look back on this kind of thing with 20-20 hindsight. I think that a lot of the pieces were around, but there wasn't any vision or coordination to make something like this happen.

Initially I was going to replace the "DONKEY KONG" title with "LANDON DYER" (same number of letters, heh) but I chickened out, and I'm not sure there was enough space in the ROM anyway. In retrospect the triggering of this was way too obscure, and the reward was paltry, but I was worried that an easy to find easter egg would cause management to get upset. So, like I said: Really hard to get, and totally not worth it. Kudos to Don for figuring this out. I hope he had fun doing it.

Developing a game on an Atari 800 with an 810 drive; source code disk is in the drive. The game crashes and somehow does a JMP to the "format floppy disk" routine in the ROM. The drive goes "tick tick tick...." and all the source code is vaporized. This is why you keep backups. [Didn't happen to me, but to a friend of mine, Jack Palevich. He was pretty miffed. I don't recall if he kept a backup.]

No. Corporate policy was to return ideas to the senders, with a letter stating that Atari did not accept unsolicited ideas from non-employees. You'll find that most corporations have a policy like this. It's to avoid being sued for "that Pac-man thing that I wrote you about years ago, and that you stole from me!" IIRC we were instructed to tell our managers if we ever got an "idea" letter.

The Transputer (aka the ATW or ABAQ) was released, i remeber seeing then in the last 2 Atari user shows in London, I think the company that co-designed them (a british company called Perhillion or something like that ...) the cambridge comapny that co designed the abaq/atw were based in the same offices (allegedly) as failed british micro maker CAMPUTERS LYNX The announcement of the ABAQ was an utter surprise to the Atari engineering staff in Sunnyvale. Like, "We announced a new computer!" / "WTF?" / "Yeah, some Atari office in England announced a Transputer-based workstation." / "WTFF?" I was a fan of the Transputer -- really a sweet instruction set -- but I knew how hard it was to program. Jim Tittsler made the observation that the machine was basically "impervious to programming." The Transputer never got the technology investment it needed to take off (and don't get me started on Occam). It was microcoded, and the microcode had some impressive bugs (like, "Don't shift by a negative amount, because the CPU will lock up for about 4 billion machine cycles.") Unlike the ARM architecture (which had good tools support and a number of neat improvements, such as Thumb), the Transputer always seemed to be permanetly in a state of "it'll be fast enough 18 months from now."

I had a bit more time to look at this, and I'm certain that it's not the final version of DK. Some things that I know are missing: - A formatted comment near the gravity control stuff (label 'PtSVel') that explains the equations of motion. - A piece of copy protection code that changes some zero-page values (in order to cause havoc). The JSR instruction is later checked to see if the stomper has been removed. - The code in the file 'tr' that implements the easter egg isn't integrated anywhere (should be near the code that draws the title screen). If someone was mucking with the code to (say) do a port, I could seem them removing the latter two, but not the first comment. Maybe this is a mix of files. The proof is in the pudding, however. If it builds (and I'm not even going to try...) and appears to work, then people will certainly find it useful. The only major bug that was fixed "late" was a situation where Mario could fall and fall forever; it was possible for his velocity to grow so that he wouldn't evern intersect with a girder, so he'd just loop around off the bottom of the screen and back to the top. I think I just noodled the collision rectangles to deal with this. So I would characterize this as "mostly finished" with me probably just twiddling my thumbs and adding the above stuff during the two weeks at the end of the project while Q/A ran through it. [Yeah, things were kind of fast and loose that way; programmers could add stuff during final testing and get away with it.]

What's the story on redistribution of this? A few people have seen the pointer to the code in my blog, registered on AtariAge, and are unable to download it [i don't know the reason]. Any objection if I re-host somewhere? Or would you prefer it to remain accessible only via AtariAge (or via the Atari Museum site)? Completely up to you. -landon

The programmer in question was adamant at the start that using FORTH was superior in terms of speed of delivery, space occupied by the code, and quality. In other words, much better than programming in assembler. He'd deliver DK Jr in record time. Management believed him. So he got Atari to spring for this $800 FORTH package that came with a thick binder of documentation printed on funny-colored paper (to prevent photocopying) and wouldn't let anyone near his code. Nobody else got a copy of this package. He mucked around in FORTH getting stuff prototyped and "ready to write code" for months. And after like five months he had one or two screens working, and no sound, and the thing sucked. And all the time he was bragging about how FORTH was going to let him whip through the rest of the game like snot through a greased pig (or something like that), but it was already late, it was clear he was at sea and wasn't going to come through. There had been a bunch of layoffs, but none that had affected engineers (just sales, marketing, manufacturing, and some research folks). So in the first round of layoffs where they had to jettison actual engineers, he was gone. Pretty bitter about it, too. I remember a sense of relief that they'd finally bagged him. So Jeff Milhorn and maybe someone else took over, and delivered a pretty good game in a few months. I was impressed with the recovery. Later, I heard from a Coin-op veteran something along the lines of, "Yeah, every couple of years someone discovers this FORTH thing and thinks they can do games in it, and it never works out." Turns out that Atari *did* ship a game written in FORTH: It was the pinball machine "Four by Four."

I have no idea what VGER was. I do remember that the MV/8000 was used for both engineering and office work (one of the things that made turnarounds so bad -- like 45 minutes -- during "working hours" were the number of people logged in and doing email on the crappy script-driven office management system). So you should find plenty of toothy political gold in the email databases from the DG machines. The Data General minis were indeed sweet machines; I would have preferred a Unix system, but the DG had a very capable screen-based programmer's editor and a pretty nice file system. Atari could have done worse.

Was that DK or DK Jr? I seem to remember that being about DK Jr. but I could be wrong. Tempest That was DK Junior. I never wrote any code for it. The original programmer was fired before it was finished, but I don't remember who wound up completing it. Probably Jeff Milhorn (who was the "junior" programmer on it) and Kevin Sacher (who was managing the group by then). I do remember that Dk Jr. was started in FORTH, and was an ego-driven disaster until that nonsense stopped.

As far as I know, CAMAC was an MV/8000 thing and wasn't available on VAX/VMS. When we moved to the VAX/VMS systems we started using the same tools (assemblers, etc.) that the Coin-Op folks were using. Kind of painful, but their assemblers had some good ideas.