It is currently Sat Oct 21, 2017 9:58 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 25 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Sep 21, 2015 2:58 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
Some of you emulator authors might be interested in this. It's an execution log of the nestest test ROM (see http://wiki.nesdev.com/w/index.php/Emulator_tests) with bus cycles included, generated with Nintendulator. So basically the same as the nestest.log that's making rounds, but more detailed. I also removed the PPU cycle counters and included a CPU cycle count instead.

Let me know if you spot any errors in it (I hope I implemented the logging correctly).


Attachments:
nestest-bus-cycles.zip [137.74 KiB]
Downloaded 110 times

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi
Top
 Profile  
 
PostPosted: Mon Sep 21, 2015 9:53 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 284
I was looking for something like this, thank you very much. :beer:

One question, though: would it be possible to put a cycle counter on the bus cycle lines too? I could add them using line numbering but I'd like to be sure, if it's not too much work.


Top
 Profile  
 
PostPosted: Tue Sep 22, 2015 6:53 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
I won't do it right now, but I'll consider it if I'll redo the log at some point. I was thinking about generating logs from some other test ROMs also.

Didn't think it would be very useful to have the cycle counts on the bus cycles because every line equals one cycle.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Tue Sep 22, 2015 8:10 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 284
It would make sure the emulator is updating the clock at the right time. I know for a fact mine isn't - everything happens in the right order, but some events are on the wrong side of a clock increment, overlapping with the bus cycle before or after and leaving a gap on the other side.

Yes, I know, I'm basically saying I'm a terrible programmer, but that's all the more reason for an automated test.


Top
 Profile  
 
PostPosted: Wed Sep 23, 2015 6:06 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
One interesting think would be generating another log, but using a NMI test ROM. I don't remember of its name, it just displays an "E" in the screen, but the middle "-" must be ok. If the NMI timing (or PPU timing?) is wrong, the "E" is glitched.

Any chance?


Top
 Profile  
 
PostPosted: Wed Sep 23, 2015 6:54 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
I made a revision of the log, it now includes also the data that is being read/written. I removed the disassembly so that comparing the data is easier. Sorry, but still no CPU clocks on every line (feel free to make a small tool to mangle the data that way, and share the results if you want :))

NOTE: The log assumes that RAM has been initialized to 0 (there are at least a few cycles that read from uninitialized stack areas).

I noticed that blargg's CPU tests are not good candidates for these types of logs because they have a bunch of hardware dependencies in them. For example they poll $2002 in the beginning which makes the cycle counter and the shown bus data values useless if $2002 reads aren't implemented. Maybe it'd be useful to compile versions of those tests that start at a known address and don't access external hardware (except memory, of course). Such tests would also be easier to run through Visual6502/Visual2A03.

Zepper wrote:
One interesting think would be generating another log, but using a NMI test ROM. I don't remember of its name, it just displays an "E" in the screen, but the middle "-" must be ok. If the NMI timing (or PPU timing?) is wrong, the "E" is glitched.

Any chance?

I think CPU logs of PPU tests would be of limited value, because it'd be hard to notice any problems in PPU emulation from them. And having such logs might only be encouraging people to make Nintendulator emulators rather than NES emulators.


Attachments:
nestest-bus-cycles-no-disasm-v2.zip [131.2 KiB]
Downloaded 62 times

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi
Top
 Profile  
 
PostPosted: Wed Sep 23, 2015 5:01 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Hmm... good point. Not exactly to me, but to everyone else that puts Nintendulator at the top of everything else. -_-;;

At anyway, I believe test ROMs are the way of getting an emulator more accurate. Any chance of another NMI test ROM?


Top
 Profile  
 
PostPosted: Wed Sep 23, 2015 8:45 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 284
If you're going to go to the trouble of logging every bus cycle, it would be worth using a test ROM that covered all the page-crossing and dummy read cases. I know blargg's tests do, but they're designed to be verified by the code itself and depend on the PPU or APU, as you said.

Do we have a CPU-only ROM that does this already?


Top
 Profile  
 
PostPosted: Wed Sep 23, 2015 9:17 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Rahsennor wrote:
If you're going to go to the trouble of logging every bus cycle, it would be worth using a test ROM that covered all the page-crossing and dummy read cases. I know blargg's tests do, but they're designed to be verified by the code itself and depend on the PPU or APU, as you said.

Do we have a CPU-only ROM that does this already?


Sorry to be harsh, but you're kind off the my subject. :shock:


Top
 Profile  
 
PostPosted: Wed Sep 23, 2015 9:33 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 284
Sorry, shutting up now. :oops:


Top
 Profile  
 
PostPosted: Thu Sep 24, 2015 2:29 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
Rahsennor wrote:
If you're going to go to the trouble of logging every bus cycle, it would be worth using a test ROM that covered all the page-crossing and dummy read cases. I know blargg's tests do, but they're designed to be verified by the code itself and depend on the PPU or APU, as you said.

Do we have a CPU-only ROM that does this already?

I'm not aware of such a ROM. Recompiling blargg's test ROMs with some small changes would probably be the best option. Really the only thing that would probably have to be removed would be the $2002 reads, since hardware register writes don't affect timing.

Zepper wrote:
Any chance of another NMI test ROM?

Definitely not from me.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu Sep 24, 2015 4:02 am 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 284
thefox wrote:
I'm not aware of such a ROM. Recompiling blargg's test ROMs with some small changes would probably be the best option. Really the only thing that would probably have to be removed would be the $2002 reads, since hardware register writes don't affect timing.


The dummy read test ROMs use clear-on-read flags on the PPU/APU as part of the test. They fail (or worse, lock up) when run on a CPU-only emulator. The timing test ROMs also rely on APU reads.

I was thinking of writing a simple test ROM myself, but I'm probably not qualified for the task. :shock:


Top
 Profile  
 
PostPosted: Thu Sep 24, 2015 4:48 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
Oh yeah, I was thinking of different ROMs. Anyways, writing test ROMs that don't have to actually verify the results (just exercise the different scenarios) should be fairly easy. Although many of the dummy read scenarios are probably already covered by the normal tests (when used with bus cycle logs).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 3:51 pm 
Offline

Joined: Fri Jan 20, 2017 3:12 pm
Posts: 2
Hello all! Sorry for resurrecting such and old thread.

Am I completely misunderstanding the concept of crossing page boundaries, or has the version of Nintendulator which made this trace log wrongly implemented CPU cycle counting for branch instructions?

Code:
My emu
------
$CFFE(F0 05): BEQ $05        | [PC -> $D005]         A:0x5A X:0x81 Y:0x69 P:0x27 SP:0xFB CYC:2598
$D005(A9 AA): LDA #$AA                               A:0x5A X:0x81 Y:0x69 P:0x27 SP:0xFB CYC:2602

Nintendulator log
-----------------
CFFE  F0 05     BEQ $D005                       A:5A X:81 Y:69 P:27 SP:FB CPUC:2598
D005  A9 AA     LDA #$AA                        A:5A X:81 Y:69 P:27 SP:FB CPUC:2601      <<--------------------


Shouldn't an extra cycle be added at this point because we're branching from CFFE -> D005?


Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 4:04 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6293
Location: Seattle
No, because the instruction pointer already points to $D000 by the time the offset is going to be added. (Hence why relative branches have an effective displacement of -126 to +129 bytes)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 25 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group