> Draft 1 (everyone please amend together!!)
Who's collecting and assembling (heheh) these? You, Glenn?
> The 6507 CPU runs in synchronization with the television scanline. The TIA
> chip only has enough memory and hardware functions to draw one scanline at
> a time. The 6507, through software (known as the kernel) must manually
> create a list of instructions (later to become the more automated display
> list system on the 400/800) which populate the TIA registers on each
> scanline and perform the various video functions like vertical blanking.
Start a little more basic than that, and lose the "list of instructions"
part.. the display list paradigm seems easy to apply to the TIA after
seeing it in the computers, but it's quite different programmatically. :
As you probably know, when a television displays a screen, the electron
beam "paints" the screen one line ("scanline") at a time. This is how the
2600's TIA (Television Interface Adaptor) works. The CPU must work in
tight sync with the TIA: while the screen is being painted, at each and
every scanline the CPU must tell the TIA what to draw on that scanline.
After a frame is completed, the CPU then has a little bit of time (called
the vertical blank interval or VBLANK) to do number crunching and game
processing, then it must walk the TIA through the next frame all over
again.
Therefore even simple games require very careful programming, where you
must count individual cycles for each instruction and count scanlines drawn
in order to maintain proper video sync and graphics stability.
> 2.2 What experience do I need?
> A good foundation in 6502 assembly language is important. But since there
A good foundation in some sort of assembly language is important. It need
not be 6502 - I came on to the 2600 with a good bit of x86 assembler and
had little trouble learning 6502.
> The 6507 is a cost-reduced (18-pin?) variant of the 6502. It has a 13-bit
> address bus (8096 bytes) and the usual 8-bit data bus. In order to
And no interrupts.
> simplify addressing logic, this 8K was split into two parts, the first(?)
> section referring to internal registers, and the second section referencing
> external (cartridge) memory.
No need to overexplain. Simply: The first 4K of the address space refers
to internal registers, and the upper 4K references cartridge memory.
> >2.5.1 What is a playfield?
>
> This is the background graphics upon which the players (or sprites) will
> animate. This is a 40 pixel by ~200 pixel grid with 1 bit depth of color
> with a 7-bit fixed palette.
Don't give it a vertical resolution, because that makes people start
thinking its like the bitmaps of PC graphics displays. And minor peeve of
mine - never ever use "pixel" to mean anything other than a single
indivisible rectangle on screen.
The playfield is the backgroung graphics on which other objects will
animate. It's 40 blocks across the screen, each block being 4 pixels
wide. (pet peeve of mine - rectangle on screen, it just confuses things.)
To actually draw a playfield, such as the mazes in Combat or Berzerk or
the city in Defender, you write new data into the playfield registers on
each scanline as the frame is being drawn. The playfield is one color,
but you can write new data to the playfield color register between or
during scanlines to generate more colors. The ark in Cosmic Ark is drawn
using playfield graphics and color changes like this.
> The ball is like the missile, only that it (can not be clone??) and its
> color register is tied to that of the playfield.
The ball cannot be cloned, correct.
> The 2600 NTSC color palette has 16 hues and 8 brightnesses of each
> hue. These map to 24-bit RGB values roughly in this table:
>
> Xxx
This should be in PC Atari's source, I would guess...
> >3.4 How do you display a screen of text?
>
> The 2600 has no hardware fonts or text capabilities. These must be
> generated in software
using either the playfield or multiple sprites.
> >3. Developing Your Project
> >3.1 Can this possibly be fun?
>
> The joy from 2600 programming comes from the challenge. The challenge is
> in fitting your game into constrained memory. While you could write a
Depends on the game. In my INV (which maybe I'll finish one day :) ), the
challenge was to get all that stuff happening during the display kernel,
when the invaders are being drawn - that's a lot of complex playfield
manipulation. The game actually uses well under 3k. Just because Piero
struggled to cram Oystron into 4k doesn't mean every game does.
> As far as comparisons with developing for other consoles, it's simply not
> viable to do grass roots development for modern consoles. Developer
The NES, Coleco and Vectrex are also viable and have active developer
activity. Although assembling NES carts is quite a bit harder; I don't
think anybody's trying to program for anything but an emulator.
> >3.2 Can I make money from this?
Ask Piero. :)
> 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
Yep, that's where I got to with INV... :/
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
