req: nestest.asm - NESdev BBS

req: nestest.asm
by zagadka on 2007-11-17 (#28345)

hi everyone

does anyone here know where to find the nestest.asm source file?

i found the readme, but i'm failing some tests and the error codes don't help me much. the readme says

Code:

For a more detailed reason
for the failure, you should check out the .ASM file included with this
document.

but i haven't been able to find the source code anywhere :oops:

by atari2600a on 2007-11-17 (#28348)

perhaps using a 6502 dissasembler may help?

http://www.ameth.org/~veilleux/dcc6502.html

by zagadka on 2007-11-17 (#28349)

your link is dead for me at the moment.. i'll try it again later

Code:
Firefox can't establish a connection to the server at www.ameth.org.

by zagadka on 2007-11-17 (#28350)

ok, fixed the flag tests, i didn't realise bit 5 of the status register was meant to be 1 at all times!

Code:
// 1 at all times
cpu->status |= MASK_BIT5;

by zagadka on 2007-11-17 (#28352)

ok, fixed the remaining bugs, i pass all of nestest.asm now

thanks a lot to whoever wrote it!

the actual bugs were

1. overflow for sbc/adc was wrong

this is what i had originally

Code:
static void cpu_updateOverflow(CPU cpu, Byte a, Byte b, Byte c) {
assert(cpu != NULL);

// positive // positive // negative
if ( ((a & MASK_BIT7) == MASK_BIT7) && ((b & MASK_BIT7) == MASK_BIT7) && ((c & MASK_BIT7) == 0) ) {

cpu_setOverflow(cpu, TRUE);

// negative // negative // positive
} else if ( ((a & MASK_BIT7) == 0) && ((b & MASK_BIT7) == 0) && ((c & MASK_BIT7) == MASK_BIT7) ) {

cpu_setOverflow(cpu, TRUE);

} else {
cpu_setOverflow(cpu, FALSE);
}
}

it still looks right to me, but apparently it was wrong. i did a rewrite based on the overflow stuff here

2. jmp indirect wasn't wrapping around the low byte property

3. all the indirect,x functions weren't wrapping around the low byte properly

(i made the indirect y functions wrap too for now)

by tepples on 2007-11-17 (#28357)

atari2600a wrote:
perhaps using a 6502 dissasembler may help?

http://www.ameth.org/~veilleux/dcc6502.html

"For a more detailed reason for the failure, you should check out the .ASM file" implies that the reasons are in code comments. Disassembly does not recover code comments.

by blargg on 2007-11-17 (#28362)

zagadka wrote:
ok, fixed the flag tests, i didn't realise bit 5 of the status register was meant to be 1 at all times!

Status bits 4 and 5 doesn't even exist. Lots of docs say otherwise, which is the start of confusion! The 6502 remembers only 6 status bits. When pushing them on the stack as a byte, the two extra bits are set to fixed values based on the cause of the push. Bit 5 is always set, and bit 4 is set for BRK and PHP, clear for an interrupt (IRQ/NMI).

by atari2600a on 2007-11-17 (#28370)

tepples wrote:
atari2600a wrote:
perhaps using a 6502 dissasembler may help?

http://www.ameth.org/~veilleux/dcc6502.html

"For a more detailed reason for the failure, you should check out the .ASM file" implies that the reasons are in code comments. Disassembly does not recover code comments.

Yeah, but if the original ASM files are unavailable, at least having a disassembly can be of a little help...

by Zepper on 2007-11-17 (#28375)

Actually, I have a built-in disassembler that can dump a piece of code into a text file, making my analysis much easier, regardless the original source of the program.

by kevtris on 2007-11-18 (#28410)

blargg wrote:
zagadka wrote:
ok, fixed the flag tests, i didn't realise bit 5 of the status register was meant to be 1 at all times!

Status bits 4 and 5 doesn't even exist. Lots of docs say otherwise, which is the start of confusion! The 6502 remembers only 6 status bits. When pushing them on the stack as a byte, the two extra bits are set to fixed values based on the cause of the push. Bit 5 is always set, and bit 4 is set for BRK and PHP, clear for an interrupt (IRQ/NMI).

Yes, but reading it (i.e. PHP PLA) results in bit 5 always being set. Checking out the 6502 chip schematic, it is shown pulled up! the BRK flag comes from the interrupt logic like you'd expect.

As for the test ROM, I am the dork that wrote it a long time ago. Sorry there's no source for it but I don't have a clean version of the source that I released. Disassembling it (or running the code under a debugger (you DO have a simple debugger in your emu, right? ) should result in the code you seek.

The code is REAL simple, I just do the tests one after another and write a number to a ZP location if something fails. I tried to make it so that the earlier tests have to pass before those functions get used later on in other tests, so that SOMETHING would work at first and it wouldn't just fail right off the bat. Though if your CPU is REAL broken it still might not work.

by zagadka on 2007-11-18 (#28412)

i pass all your tests now

in other news i've decided to call my emulator 1337nes

by atari2600a on 2007-11-18 (#28413)

lol, kind of reminds me of a friend's 8086-compatible IRC client, 1337IRC!