[stella] The Latest FAQ

Subject: [stella] The Latest FAQ
From: "Mark Graybill" <saundby@xxxxxxxxxxxx>
Date: Fri, 18 Oct 2002 18:01:33 -0700
The Stella Mailing List FAQ

Updated October, 2002 by Mark Graybill

1. The Stella Mailing List
 1.1 What is the Stella Mailing List?
 1.2 How do I get on the list?
 1.3 Where are the list archives?
 1.4 What are the posting guidelines?
 1.5 Who is "Stella?"
 1.6 How do I get the FAQ?
 1.7 How do I submit to the FAQ?
 1.8 Where did the FAQ come from?

2. Getting Started
 2.1 Are the 2600 and 7800 difficult to program?
 2.2 What do I need to get started?
 2.3 What experience do I need?
 2.4 What books are there on 6502 programming?
 2.5 Where can I find info on the internet?
 2.5.1 Where is info specific to 2600/7800 programming on the internet?
 2.5.2 Where is general info about the 2600 and 7800 on the internet?
 2.5.3 Where is more general 6502 programming and tech info on the internet?

3.0 System Hardware Overview
 3.1 What are the Atari 2600 VCS and Atari 7800?
 3.2 What CPU does the Atari 2600 VCS use?
 3.3 What CPU does the Atari 7800 ProSystem use?
 3.4 What graphics chip does the 2600 use?
  3.4.1 What software features does the TIA have?
  3.4.2 What are the registers in the TIA and their functions?
 3.5 What graphics chip does the 7800 use?
 3.6 What I/O chip does the VCS use?
 3.7 What I/O chip does the 7800 use?
 3.8 What sound chip does the VCS use?
 3.9 What sound chip does the 7800 use?

4.0 Programming Tools
 4.1 How do I test code? (The Emulator)
 4.2 Where do I get coding info? (The Documentation)
 4.3 How can I read other peoples' code? (The Disassembler)
 4.4 How do I compile my own code? (The Cross-Assembler)
 4.5 How do I make programming go faster? (Programming Environment)
 4.6 How do I get my code to the 2600 hardware?
  4.6.1 The Starpath Supercharger
  4.6.2 The CuttleCart
  4.6.3 RAM/Flash Cartridges
  4.6.4 ZIF Cartridges
  4.6.5 Cartridge Manufacture
 4.7 How do I get my code to the 7800 hardware?

5.0 Basic Programming for the Atari 2600
 5.1 Where can I find programming tutorials?
 5.1 How do I start? (The Kernel)
 5.2 Program Structure
 5.3 How do I put something on the screen?
  5.3.1 The Background
  5.3.2 The Playfield
  5.3.3 The Players
  5.3.4 The Missiles
  5.3.5 The Ball
 5.4 How do I talk to the game controllers?
  5.4.1 The Fire Buttons
  5.4.2 The Joysticks
  5.4.3 The Paddles
  5.4.4 The Driving Controllers
  5.4.5 The Keypads
 5.5 How do I make it _do_ something?
  5.5.1 Vertical Positioning and Movement
  5.5.2 Horizontal Positioning and Movement
  5.5.3 Collision Detection
 5.6 How do I make sounds?
  5.6.1 Noise
  5.6.2 Music
 5.7 How do I provide score and status displays?
  5.7.1 The Divided Display
  5.7.2 Score Displays
  5.7.3 Status Displays
6.0 Basic Programming for the Atari 7800

7.0 Advanced Routines for the Atari 2600
 7.1 How do I display more than two players?
 7.2 How can the two halves of the playfield be different?
 7.3 How can I use six digit displays?
 7.4 How do I get more than 4K of ROM?
 7.5 How do I get more than 128 bytes of RAM?
 7.6 How do I display text?

8.0 Advanced Routines for the Atari 7800

9.0 Programming Info Common to Both Systems
 9.1 Common Problems and Gotchas
 9.2 Useful Tidbits
  9.2.1 How do I kill time efficiently?

10.0 The Zen of VCS Development
 10.1 What sort of masochist does this, anyway?
 10.2 How do I port Quake III and Unreal Tournament to the VCS?
 10.3 Is it true what they say about the VCS programmer groupies?
 10.4 Is this a great way for me to make my first million?
 10.5 Why should I post my code, what will the list do for me?
 10.6 Won't somebody steal my amazing secret algorithm?

11.0 Sharing and Selling Your Work
 11.1 How can I sell my work?
 11.2 How can I market my work?
 11.3 How many people will actually buy this stuff?
 11.4 What will people pay for this stuff?
 11.5 What are the major events I should know about?



1. The Stella Mailing List

1.1 What is the Stella Mailing List?

The Stella Mailing List is a meeting place for programmers of the Atari
2600 VCS and Atari 7800 ProSystem game consoles. It is used to share
code, programming tips and techniques, and other information related to
programming these systems. The list has also been peripherally involved
with the development of some new hardware for the Atari video game
systems.

The list started in 1996 as a special interest group for the Starpath
Supercharger CD project. Since 1996, the Stella List has evolved into
the primary clearing-house for game development for the Atari 2600 and
7800.

