• contact | 
• products | 
• technical

Asteroids Multigame Kit -- Power On Diagnostic Sequences

WORK IN PROGRESS

Power On Self Test (POST)

The Multigame has TWO special power on diagnostic sequences which are automatically executed at startup when the game is turned on. One sequence if the self-test switch is ON (test mode) and a different sequence if the self-test switch is off (game mode). The two test sequences are very different and the use of LEDS, sounds, and the display are different. The first step in trouble shooting will be to run each diagnostic sequence and observe any results. In order to help clarify each sequence, the following names are used. Boot sequence refers to when the game is powered up in game mode. Testmode sequence reference to when the game is powered up with the self-test switch on.

These sequences are very different and much more extensive from the original game. Additionally the multigame can run these tests and make use of the vector display even in absence of a valid vector rom.

When the game is in testmode, the multigame executes the standard Atari testmode diagnostics with a few modifications for the multigame.

During the poweron selftest (boot), the Multigame boot code performs 4 basic diagnostic tests before attempting to use the display. If any of these 4 diagnostics fail, the P1/P2-start LEDS will flash in a pattern to indicate which test has failed.

At powerup, the Asteroids hardware automatically turns the start1 and start2 LEDS ON. One of the very first things the Multigame selftest does is to turn off LED1. This indicates that the 6502 CPU is executing instructions, the first signs of life. Next the Multigame selftest will verify in the CPU RAM. The CPU RAM test is a simple test and not intended to be exhaustive. Note: For technical reasons not discussed here, interactions with the Non Maskable Interrupt (NMI), make it so it is not possible to reliably perform a CPU RAM test when the game is not in testmode. If the CPU RAM test fails, the game will either watchdog reset and start over, or it may just stay stuck with the current LED pattern (LED1=xx, LED2=yy). Assuming the CPU RAM test passes, the selftest updates the LEDS to the next state (LED1=xx, LED2=yy).

The next test is

then perform a CPU ROM checksum, and then perform the VECTOR RAM and ROM checkum tests. Any failure is indicated by a flashing LED code.

Assuming the above tests pass, the multigame selftest then sets the progress LEDS to LED1=ON, LED2=OFF to indicate it is starting the next phase. during this phase of test, attempts are made to show progress and results on the vector display itself.

Once all selftests have passed, both LEDS are turned off. If there is a failure during phase 2, the LEDS will both flash together and the display should indicate the problem.

In the event the selftest fails, pressing P1+P2 will cause the selftest to attempt to continue the initialization sequence.

Once the selftest has completed, if there are any selftest failures, the selftest results remain on the screen until user intervention. If the selftest passes, the selftest success results are displayed for about 15 seconds before switching to the configured powerup game. At anytime during this period pressing any button will cause the multigame to startup the configured powerup game.

Selftest LED codes (boot)

Testmode enhancements

This kit includes several enhancements over the original Asteroids/Deluxe testmode. The improvements include better indication of failures (for example, instead of just forcing a watchdog reset indicate the failure other ways). Better RAM failure testing and chip identification. A new input test which shows visually all the active inputs (switches). A new sound test which allows ALL sounds to be played (tested). No dependancy on the vector ROM, in fact the testmode can run entirely without ANY vector ROM present.

Testmode Memory Test Improvements

The multigame has an entirely new testmode memory test that replaces the simple one originally in the game. Some of the issues with the original memory test are:

1. The original memory test would stop on first failure. Thus valuable information about additional memory chips which could be bad might have been masked. Knowing for example that all 6 RAM chips have tested bad prior to replacing any could be valueable information in that one might determine that the memory chips are not the problem but that other circuitry such as the decode logic or buffers could be causing the problem.
2. The original memory test was exposed to aliasing problems, that is the same value was written to each memory location and done one at a time, in theory to pass all you needed was ONE memory location working. Shorted address lines or faulty ram chips could have passed this simple test.
3. The original memory test would exercise the first 256 bytes of CPU RAM. Then it used that RAM to test the remaining bytes of CPU RAM and the vector RAM. So the same RAM device was being used and assumed good while another part of that same RAM device was being tested.
4. The original memory test would exercise the memory chips in pairs and if either of those chips failed, the test would stop at that point and attempt to beep out the failure code. This preventing further testing of the remaining chips until after the first failure has been fixed.
5. The original memory test required that the 3Khz signal to the CPU was working properly in order to beep out the RAM failure codes. If the 3khz was not pulsing testmode would simply spin, then watchdog reset. Or with the watchdog disabled, it would never finish the beep sequence.
6. On the original games asteroids and deluxe had different failure sequences to identify the failing rams in terms of low and high pitched tones. The multigame uses one common sequence for both platforms similar to the original asteroids identication sequence.
7. The original testmode would watchdog reset if the VG_HALT signal was not working correctly or the vector engine never finished. No indication was given as to why testmode would reset.

scottb fixme leds...

