3 ms·

Just FYI, this is for the Atari computers, not the 2600 console. The 2600 used the 6507 processor, basically a 6502, but it didn't have the interrupt pins (to

Just FYI, this is for the Atari computers, not the 2600 console. The 2600 used the 6507 processor, basically a 6502, but it didn't have the interrupt pins (to save on cost). I imagine it made programming for the 2600 a lot more interesting.

boomlinde 7y ago
Having tried at it after programming for platforms like the C64 and VIC20 for a while, I found it refreshingly simple. There's nothing that'll steal the bus from you at strange times (like badlines on the C64) and since there are no interrupts there's no interrupt jitter either. It makes it easier to keep track of how many cycles you're wasting and when exactly. The 2600 doesn't even really synchronize video for you. It can pause the CPU until the next scanline (via a WSYNC register, like the computers) but it's up to the programmer to generate the correct number of lines and generate a vertical sync pulse. Because all the graphics registers are one dimensional, the CPU will most likely be occupied with reloading them during the visible portion of the screen to produce 2D graphics and handle game logic outside it, keeping track of when to prepare for drawing again by polling a timer register or keeping track of how many cycles were wasted exactly. Another interesting limitation is that there is only a very crude way of absolutely positioning sprites horizontally. You do this by strobing a register that resets a horizontal sprite counter. This positions the sprite horizontally where the beam happens to be at the time, so you have to pace your positioning with the beam. After you have done that to position the sprite roughly where you want it, you can nudge it relatively to its current position -8 to 7 (or something like that) pixels at a time. It became apparent to me while working with it and reading the documentation that this was designed to be the minimum viable product to support just a couple of types of games (e.g. Combat and Pong) which makes the variety of its game library much more impressive. My game source is at https://github.com/boomlinde/jupitersumo https://github.com/boomlinde/jupitersumo if anyone is interested. It's a two player game with a simple graphics kernel (two player sprites, a playfield and two life counters).

boomlinde 7y ago

Having tried at it after programming for platforms like the C64 and VIC20 for a while, I found it refreshingly simple. There's nothing that'll steal the bus from you at strange times (like badlines on the C64) and since there are no interrupts there's no interrupt jitter either. It makes it easier to keep track of how many cycles you're wasting and when exactly. The 2600 doesn't even really synchronize video for you. It can pause the CPU until the next scanline (via a WSYNC register, like the computers) but it's up to the programmer to generate the correct number of lines and generate a vertical sync pulse. Because all the graphics registers are one dimensional, the CPU will most likely be occupied with reloading them during the visible portion of the screen to produce 2D graphics and handle game logic outside it, keeping track of when to prepare for drawing again by polling a timer register or keeping track of how many cycles were wasted exactly. Another interesting limitation is that there is only a very crude way of absolutely positioning sprites horizontally. You do this by strobing a register that resets a horizontal sprite counter. This positions the sprite horizontally where the beam happens to be at the time, so you have to pace your positioning with the beam. After you have done that to position the sprite roughly where you want it, you can nudge it relatively to its current position -8 to 7 (or something like that) pixels at a time. It became apparent to me while working with it and reading the documentation that this was designed to be the minimum viable product to support just a couple of types of games (e.g. Combat and Pong) which makes the variety of its game library much more impressive. My game source is at https://github.com/boomlinde/jupitersumo https://github.com/boomlinde/jupitersumo if anyone is interested. It's a two player game with a simple graphics kernel (two player sprites, a playfield and two life counters).