

Sonic the Hedgehog for the Atari 2600 - rocky1138
http://1morecastle.com/2013/09/the-homebrew-corner-sonic-the-hedgehog-for-the-atari-2600/

======
T-hawk
The article doesn't give any information on the technical detail. As a 2600
programmer, I can make some assumptions.

Looks like the major constraint is sprite inventory. There's only ever one
other object on screen besides Sonic/Zippy. This covers enemies, springs,
powerups, rings (which are done with a hardware register that repeats copies
of a sprite.) So the levels look and feel really sparse.

The 2600 has only two hardware sprites, so that's not unexpected. To get more
on screen, you have to reposition a hardware sprite in the middle of each TV
frame while the electron beam is drawing it. The 2600 literally uses the
phosphor on the TV screen as the frame buffer. So the 2600 can draw many
sprites that march in vertical lockstep (Space Invaders, River Raid) but it's
hard-to-impossible to draw sprites with full freedom of movement (famously
Pac-man's flickery ghosts, which are each drawn only once every four frames.)
It's possible with smart sharing algorithms - do reposition and reuse a sprite
whenever it's possible, otherwise flicker when you must when sprites overlap.
But doing that along with the fairly complicated playfield manipulation will
run out of cycles very quickly. You only get 76 machine cycles per scanline --
just 20-some instructions in 6502 assembly.

~~~
jbermudes
I always wondered, would it be possible to design a custom cartridge with its
own CPU/memory and only use the Atari for drawing on the screen and therefore
have more complex screens? In other words, use the special hardware to
calculate the frame and then use the Atari to control the beam to color the
screen the way you want. So the classical interface between the cartridge and
the Atari is only handling turning the beam on and off and with what color.

I know that the Atari has a certain pixel size due to how fast it can turn the
beam on and off, but working with that constraint it seems with the above
method you could still produce much more complicated games that rival the
interactivity of say the SNES.

~~~
T-hawk
The Atari can't control the color of the beam with much precision. The CPU
doesn't directly control the beam. It writes to the TIA chip's graphics
registers, which are things like the 8 monochrome bits of a sprite or 8 bits
worth of playfield background. The TIA then produces the beam, still limited
to its natural resources of a one-dimensional single-scanline world containing
the 40 monochrome playfield pixels and two hardware sprites.

All this method could do is continually feed the 6507 a stream of instructions
to write those registers. It would be like if you had enough ROM space to
unroll every possible loop and inline every lookup. The cartridge still
couldn't write to the TIA any faster than the 6507 CPU can. It couldn't hit a
register any more often than every 18 pixels, which is how long it takes for a
basic load/store pair of instructions.

The SNES Starfox chip works by drawing polygons into its own RAM then using
DMA to copy them to the console's video memory. The Atari 2600 has no video
memory beyond the TIA's registers, and no DMA to hit them any faster.

Unless... I don't know enough about the electrical side, but is it possible
for a cartridge to disable or halt the 6507 CPU and directly drive the bus to
the TIA? Then you could at least write to the TIA every cycle, yielding
resolution of every three pixels. The Atari cartridge slot pinout is pretty
plain though, just the 13 address and 8 data lines. Nothing fancy like a CPU
halt or reset line or even a clock, and actually not even a read/write line
that would be necessary to write to the TIA. It would require some motherboard
hardware hacking, and by that point you're pretty much implementing an
entirely new game console with an arbitrary CPU coupled to the 2600's TIA
graphics chip.

(TIA is Television Interface Adaptor:
[http://en.wikipedia.org/wiki/Television_Interface_Adaptor](http://en.wikipedia.org/wiki/Television_Interface_Adaptor)
)

------
jevinskie
Very impressive given that the developer has 128 bytes of RAM (just four AVX
registers) to work with.

