Atari 2600 Program Development

1. Atari 2600 Program Development Joe Decuir jdecuir@ieee.org.com alumnus of Atari & Amiga

2. Agenda • Goals and non-goals • Why do this • Requirements for Program Development • Development Tools • Hardware environment • System programming model • Example Game Design (Combat) • Suggestions

3. Goals for today • Audience understands what is required to develop game software for a production Atari 2600 VCS • Some discussion about how that might apply to developing game software for successors, both hardware and emulator software. • Not goal: demonstrations – I can’t do that without a video projector.

4. Why program for the VCS today? • There is not a mass market to buy cartridges • There is an emerging base of users who enjoy simpler games: • Owners of original Atari 2600 VCS consoles • PC owners running emulators • To create games without the huge effort involved in creating modern graphics-intensive games. • Summary: fun, education, impress your friends

5. Requirements for Program Development • Target environment requirements • Specifications for the hardware, registers, etc • Program generation tools: assembler • Target environment emulator, hard or soft • Program debug tools • Program distribution: • ROM cartridges • Binary image files for use on emulators

6. Objective of Program Development • Produce a 6507 binary image: • 2-4K bytes for use as a 2600 cartridge • Possibly larger when used with a software emulator, particularly if it can emulate bank-switching techniques (e.g. PCAE 2.2)

7. Development Targets • There are several development targets: • Original Atari 2600 hardware • VCS Hardware clones (e.g. Coleco) • Modern hardware clones, e.g. LCD handheld models • PC emulators (e.g PCAE 2.2, etc) • The capabilities of the successive targets may exceed those of the original hardware, in memory, but they have to match some other limits to remain compatible with old games.

8. Original Production 2600 Hardware Resources • 6507 at 1.2MHz (3.579545 / 3) • 6502, 13 bit address space, no interrupts, RDY • 128 bytes of RAM, mapped to 00XX, 01XX • Space for ROM cartridges of up to 4KB • Two joysticks, supported by TIA and 6532 • TIA video and audio chip • 6532 Timer

9. Original Production 2600 Hardware Limitations • NO host development capabilities • NO interrupts – single thread for everything • NO DMA, 6507 does everything • NO vertical support in hardware • Very small RAM • Small ROM, 8K address space Note: software emulators can remove these limitations, a boon for program debugging.

10. Original 2600 Program Development Environment • 6502 Cross Assembler, based on host • E.g. timesharing machine, or DEC PDP-11 • Hardware Emulator, w/RAM in code space • Debug monitor, for downloading and manipulating object code • HP-1600 series symbolic logic analyzer • Capture and disassemble bus traffic • Pre-trigger or post-trigger on bus values

11. 6502 Tools • 6502 is 26 years old; current tools are scarce. • Self-assemblers for 6502 code ran on Apple II, Atari 800/PCS or Commodore 64s • Windows or Macintosh PCs have plenty of resources to run cross assemblers (or compilers) for 6502. They also exist for older machines: http://www.6502.org/crossdev/asm/index.htm. • 6502-specific hardware logic analyzers are out of production • They might be available used

12. Simple way to test game code • Make a ROM image • Burn a PROM • Mount it on a cartridge • Plug it into a production VCS • See what happens • Iterate until it works as intended

13. Easiest VCS Development Today Start in a soft environment: • Use suitable PC Emulator (e.g. PCAE) • Generate assembly code: • PC Cross-assembler • Run the code in the emulator, with Debug tools turned on

14. PCAE 2.2 Debug Features • An example Atari VCS emulator for PCs • Display and/or modify: • Program code • 6507 registers • Zero page RAM • TIA registers • Current virtual beam position • Online command and TIA register reference • Breakpoints on conditions http://www.oneminuteleft.com/emuatari2600.html

15. Hardware environment:Testing ROMs The developer needs only two tools: • PROM burner • PC based • Stand alone serial port devices • PROM cartridge with socket • 4KB DIP package PROMs are long obsolete • Extra logic is needed to invert A12 as a chip select (e.g. an inverter)

