It is currently Wed Oct 18, 2017 1:06 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 70 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 2:03 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Disch wrote:
Could the reason the test is failing be due to something else? Blargg's post clearly indicates it should be 1,2,3.


It's been a LONG time since I debugged it like crazy, so one possible reason is...
Code:
CPUOP(STA1) /* sta $xxxx */
  dmc_runfor(3);
  writevalue(offset, cpu->A);
  /* You can see this in the STA $100 after OAM DMA,
  where DMC DMA takes three cycles for two different times.
  This is because both times it's landing on the fourth cycle of STA $100.
  */
OPEND


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 2:14 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 709
Location: New York, NY
Zepper wrote:
@zeroone
You're being more boring than constructive.
#define microcode with an example, then we'll continue.


Sure. I just mean the incremental steps that occur as an instruction is executed. For instance, 1--7 below are separate microcode instructions. Each microcode instruction takes 1 CPU cycle. And, every single microcode instruction does a memory access; it's either a read instruction or a write instruction (see the R/W column). If RockNES does not run at the microcode level, how does it handle Blargg's "3 if it lands on a CPU write" case?

Code:
     Read-Modify-Write instructions (ASL, LSR, ROL, ROR, INC, DEC,
                                     SLO, SRE, RLA, RRA, ISB, DCP)

        #   address  R/W description
       --- --------- --- ------------------------------------------
        1    PC       R  fetch opcode, increment PC
        2    PC       R  fetch low byte of address, increment PC
        3    PC       R  fetch high byte of address,
                         add index register X to low address byte,
                         increment PC
        4  address+X* R  read from effective address,
                         fix the high byte of effective address
        5  address+X  R  re-read from effective address
        6  address+X  W  write the value back to effective address,
                         and do the operation on it
        7  address+X  W  write the new value to effective address

       Notes: * The high byte of the effective address may be invalid
                at this time, i.e. it may be smaller by $100.


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 2:26 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
My CPU emulator was written using this exact idea ages ago. You're misjudging my emulator.
Peace. ^_^;;


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 2:46 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 709
Location: New York, NY
Zepper wrote:
My CPU emulator was written using this exact idea ages ago. You're misjudging my emulator.
Peace. ^_^;;


I must have misinterpreted your description earlier in the thread. Thanks for the clarification.

If possible, could you please provide the code that you used to implement the PHA instruction?


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 3:05 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
zeroone wrote:
Zepper wrote:
My CPU emulator was written using this exact idea ages ago. You're misjudging my emulator.
Peace. ^_^;;


I must have misinterpreted your description earlier in the thread. Thanks for the clarification.

If possible, could you please provide the code that you used to implement the PHA instruction?


Not much.
Code:
/*      #  address R/W description
       --- ------- --- -----------------------------------------------
        1    PC     R  fetch opcode, increment PC
        2    PC     R  read next instruction byte (and throw it away)
        3  $0100,S  W  push register on stack, decrement S
*/
CPUOP(PHA3)
   _readvalue(cpu->PC);     //2nd cycle
   PUSH(cpu->A); cpu->S--;  //3rd cycle
   _INT_ACK(); /* acknowledge IRQ/NMI */
OPEND


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 3:24 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 709
Location: New York, NY
Thanks Zepper. In addition to returning a value from memory, does _readvalue() update the PPU by 3 PPU cycles?


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 3:39 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
What happened to the good old catch-up approach? What's with all this running stuff in parallel nonsense. =P


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 4:23 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
zeroone wrote:
Thanks Zepper. In addition to returning a value from memory, does _readvalue() update the PPU by 3 PPU cycles?

Yes. Functions with a _dash do not poll IRQ/NMI, since it must be done only near the last cycle.
Code:
#define PULL()           readvalue(0x100|cpu->S)
static inline BYTE _readvalue(C_DWORD offset)
{
   ppu_new_clock();
   cpu_address_bus = offset;
   return cpu->read_mem[offset >> 13](offset);
}
static inline void _writevalue(C_DWORD offset, C_BYTE value)
{
   ppu_new_clock();
   dmc_runfor(3);
   cpu->writemem[offset >> 13](offset, value);
}

Disch wrote:
What happened to the good old catch-up approach? What's with all this running stuff in parallel nonsense. =P