Stella List members represent programmers who work collectively to
solve technical problems, and also observers who offer game design
advice and playtesting.  It provides a place for peer review and
collaboration, as well as assistance and guidance for struggling new
programmers of these systems.


1.2 How do I get on the list?

Go to:
http://www.biglist.com/lists/stella/


1.3 Where are the list archives?

Go to:
http://www.biglist.com/lists/stella/archives/


1.4 What are the posting guidelines?

Other than the standard netiquette, see:
http://www.biglist.com/lists/stella/info.shtml

In general, posting of program binaries and source is encouraged. Since
these programs tend to be small (compared to the software used by
current systems), this does not pose a problem for most people's email
systems.


1.5 Who is "Stella?"

Stella was the name of a french bicycle owned by Joe Decuir, one of the
original Atari 2600 hardware designers.  He chose that name as a
password for his time-sharing account he used to develop early kernels
such as Video Olympics. Ultimately Jay Miner, another Atari hardware
designer, attached it to the Atari 2600 project.


1.6 How do I get the FAQ?

It's a little odd to asnwer the question inside the FAQ, but let's suppose
you have an old one and want a new one.

The FAQ has been posted to the Stella ML, so if you haven't received
one among the things you've gotten from the ML, you'll want to go to the
Stella ML Archives and get it.

You may also find a copy at The Dig!, a spectacular compilation of
some of the best bits of the list's archives:
http://www.neonghost.com/the-dig/index.html

_Don't_ ask the maintainer (whoever that may be) to email it to you,
please.


1.7 How do I submit to the FAQ?

The FAQ has no real maintainer at present. I (Mark Graybill) have
contributed to the FAQ, but I'm not really the maintainer. If you have
something to add to the FAQ, mention it in a post to the list. Then one of
the following may happen:

-I or someone else who've had hands on the FAQ recently and have a
copy handy will insert it in the FAQ and post the updated FAQ.

-Someone(s) will comment that the FAQ doesn't really have anybody
maintaining it and how would you like the job? And while you're at it,
go ahead and insert that bit you've posted.

-You politely regret that you are unable to dedicate the time to be a
moderator since you're a programmer, not a writer. But you get the most
recent copy of the FAQ and insert your bit, returning it to the communal
pool afterward.


1.8 Where did the FAQ come from?

After some back and forth about FAQs in May 1997, David
Schweinsberg posted a draft outline proposal for a FAQ specific to the
Stella list:
http://www.biglist.com/lists/stella/archives/200005/msg00098.html


2. Getting Started

2.1 Are the 2600 and 7800 difficult to program?

The 2600 is considered one of the most difficult systems to program
because of the strict timing required of any program it runs. The design
of the 2600 requires the program to perform its activities in
synchronization with the drawing of video data on the TV screen. Also,
the system resources are very sparse, with very little space for program
memory or variable data.

The video image itself is generated "on the fly" by the program, there is
no video memory in which the image is stored. Only registers in the
video chip store data that is to be displayed, and the values in the
registers must be changed whenever the data to be displayed onscreen
needs to be changed.

The Atari 7800 has more resources than the 2600, and provides
significantly greater capabilities. It has been relatively untapped by
programmers, however, due in large part to the encryption/digital
signature system that makes its enhancements unavailable to the
programmer unless the program includes an appropriate code to unlock
these features. The hardware of the system can be modified to remove
this protection, but it is not a trivial task.

Recently the encryption system of the 7800 has been removed as a
barrier to program development. Programmers can now generate codes
to give their programs access to the 7800's enhancements through
commonly available tools.

Programming of both systems would be a laborious process, even
beyond the problems posed by the systems themselves, if it were not for
the availability of good programming tools for both systems. Emulators
allow software to be tested on the development system itself, without
having to transfer the software to the target system. Disassemblers allow
code from existing ROMs to be reviewed for useful programming
techniques. Cross-assemblers allow development on current computer
systems. And so on. With respect to tools for programmers, things have
never been better for programmers of these systems than they are now,
and the tools themselves continue to be developed and improved.

2.2 What do I need to get started?

Here are the general steps:

-Join the mailing list, so that you can draw on the experience of the
people there as well as share your own experience.

-Obtain an emulator for the system you are planning on programming that
will run on your development system to test your code.

-Get the basic documentation on the system.

-Get a cross-assembler for your development system, and a
disassembler.

More detail on each of these steps is below.

2.3 What experience do I need?

A good foundation in 6502-family assembly language is very useful.  But
since there is very little time in-between frames for the 2600 to "think",
you probably won't need to learn much about assembly number
crunching algorithms.  Most 2600 programming is simple load and store
commands to the TIA registers and a careful watch of cycle times.

Otherwise, assembly language experience for other processors will do
at a pinch, particularly if the experience is in programming video games
on older systems like the Odyssey^2 and the Vectrex. You will find the
6502 series to be rather sparse processors compared to others with
more registers and a more orthagonal instruction set, but its simplicity
also makes it easy to learn.

