mirror of
https://github.com/daniel5151/ANESE.git
synced 2025-04-02 10:32:00 -04:00
93 lines
3.3 KiB
Text
93 lines
3.3 KiB
Text
CPU Power/Reset Tests
|
|
---------------------
|
|
Verifies CPU register values at power, and changes that occur during
|
|
reset. Also verifies that RAM isn't modified during reset.
|
|
|
|
|
|
Expected behavior
|
|
-----------------
|
|
At power:
|
|
A, X, Y = 0
|
|
P = $34
|
|
S = $FD
|
|
|
|
After reset:
|
|
A, X, Y unchanged
|
|
I flag set (P ORed with $04)
|
|
S decremented by 3, but nothing written to stack
|
|
|
|
|
|
Multi-tests
|
|
-----------
|
|
The NES/NSF builds in the main directory consist of multiple sub-tests.
|
|
When run, they list the subtests as they are run. The final result code
|
|
refers to the first sub-test that failed. For more information about any
|
|
failed subtests, run them individually from rom_singles/ and
|
|
nsf_singles/.
|
|
|
|
|
|
Flashes, clicks, other glitches
|
|
-------------------------------
|
|
If a test prints "passed", it passed, even if there were some flashes or
|
|
odd sounds. Only a test which prints "done" at the end requires that you
|
|
watch/listen while it runs in order to determine whether it passed. Such
|
|
tests involve things which the CPU cannot directly test.
|
|
|
|
|
|
Alternate output
|
|
----------------
|
|
Tests generally print information on screen, but also report the final
|
|
result audibly, and output text to memory, in case the PPU doesn't work
|
|
or there isn't one, as in an NSF or a NES emulator early in development.
|
|
|
|
After the tests are done, the final result is reported as a series of
|
|
beeps (see below). For NSF builds, any important diagnostic bytes are
|
|
also reported as beeps, before the final result.
|
|
|
|
|
|
Output at $6000
|
|
---------------
|
|
All text output is written starting at $6004, with a zero-byte
|
|
terminator at the end. As more text is written, the terminator is moved
|
|
forward, so an emulator can print the current text at any time.
|
|
|
|
The test status is written to $6000. $80 means the test is running, $81
|
|
means the test needs the reset button pressed, but delayed by at least
|
|
100 msec from now. $00-$7F means the test has completed and given that
|
|
result code.
|
|
|
|
To allow an emulator to know when one of these tests is running and the
|
|
data at $6000+ is valid, as opposed to some other NES program, $DE $B0
|
|
$G1 is written to $6001-$6003.
|
|
|
|
|
|
Audible output
|
|
--------------
|
|
A byte is reported as a series of tones. The code is in binary, with a
|
|
low tone for 0 and a high tone for 1, and with leading zeroes skipped.
|
|
The first tone is always a zero. A final code of 0 means passed, 1 means
|
|
failure, and 2 or higher indicates a specific reason. See the source
|
|
code of the test for more information about the meaning of a test code.
|
|
They are found after the set_test macro. For example, the cause of test
|
|
code 3 would be found in a line containing set_test 3. Examples:
|
|
|
|
Tones Binary Decimal Meaning
|
|
- - - - - - - - - - - - - - - - - - - -
|
|
low 0 0 passed
|
|
low high 01 1 failed
|
|
low high low 010 2 error 2
|
|
|
|
|
|
NSF versions
|
|
------------
|
|
Many NSF-based tests require that the NSF player either not interrupt
|
|
the init routine with the play routine, or if it does, not interrupt the
|
|
play routine again if it hasn't returned yet. This is because many tests
|
|
need to run for a while without returning.
|
|
|
|
NSF versions also make periodic clicks to prevent the NSF player from
|
|
thinking the track is silent and thus ending the track before it's done
|
|
testing.
|
|
|
|
--
|
|
Shay Green <gblargg@gmail.com>
|