i am working on my emulator and i can get some of the test demos to work. but there are alot that just goto a grey screen. assuming its polling a ppu register. i wanted to test the cpu with one of the test roms like nestress, but that requires the graphics to work. is there a cpu test where i can debug in ram. like run it and use the ram for the out put ?
matt
Kevin Horton's nestest maybe ?
"This test program, when run on "automation", (i.e. set your program counter to 0c000h) will perform all tests in sequence and shove the results of the tests into locations 02h and 03h."
I'm not sure if it'll do what you want, the first time I tried it I had graphics working.
It would be nice of all test ROMs that didn't need the PPU would poll $2002 with a timeout, so they wouldn't get stuck if the PPU weren't implemented. This would allow them to run in an NSF player with little modification. Then again, it's pretty easy to simply fake $2002 if you don't have the PPU implemented.
i tried to get my controller input working and think it might be ok, but i can not get nestest to work. i was thinking that it might use sprites. does anyone know if it uses sprites? i dont have sprites yet.
and i tried setting the program counter to 0c000h, but my cpu core stops with unknown opcode 63. maybe i am loading it wrong ? not sure
is there a trusted cpu core that might be easily used to compare with mine?
thanks matt
I threw together a quick log function and recorded a log of my emulator running nestest.nes until the main screen appears. The register values to the left of the current instruction are *before* that instruction executes. I can give you the standalone code I used for logging/disassembly in case you'd like to insert it in your emulator and compare logs.
nestest.log.zip (84K)
My debugger breaks on any esoteric undefined instructions, and none are ever executed while I recorded the log.
i coded part of that debugging line and the first several lines are the same. if you could post your code for debugging that would be great.
if i start the programm counter at fffc, then i get the menu. but have a problem with my controller input so i can not select the test. maybe send a log of the reads and writes to 4016?
then if i set the program counter to c000, it stops with opcode 63. maybe a log of what you get if the program counter starts at c000?
thanks for your help
matt
mattmatteh wrote:
then if i set the program counter to c000, it stops with opcode 63. maybe a log of what you get if the program counter starts at c000?
Starting at address $C000, the first instruction is JMP $C5F5. This then runs through all of the tests, including the invalid opcode tests (the first of which runs opcode 04 - opcode 63 doesn't come until near the end). Unfortunately, a small programming error means that the program will
crash after completing all of the tests (just after it writes some values to the APU to play a 'beep' sound of some sort).
For a full trace log of nestest.nes when run in automation mode:
http://www.qmtpro.com/~nes/misc/nestestlog.zip
I see now; before I had thought you weren't even getting to the main selection screen, which is why I posted the log starting at reset.
I put together the disassembly module and example of use, for use in C or C++. I modified the log format to match that of the log Quietust just posted, except it doesn't have the CL: and SL: fields (clocks and scanlines).
nes_disasm-2.zip
thanks for the dumps, very helpful; in debugging. they have kept me busy finding all my errors.
Quietust,
i noticed the debug output from 2 opcodes seem to be delayed by one instruction. opcode sta 85 and stx 8e. example, shows it storing accumulator value 00, when accumulator is ff, and i think i saw later in the output that it loads ff too.
correct me if i am reading it wrong or misunderstand....
thanks,
matt
My trace logs show the states of each register/memory location BEFORE the opcode is executed, not after.
yes, i was aware that the registers were before the instruction.
for example...
line 36 and 37
C77E A9 FF LDA #$FF A:00 X:00 Y:00 P:26 SP:FB CYC:258 SL:241
C780 85 01 STA $01 = 00 A:FF X:00 Y:00 P:A4 SP:FB CYC:264 SL:241
lda loads the accumulator and it is showen in the next line for register A, then if register A is stored, should it be
STA $01 = FF
not
STA $01 = 00
sorry, if misunderstand this and thanks alot for your help.
matt
No, because memory location $0001 contained the value $00 BEFORE the STA instruction took place, so that 's the value you see - if you want to know the value that was just stored, then you look at the instruction (and see STA) and look at the appropriate register.
each line is ?
instruction registers before the instruction
then...
C771 EA NOP A:40 X:00 Y:00 P:24 SP:FB CYC:225 SL:241
C772 A9 00 LDA #$00 A:40 X:00 Y:00 P:24 SP:FB CYC:231 SL:241
C774 D0 03 BNE $C779 A:00 X:00 Y:00 P:26 SP:FB CYC:237 SL:241
C776 4C 7D C7 JMP $C77D A:00 X:00 Y:00 P:26 SP:FB CYC:243 SL:241
C77D EA NOP A:00 X:00 Y:00 P:26 SP:FB CYC:252 SL:241
C77E A9 FF LDA #$FF A:00 X:00 Y:00 P:26 SP:FB CYC:258 SL:241
C780 85 01 STA $01 = 00 A:FF X:00 Y:00 P:A4 SP:FB CYC:264 SL:241
C782 24 01 BIT $01 = FF A:FF X:00 Y:00 P:A4 SP:FB CYC:273 SL:241
at address c772, instruction LDA, the accumulator was 40, then on the next line it is 00
at address c77e, instruction LDA, the accumulator was 00, then on the next line it is FF
at address c780, instruction STA, the accumulator is FF but seems to store 00. also, if the previouse instruction is LDA FF, the next should store FF ?
and i have found other lines ( i can find the lines later ) where is stores the accumulator with a different value than A and loads from the same address with the value that was in A, not the argument of the instruction.
sorry if i am missing something and thanks for your help.
matt
sorry !!!!!
cancel that last post.
i think i got it now. the memory , not the accumulator.
thanks for the help, ill look it again in the morning.
matt
The idea is that it's giving you information you don't otherwise have. You have the registers, therefore you know the new value being stored, and the value read by read instructions.
Hi, thanks to Quiestust's log file I have fixed some bugs in my processor code - but why does the stack pointer start at 0xFD? Mine starts at 0, is this not correct?
Perhaps it starts at 0, but is decremented by 3 due to a reset interrupt being performed on startup (which would put it at $FD)
It doesn't matter where it starts as it wraps anyway and all programmers are aware of that. The NES may set it to 0xFD on power-up/reset (I wasn't aware of that until now) but don't worry about it. Most emulators of the 6502 set it to 0xFF. Just make sure that your stack pointer is 8-bit and works something like this;
CPU.Memory[Stack + 0x100] = ...
Quote:
It doesn't matter where it [stack] starts as it wraps anyway and all programmers are aware of that.
The initial value of the stack pointer
does matter if the code being executed doesn't initialize it and also uses absolute locations in the $100-$1FF region, or accesses the stack directly by doing tsx then lda $103,x. What reason would an emulator have to not initialize the stack pointer properly?
Disch wrote:
Perhaps it starts at 0, but is decremented by 3 due to a reset interrupt being performed on startup (which would put it at $FD)
That explains it, thanks.