The Atari videogame systems are not really the place to start if you don't
have prior experience in these areas, though the members of the list will
certainly try to help if you're sufficiently determined to try anyway. It is
more advisable to start with one of the home computer systems (Apple
II, Atari 400/800/XE, BBC, Commodore Pet/Vic-20/C-64/+4/128, etc.)
or microprocessor trainers (KIM, AIM-65, etc.) that use a 6502-series
CPU, then move to the Atari videogame systems once you've got your
feet under you. You can also start with an emulator for one of these
systems if you don't want to mess with the actual hardware.

2.4 What books are there on 6502 programming?

Probably the definitive work on 6502 programming is:
Programming the 6502 by Rodnay Saks (Sybex, 1978-, ISBN 0-89588-135-7)

There is also:
6502 Assembly Language Programming by Christopher Lampton (Franklin Watts,
1985, ISBN 0-531-04923-X) which specifically covers
programming the Apple, Atari, and Commodore systems based on these
processors.

6502 Assembly Language Programming by Lance Leventhal (Osborn/McGraw-Hill,
ISBN 0-07-931027-3.)

Other good introductions to 6502 assembly programming can be found in
the KIM-1, Commodore VIC-20 and Commodore 64 Programmer's
Reference Guides, as well as The Atari Assembler by Inman and Inman
(Reston Publishing Company, 1979, ISBN 0-8359-0236-6). The
Commodore guides practically contain the 6502 family programmer's
guides from Mostek/CSG, the chip's manufacturers. The manual for the
Rockwell AIM-65 microprocessor trainer/development board is also
very good.

A brief introduction to programming the 6502 can be found in
Microprocessors and their Operating Systems by R.C. Holland
(Pergamon Press, 1989, ISBN 0-08-037188-X), but there are some
errors in the sample code where 16-bit operands are used where 8-bit
ones are required.

These are only a few of the many fine books on 6502 programming that
have been published. Most 6502 programming books are out of print, but
they were once common enough that finding them from vendors of used
technical books is not difficult. Searching at powells.com and
abebooks.com or similar sites will turn them up.