That scheme of queue events, then dequeue? No. ;)


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 5:09 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 709
Location: New York, NY
@Zepper

That looks great. That is exactly what I meant by an emulator running at the microcode level. I think the confusion in this thread is partially due to language-barrier issue.

However, even at the microcode level, the PPU and CPU are not perfectly synchronized. The PPU will advance by at least 3 PPU cycles and then the CPU catches up by running 1 CPU cycle. A engineering trade-off will likely have to be introduced to compensate for that gap.


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Mon Dec 21, 2015 5:33 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Zepper wrote:
That scheme of queue events, then dequeue? No. ;)



No, the scheme of predicting when the next interesting event is, and running the CPU up to that point, then catching everything else up.


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Tue Dec 22, 2015 5:38 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Anyway, about the game "The Simpsons - Bart vs Space Mutants", any clues regarding the flickering scorebar??? I tried messing up the sprite zero hit timing, but the game doesn't seem to be sensitive.

UPDATE: trapped secondary writes to $2006. Format is scanline, PPU cycle, loopy_v, loopy_t, screen enabled.
UPDATE2: can $2006 secondary writes occur before PPU cycle 256? Shouldn't be after 260?
Code:
-- frame --
000,172 * $0800 <- $3F00 ON
005,213 * $3F20 <- $0000 ON
196,254 * $72A6 <- $02C0 ON
-- frame --
000,176 * $1800 <- $3F00 ON
005,217 * $3F20 <- $0000 ON
196,265 * $02C0 <- $02C0 ON
-- frame --
000,181 * $0800 <- $3F00 ON
005,222 * $3F20 <- $0000 ON
196,263 * $02C0 <- $02C0 ON
-- frame --
000,173 * $0800 <- $3F00 ON
005,214 * $3F20 <- $0000 ON
196,262 * $02C0 <- $02C0 ON
-- frame --
000,175 * $0800 <- $3F00 ON
005,216 * $3F20 <- $0000 ON
196,260 * $02C0 <- $02C0 ON
-- frame --
000,173 * $0800 <- $3F00 ON
005,214 * $3F20 <- $0000 ON
196,268 * $02C0 <- $02C0 ON
-- frame --
000,178 * $0800 <- $3F00 ON
005,219 * $3F20 <- $0000 ON
196,263 * $02C0 <- $02C0 ON
-- frame --
000,173 * $0800 <- $3F00 ON
005,214 * $3F20 <- $0000 ON
196,262 * $02C0 <- $02C0 ON


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Tue Dec 22, 2015 11:47 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
What notation are you using for scanline number? I always thought the notation was to use 0-239 as the visible scanlines, -1 as the prerender, 240 as the postrender, and 241-260 as vblank time.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Tue Dec 22, 2015 12:28 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
That was always my notation -- but I don't think it's standardized anywhere =P

And now the PPU cycles have been shifted by 1 because of Visual2A03... and dots 1-256 are the ones that render pixels instead of the easier-to-use 0-255


Top
 Profile  
 
 Post subject: Re: CPU timing precision
PostPosted: Tue Dec 22, 2015 1:16 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Ah, sorry. :oops: I'm using...
0-19 VBlank,
20 scanline -1,
21-260 visible lines,
261 dummy scanline.


Top
 Profile  
 
PostPosted: Wed Dec 23, 2015 2:27 pm 
Offline

Joined: Mon Sep 27, 2004 11:51 pm
Posts: 101
Disch wrote:
It's not a hack. DMC DMA takes a different length depending on where they land during the OAM DMA.

Though I thought the last few cycles were 1,2,3 ... not 2,1,3. Lemme find that page.

EDIT: Here's the post:

viewtopic.php?p=62690#p62690

blargg wrote:
DMC DMA adds 4 cycles normally, 3 if it lands on a CPU write, 2 if it lands on the $4014 write or during OAM DMA, 1 if on the next-to-next-to-last DMA cycle, 3 if on the last DMA cycle.


So:

last cycle = 3 cycles
next-to last cycle = 2 cycles
next-to-next-to-last cycle = 1 cycle

so the last 3 DMC runs in Zepper's code should be 1,2,3 -- not 2,1,3

Good stuff. Thanks for this :)

_________________
http://hydesprojects.cjb.net/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 70 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 11 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