The multigame testmode sequence uses a very different approach. This allows the multigame to be yet another tool in debugging failing boardsets. The mulitgame testmode starts by testing ALL 1K of CPU RAM using a uniq changing memory pattern to avoid aliasing issues. It writes the entire 1K, then verifies back the 1K pattern. If keeps a "running" bit mask of all the failures seen as it performs multiple passes across the RAM. At the end of the test, it determines which is any CPU RAM chips have failed and saves that result away in a register for later use. This allows the memory tests to continue even when the CPU RAM has failed. Next the 1st 1K of VECTOR RAM is tested using the same algorithm and "running" failures mechanism. Just like with the CPU RAM this is then mapped onto the chips that may have failed and that result is saved away. Lastly the 2nd 1K of VECTOR RAM is tested.

At this point the save register (SP) has a bit mask of 6 bits indicating which if any RAM chips are faulty. No RAM has been required to be functioning to get to this point.

The last test before the main testmode loop is invoked is a simple VG_HALT test. The purpose of this test is to make sure VG_HALT is not stuck and that the vector engine can run a few minimal instructions. If in the previous steps the VECTOR RAM had FAILED, then the VG_HALT test is not executed, but skipped. The VG_HALT test requires that upon entry the vector machine must indicate it is halted. A few instructions are poked into vector RAM and then the vector engine is started. The VG_HALT signal must then go inactive briefly while the vector engine runs those few instructions. Then the VG_HALT signal must become active again assuming the vector engine completed. If those transitions do not occur within a very short amount of time then the VG_HALT test is considered a failure.

Should a failure occur in the CPU RAM, VECTOR RAM or VG_HALT, then no attempt is made at using the vector engine to display any results, as these failures are considered fatal. The fatal failure code(s) are beeped out using both the audio section of the board AND the LEDS and like the original asteroids testmode the pattern consists of low and high pitched beeps (tones). As the tones are beeped out, the LEDS are set to indicate the same failure (ie. LED1-ON means low tone, LED2-ON means high tone). The corresponding memory chip locations is the same as the original asteroids code and is listed before. Note some memory chips have alternate chip locations on the board depending on the hardware level or hardware configuation of that board. If there are multiple failures one should consider that it might be possible that the RAM chips are ok and that some other hardware problem is contributing to the RAM being unable to respond (such as memory address decodes, memory data and address buffers, etc). It is also possible (but unlikely) that the original asteroids memory test passed, but now that the multigame is installed which does a much more extensive test that it is possible that a memory failure has been found that has been masked before. The failing chip(s) will need to be replaced before the multigame can continue, there is no bypass of the memory tests as that hardware is critical to a functioning multigame.

input test

The multigame testmode input test will show on the screen each possible input. There are 12 inputs that can be shown. p1-start, p2-start, coin-left, coin-center, coin-right, slam, rotate-left, rotate-right, hyperspace/shields, fire, thrust, diagstep. When the input is active text that corresponds to that input is displayed on the screen. See screen image below for where all 12 inputs show up. DIP switch settings are ignored by the multigame and not shown in testmode. The analog thrust input if configured is shown separately. Note: some of the input buttons are also used to trigger the sound test.

sound test

The multigame sound test is activated by various inputs. All possible sources of sounds can be tested. Asteroids hardware has more analog sounds than does Deluxe hardware. In deluxe mode some of these tests are not available and pressing that input key does nothing (other than show the input is active).

pokey test

During testmode the pokey chip is continually queried. The tests attempts to verify the pokey is present and minimally performing. One of the tests is to continually poll for random numbers from the chip and make sure the random numbers are changing and not stuck. Another test simply verifies some of the registers are reading values consistent with what is expected. Failing of this test means the pokey chip is bad or not present. Just because the test passes does not mean the pokey chip is fully functional, it could still have audio problems and those should be tested using the pokey sound test. The display continually shows the random number provided by the chip.

thrust interface test

When the multigame is configured for external thrust, testmode will then show the value provided by the external thrust interface circuit. The value is shown in hex and should change as the external thruster is moved. It should be noted that Lunar Lander does not make use of the full range of 256 values, in fact only uses about 25% of the range. This is consistent with how original lunar lander works.

high score save test

The high score save test is a simple test similar to all other Braze Technologies kits that save high scores. For the Asteroids multigame this is a single byte read/write test performed on a spare memory location in the serial eeprom. The test simply reads and writes a few patterns to one location and captures the result. The test is performed just once when entering test mode and the result is saved for display purposes. Failure could indicate a problem with the chip itself, the chip not present, or a problem on the multigame kit. This test is specific to the multigame and not related to the gameboard. This field also displays a status information about the high score save chip if it is erased or if it contains the older asteroids high score save data (see: Import Asteroids High Scores)

RAM Failure Codes (testmode)

Testmode RAM Failure is indicated by a sequence of 1 to 6 tones. A low-frequency tone is heard for each good RAM chip. A much lower frequency is heard for a failing RAM chip. At the same time the tone is played, the LEDS are updated. LED1 ON corresponds to a failing RAM, LED2 ON corresponds to a good RAM.

Example: 2 good (high) tones followed by 1 bad (low) tone indicates RAM #3 is bad. 3 low tones without any high tones would indicate RAMS #1, #2 and #3 are all bad, but that RAMS #4, #5 and #6 passed.

Note: this is an improvement from the original game software which would sometimes stop on first failure and not test the remaining RAMs. The multigame software always fully tests all 6 RAMs even when one or more fails.