There are also numerous introductions to 6502 assembly programming
that were printed in magazines that covered the systems based on this
processor (e.g. Compute, Compute's Gazette.) Many of these are
excellent places for beginners.

2.5 Where can I find info on the internet?

There's no way to compile a complete list of all the sites that would be
valuable to a 2600/7800 programmer. There are just too many that
would fit from too many different points of view. The following lists
should be considered as starting points, rather than as comprehensive
listings.

2.5.1 Where is information specific to 2600/7800 programming on the
internet?

Cyberpunks Website, the founders of the list:
http://www.geocities.com/Hollywood/1698/cyberpunks/

The Stella ML Archives, of course:
http://www.biglist.com/lists/stella/archives/

The Dig! An excavation of the information in the Stella ML archives:
http://www.neonghost.com/the-dig/index.html

Nick Bensema's comprehensive site, a must-see for any VCS
programmer:
http://www.io.com/~nickb/atari/

Paul Slocum's page of projects, including music synthesis with the 2600:
http://www.mindspring.com/~paul-slocum/

2.5.2 Where is general info about the 2600 and 7800 on the internet?

A mecca of Atari information:
http://www.atariage.com/

2600 Tech info, and a mega-ROM/Supercharger project called
Bankzilla:
http://tripoint.org/kevtris/2600/2600schemo.html


2.5.3 Where is more general 6502 programming and tech info on the
internet?

A cornucopia of 6502 information, data sheets, projects, you name it:
http://www.6502.org/

Tech info on the 6502 used in creating arcade machine emulation:
http://www.spies.com/~arcade/simulation/processors/6502/


3.0 System Hardware Overview

3.1 What are the Atari 2600 VCS and Atari 7800? What versions of
these systems are there?

For general information on these systems, consult the relevant FAQs for
each system. The Atari videogame systems (2600, 5200, 7800) were
once all in one document, but the 5200 was split out some time ago as it
is a very different sort of system from the 2600 and 7800. The FAQs for
the 2600 and the 7800 have recently been split as well, as the
information unique to the 7800 has grown.

The hardware information contained in this FAQ focuses on the features
from a programming viewpoint.

Atari 2600 FAQ:
http://www.atariage.com/2600/faq/index.html?SystemID=2600

Atari 7800 FAQ:
http://www.atariage.com/7800/faq/index.html?SystemID=7800

3.2 What CPU does the Atari 2600 VCS use?

This system is based on the Mostek/CSG 6507 microprocessor. This is
one of the variants of the 6500 series that came in a 28-pin package for
use in limited or embedded applications that do not require the features
or cost of the 40-pin versions like the 6502.

>From a programmer's point of view it is practically identical to the
6502, it will run software for the 6502, with the only limitation being
that instructions that specifically rely on the hardware elements of the
6502 that are not present in the 6507 will not have the same effect. They
will not cause an exception if they are used, however.

The 6507 has only 13 address lines, providing an 8K address space.
Addresses outside this address space can be used, with the effect that the
upper bits are ignored, resulting in the appearance of a "folded" address
space.

The 6507 also has no external interrupt hardware, so it is not affected be
 any external interrupts.

The pinout of the 6507 is as follows, for those of you who debug with a
Chip Clip or an oscilloscope probe:

/RESET-| 1      28 |--Phi2
Vss----| 2      27 |--Phi0
RDY----| 3      26 |--R/W
Vcc----| 4      25 |--D7
A0-----| 5      24 |--D6
A1-----| 6      23 |--D5
A2-----| 7      22 |--D4
A3-----| 8      21 |--D3
A4-----| 9      20 |--D2
A5-----| 10     19 |--D1
A6-----| 11     18 |--D0
A7-----| 12     17 |--A12
A8-----| 13     16 |--A11
A9-----| 14     15 |--A10

This CPU was also used in many of the peripherals Atari made for their
line of 8-bit computers.

3.3 What CPU does the Atari 7800 ProSystem use?

The ProSystem uses the Mostek/CSG 6502 processor. The version used
is the "C" version, which is a standard 6502 that can be clocked at
speeds up to 4MHz. It is an NMOS processor, not to be confused with
the 65C02, which is a CMOS version of the 6502 with some
programming changes, and it is not used in the 7800.

The mention of the less well-known versions of the 6502 processor used
in the 2600 and 7800 often brings up questions and confusion about the
processor family as a whole. There were several versions of the NMOS
6502 in different speed grades. The original 6502 was a 1MHz
processor, the 6502A was functionally identical, but could be clocked
up to 2MHz. The 6502B clocked up to 3MHz. And then there was the
6502C as used in the 7800, which goes up to 4MHz.

The 6507 used in the 2600 was one of many 28-pin variants of the 6502.
Each of the different versions brought out different pins from among
those that had been dropped from the 40-pin package to provide access
to different features on the chip for different applications. Some brought
out the interrupt line, but not the RDY line, for example, or dropped an
address line for both, or for the NMI line. There were variations among
the 40-pin versions, too, including versions that provided for separation
of data and program memory spaces, added I/O, etc. For further
information on the 6502 chip family, visit http://www.6502.org/.

3.4 What graphics chip does the 2600 use?

The chip used to drive the graphics in the 2600 is called the TIA
(Television Interface Adapter.) It is a custom chip designed by Jay
Miner at Atari for the 2600. It generates the video and audio signals of
the 2600. It is controlled through a number of write-only registers that
are memory-mapped into the zero page of the 2600.

The TIA directly produces composite color video signals and controls
the horizontal timing of the video signal. Vertical timing control is
managed by the CPU through software. This means that the software has
to send the appropriate signals at the correct times to the TIA to produce
a proper video signal. Without these signals, the 2600 will not produce
displayable video signals. This is part of what makes programming the
2600 challenging.

3.4.1 What software features does the TIA have?

In addition to video control, the TIA provides 5 movable objects,
playfield graphics, and background color control. The five movable
objects are two "players", two "missiles", and a "ball". Each of the
missiles has functions that relate them to one of the players. The players
are displayed using a byte-wide bitmap, the missiles and ball are solid
objects that have a width set by writing to the appropriate TIA control
registers.

It sounds very limiting to have only 5 movable objects to display, but
each object can be reused many times to produce a display that shows
more than 5 objects at one time. The TIA specifically provides functions
to display a single player/missile combination repeatedly (one, two, or
three times per display), but there are also software techniques that can
do far more.

The primary limitation to how many objects can be displayed, and how
much can be done with those objects, is the time available to the
programmer to execute the instructions to reuse the objects as the display
is drawn. The timing is such that while it is possible to display as many
as 15 (or 14 and 1/2) sprites side-by-side per scanline, there's no time
left over to change the bitmap and colors of the individual sprites (so far
as anyone can tell at present.)

The playfield is a bit-mapped graphics overlay with a resolution of 40
bits per scanline. It was designed to be used for background elements
that are seldom changed, but it can be used far more flexibly to provide
active elements of the game.

In the Atari Combat cartridge, the playfield is used to produce the mazes
that the tanks are in and the clouds in the aircraft games. In Centipede,
the playfield elements are used to produce the mushrooms.

The TIA will detect collisions between the different movable objects,
and between the movable objects and the playfield. The collision
detection can be used to trigger game effects. The TIA also controls the
display priority of the different parts of the display, managing which
objects will "cover" the others in the display when they are to be
displayed at the same place. Software can control the priorities that the
TIA uses.

3.4.2 What are the registers in the TIA and their functions?

3.5 What graphics chip does the 7800 use?

In addition to having the features of the TIA, the 7800 has a chip called
the MARIA which is considerably more sophisticated than the TIA.


3.6 What I/O chip does the VCS use?

A 6532 "RIOT" chip is used. This is a version of the 6520/30 VIA
(Versatile Interface Adapter) that includes 128 bytes of RAM. It is used
to communicate with the console switches, and the game controllers. It
also provides a single software controlled timer.

The features of the 6532 are used through a set of memory-mapped
registers that allow the control of the chip as well as the reading and
writing of data.

3.7 What I/O chip does the 7800 use?

3.8 What sound chip does the VCS use?

The TIA chip is not only a graphics chip but also a rudimentary sound
chip.  It uses polynomial counters (pseudorandom number generators)
and various clock dividers to generate different tones and distortions on
those tones.

These tones do not match up perfectly to the diatonic musical scale.  A
chart was created to provide relative note values and their actual
frequency (in hertz). You can see it at The Dig! here:
http://www.neonghost.com/the-dig/dox/sound_chart.txt

3.9 What sound chip does the 7800 use?


4.0 Programming Tools

4.1 How do I test code? (The Emulator)

4.2 Where do I get coding info? (The Documentation)

4.3 How can I read other peoples' code? (The Disassembler)

4.4 How do I compile my own code? (The Cross-Assembler)

4.5 How do I make programming go faster? (Programming Environment)

4.6 How do I get my code to the 2600 hardware?

4.6.1 The Starpath Supercharger

4.6.2 The CuttleCart

4.6.3 RAM/Flash Cartridges

4.6.4 ZIF Cartridges

4.6.5 Cartridge Manufacture
If you have a cart you want made, check out Hozer Video:
http://webpages.charter.net/hozervideo/index.html

You can also make your own, for onesies you can get the basic info from
Hozer video:
http://webpages.charter.net/hozervideo/atari/makecart.html

If you want to go into production, you can look into having PC boards
manufactured to accept the ROMs, work with a plastic manufacturer to
come up with a cart case design and put it into production, and either get
the ROMs masked or burn your own. Then you just need to look into
assembly services. Make sure you have a stable home life and
substantial disposable income before beginning (and enjoy them while they
last.)

To get PC (printed circuit) boards manufactured, you can go to any of
several companies that do prototype quantities at reasonable rates. Many
provide free layout/artwork software for designing your board, tutorials
on how to do it, and will provide you with a quote online. Here are a
couple:

http://www.pcbexpress.com/
http://www.pcb123.com/

To get the cases made, look in your phone book to find a plastics
manufacturer in your area that does prototype work. You'll probably
want to work with them face-to-face in designing it to make sure it doe
everything you need. Having an assembled PCB along will help.

Semiconductor suppliers and manufacturers will often provide services
to program parts for you. An idea: if you use flash components you can
assemble the carts, then program whatever program you want into them
later if you have your own programmer.

Assembly services can also be obtained locally. Look for electronics
manufacturers in the area. Many of them have excess capacity on their
production floor that they would be happy to sell you. Their
requirements for taking on the work will vary. Some will require
specific parts preparation and assembly instructions, others will take
loose boxes of parts and a sample assembled board that they can use as
a guide to assembling the others.

Now that you've got boxes of assembled carts (never mind the ruined
marriage, empty bank account, and lost job), you're ready to get some art
drawn up by a graphic artist, and labels and boxes made up by a printer.
Then you need to start marketing and selling your carts.


