I survived making an Atari 2600 game! <a href="https:&#x2F;&#x2F;github.com&#x2F;boomlinde&#x2F;jupitersumo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;boomlinde&#x2F;jupitersumo</a><p>The tricky part is writing the graphics kernel (which is responsible for updating the one-dimensional screen registers as the beam advances vertically). It needs to be quick, and it&#x27;s probably not healthy for the programmer trying to incorporate any other game logic into this part.<p>After the screen has been drawn you have a few lines free for arbitrary code on every frame. You still have to keep track of how many lines have passed to maintain the correct screen frequency and initiate the vertical sync at the right moment, though. There are no interrupts to deal with this, but there is a timer that you can set up and start polling once your game code is finished not to have to think about lines when doing the game logic.<p>Then there&#x27;s the sprites... They can be nudged side to side arbitrarily in up to 8 pixel increments, but can only be placed at an absolute horizontal location by waiting for the beam to get there and writing to a register that resets an internal sprite counter. There is no vertical positioning, and you just enable&#x2F;disable the drawing of the sprite or clear its pattern at the right line.<p>In my game, I could save a lot of time in the kernel by never explicitly clearing the sprites to produce 2D objects. Instead, as the screen draws lines, it decrements an 8-bit counter which is used to index a table of 256 sprite lines. &quot;Moving&quot; the sprite vertically, then, is just a matter of changing the initial value of the counter.