These tests are created by Joel Yliluoma.
The test framework however is created by Shay Green, and is documented below.
NES Tests Source Code
---------------------
Building with ca65
------------------
To assemble a test with ca65, use the following commands:
ca65 -I common -o rom.o source_filename_here.s
ld65 -C nes.cfg rom.o -o rom.nes
your_favorite_nes_emulator rom.nes
Don't bother trying to build a multi-test ROM, since it's not worth the
complexity. Also, tests you build won't print their name if they fail,
since that requires special arrangements.
Framework
---------
Each test is in a single source file, and makes use of several library
source files from common/. This framework provides common services and
reduces code to only that which performs the actual test. Virtually all
tests include "shell.inc" at the beginning, which sets things up and
includes all the appropriate library files.
The reset handler does minimal NES hardware initialization, clears RAM,
sets up the text console, then runs main. Main can exit by returning or
jumping to "exit" with an error code in A. Exit reports the code then
goes into an infinite loop. If the code is 0, it doesn't do anything,
otherwise it reports the code. Code 1 is reported as "Failed", and the
rest as "Error <code>".
Several routines are available to print values and text to the console.
Most update a running CRC-32 checksum which can be checked with
check_crc, allowing ALL the output to be checked very easily. If the
checksum doesn't match, it is printed, so you can run the code on a NES
and paste the correct checksum into your code.
The default is to build an iNES ROM, with other build types that I
haven't documented (devcart, sub-test of a multi-test ROM, NSF music
file). My nes.cfg file puts the code at $E000 since my devcart requires
it, and I don't want the normal ROM to differ in any way from what I've
tested.
Library routines are organized by function into several files, each with
short documentation. Each routine may also optionally list registers
which are preserved, rather than those which are modified (trashed) as
is more commonly done. This is because it's best for the caller to
assume that ALL registers are NOT preserved unless noted.
Some macros are used to make common operations more convenient. The left
is equivalent to the right:
Macro Equivalent
-------------------------------------
blt bcc
bge bcs
jne label beq skip
jmp label
skip:
etc.
zp_byte name .zeropage
name: .res 1
.code
zp_res name,n .zeropage
name: .res n
.code
bss_res name,n .bss
name: .res n
.code
for_loop r,b,e,s calls a routine with A set to successive values
--
Shay Green <gblargg@gmail.com>
Some tests might turn the screen off and on, since that affects the
behavior being tested. This does not indicate failure, and should be
ignored. Only the test result reported at the end is important.
The error code at the end is also reported audibly with a series of
tones, in case the picture isn't visible for some reason. The code is in
binary, with a low tone indicating 0 and a high tone 1. The first tone
is always a zero, so you can tell the difference. A code of 0 means
passed, 1 means failure, and 2 or higher indicates a specific reason as
listed in the source code by the corresponding set_code line. Examples:
low = 0 = passed
low high = 1 = failed
low high low = 2 = error 2
low high high = 3 = error 3
See the source code for more information about a particular test and why
it might be failing. Each test has comments and correct output at top.
--
Shay Green <gblargg@gmail.com>
41d70a5e1d