4.7 How do I get my code to the 7800 hardware?



5.0 Basic Programming for the Atari 2600

This section provides information to allow the programmer to make
rudimentary use of the 2600. Most programmers will want to develop
games that are more sophisticated than these basic routines allow. More
advanced techniques are covered below. The information here is not
intended to be a complete tutorial, see 5.1 for some of those.

5.1 Where can I find programming tutorials?

An excellent beginner's tutorial that teaches Atari 2600 programming
step-by-step is Kirk Israel's "2600 101":
http://alienbill.com/vgames/guide/


5.1 How do I start? (The Kernel)

5.2 Program Structure

5.3 How do I put something on the screen?

 Once you have a kernel that generates a video display, the basic routine
is to put a bit pattern into the graphic data register associated with an
object, position the object if it's a ball, player or missiles, and watch it
appear onscreen. There's a bit more to it than that to get something
useful, however.

 First, the bit patterns will cause pixels of the color of the drawn object
to be displayed when a bit in the graphic register is set, and the color of
the object behind the drawn object to show through where a bit in the
graphic register is cleared. Also, in order for an object to be visible, its
color needs to be a different color than the colors of the objects that are
behind it and over it in display precedence, otherwise it will blend in
and not be visible.

 The background and the playfield don't have positions onscreen, they
occupy the full width of the screen. The players, missiles, and ball all
have a position horizontally on the screen. Their positions are set by
doing a write to their Reset register (RESP0, RESP1, RESM0, RESM1,
 and RESBL) at the right time to put them where you want them (more on
this later.)

 Beside the horizontal position, these objects can also be given a height
and a vertical position by clearing the graphic data register for the
object on scanlines where the object does not appear, and filling the
registers with the appropriate data on the scanlines where they should
appear. If the graphics data registers are filled at the top of the display,
and not changed for the course of the display, then the object will form a
vertical stripe across the screen.


5.3.1 The Background

 The background is a graphic area that underlies all other graphics and
has a color or colors. It does not generate collision events with other
graphic objects, but it can still be used creatively to contribute more to
the graphic display than a simple background color (though for many
games this is sufficient.)

 The background color is changed by writing a color to the COLUBK
