It is currently Wed Nov 22, 2017 6:12 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Sun Feb 12, 2017 9:15 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
Thank you sir! ^_^;;


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 10:01 am 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 41
Location: Sweden
Cool! I was thinking I should write some kind of test rom for this, but I'm not sure if I could get the timings right! Haha.


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 12:07 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 729
Location: New York, NY
Rahsennor wrote:
So to get from the time of the $2006 write to the time of the v register load, the rule is "add 13 cycles (3.25 pixels) and round down to the nearest multiple of 4 (pixel)". If you don't emulate steps less than a pixel (and why would you) that works out to a three pixel delay from the second $2006 write to the v = t register load.


I added a delay of 3 PPU cycles to the PPU Addr register ($2006) write and it actually appears to have fixed the Difference (Unl) issue without breaking anything else (Battletoads stage 2 has yet to freeze, The Simpsons status bar does not shake, the MMC3 tests still pass, etc.).

Are register t updates delayed also? Or, does the delay happen only to v? $2006 supposedly updates v and t together (switched off of the state of w). Is that pair of updates delayed?

As for emulator implementation, is a queue/buffer required to simulate these delays? Nintendulator uses simple timers for the $2007 VRAM write delays. But, what happens if 2 writes happens within a short time period?

fred wrote:
Cool! I was thinking I should write some kind of test rom for this, but I'm not sure if I could get the timings right! Haha.


A test ROM verified on real hardware would settle the matter and greatly aid all emulator authors.

Zepper wrote:
1. True, Nintendulator has such "delay" on $2007 only.


VRAM read/write delays were discussed in other threads. And, not only are they delayed, but they are aligned to read/write cycles.

If v register writes are delayed, do they only occur on specific PPU cycles?

Zepper wrote:
2. Do you expect a Nintendulator update to formalize the recent $2006 loopy_v=loopy_t delay find? Yes?


More research should be done before anyone uses this. More importantly, the omnipotent Q remains in control of Nintendulator.

Zepper wrote:
Well, Battletoads still hangs during stage 2 - you know... it's a missing sprite zero hit.


As an experiment, make the X and Y increments happen one or two PPU cycles earlier that they normally should. That is how Nintendulator 970 avoids the problem.


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 12:24 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
The fastest consecutive writes by a 6502:

  1. BRK, /IRQ, /NMI: Three writes to $0100-$01FF in three cycles
  2. JSR: Two writes to $0100-$01FF in two cycles
  3. Read-modify-write (RMW) opcodes (ASL, LSR, ROL, ROR, INC, DEC): Two writes anywhere in two cycles
  4. Store instructions to zero page: One write to $0000-$00FF per three cycles
  5. Push instructions: One write to $0100-$01FF per three cycles
  6. Store instructions to zero page indexed or absolute: One write anywhere per four cycles

In $2000-$3FFF, only 3 and 6 apply. I imagine that RMW instructions on PPU ports are considered "undefined behavior". This leaves four cycles, or 12 dots, between the start of one write and the start of the next.


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 1:14 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 729
Location: New York, NY
tepples wrote:
The fastest consecutive writes by a 6502:

  1. BRK, /IRQ, /NMI: Three writes to $0100-$01FF in three cycles
  2. JSR: Two writes to $0100-$01FF in two cycles
  3. Read-modify-write (RMW) opcodes (ASL, LSR, ROL, ROR, INC, DEC): Two writes anywhere in two cycles
  4. Store instructions to zero page: One write to $0000-$00FF per three cycles
  5. Store instructions to zero page indexed or absolute: One write anywhere per four cycles

In $2000-$3FFF, only 3 and 5 apply. I imagine that RMW instructions on PPU ports are considered "undefined behavior". This leaves four cycles, or 12 dots, between the start of one write and the start of the next.


Right. So, a simple counter delay should be sufficient.

But, it's still unknown if the delayed write affects t and v, or just v and if the write is aligned with even/odd cycles. We need to figure out why the delay exists.


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 1:37 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
zeroone wrote:
But, it's still unknown if the delayed write affects t and v, or just v and if the write is aligned with even/odd cycles. We need to figure out why the delay exists.

Well, you see... Abstract concepts provide the "big picture", then you can get into details of how that big picture works. Going straight for the hypertechnical explanation without first providing a general overview of what's going on is going to be confusing for most people -- and is going to intimidate people and shy them away from the main question.


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 5:04 pm 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 41
Location: Sweden
zeroone wrote:
A test ROM verified on real hardware would settle the matter and greatly aid all emulator authors.

