Atari 2600 Program Development

1
Atari 2600 Program Development

• Joe Decuir
• jdecuir_at_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 cant 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 environmentTesting 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 wasnt 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
• 45 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

• 000 Vertical Sync
• 001 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-0C3 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