Subject: Re: [stella] Build up the FAQ bit by bit From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx> Date: Mon, 15 May 2000 11:12:36 -0400 |
> 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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [stella] Build up the FAQ bit b, Ruffin Bailey | Thread | Re: [stella] Build up the FAQ bit b, Glenn Saunders |
RE: [stella] Stella Programmer's Gu, John Saeger | Date | RE: [stella] FAQ draft proposal, Gene Johannsen |
Month |