register of the TIA at memory address $09. The background color can be
changed scanline by scanline, or on the fly as the scanline is being
drawn to create a variety of graphic effects.

5.3.2 The Playfield

 The playfield is a graphics pattern that is generally treated as static
compared to the players and the ball. It is a 20-bit pattern that is
displayed on the left half of the screen, then repeated or reflected on the
right half of the screen, for a total of 40 giant "pixels" onscreen per
scanline. The playfield is used in Combat to create the maze for the tanks
and the clouds for the aircraft. In Centipede for the 2600 the playfield is
used to represent a more active element, the mushrooms. Creative use of
the playfield is typically only limited by its relatively low horizontal
resolution.

 The data for the playfield is stored in three eight-bit registers, PF0,
PF1, and PF2 (at addresses $0D, $0E, and $0F.) Only 4 bits of PF0 are
used. Each bit that is set in each of the registers will result in the
playfield color being displayed on screen. The order of the bit patterns
will depend on the individual register and the settings of the playfield
control register, CTRLPF (address $08.)

When the playfield control register is set to repeat the pattern from the
left hand side of the screen on the right hand side of the screen the byte
pattern is as follows:

PF0   PF1      PF2      PF0   PF1       PF2

When the playfield control register is set to reflect the pattern from the
left to the right side of the screen, the pattern of bytes is as follows:

PF0   PF1      PF2      PF2       PF1   PF0

The pattern of bits varies by the register used. The bit pattern for the
left
side of the screen is as follows (note the reversal of bit pattern between
registers):

PF0         PF1                     PF2
D4 D5 D6 D7 D7 D6 D5 D4 D3 D2 D1 D0 D0 D1 D2 D3 D4 D5 D6 D7

The pattern for the right side will either repeat this or reflect this
bit-for-
bit.

The playfield color is set by writing the color to the COLUPF register at
address $08. The ball uses the same register for its color.

5.3.3 The Players

5.3.4 The Missiles

5.3.5 The Ball

5.4 How do I talk to the game controllers?

5.4.1 The Fire Buttons

5.4.2 The Joysticks

5.4.3 The Paddles

5.4.4 The Driving Controllers

5.4.5 The Keypads

5.5 How do I make it _do_ something?

5.5.1 Vertical Positioning and Movement

5.5.2 Horizontal Positioning and Movement

5.5.3 Collision Detection

5.6 How do I make sounds?

5.6.1 Noise

5.6.2 Music

5.7 How do I provide score and status displays?

5.7.1 The Divided Display

5.7.2 Score Displays

5.7.3 Status Displays

6.0 Basic Programming for the Atari 7800

7.0 Advanced Routines for the Atari 2600

7.1 How do I display more than two players?

7.2 How can the two halves of the playfield be different?

7.3 How can I use six digit displays?

The six digit display, also known as the six-character-display or the
six-char is actually not digits or characters per se, but six
sprites.  These sprites represent player 1 and player 2 cloned into 3
copies with wide spacing, lined up in such a way that they overlap
each other, forming a 48-pixel block which the programmer can use to
draw graphics.  Typically, cloned sprites must share the same graphics
data.  However, since the 6507 is free to overwrite graphics registers
while the scanline is being drawn, a properly timed kernal has just
enough time to rewrite player copies inbetween the TIA's drawing
operation for each sprite.

This is typically used in score routines, but can also be used to display
narrow but higher-resolution blocks of graphics for things like title
displays, or even moving objects like the drag racers in Dragster.  When
moving these objects, a very precise time-wasting kernel is employed to
adjust the positions and rewrite-time of the kernel.  This severely limits
any sort of playfield manipulations.

7.4 How do I get more than 4K of ROM?

Bankswitching allows one chunk of memory to be changed out for
another, providing access to additional memory a piece at a time. There
are several techniques used in commercial cartridges. Memory space
provided by these techniques ranges from 6K to 64K. Theoretically
bankswitching could provide access to as much memory as you'd care to
pack into a cart.

Kevin Horton has written a great article on bankswitching. You can see
it at:
http://members.iquest.net/~khorton/files/sizes.txt

7.5 How do I get more than 128 bytes of RAM?

Since the phase2 (clock) and read/write lines were omitted from the
cartridge port for cost purposes, RAM on the cartridge can not be
supported through conventional means.  The Starpath Supercharger,
Superchip, and CBS Ram Plus all provide elaborate means of providing
external RAM to the 2600.

Of these, the Starpath Supercharger is probably the only one hobby
gamers would likely support, since most who frequent Stellalist own
Superchargers to use as development stations since game code can be
downloaded into them.

7.6 How do I display text?

The 2600 has no hardware fonts or text capabilities.  These must be
generated in software. Typically players are used to create characters
using font bitmaps on the ROM.

8.0 Advanced Routines for the Atari 7800

9.0 Programming Info Common to Both Systems

9.1 Common Problems and Gotchas

9.2 Useful Tidbits

9.2.1 How do I kill time efficiently?