16. Making a Hardware Debugger • Get a 6502 evaluation board with a debug monitor: KIM-1 ; JOLT (using TIM 6530 chip; Rockwell AIM-65; Synertek SYM-1; EPE See: http://www.6502.org/oldmicro/trainers.htm • Wire wrap a board with: • 6507 socket, wired to the 6502 pins • Decoder logic replacing the A12 pin on the 6507 • At least 4KB of RAM for Code • Serial connection to a host PC, if not on eval board • Take apart a 2600 VCS, remove the motherboard, remove the 6507 chip, connect the 6507 motherboard socket to the debug board socket.

17. Hardware test system diagram Hardware Debug Board W/monitor RS- 232 Optional Hardware logic analyzer Host Assembler System Modified Atari VCS w/6507 socket TV Game controllers

18. Hardware vs Software Debug environments • Software emulation wasn’t feasible until recently • PCAE runs full speed on a 486/100 - 1996 • Software debug has many advantages: • The emulator knows the internal states of the CPU and the TIA • The emulator can freeze the action anywhere, while maintaining the game screen • Software emulation of game controls is tough • No standard hardware that matches originals

19. Atari 2600 Programming Model • System Block Diagram • Graphics • Controls • TIA registers

20. Stella System Block Diagram

21. Stella System • TIA video chip (see below) • 6502-based processor, “6507”: • 13 bit address, no interrupts, RDY line • 1.2 MHz • 6532 combo • 128 bytes of RAM (all mapped into zero page) • 16 bits of parallel I/O (joysticks and panel) • timer (interrupt not used) • cartridge slot for 2K or 4K ROMs (24 pins) • 2 game control ports

22. Stella Graphics • Fundamental pixel resolution is 1 color burst clock (280nsec, 160/line) by 1 line. • Motion objects are 1, 2, 4 or 8 clocks/bit. • Motion objects may be replicated in hardware. • Playfield is 4 clocks per bit. • Playfield bits are either repeated or reflected in hardware.

23. Other TIA chip features • 4 7-bit palette registers • 15 collision detection latches • 2 channel sound system • variable prescaler • 4+5 bit polynomial counters • volume registers • trigger and potentiometer input ports • trigger input could be used for light pens or light guns.

24. Human Input Requirements • Console controls: • Game select, and start switches • Options: handicaps, color/monochrome • Various types of game controls: • For TANK, etc: a joystick with a “fire” button • For PONG: a dual analog potentiometer • For Driving: a rotary control • For head games: a keyboard

25. HID implementation • One power switch • 5 bits of console parallel I/O, not scanned • 5 + 5 bits of game control I/O, not scanned • 2 bits in TIA, 8 bits in parallel ports • 4 bits of potentiometer input, in TIA

26. TIA Register Map: 00-0A • 00:0 Vertical Sync • 00:1 Vertical Blank • 02 Wait for Horizontal Sync • 03 Reset Horizontal sync (testing) • 04-05 Number and size of P0/M0, P1/M1 • 06-09 Color/lum registers • 0A Playfield controls

27. TIA Register Map: 0B-1F • 0B-0C:3 Player reflect bits • 0D-0F Playfield graphics (7-4; 7-0; 7-0) • 10-14 Horizontal reset, all 5 objects • 15-16 Audio control • 17-18 Audio frequency • 19-1A Audio volume • 1B-1C Player graphics (8 bits) • 1D-1F Missile/ball enable (1 bit each)

28. TIA Register Map: 20-3F • 20-24 Horizontal motion registers (7-4) • 25-27 Vertical delay: P0, P1, Ball • 28-29 Reset Missiles to Players • 2A Horizontal Motion strobe • 2B Horizontal motion clear • 2C Clear collision latches • 30-37 Collision detect latches • 38-3D 4 pot inputs, 2 trigger inputs

29. Example Simple Game Design • General architecture • Display generation • Game play • Sounds

30. Combat Game Architecture • The code has three components: • Game play code • Process game control and console control inputs • Process game results (e.g. collisions) • Decide next graphics and sounds • Graphics display code • Graphics tables

31. General VCS Game timing • In Vertical Blank: • detect collisions and control inputs • decide new game conditions • computer new game graphics pointers, as inputs to the display kernel • In Display, for each line or two: • step graphics pointers • fetch graphics • wait for horizontal blank, and write graphics

32. Combat Main loop • VCNTRL: generate vertical sync • GSGRCK: game select and reset • LDSTEL: load Stella (TIA) registers • CHKSW: read the joystick switches • COLIS: Detect and process object collisions • STPMPL: Move players and other objects • ROT: generate & rotate object graphics • SCROT: generate score graphics • VOUT: display the game

33. Horizontal motion • For each moving object: • Given the horizontal position (0-159) • Compute a loop count for a wait loop, mod 15 • Compute the horizontal motion step, -7 to +7 • Wait for horizontal sync • Run the wait loop • Reset the object motion counter • Write the horizontal motion register • Write HMOVE after all registers set up

34. Combat Display Kernel • For pairs of horizontal lines: • Compute indexes to playfield: • move 2.5 bytes from ROM tables • playfields are vertically reflected in software • For each object that is on, copy graphics • For 8 bit objects, copy graphics from RAM • For 1 bit objects, enable/disable • Use Wait-for-sync, and write graphics in horizontal blank

35. Concluding Suggestions • Acquire or create an emulator-based toolkit • Learn from existing code: • Download old ROM images • Disassemble them for study • Experiment by patching them and observing the results • Create original games, focused on game play: • Easy to learn • Difficult to master • Good luck monetizing your work.

36. Web Resources • Salon.com: “Atari Lives” • Salon.com/tech/feature/2001/07/09/atari/index.html • PC Atari Emulators, PCAE by Dullea: • www.oneminuteleft.com/emuatari2600.html • 6502 Tools: http://www.6502.org • Atari Hardware Manual, scanned: • www.atariarchives.org/dev/tia