Sonic the Hedgehog for the Atari 2600(1morecastle.com)
1morecastle.com
Sonic the Hedgehog for the Atari 2600
http://1morecastle.com/2013/09/the-homebrew-corner-sonic-the-hedgehog-for-the-atari-2600/
2 comments
If anyone is interested in this kind of stuff, there is a fantastic book called Racing the Beam [1] from MIT Press. Here's a bit of the book's description:
"Nick Montfort and Ian Bogost discuss the Atari VCS itself and examine in detail six game cartridges: Combat, Adventure, Pac-Man, Yars' Revenge, Pitfall!, and Star Wars: The Empire Strikes Back. They describe the technical constraints and affordances of the system and track developments in programming, gameplay, interface, and aesthetics. Adventure, for example, was the first game to represent a virtual space larger than the screen (anticipating the boundless virtual spaces of such later games as World of Warcraft and Grand Theft Auto), by allowing the player to walk off one side into another space; and Star Wars: The Empire Strikes Back was an early instance of interaction between media properties and video games."
[1] http://mitpress.mit.edu/books/racing-beam
"Nick Montfort and Ian Bogost discuss the Atari VCS itself and examine in detail six game cartridges: Combat, Adventure, Pac-Man, Yars' Revenge, Pitfall!, and Star Wars: The Empire Strikes Back. They describe the technical constraints and affordances of the system and track developments in programming, gameplay, interface, and aesthetics. Adventure, for example, was the first game to represent a virtual space larger than the screen (anticipating the boundless virtual spaces of such later games as World of Warcraft and Grand Theft Auto), by allowing the player to walk off one side into another space; and Star Wars: The Empire Strikes Back was an early instance of interaction between media properties and video games."
[1] http://mitpress.mit.edu/books/racing-beam
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.
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.
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 )
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 )
Pitfall II had a custom cartridge with additional memory and chips to do multi voice sound (there's music continuously playing in Pitfall II) so it is possible. I just don't know how much the custom hardware can take over the machine.
I was thinking the same thing, and it's funny you mentioned the SNES since some of the more advanced games for that platform used a second processor on the cartridge to assist.
Damn. I remember feeling frustrated with resource constraints when programming for the Gameboy. Now I feel lucky ;).
Batari Basic (which this was programmed in) abstracts away most of those concepts.Pretty much all of the scanline stuff is done by a single command.
[deleted]
Very impressive given that the developer has 128 bytes of RAM (just four AVX registers) to work with.
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.