10/25/2023 0 Comments Battle tank atari gameThat gave me enough cycles, but all of the additional instructions and data could not fit in the 2 KB ROM. No difference in response times can be detected between original Combat and Combat AI. I also spread these interruptions around evenly (not consecutive frames), so they are completely transparent. Since the 2600 displays 30 frames per second, that still allowed the normal game logic to run 27 (out of 30) times each second. My solution was to hijack the entire VBLANK for 3 frames out of each second to run my machine learning algorithm. To make this work, I needed more cycles than are available in an entire VBLANK, so using the leftover cycles was out of the question. Unfortunately, there are not many cycles available during the VBLANK cycle because Combat needs them to, well, play Combat. This means that nearly all game logic (handling joystick input, collision detection, firing missiles, sound, etc.) needs to fit into the vertical blanking (VBLANK) period when nothing is being drawn to the screen. There is no video buffer CPU instructions must be in sync with the display, and pixel information is specified at the exact moment it is needed by the television. Most of the processing cycles are consumed by drawing graphics to the screen. First, a bit about the platform - the Atari 2600 has an 8-bit MOS 6507 CPU running at 1.19 MHz and a paltry 128 bytes of RAM. There were a number of problems to overcome to fit an AI algorithm into an already tightly-packed 2 KB ROM on the highly resource-constrained Atari 2600. To this, I added a K-nearest neighbor algorithm that uses examples from a training dataset to make a prediction about the best course of action for the AI-controlled tank to take. I started with a well-known disassembly of Combat (by Harry Dodgson, later improved by Nick Bensema and Roger Williams).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |