It is currently Tue Sep 25, 2018 4:27 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Sun Aug 26, 2018 9:36 am 
Offline

Joined: Sun Aug 26, 2018 9:06 am
Posts: 2
Hi all,
I have some questions about Mesen's tracelog.

I'm debugging the 'instr_test-v3 / rom_singles / 01-implied.nes'.

And this is the output of the tracelog:
Code:
E783 SEI                                 A:00 X:00 Y:00 P:nv--dIzc SP:FD CYC:30  SL:0   CPU Cycle:0
E784 JMP $EBCF                           A:00 X:00 Y:00 P:nv--dIzc SP:FD CYC:36  SL:0   CPU Cycle:2
EBCF LDA #$00                            A:00 X:00 Y:00 P:nv--dIzc SP:FD CYC:45  SL:0   CPU Cycle:5
....


Why does the CYC PPU start from 30?


thanks.


Top
 Profile  
 
PostPosted: Sun Aug 26, 2018 10:52 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20574
Location: NE Indiana, USA (NTSC)
Probably because it takes a few cycles for the 2A03's clock divider to spin up and the DMA controller and 6502 core to come out of reset. The 6502 alone accounts for 7 CPU cycles, per "Internals of BRK/IRQ/NMI/RESET on a MOS 6502" and "How many cycles for R65C02 Reset?", which covers 21 of the 30 dots.


Top
 Profile  
 
PostPosted: Sun Aug 26, 2018 11:58 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 518
tepples is correct - there are (at least?) 7 CPU cycles of delay before the first instruction is executed (to fetch the reset address, etc.). This is 21 PPU cycles, but I ended up going with ~28? cycles purely because this is the value that gave the closest result compared to hardware results for the read2004.nes test, but there is no science behind the 28 cycles (odds are that it is somewhat incorrect).

The trace log's "CYC" value for the PPU is shown after the first byte of the instruction has been loaded, so it ends up writing 30 (which is the value of the last PPU cycle that was executed - e.g a total of 28+3 cycles have been executed by the time the CPU finishes processing the first instruction's first byte)

Trying it out in "Visual NES" and loading a NROM game into it, it looks like the first instruction starts executing around cycle 25-26. So Mesen is probably delaying the CPU's startup compared to the PPU a bit too much.

If you're just working on your CPU's code, though, you can just ignore the PPU cycles for now, the PPU should have no impact on any of those tests.


Top
 Profile  
 
PostPosted: Sun Aug 26, 2018 12:08 pm 
Offline

Joined: Sun Aug 26, 2018 9:06 am
Posts: 2
Thanks.

I found out where Mesen is doing this cycles.

https://github.com/SourMesen/Mesen/blob ... U.cpp#L106
Code:
   //The CPU takes some cycles before starting its execution after a reset/power up
   for(int i = 0; i < (model == NesModel::NTSC ? 28 : 30); i++) {
      _console->GetPpu()->Exec();
   }


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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