I began writing something but it often doesn't get past the cpu-ppu syncing stage in visual nes, or maybe it just takes a really long time. Seems fine in emulators. I don't actually own a nes, so I can't really get further at this point.

I'll get back to it some time™, but if someone doesn't want to wait and need a starting point, I'll attach what I had to compile it in cc65. I've written very little nes code, so it's probably ugly.


Attachments:
2nd2006-256.7z [1.18 KiB]
Downloaded 18 times
Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 5:09 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 288
zeroone wrote:
Are register t updates delayed also? Or, does the delay happen only to v? $2006 supposedly updates v and t together (switched off of the state of w). Is that pair of updates delayed?

I haven't run any simulations, but my understanding of the circuits is that all writes to t happen immediately. Only copying t to v is delayed. The timings fred posted earlier seem to agree.

The delayed copy is triggered by a dedicated circuit, whose output is ORed with the normal copy signals, so a second write to $2006 on the same pixel as a vertical or horizontal reset should cause the newly-written value to be copied to v immediately (and again three pixels later).

zeroone wrote:
As for emulator implementation, is a queue/buffer required to simulate these delays? Nintendulator uses simple timers for the $2007 VRAM write delays. But, what happens if 2 writes happens within a short time period?

The CPU can issue at most one bus operation every three pixels, so a simple timer will do.

zeroone wrote:
If v register writes are delayed, do they only occur on specific PPU cycles?

They're aligned to the pixel clock. I traced the circuit and simulated every alignment in Visual 2C02; there should be no special treatment needed for a pixel-accurate emulator.

zeroone wrote:
We need to figure out why the delay exists.

The circuit that generates delayed_write_2006_low takes no other input and serves no other purpose. It's a delibrate two-pixel delay, with a further one pixel delay in driving copy_vramaddr_vscroll and copy_vramaddr_hscroll, all explicitly timed by the pixel clock.

I don't have enough cycle-timing voodoo or functioning brain cells to write a test ROM, but if anyone who does wants more info, I'll see what I can find.


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 5:15 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
Rahsennor wrote:
zeroone wrote:
We need to figure out why the delay exists.

The circuit that generates delayed_write_2006_low takes no other input and serves no other purpose. It's a delibrate two-pixel delay, with a further one pixel delay in driving copy_vramaddr_vscroll and copy_vramaddr_hscroll, all explicitly timed by the pixel clock.

I don't have enough cycle-timing voodoo or functioning brain cells to write a test ROM, but if anyone who does wants more info, I'll see what I can find.

Awesome. Thanks a lot! ^_^;;

I sense that someone still doubts about it... :shock: :lol: :lol:


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 5:20 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 288
Zepper wrote:
I sense that someone still doubts about it... :shock: :lol: :lol:

And so he should, because I have the brain of a turkey right now. :P

A hardware-verified test ROM is always a good idea.


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 6:16 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
If an hardware test is required, what's the value of VisualNES (or Visual6502) after all? Let's assume the test FAILS in hardware. So, we have a problem with VisualNES, a major bug...? In short words, makes no sense.


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 6:24 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 729
Location: New York, NY
Zepper wrote:
If an hardware test is required, what's the value of VisualNES (or Visual6502) after all? Let's assume the test FAILS in hardware. So, we have a problem with VisualNES, a major bug...? In short words, makes no sense.


We want a test ROM that passes in real hardware. The test ROM is not for validating VisualNES; it's for validating emulators.


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 6:50 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5825
Location: Canada
Visual NES needs validating too. ;)


Top
 Profile  
 
PostPosted: Sun Feb 12, 2017 8:12 pm 
Offline

Joined: Fri Dec 30, 2011 7:15 am
Posts: 41
Location: Sweden
Rahsennor wrote:
They're aligned to the pixel clock. I traced the circuit and simulated every alignment in Visual 2C02; there should be no special treatment needed for a pixel-accurate emulator.

Oh, you can read and write to the ppu at every alignment in visual2c02? I never quite understood how to use r/w with the strange register access... I should give that a try again, haha.


Top
 Profile  
 
PostPosted: Mon Feb 13, 2017 7:27 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
rainwarrior wrote:
Visual NES needs validating too. ;)

Keep this line of thought and the "validation" won't pass in the hardware too. Remember - USA NES, Famicom (Jap), Dendy (Russian) and others. It may be valid in NES, but not on Famicom, for example.
In fact, it's the first time in 20 years that I see such goofy discussion. Names that should already be testing this stuff are just away of the discussion. Too bad.


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

All times are UTC - 7 hours


Who is online

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