In this article I describe ways in which aspects of the UNIX system aided and influenced the development of two video games, “Ballblazer” and “Rescue on Fractalus!”. Not only was the development of these games aided by the presence of UNIX software tools, but many useful ideas were suggested by examination of the tools’ thoughtful design.
we decided to design and implement one or two “throw-away” games as a combination rite-of-passage and reality check. These games would also serve as a way of identifying the areas that would profit most from the creation of some software tools. It’s a credit both to the members of the Games Group and to the ideas we championed that the “throw-away” games have gotten such enthusiastic reviews
The cross assembler and its macro library were written in Lisp. The Atari end of the download programs and the drum machine program were written in our Lisp-like cross assembler. The rest of the tool software was written in C.
Lisp was chosen because it took only two weeks to implement a cross assembler that allowed both assembler macro definitions and arbitrary Lisp expressions to be included in the assembly task. It also meant we could extend or reconfigure the assembler as we discovered unforeseen needs and deficiencies.
The ways in which the UNIX system aided the games design process can be grouped into two broad categories: software available on UNIX systems, and capabilities of the UNIX operating system itself. Available software included program languages, editors, communications programs, and other miscellaneous tools. The capabilities of the system included a hierarchical file system that made file sharing convenient. input/output redirection, and a general “permissiveness” that kept the system from getting in our way when we needed to do something strange.
You can always tell an article written by Peter S. Langston, and I mean that in a very good way. Amongst many other developments, PSL has been responsible for making DECTalk speech synthesizers (meant for phone call management at Bell Labs) sing extremely well.
(I tried to look up a biography, but found none on his background. “Peter Langston, AKA Peter S. Langston” seems to hint at MIT, where everybody is a three-letter-acronym (TLA) as in ‘first name, middle name or mother’s name initial, last name’.)
No, my own contraction. For a while pretty much every Unix paper and weird-music-thing website I looked at was by Peter Langston. Founder of Lucasfilm Games, much requested banjo teacher, member of the Wretched Refuse String Band … and far too much else to mention: Peter Langston’s Home Page
Well, with those DEC connections, I thought it might be plausible. (Also, the “S.” in the name is sometimes referred to and sometimes not, e.g., Wikipedia has him listed without.)
I also remember marveling at the lisp based 6502 assembler he used to make Ballblazer. The music had attributions of all the people who contributed, and it was like a who’s who of modern jazz. I still remember that amazing riff. I worked at GCC at the time and we got the source code so we could port it to the 7800.
Extraordinary in that on Atari800, vast majority of games were written in 6502 assembly. Mostly for speed, but also apart from Deep Blue C (?) which was a noddy C compiler, I’m not aware of anything else on Atari800.
First time that alien jumps up in front of you, I jumped out of my seat!
It’s interesting that nothing like PL/M emerged for the 6502. (I’m not sure, if this is a testament to the instruction set and associated assemblers, the viability of which wouldn’t have called for any mid-level tools, or for other reasons.)
8 bit micros where never designed for self compile of any programs or running high level languages. You had a PDP 10 to run all your development software. Only later did better
cpu’s like the 6809 or the Z80 have the power for PL/? but by then C had taken over.
This is certainly true for early systems, and it was even true for the early 16-bit era (e.g., for the first Macs, you needed a Lisa or a Mac XL to do the programming). However, higher level tools that aligned themselves to the microporcessor register level certainly had quite an impact on the S100 platform, not least by CP/M.
The Z80 and 6809 are quite powerful enough to host a high level language - much more of a struggle for the 6800, 8080 and 6502. But AcornSoft did produce a few for the 6502: Lisp, Forth, BCPL, Logo, Pascal, Prolog, Comal.
PASCAL and COMAL where also present on the PET (even COBOL!), and, I believe Lisp, as well. (I’d expect the same for Forth, but I’m not sure. But there were definitely versions for the C64.)
The problem with these languages is that they don’t let you exploit any design decissions regarding the use of registers or flags, like CP/L PL/M does. Admittedly, the available choices are rather limited, but I don’t know any higher or structured language that would have been expressedly designed for use with the 6502. I guess, it should be possible to come up with a language, which lends itself especially well to the 6502 by its basic constructs.
(This may be a challenge… )
I am guesing here, that all of the above use some sort of vitrual machine, rather than pure 6502
code. Infocom had a Z-machine for sereral platforms, thus thier games run on any thing that had ample ram. Sadly lots of good text based software seems have got lost when everbody moved
to some sort of GUI interface and 32 bit cpu’s.
For me, the important point is that there’s a high level language which can run on the micro - the distinction is between self-hosted development on the one hand, and using a nearby minicomputer on the other. Although native code has its advantages, it also has disadvantages, and it’s the productivity of the programmer that I’m thinking of. I suppose, give this thread’s origin in programming games, the performance of the code is also important. But I don’t think we can say that all games are implemented in native code.
Regarding virtual machines or emulation, I’m certainly guilty. But it’s mostly for the ability to switch context, the kind of overview you can achieve over a source text with modern GUIs and bigger screens, and also for the speed of the development tools. (And, of course, there are systems that I don’t have and will never have access to.) But I do prefer recreations of resident tools, which actually existed at that time.
(E.g., for the PDP-1, a recreation in C of MIT’s Macro assembler from the early 1960s, or for the 6502 something that is close to the self-hosted assemblers.)
BTW, regarding the 6502, the MOS resident assemblers where actually richer in syntax and more powerful than the original cross-assembler(s). There’s a real feat in the kind of augmentation that was achieved by Lucas Arts and by the tools they created.
A nice story about the first resident 6502 assembler, for the MDT-650 (MOS’ Microcomputer Development Terminal):
Compas developed the software for the MDT-650 and Larry Hittel, at his company Comlog in Phoenix designed the hardware. The MDT was a dual 6502 processor development terminal with ICE capability for the 2nd processor and built-in editor and native 6502 assembler on the 1st processor. The native 6502 assembler produced by hand compiling the FORTRAN to 6502 assembly language, assembled on the FORTRAN version and burned into ePROM for the MDT.
There was a nice language for the Atari 8-bit family called ACTION! that had an integrated editor and a nice mapping onto the hardware. I never used it, but it reminds me of the first version Turbo Pascal on the PC.
)