Just another set of N64 CPU tests

This repository contains a series of tests for verifying implementations of MIPS instructions specifically for the N64's VR4300 processor. Some notable features of these tests:

• All tests for each instruction contain a few thousand cases, the inputs are randomly generated from fixed-seed LCGs for random coverage of the input space.
• All tests, including those for 32-bit instructions, utilize the full 64 bits of the input and output registers. This helps catch common errors in implementing correcting sign extensions from 32-bit to 64-bit.
• All tests contain two memory images, the initial and final memory states. The final memory state for all tests was generated by running the test on hardware.

Test summaries:

• addu_data.bin: Single-instruction tests for addu
• ddiv_data.bin: Single-instruction tests for ddiv
• ddivu_data.bin: Single-instruction tests for ddivu
• div_data.bin: Single-instruction tests for div
• divu_data.bin: Single-instruction tests for divu
• dmult_data.bin: Single-instruction tests for dmult
• dmultu_data.bin: Single-instruction tests for dmultu
• dsll32_data.bin: Single-instruction tests for dsll32
• dsll_data.bin: Single-instruction tests for dsll
• dsllv_data.bin: Single-instruction tests for dsllv
• dsra32_data.bin: Single-instruction tests for dsra32
• dsra_data.bin: Single-instruction tests for dsra
• dsrav_data.bin: Single-instruction tests for dsrav
• dsrl32_data.bin: Single-instruction tests for dsrl32
• dsrl_data.bin: Single-instruction tests for dsrl
• dsrlv_data.bin: Single-instruction tests for dsrlv
• ldl_data.bin: Single-instruction tests for ldl
• ldr_data.bin: Single-instruction tests for ldr
• link_data.bin: Verifies behaviors of instructions that modify the RA register, and branch instructions used as tail calls
• lui_data.bin: Single-instruction tests for lui
• lwl_data.bin: Single-instruction tests for lwl
• lwr_data.bin: Single-instruction tests for lwr
• mult_data.bin: Single-instruction tests for mult
• multu_data.bin: Single-instruction tests for multu
• sll_data.bin: Single-instruction tests for sll
• sllv_data.bin: Single-instruction tests for sllv
• sra_data.bin: Single-instruction tests for sra
• srav_data.bin: Single-instruction tests for srav
• srl_data.bin: Single-instruction tests for srl
• srlv_data.bin: Single-instruction tests for srlv

The source to generate each test is currently unavailable, it is planned to be made available in the future.

---

Binary file spec

The binary format is designed to be easily loaded and integrated into any setup. They may be loaded directly by a program or may be embedded into an N64 ROM that implements loading and running their contents.

An 0x20 byte header:

/* 0x00 */ u32: offset of code chunk
/* 0x04 */ u32: length of code chunk
/* 0x08 */ u32: offset of initial memory state
/* 0x0C */ u32: offset of final memory state
/* 0x10 */ u32: the size in bytes of the memory states
/* 0x14 */ u32: load address of the code chunk
/* 0x18 */ u32: load address of the memory state
/* 0x1C */ u32: offset of first extended header

The code chunk contains a MIPS program, the entrypoint is the start of the chunk. The program must exit with a JR RA to whatever RA was provided by the host of the test. The code chunk expects to be loaded into memory at the load address specified in the header at position 0x14.

The initial memory state should be loaded into memory before the code chunk is executed, at the load address specified in the header at position 0x18. The code chunk may use data from this initial state for any purpose. The test also contains the final memory state, the code chunk transforms the initial memory state into the final memory state as it runs, the computed final memory state should be compared to the stored final memory state to indicate whether the test has passed.

Extended headers always start with:

/* 0x00 */ u32: header type
/* 0x04 */ u32: offset of next extended header

The rest of their contents then depends on the header type.

Extended Header Type 1: Function Description

For tests containing more than one function it is sometimes helpful to know the load address and size of every function the test contains before running it. This header provides this information following the common extended header contents:

/* 0x08 */ u32: number of functions (n)
/* 0x0C */ u32: index of the entrypoint function in the array that follows
/* 0x10 */ u32: function 0 VRAM address
/* 0x14 */ u32: function 0 size in bytes
/* .... */ Last two words repeated for each function [1,n)