It is currently Sat Oct 21, 2017 12:43 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 39 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject:
PostPosted: Tue Jul 26, 2005 4:16 pm 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Bregalad wrote:
I can guarantee that Castlevania 3 - Dracula's Curse (E) does glich while scrooling vertically in Nintendulator as well than on the real hardware (many emus doesn't show the glitch exacly how it is on the real hardwar), however I don't know if the US version has gliches or not.


You mean that background scanline flickering near the statusbar ? Any idea what causes this ?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 27, 2005 12:28 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
I like using VirtuaNES myself, it has good graphical inferface, good sound interface, and is pretty much accurate, but not as accurate than Nintendulator or FCEUltra.

About CV3, I think this is there because of the NTSC->PAL transition, and because the programmers didn't know that it was possible to write to $2005 between two $2006 writes, there is 8 black scanlines below the status bar, and where the scroll is setup to a new value varies in this 8 pixels range.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 27, 2005 11:23 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
[quote]I can guarantee that Castlevania 3 - Dracula's Curse (E) does glich while scrooling vertically in Nintendulator as well than on the real hardware (many emus doesn't show the glitch exacly how it is on the real hardwar), however I don't know if the US version has gliches or not.[/quote]

Interesting, because with the (U) version Nintendulator glitches incorrectly. The line seperating the status screen from the play screen should only flicker on the sides of the screen, not for the whole screen as Nintendulator does.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 27, 2005 9:44 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
That flickering is most likely due to incorrect timing on VRAM address reloading; we need to get kevtris to test the exact timing on his 3-in-1 tester so we can solve this problem once and for all.

I know for a fact that my MMC5 IRQ timing is correct.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 29, 2005 8:47 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
As I write this message, Kevin Horton is running the first of several PPU test programs on his 3-in-1 unit. This test will determine the exact point where the VRAM address latch is copied into the 'working' address register at the beginning of each frame (and will take quite a while to run, since it's testing every single cycle on the 'dummy' scanline). The test functions as such: set the PPU to start rendering at the 3rd nametable ($2800) with scroll X=0 and Y=0 and wait until just before the dummy scanline starts, then set Y-scroll to 128 at every possible point during the dummy scanline (starting at the very end, where it will have no effect) until the PPU starts rendering from 2A00 instead of 2800.

After I have some results, I'll write the next test to see when the horizontal scroll portion of the VRAM address is reloaded at the beginning of each scanline - set horizontal scroll to 0 at the beginning of the scanline, then set it to 128 near the beginning of HBLANK (starting after HBLANK, where it will have no effect, and moving to before HBLANK to see when it starts working).

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 29, 2005 9:02 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19114
Location: NE Indiana, USA (NTSC)
Quietust wrote:
As I write this message, Kevin Horton is running the first of several PPU test programs on his 3-in-1 unit. This test will determine the exact point where the VRAM address latch is copied into the 'working' address register at the beginning of each frame (and will take quite a while to run, since it's testing every single cycle on the 'dummy' scanline).

There are 341 cycles on scanline -1. How does 341 cycles of a loop take "quite a while", especially given that sprite 0 overlap lets you automate the test cycle and print a number within 6 seconds?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 29, 2005 10:43 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
The test was not running on a complete NES - it was running on a PIC microcontroller attached to an NES PPU, manually clocking it and watching the address bus and reading/writing its I/O port ($2000-$2007). The reason it took so long is because for every test (of which there were 1536 - 1364 for the scanline itself and a few others before and after), I had to wait for an NMI (cycle-exact) and the PIC is only capable of clocking the PPU at around 2.75MHz (as opposed to 21.47MHz) - add in the delays from dumping the address data over a slow serial connection, and it took nearly an hour to complete.

Now that I have results for the first test, I've discovered something rather peculiar: the PPU copies the VRAM address latch onto the 'working' VRAM address register during cycle 304 - that is, the 'nametable data' fetch cycle for the 7th sprite! It doesn't make much sense to me, but this is exactly what the test results indicate.

[edit]

Results are in for the second test. The PPU appears to reload the 'horizontal' portion of the VRAM address at cycle #257, the data fetch portion of the 'nametable' fetch for the first sprite. This is actually consistent with the addresses the PPU reads from for sprite 'nametable' and 'attribute' data.

Results for the 3rd (and final) test will be available when kevtris wakes up in the morning; after he ran the test and went to bed, I realized there was a significant bug in it.

[edit: fix description for cycle #257]

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Last edited by Quietust on Sat Jul 30, 2005 8:52 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 30, 2005 2:31 am 
Offline
User avatar

Joined: Thu Mar 24, 2005 3:17 pm
Posts: 355
Thanks. Silly question: in your explanation, is the 1st cycle cycle 1 (1..341) or cycle 0 (0..340) ?


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 30, 2005 7:36 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
0..340, of course.

[edit]

The final test is complete: the VRAM address vertical scroll increment takes place at cycle #251 - that is, during the data fetch portion of the last tile's attribute data (cycle #250 is when it outputs the attribute address). This happens to be exactly the timing my emulator currently uses. Horizontal increments have also been verified to occur during the 4th cycle of each tile (again, during the data fetch portion of the attribute data); in addition, the very last tile on each scanline increments both the vertical AND horizontal offsets - evidently, this why the PPU needs to reset the horizontal offset later.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


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

All times are UTC - 7 hours


Who is online

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