done back in the day...

[squidbait]

We have a plethora of tools and techniques for coding 2600 games today. I'm wondering though how was it originally done? When the Atari first came out there weren't home computers etc. What tools did the first VCS programmers use? Later when the Atari 800 etc came out did 2600 authors move to it?

[Keatah]

Paper. Pen. Brain.

[tschak909]

I can attempt to explain as best I can...A lot of context will be lost, because a lot of the tools that were used at the time don't really have analogues, today. I will try to explain as best I can, which will be difficult because there were a lot of ways to do it:

For a long time, until glass teletypes became inexpensive enough to use for every programmer, you would write your program (source code) down on paper, with pencil. Each instruction.

Let's start circa 1977:

Then you would hand your program code to an operator who either had access to a terminal, teletype, etc...which was attached to a computer, e.g. a DEC PDP-11. They would take your changes, and use the resident text editor on the computer to make the changes, and then run the cross assembler, which would either successfully assemble the source code and produce a binary, or not be successful, and produce a list of errors that require changes and attention. Either way, the assembler would produce an output listing showing both the source code, and hexadecimal forms of the output machine language, assembled at the final addresses. The output of this listing could then be marked up with pen, and sent back to the operator for further revision and assemblage.

The binary would be punched onto paper tape, which could then be loaded into the programmer's development system, which I will explain a bit later.

Let's go a bit furher in, say, 1979:

Later, as computing power ultimately democratised itself, each operator would have access to either a terminal on a big computer, or a small computer at their desks. The programmers would be responsible for their own source code management (managing their code, typing it in, backing it up onto other medium, e.g. other floppies), and they would use the text editors and assemblers directly to generate binary output.

What were the text editors like?

Welp, Depending on the system you had access to, most of them at that time were very line oriented, and you would send commands to edit pieces of text, like:

:a

Start typing a few lines.

Anything you want, really.

Just go right ahead.

When you're done, just type a period by itself.

.

and you'd have commands to do search and replace, go to specific lines, etc... and you would have to know ahead of time what you wanted to edit, and where. It took a lot of planning. When 'vi' and the other full screen editors started appearing on these systems, it really was such a quantum leap forward to be able to SEE WHAT YOU WERE CHANGING!

So let's say you were done editing and you wanted to assemble the code to produce a binary?

You'd do something like this: (I am using UNIX as an example here, as my RSTS/E, RSX-11/RT-11/etc knowledge is buried way too deep in brain)

let's assume you have a 6502 assembler called 6502asm on the machine, and it spit out raw binaries by default:

% 6502asm mygame.asm

(... some time passes...)

0 errors reported, 2048 octets of code generated.

 

%

Totally fictitious, but I hope you get the point, the various assemblers etc used were typically written in-house in languages like FORTRAN, and tended to be rather slow.

Once this was done, you were at least left with a list file, usually the same name as the source, with a different extension, such as mygame.lst.

If you did your job right, you'd have an object file, e.g. mygame.obj that you could dump into the memory of your development system, and hopefully a symbol file that would show you where variables, constants, special memory locations etc were defined, so as to aid in debugging.

So now that you have this code, what next?

I mentioned the paper tape method, and honestly, if you _really_ want to know how that would work, ask me further in the thread, as that requires one hell of a digression.

What if you have your own terminal?

Now I can describe the development system:

The development system was typically an Atari VCS, which has been opened, the CPU has been removed or bypassed, and attached to a homegrown box (or a microprocessor development system of sorts, if you want a commercial equivalent, look up the HP 64000, for example, hideously expensive, but it could work wonders.). You would also have a specially made cartridge that contained RAM and circuitry to allow for that RAM to be written to either via RS-232, or an 8-bit parallel port. Lots of different names for such a device, such as a "Romulator".

A common configuration would consist e.g. of an ADM-3A terminal, which had two serial ports, one of them was intended for connection to the host computer, the other, was initially intended for a printer, but it is in essence a pass through port which can be toggled on and off under either manual or computer control, this was the EXTENSION port on the 3A. The Romulator would be connected to the extension port, and when you were done compiling, you would connect the romulator to the extension port, and run a home grown utility to simply dump the object code through the terminal.

% bindump mygame.bin

PLEASE READY RAM CARTRIDGE FOR RECEIVE AND PRESS <CR>

(operator would do so, usually involving turning on the VCS and press enter)

(lots of nifty non human readable garbage on screen as code flows through the terminal and out the extension port..beeps happen as BEL is interpreted by the terminal.)

Once done, the operator would typically have a reset switch on the development box, which would send a reset signal to the transplanted processor on the development box, and the game would run.)

How about debugging?

Well, this one is an interesting one, because VCS development was very much like what was considered "embedded systems development" at the time. That is, you were using a processor to replace discrete logic, and thus you treated what you were writing as something that directly affected hardware. I must make this point in this day and age, because everything has since become unbelievably abstracted.

In a nutshell, this meant using devices like the HP-1611A logic analyser, which would have its probes connected to the individual pins of the TIA, the 6502, and/or the RIOT, so that you could watch the signals on the bus, and tell the logic analyser to tell the homebrew dev box (by asserting a signal high or low as needed), TO HALT and go into single step mode.

And yes, That behooves me to mention, that the development box had a facility so that you could step through code, maybe show the contents of registers on a 7 segment hex display, or with binary lights...and provide A way for the programmer to see what's going on.

You might think this was barbaric...and..well...yeah, it was...but (a) it was all that anyone had, and (b) the programs are so comparitively small, it was, and is possible for a VCS programmer to have the whole game in his head enough to understand the cryptic output of a few choice binary or hexidecimal or octal digits.

Because the VCS's video system is literally bit-banged by the software, a dev back in the day hitting pause on the dev box, would cause the whole screen to go black, and crashes were easy enough to see, because any crash would cause the screen to streak in interesting ways (because the TIA write registers are latched, they keep their last value, until changed)

So you would have this whole cycle of:

* Write code

* Assemble code

* Dump code to romulator

* Reset the dev box

* Play the game

* Crash? Look at the dev box and the analyser

* Think a lot. Smoke a joint. Vassilate between thinking you're a god, and an invalid who needs a crash helmet, a chin strap, and a drool cup...

* Repeat this process until you have what you want, or until you're transferred onto a different project, or your boss lets you go, or you leave the company by walking out to the car in your underwear.

--- ok, and?

