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 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
Presented here, practically unmodified, are some comments on collision
detection from some of the
masters of the art:
>From Manuel Polik:
This is determining a whether a single pixel hit an 8*11
square:
LDA bulletHorPos,Y
ADC #$08
SBC horPosP0,X
BMI NoHit
SBC #$08
BPL NoHit
LDA verPosP0,X
SBC bulletVerPos,Y
BMI NoHit
SBC #$0B
BPL NoHit
I case the invader is only 6 pixel wide, it could still
be aligned on the left side of the sprite, so all that
was required to change in this code was adopting the
height from #$0B to the invader height and replacing the
hardcoded #$08 with a temporary variable.
>From Christopher Tumber:
Collision detection in Space Instigators is a little complex because it
needs to determine the
row/column number of what (if anything's) been hit. (This is player's
shot/Instigators collision.
Insitigator's shot/Player's ship collision detection is quite simple
while Shot/House collision
detection is a little complicated again):
To set this up. Alive/Dead data for Instigators are contained 9 bytes,
the variables are named
Column1, Column2, etc (Though usually reference is indexed so Column1 is
generally the only one
referred to in code). The lower 5 bits are bitflags indicating
Alive/dead status of the
corresponding Instigator. Bit0 of Column1 is the top left hand corner
Instigator.
Aliens_Position is the horizontal position of the formation (value 0-9)
Aliens_Top_Row is the number of scanlines from the top of the playfield
to the top of the formation
Player_Shot_Pos_Y_top is the scanline of the top of the player's shot
Player_Shot_Pos_X is horizontal position of the player's shot
lda #1
sta temp2
lda Player_Shot_Pos_Y_top
beq no_alien_hit
sec
sbc #10
bmi no_alien_hit
sec
sbc Aliens_Top_Row
bmi no_alien_hit
ldy #0 ;Find row
next_find_row:
cmp #12
bmi found_row
asl temp2
iny
sec
sbc #18 ;#15 ;#12 Height in scanlines of a row
jmp next_find_row
found_row: ;X now contains row, temp2 contains bitmask for row
cpy #5
bpl no_alien_hit ;Shot too low
lda #16
ldx Aliens_Position
beq no_add_pos
next_add_pos:
clc
adc #3
dex
bne next_add_pos
no_add_pos:
sta temp ;Postion of left edge of Aliens
lda Player_Shot_Pos_X
sec
sbc temp
bmi no_alien_hit ;Shot is too far left
ldx #0
find_next_column:
cmp #12
bmi found_column
inx
sec
sbc #12
jmp find_next_column
found_column: ;Y now contains the column number
cmp #8
bpl no_alien_hit ;Weed out shot in column but not hiting alien
cpx #9
bpl no_alien_hit ;Shot is too far right
lda temp2
and Column1,x
beq no_alien_hit
lda temp2
eor #255
and Column1,x
sta Column1,x
ldx #0
stx Player_Shot_Pos_Y_top
jsr start_explosion_sound
dec Aliens_Speed ;Make 'em go faster!
jsr Add_10_To_Score
cpy #3
bpl no_alien_hit
jsr Add_10_To_Score
cpy #1
bpl no_alien_hit
jsr Add_10_To_Score
no_alien_hit:
; jmp done_alien_hit
done_alien_hit:
>I thought to present mine. I once spent
>almost a whole day for finding the optimal technique to
>determine wether a particle hit a square and I think it
>possibly might be adopted to detect a collision with
>variable width invaders:
It looks like a good routine, however a game like Space Instigators adds
the complexity of having
to do 45 collision detections (Your routine would probably need nested
loops or at least a big 55
iteration loop which would add a lot of unneeded overhead...) as well as
maintaining the status
data - Like I use bitflags because you don't really want to use 1 byte
each if you can avoid it...
Looking over my code, I could actually adapt my routine fairly easily by
changing:
jmp find_next_column
found_column: ;Y now contains the column number
cmp #8
bpl no_alien_hit ;Weed out shot in column but not hiting alien
to:
jmp find_next_column
found_column: ;Y now contains the column number
cmp AlienLeftEdge ;A Variable
bmi no_alien_hit ;Weed out shot in column but not hiting alien
cmp AlienRightEdge ;A Variable
bpl no_alien_hit ;Weed out shot in column but not hiting alien
Uses 2 extra bytes RAM but they're really temporary values that would be
setup only for that
routine (probably pulled off a ROM table) but the only way around that
would be more bitmasks
(since it's only going to be a small value we could share a byte) or
rewrite the code slightly to
use a Width variable (Right now it's finding which column the shot is in
based on the left edge of
each Instigator and then checking that the shot isn't too far right
within that column. Instead it
could be finding the column based on the center of the Instigator and
then it would determine if
the shot is within the width of the Instigator. Yeah, that would
probably be the way to go...)
No, no, no, speaking of tables it would be something like this:
jmp find_next_column
found_column: ;Y now contains the column number
ldx ROW ;Because we're not able to preserve X so we'd have to save
the ROW to a temp variable
cmp AlienLeftEdge,x
bmi no_alien_hit ;Weed out shot in column but not hiting alien
cmp AlienRightEdge,x
bpl no_alien_hit ;Weed out shot in column but not hiting alien
Where AlienLeftEdge and AlienRightEdge are ROM tables containing the
left/right thresholds for
collison...
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
eachother, 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.
Here are some resources:
>From Joe Grand:
You can take a look at the SCSIcide source code, as I use a modified
version of the 6-digit display source to display the hexadecimal score.
I
also use it to display the 6-character easter egg, so I have a few alpha
characters defined.
Since I've already posted the source to the list last year, you can get
it
from: http://www.pixelspast.com/games/scsicide/scsi130.s.txt
>From Kirk Israel:
Don't know if this helps, but once upon a time there was a cool site
called "Pixeltime" and I made up a super minimal pixel font, most
characters
were 3x4, but it was still pretty readable...
http://www.kisrael.com/pixeltime/ is the page (the original site is
defunct,
alas, that's my tribute page) but if you just want the actual graphic
it's
http://www.kisrael.com/pixeltime/mypix/932259817_27626.gif
>From Paul Slocum:
There's also David Crane's 12 character flickery routine from Basic
Programming and Stellar Track, although I think the flicker is pretty
tolerable the way it's done. I used it for a bunch of my projects. You
might talk to Thomas [Jentzsch] if you want to use this since he has an
optimized version that allows more lines on the screen.
>From Thomas Jentzsch:
I guess Paul is referring to the source code of "Fellowship Of
The Rings", where I helped a bit.
http://www.atariage.com/software_page.html?SoftwareLabelID=2023
8.0 Advanced Routines for the Atari 7800
9.0 Programming Info Common to Both Systems
9.1 Common Problems and Gotchas
9.1.1 6502 Addressing Modes
ZERO PAGE INDEXED
Note that there is no zero page indexed addressing mode that uses the Y
register. If you write an
instruction as follows:
LDA $10,y ; Your assembler may take this, but you may find one extra
byte in code
This would seem to indicate an indexed zero page addressing mode.
However, many assemblers (DASM
among them) will assume that you are intending to do _absolute_ indexed
y addressing, and will
change the instruction to:
LDA $0010,y
without issuing any warnings.
INDIRECT INDEXED
Here note that the indirect address must be located on the zero page,
and that it must be
indexed using the Y register:
LDA ($2A),Y
If you type the following:
LDA ($002A),Y ; your assembler may take this, but it may not do what you
think
many assemblers will accept it, and convert $002A into the equivalent
zero page address. The
following, however, is illegal:
LDA ($FE2A),Y ; illegal, must be zero page address
or
LDA ($2A),X ; illegal, must use Y to index this.
The first because it uses an absolute address that is not on zero page
(the assembler should
give an error here) and the second because it uses X as an index (the
assembler should flag
this, too.)
INDEXED INDIRECT and other seeming repentant redundancies
OK, here we are indexing the address that we obtain our final lookup
address from, rather than
indexing the address that we get out of the location in the parentheses,
as in indirect indexed.
Besides noting the differences between the two modes, there are also the
obligatory limitations
which are part of what has led the 6502 series processors to be called
"the least orthagonal
processors known to mankind." (Spring that on your compsci teacher
sometime for extra credit.)
Again, the indirect address can only be stored on the zero page, and in
this case only the X
register can be used to index it to obtain the final address.
Legal:
LDA ($23, X)
Illegal:
LDA ($1FF, X) ; illegal, not a zero page address
LDA ($12,Y) ; illegal, can't use Y register for index. Change it to X.
The assembler should catch the illegal values for you.
REGISTER USAGE
You can't store a result in the same register you used to index an
address. You can't do:
LDX ($08,X) ; illegal, indexing on X and storing to it at once
or
LDY ($23,Y) ; illegal, indexing on and storing to Y both
or
LDX $18,X ; illegal, using X to store to and index
or
LDY $2304,Y ; illegal, storing to and indexing on Y
You also can't do these:
STX $2304,X ; illegal
STY $114F,X ; illegal, even though it does use Y and X
STX ($21,Y) ; yikes! No, no, no. If you want to use indexed addressing
modes,
; use the Accumulator, please!
9.1.2 A Branch Too Far...
Check your branches. It's easy to lose track of just how far that branch
is going when you're
using an assembler that takes care of all the heavy lifting for you. If
your relative address
crosses a page boundary, you'll spend an extra cycle because of the
carry or borrow this
causes. The program will merrily run, but you're timing will be shot to
pieces. Check the
location of the branch in memory, and check the place it branches to to
make sure it is
on the same page. If the change of a seemingly unrelated bit of code
suddenly throws off an
entirely unrelated piece of code, suspect this. Dump a disassembly of
the listing with the
memory locations annotated, and see where the page breaks are.
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/
