"The Way it Should be Done" - writing Atari games at Lucasfilm, with Unix

Software
21

Here’s an interview with David Fox, the creator of “Ballblazer” and “Rescue on Fractalus.”

He talked about using the Lisp-based assembler. He said it was used successfully at least for Ballblazer, but its code production was so slow that they chose not to use it for their other games. It was a neat factoid to find out about this cross-assembler, though.

Another neat factoid is they used an Evans & Sutherland graphics system to do some of their beta testing for Ballblazer; I think he said using wireframe graphics.

The game was downloaded to an Atari 800 through a serial port connection for final testing.

Whenever I read stories about how system software for microcomputers was developed, I always read about the dev. team using this method of using a more powerful system to do it. It makes sense. While the hardware is being developed, you don’t want to be writing your system software on it. You want to use a more stable system for development, emulate the target platform on it, using cross-compilers and assemblers to generate your object code, and transfer it when the hardware is ready for testing.

It was more recently that I learned that it was common practice to do this with commercial application/game software, as well. When I learned 6502 assembly some years back, I read in the Atari Assembler manual that it was not written for development of professional-quality software. It said:

The Assembler Editor cartridge is designed to support intermediate-level assembly language software development. It is good enough in this function to be used by Atari’s own programmers for some system development.

The Assembler is powerful, and can do a great deal, but it is not a professional software development system. It is not well suited for development of large assembly language programs. A good rule of thumb is to take the amount of RAM you have in your system and divide by ten to find the largest amount of object code you can comfortably develop with this cartridge. Thus, an Atari personal computer system with 16K RAM can be used to develop object code programs up to about 1600 bytes in size.

This was due to the fact that you, of course, edited your source code in RAM, which took up a lot more space than the object code. Though, this assembler was capable of assembling from disk, so you didn’t have to load all the source code into memory, if you were just generating object code.

2 Likes
22

Sharp MZ 80K/A/B and 700/800 (CPU was Sharp LH-0080 but Z80 compatible) had allegedly at least Pascal, Forth (several of these), Lisp, C, Comal, Fortran, Logo. Of those I used personally only Pascal. Hi-Soft was one of the companies making those, another one was Hudson Soft. My brain is trying to tell there was a third one, began with K… Kumon? Komon?

2 Likes
23

There was Cobol for the MZ-80, as well! (I believe, it was a German vendor, at least, the only known documentation is in German.)
I think, Sharp’s “clean computer” policy, where there is just a basic monitor in ROM, paid off in this regard, as there is quite a variety in languages and competing implementations (just have a look at the various BASIC implementations for these systems).

The same should have been true for the Atari 800, where BASIC came on a cartridge and other cartridge based languages could have competed with this on equal standing, but I just don’t see this kind of variety there.

1 Like
24

I have slow memory: the software beginning with K was “Kuma”. See e.g. Beyond for the Sharp MZ-700

1 Like
25

Oh, “Beyond” is much like “Pharaoh’s Curse” on the C64, which was my favorite game back then. :slight_smile: (I believe, there was a similar game for the Atari 8-bit, of which this was a clone.)

The mention of FORTRAN is interesting: it had been used (together with fast assembler routines) early on in video game development (e.g., for Albert Kuhfeld’s version of Spacewar at the University of Minnesota, 1966-68), but is mostly neglected in this role.