well, there were other variations as well. Garry Kitchen, for example, wrote Donkey Kong on an Apple ][ Plus, with a modified Language card (which is in and of itself a RAM card) which had a 4K ROM space mapped directly onto a romulator umbilicus that connected to the VCS's cartridge slot... The user would write code, and assemble using an assembler (you could even have used the Apple mini-assembler that was part of the old integer basic roms), and what would be in memory would appear as code to the VCS.

The guys at Apollo (and maybe others) later e.g. 1981-1982 would use an Atari 400/800, with e.g. the Atari Macro Assembler, or Atari Assembler/Editor, to generate raw code, and have a cartridge umbellicus that would e.g. plug into the right cartridge slot (each cart slot was 8K in address space, so plenty of room to make a straight romulator umbilicus with very little circuitry, not much more than some SRAM would be needed.)

Others in 1981-1982 timeframe would get a CommaVid MagiCard and literally use that to program VCS titles, or to at least understand the VCS registers (even though the MagiCard did have the ability to save to tape, the sheer thought of trying to input machine code on those keyboard controllers is enough to put me in the fetal position, if for no other reason than the pain on the fingers...a good hex keyboard is a whole different matter...) I often wonder if there were people actually masochistic enough to make their own keyboard controllers with full impact keys to be able to use the MagiCard as a development system?!

Still later, there were development systems for machines like the Apple ][, the Frob being the most legendary example (it came with LOTS of goodies, graphic utilities, etc... for about $495, if I remember right)

Anyway, I hope this has provided some insight, and perhaps further discussion. I KNOW DanOliver, and Joe Decuir, and a few others can jump in here... I tried to provide a contextual bridge because I know that so there's so much domain specific knowledge that never really gets carried across when people ask this question...

...hope it helped.

-Thom

Edited June 13, 2016 by tschak909

[+frankodragon]

[tschak909]

Yes, but even David Crane's explanations don't really explain adequately the whole process, only from a conceptual level.

 

-Thom

[gauauu]

Wow, Thom, that was amazing. Thanks for taking the time to type that up.

[Kylearan]

Indeed, that was a great read - many thanks, Thom! I love that kind of historical stuff.

[Mr SQL]

Paper. Pen. Brain.

X2!

 

Not all programmers used a Logic Analyzer or an Oscilloscope back then, or even the debugger in Stella today.

 

I still prefer to use Tron; it's more fun because you get to write more code, and you get better and better at writing Tron the more you practice just like anything else.

 

 

 

 

What were the text editors like?

Welp, Depending on the system you had access to, most of them at that time were very line oriented, and you would send commands to edit pieces of text, like:

:a
Start typing a few lines.
Anything you want, really.
Just go right ahead.
When you're done, just type a period by itself.
.

and you'd have commands to do search and replace, go to specific lines, etc... and you would have to know ahead of time what you wanted to edit, and where. It took a lot of planning. When 'vi' and the other full screen editors started appearing on these systems, it really was such a quantum leap forward to be able to SEE WHAT YOU WERE CHANGING!

 

 

Lots of fans of vi today! There were fullscreen text editors out already though; vi started out as a line editor like the one you described and Wordstar had a full screen editor around the same time (1978).

 

The Commodore PET had an awesome full screen text editor first in 1977 built right into the BASIC OS and much better than the line editor in the contemporary TRS-80 (edit linenumber).

 

You can still have fun with line editors today even on the Windows, I use it when it's just a few lines

 

From the shell:

copy con filename

type stuff....

type another line...

hit ctrl-z to end.

[tschak909]

Some hardware pictures:

 

A DEC PDP-11/03 minicomputer circa 1978...

 

 

Common enough in development houses. This is an LSI-11 based PDP-11 (Basically most everything on a pair of boards). You also see a DEC RX-02 floppy drive unit that contains two 8" disk drives, that hold approximately 512 Kilobytes of data on a disk (256 kilowords). The RX-02 could also read disks from the RX-01, as well as any IBM 3740 compatible 8" floppy (which made interchange with other minicomputers at least somewhat possible with some coding grease). This machine is a desk-side unit that could very well be placed at a single programmer's desk, or maybe even shared across 4 or more programmers, depended on the budget. although with the 03, this would have been very painful...

 

Another PDP example, this one could be shared across the software company:

 

 

A large UNIBUS PDP-11/70, with several RL02 disk pack drives (each disk pack capable of storing 10 megabytes of data), an RX02 for backup and personal storage, and perhaps 9-track tape for bulk backup.

 

You'll also notice something interesting there too, a front panel of blue switches...This was used to literally bring up the machine, as the earliest machines did not come with a boot ROM (think BIOS or UEFI today), so if you didn't have a boot rom somewhere in memory, you'd have to toggle in a small program to actually boot the operating system off of one of the drives (or even from the DECtape drive, if it were a fresh install) ... and YES, the front panel was used to debug the machine when it _really_ crashed... (I put this here before somebody quips me about it!) but I digress.

 

The disk media for storing games on these systems were most commonly 8" floppies, at first, followed by 5 1/4" floppies.... I have pasted a picture here, comparing the sizes:

 

 

The ADM-3A terminal I mentioned was insanely cheap and ubiquitous for development systems, and looks like this:

 

and, this is a HP 1611A logic analyser. The ZIF socket you see on front, connects to a "pod" which provides the probes to connect to the processor socket in the target machine (in this case, the VCS.. of course, since the 6507 is a pin reduced 6502, some phenagling had to be done on the hardware side..but not much.) and this really brings up an important point too, companies like Atari, and Activision had technicians who were available to cook up any sort of hardware needed to bridge a gap...from the development hodge podge boxes, to modifying a logic probe pod to work in a target system.

 

 

Close up.

 

Hope you all enjoyed that,

-Thom

Edited June 13, 2016 by tschak909

[DanOliver]

Long after the start but at Apollo and VentureVision we used an Atari 800, the Assember cart, down loaded to a EPROM burner. EPROM moved to a ZIF on a cart board and then inserted into a 2600 like a normal cart. For debugging we looked at the image on the TV. Using a large screen help see dots.

 

Later for Telepathy I used an Apple II, an instant assembler I wrote, 512K RAM drive and a Frob. Turn around from compile to seeing the game on screen was a second or two. Completely changed the development. Best system I've ever worked on. Wish I still had it.

[tschak909]

Contrast this to today, where I am typing in a window in emacs, and I can see the output in Stella almost immediately after a recompile....

 

 

I know Dan has alluded to this before, and I've used variations of it in other environments....Funny thing is, I'm tempted at this point to modify Stella to set aside a shared memory segment that the compiler can just continuously recompile and dump the object code straight into. The impact on my development machine would be negligible, and I could literally watch the game output as I'm typing out code.

 

 

-Thom

[Paul Slocum]

Once they had assemblers, then it's really not that different from what I use today. I still use a EPROM emulator with a serial port to do C64 development (which is very fast), and I use a Cuttle Cart for Atari 2600. Often I use up testing more on the real device than on the emulator.

[ataridave]

What software and hardware was used to develop games for the Atari 2600 in the late 1980s?  Games like Solaris and Ikari Warriors.

[tschak909]

On 4/27/2023 at 3:05 PM, ataridave said:

What software and hardware was used to develop games for the Atari 2600 in the late 1980s?  Games like Solaris and Ikari Warriors.

For Solaris, Doug Neubauer built a custom ISA card for his PC that provided a shared memory area for the assembled binaries that was connected via a cable and cart board to the VCS. It provided a simple debugging environment.

 

-Thom

[ataridave]

On 4/28/2023 at 5:40 PM, tschak909 said:

For Solaris, Doug Neubauer built a custom ISA card for his PC that provided a shared memory area for the assembled binaries that was connected via a cable and cart board to the VCS. It provided a simple debugging environment.

 

-Thom

Interesting; thanks!  I'm assuming that Doug (and others who were programming games for the 2600 in the late 1980s) was using assembly language?

[MrMaddog]

On 4/27/2023 at 4:05 PM, ataridave said:

What software and hardware was used to develop games for the Atari 2600 in the late 1980s?  Games like Solaris and Ikari Warriors.

 

Atari Corp. (late 80's) programmers used a cross assemblier on a ST computer with the interface card plugged in the 2600 or 7800.

 

This was a practice called "eating your own dog food" where the company uses it's own products...

 

[ataridave]

That's really interesting!

[stepho]

For me in the late 80s and 90s on non gaming devices, I'd build my binary on a DOS based PC, burn the image to an EPROM, plug the EPROM in and see what happens.
Also had a big pile of EPROMS being erased under a UV lamp.
A RAM based EPROM simulator certainly would have made my job much easier - oh well, 20/20 hindsight.

 

My equipment was modified to have a bank of LEDs hanging off it that my code would trigger on/off as it passed through various points (eg turn on LED3 when entering interrupt handler, turn off when exiting handler, or turn on LED5 when a particular state is reached).
I'd hook up an oscilloscope to these LEDs, record a run and look at the recording to see the timing and which routines/states were being reached.
I still use this technique for time sensitive code that can't be single stepped with a modern debugger (typically when my code is watching external signals that can't be slowed down).

[tschak909]

This video shows the process of doing #gamedev using other, larger systems to develop software for the #Atari 2600 and 5200 game consoles using a cross assembler. This example contrasts a cross assembler from Sorcim running on #Atari8bit and #S100 hardware. Enjoy. #retrocomputing #retrogaming

 

[tschak909]

I actually wonder if an RP2040 could form the core of an ICE and EPROM emulator? hmmm

 

-Thom