Differences

This shows you the differences between two versions of the page.

--- project:atari_asteroids_autoplay [2013/03/17 04:33] – [3/16/2013 @ 9:07pm] smark
+++ project:atari_asteroids_autoplay [2013/03/17 05:31] (current) – [3/16/2013 @ 9:07pm] smark
@@ Line 75: / Line 75: @@
-^ DACY#* | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
+^ DACY#* |  10  |  9  |  8  |  7  |  6  |  5  |  4  |  3  |  2  |  1  |
-^ B11 Pin | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 |
+^ B11 Pin |  13  |  12  |  11  |  10  |  9  |  8  |  7  |  6  |  5  |  4  |
-^ Sample Value | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 1 | 0 | 0 |
+^ Logic Channel |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  | | |
-^ Digit Weight | 512 | 256 | 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |
+^ Sample Value |  1  |  0  |  1  |  0  |  1  |  1  |  0  |  1  |  0  |  0  |
-^ Value | 512 | 0 | 128 | 0 | 64 | 32 | 0 | 16 | 0 | 0 |
+^ Digit Weight |  512  |  256  |  128  |  64  |  32  |  16  |  8  |  4  |  2  |  1  |
-^ Total | 692 |
+^ Value |  512  |  0  |  128  |  0  |  64  |  32  |  0  |  16  |  0  |  0  |
+^ Total |  692  ||||||||||
+Now whats important to note is that the DAC does not have an internal register so it doesn't load it into a register then "pull the trigger" to change the value for the output. As bits come streaming down DACY* they change the voltage. This means the voltage will jump around a little bit (therefore making the beam jump around). Luckily this happens rarely and is accounted for by BVLD... I think.\\
-  DACY  10 9  8  7  6  5  4  3  2  1 *
+\\
-        |  |  |  |  |  |  |  |  |  |
+Anyway, I hooked the logic analyzer up to B11 Pins 13 thru 6, which leaves off pins 5 and 4, which means you lose the last two bits of accuracy. I'm not sure if it is important at this point or not. That means the last two bits are always considered 0. The Saleae Logic software is pretty cool. You end up getting data that looks like this:\\
-   BIT  1  1  0  1  0  1  1  0  1  0
+\\
-        |  |  |  |  |  |  |  |  |  |
+{{:project:130316_b11_saleae_logic.png?direct&600}}\\
-   BIN 512 |  |  |  |  |  |  |  |  |
+\\
-|  |  |  |  |  |  |  |
+Well thats interesting but not really visually useful is it? If you take a vertical slice at any point in that output and assign each channel a 0 or 1 you will get the binary representation just like in the table above. I've compiled the output for each slice (all 336,000 of them) and uploaded them here: {{:project:130316_b11_saleae_logic_export.zip|}}\\
-|  |  |  |  |  |  |
+\\
-|  |  |  |  |  |
+Now that I have 336,000 height values (Y-Axis 0-1023) I was able to compile this chart with gnuplot:\\
-|  |  |  |  |
+\\
-  |  |  |  |
+{{:project:130316_b11_composite_output.png?direct&600}}\\
-  |  |  |
+\\
-  |  |
+Well HMM that looks a little bit like the horizontal output for the test pattern! Don't quite see it? Heres a labeled version:\\
-  |
+\\
-                                   ?
+{{:project:130316_b11_composite_output_labeled.png?direct&600}}\\
-   TOT              16 8  4  0  1  0
+\\
+Looking at the math here there is an entire screen refresh approximately every 14ms. Do I think I can write code efficient enough to process several thousand points minimum in less than 14ms? I don't really know how long 14ms is in the programming world, but I think even if the application is multithreaded and I have one thread for each interface (1 for each: Beam On/Off, X Position, Y Position, Game Processing) I don't think I can be quite that efficient. I think now would be a good time to give up on the strategy of processing each frame. Even if I process one out of every 10 frames at 140ms (which I think is probably doable) I'm still not sure I can filter through and pick out a frame easily enough. There would have to be some sort of a pattern recognition that would be insanely hard to write and require a lot of processing time. I think my next step is to look at intercepting the commands as they go to the vector RAM.\\
+\\
+Now that we're moving in that direction... What do I know? The Vector State Machine seems to be a complicated beast. I believe basically the CPU sends a pulse to the Vector State Machine to turn on. It starts its drawing timers and such and immediately starts reading from the vector RAM. It swaps back and forth between reading and executing until the vector RAM is empty, then it turns itself off and waits for the next command. I'll need to decide on one of two approaches:\\
+\\
+  - Read from the CPU as it goes into the RAM and just assume that the commands are written to the screen quickly
+  - Watch that "pulse" line and inspect all of the communications out of the vector RAM and just assume that the vector circuits generate it right away (a given).
+\\
+Well I'm going to go investigate how to look at the RAM. I don't know how easy this will be without the Asteroids game code....
 ===== Major Challenges =====
@@ Line 108: / Line 117: @@
 {{:project:130312_atari_asteroids_digital_vector_generator_schematic.pdf|Atari Asteroids - Digital Vector Generator Schematic}}\\
 {{:project:130312_atari_asteroids_drawing_package_supplement.zip|Atari Asteroids - Drawing Package Supplement (Schematics) - Contains All 4 Sheets, In High Resolution}}\\
-[[http://www.jmargolin.com/vgens/vgens.htm|The Secret Life of Vector Generators (Jed's Website)]] {{:project:130313_the_secret_life_of_vector_generators.pdf|(Local PDF Copy)}}
+[[http://www.jmargolin.com/vgens/vgens.htm|The Secret Life of Vector Generators (Jed's Website)]] {{:project:130313_the_secret_life_of_vector_generators.pdf|(Local PDF Copy)}}\\
+[[http://www.analog.com/static/imported-files/data_sheets/AD561.pdf|Low Cost 10-Bit Monolithic D/A Converter (AD561) DataSheet (B11/D11 Vector DACs)]]