From: Christopher Tumber
One thing I've found... annoying if wasting a bunch of ROM space doing
noting. That is, burning cycles for timing purposes but at the cost of
ROM space. Ideal solution would be various flavour NOPs, all using 1
byte but consuming 2-a bunch of cycles. Unfortunately that's just not the
case.
So these are the instructions and instruction combinations that I've been
using to waste cycles. Anybody have any better ones?
-------------------------------------------------------------------------
1 Cycle (0 or 1 byte)
.w (Make a zero page instruction an absolute instruction)
or
,x (Make a zero page or absolute instruction an indexed instruction)
Notes: .w adds a byte of code.
,x needs x=0 (can also use y register)
--------------------------------------------------------------------------
2 Cycles (1 byte)
NOP
--------------------------------------------------------------------------
3 Cycles (2 bytes)
     STA $ZeroPage
or
     LDA $ZeroPage
or
     DOP $ZeroPage
Notes: STA/LDA Destroys register or RAM location (use scratch variable)
 DOP is an undocumented opcode, a double NOP with addressing modes that
affect the instruction's timing.
Chris Wilkson notes:
STA to locations $2D-$3F will do nothing...these addresses are unused.
They aren't even decoded!
--------------------------------------------------------------------------
4 Cycles (2 bytes)
     NOP
     NOP
--------------------------------------------------------------------------
5 Cycles (2 bytes)
     dec $ZeroPage
Notes: Destroys RAM location (use scratch variable)
Chris Wilkson notes:
Again, DEC $2D-$3F will work here without corrupting anything.
--------------------------------------------------------------------------
6 Cycles (3 bytes)
     NOP
     NOP
     NOP
--------------------------------------------------------------------------
7 Cycles (2 bytes)
     PHA
     PLA
Notes: Don't overflow stack
--------------------------------------------------------------------------
8 Cycles and more - combinations of the above, or loop.
[You can use PHA/PHP (1 byte 3 cycles) or PLA/PLP (1 byte 4 cycles) alone
but you have to be carefull not to mess up your stack (PLP/PHA would be
usefull if you have no stack!)]
Chris...
----------------------------------------------------------------------------
--------------------------
From: Manuel Polik
Yours sound ok so far. Here's another one:
12 cycles (3Bytes+page crossing delays):
     JSR AnyRTS
14 cycles and more
- jsr to any subroutine point wasting the desired # of
cycles without destroying other data.
Or do something like:
...
Waste16
     NOP
Waste14
     NOP
Waste12
     RTS
...you get the idea :-)
Greetings,
Manuel
>From Christopher Tumber and Manuel Polik comes the following long delay
approach:
      ldy $ZeroPage
NextPause:
     dey
     bne NextPause
With a delay of  6 + 5 * (ZeroPage - 1), since a branch
taken is 3 cycles.

Also, Andrew Davie suggests checking out this thread in the archives:
<http://www.biglist.com/lists/stella/archives/199805/msg00090.html>

Another time killer from Christopher Tumber:
JMPaddress EQU $80
    lda #10
    jsr DoPause
... ;Code here
     lda #20
     jsr DoPause
... ;Code here
     org $f200
DoPause:
     clc
     adc #$0d
     sta JMPaddress
     lda #$f2
     adc #0 ;You can avoid this if max length won't exceed page
            ;boundary
     sta JMPaddress+1
     jmp (JMPaddress)
     nop
     nop
     nop
 ;Bunch more NOPs...
     rts


10.0 The Zen of VCS Development

10.1 What sort of masochist does this, anyway?

The joy from 2600 programming comes from the challenge.  The challenge is
in fitting your game into constrained memory.  While you could write a
large banked ROM game, most people write for 4K because it's easier to
cannibalize common cartridges (Pac-Man especially) for distribution.  4K
also fits neatly in the Supercharger for easy debugging.

The challenge also comes in taking an idea for a game and find a way to
make it happen given the quirks of the 2600 hardware.  The end result
represents many individual tradeoffs of the programmer which are very
apparent to the player in how the game looks and feels.  Now to the bad
programmer, these limitations will get the best of him, but to the good and
persistent programmer, he can find a middle-ground where everything becomes
balanced.  Like working within the constraints of a rigid poetic structure
such as haiku, a programmer's style shows through in the end product far
more than would be evident from other systems.

Also, remember that far more is expected from games on the PC than any one
programmer can create within a reasonable span of time.  To write a PC game
of professional quality is beyond the scope of a hobbyist.  You could write
a game which played like a fancy 2600 title much faster than writing for the
2600, but it would likely be ignored or scoffed by the PC gamer.  The 2600
provides programmers with an individual creative outlet in which simplicity
is an inevitability, and therefore criticisms about the art and the sound
are eliminated.  The coder is free to focus on the core aspects of gameplay.
He also knows that there is a small but solid group of people who will
really appreciate his work.

As far as comparisons with developing for other consoles, it's simply not
viable to do grass roots development for modern consoles.  Developer
machines are very expensive.  So some satisfaction can be gained from being
able to actually have a game distributed in cartridge form for a real
console system.


10.2 How do I port Quake III and Unreal Tournament to the VCS?

Ah, yes. We all have dreams of what we'd like to make the VCS do. The thing
is that we keep running up against the hardware whenever we try to make the
VCS into something that it really isn't. One of the best ways to get
frustrated as a programmer is to pick impossible goals, get halfway through
development and end up dropping the project because there's just no way to
get there even if we do all modify our VCS's with the amazing overclocked
Voodoo3 chip mod.

A more realistic approach to programming is to start small, and plan small
steps while keeping sight of a goal that's got some flexibility to it. If
you're just starting out, don't try to leap right into your dream
masterpiece game. Start out with something reasonable in scope that gives
you a chance to exercise your skills on the parts of the system that you'll
want to use in your masterpiece.

Don't try to get all the features in right at the outset, either. Build a
running framework for the game, then start putting other pieces in a few at
a time. You'll probably end up with some tough choices given the limitations
of the system, but the existing base of software stands as a strong
testimony that it's possible to produce fun, exciting games even within the
limitations of the VCS.

And if you're still determined to bring QIII and UT to the VCS, Ruffin
Bailey has this to say:
"Maybe you should suggest starting with Quake II, since the source has been
released under GPL already."
So there you are. Pull the code, push it through a 6502 cross-compiler and
start hand-optimizing. You'll probably want to look up the section above on
bank-switching. You'll have to add all your own graphics and sound, though,
since it's only the code that's been GPL'd.

10.3 Is it true what they say about the VCS programmer groupies?

Yes, every word of it. There aren't any. At least none that we've
encountered. Some of us have significant others that still consider us
pretty cool in spite of the fact that we spend our time writing code for an
out-of-production game console, and they may even enjoy playing the games we
write, though they'd probably rather we spent more time with them instead.
That's about as close to groupies as we've seen so far.

If you do happen to be someone who wishes to use their nonstop body to
please a hypercool retroprogrammer, feel free to join in the discussion on
the mailing list, you can almost certainly get hooked up with some lonely,
appreciative programmer, preferably one who doesn't have a significant other
who will remove important pieces of the programmer's anatomy for having fun
with VCS programmer groupies.

10.4 Is this a great way for me to make my first million?

Yes, assuming you're looking to make your first million machine cycle counts
as opposed to making millions in large denominations of money or something
crass like that. A million machine cycles goes by pretty fast when you're
debugging, so you can get there really fast, too.

If you're looking to make money, it has been reported by some that it is
actually possible to break even or come close to it with good new products
for the VCS. That's assuming you've done a good job of managing costs to
start with. That may not sound like much, but being able to cover your costs
is a pretty darn neat way to run a hobby, and if you were to compare the
costs to, say, a hobby involving boats or automobiles, you might be able to
use the balance sheets to turn your cost-conscious significant other into a
VCS programmer groupie (see above.) And you won't be filling the front yard
with old vehicles, either.

10.5 Why should I post my code, what will the list do for me?

Game development works best when the programmer periodically shares his
source code to the list.  This is typically done through attaching a .BIN
file and a ZIP of the sourcecode (or just inserting it as plaintext into the
body of the message).  The list (or peers) review the soruce code and often
find ways for the code to be more efficient.  The less technical play around
with the assembled BIN file.  They act as beta testers and game testers,
finding visible bugs and offering advice in how to make the game look and
play better.

The most critical period for game development is the last 10%.  This can be
the most frustrating.  You've worked on your game so much you're burned out,
but people keep on asking for new features and tweaks.  The temptation is to
just ship it.  But if you know it can be better, and other people on the
list help out to free up bytes and processor time, then keep whittling at
it.  It could mean the difference between a good game, and a great one.


10.6 Won't somebody steal my amazing secret algorithm?

Um, assuming you have a way to unlock multi-MIP processing power from within
the VCS you may ask yourself how you came about obtaining the skill to find
it and get at it. Have you benefitted from the list's assistance or the
shared tools in any way? Would you have gotten that benefit if we'd all sat
in our own caves and kept our work "secret"?

If you give the same algorithm to 'n' programmers it'll end up being used in
a minimum of n-cubed different ways. So even if you share it you probably
won't find anyone treading on the toes of your current project. If you're
doing a port of Final Fantasy IX with it, that doesn't mean that everyone
else will, too. One programmer will make a Frotz interpreter so that we can
all play Infocom games on our VCS's, another will use it to make the most
amazing Pong variant that's ever seen the light of day. Someone else will
turn out a demo that gives onlookers an intuitive understanding of
four-dimensional space and a serious headache. Sharing code enriches
everyone, and maybe someone else will post a tweaked version of it that
trims off those last few machine cycles that have _you_ tearing your hair
out.

Besides, we'll all see your code once you ROM it, anyway.

11.0 Sharing and Selling Your Work

11.1 How can I sell my work?

11.2 How can I market my work?

11.3 How many people will actually buy this stuff?

11.4 What will people pay for this stuff?

11.5 What are the major events I should know about?

11.6 What are the major projects that have come out of the list?

----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/


Current Thread