Does anyone know what could be going on here?
Possible nametable issue here? My emulator passes all of blargg's ppu and vbl tests (immensely helpful, thanks). I know it is not a bad dump as i've used it on other emulators fine.
What about nestest and NEStress? It could be an opcode error. Run them to make sure that you're CPU is 100%.
If you're wondering why the title screen has not appeared, it's because you haven't emulated the PPU's one byte read delay yet.
This is how it should look:
http://www.geocities.com/legocentric/
I've just realised what it is - if rendering was in progress (ie. currently on scanlines 0-240), reads to 2007 would be ignored, and instead return the buffered value, whilst setting the buffered value to zero. After commenting it out and allowing all reads to 2007, it displays correctly.
Should i be allowing reads to 2007 during rendering? What about writes?
raidtab wrote:
Should i be allowing reads to 2007 during rendering? What about writes?
No - reads and writes should not be allowed
while rendering, but remember that it is certainly possible to
turn off rendering during scanlines 1-240 by clearing $2001.3 and $2001.4 - once you do this, you can mess with $2007 at any point during the frame.
Quietust wrote:
raidtab wrote:
Should i be allowing reads to 2007 during rendering? What about writes?
No - reads and writes should not be allowed
while rendering, but remember that it is certainly possible to
turn off rendering during scanlines 1-240 by clearing $2001.3 and $2001.4 - once you do this, you can mess with $2007 at any point during the frame.
A programmer can read from $2007 any time they like, even if it's during refresh. I know that this will mess the screen up, but it's not like reading or writing to $2007 is banned or anything.
Uhh... right, but if a read is performed during the rendering, is valid data returned?
$2007 reads/writes during rendering are possible, tough they ARE banned. Writes to $2007 causes the $2006 pointer to increase, meaning that the the PPU scrolling will go mad until it's set to a proper value again (and the write will have no effect of course), and I have no idea what a $2007 read can do, but most probably it reads some unpredictable stuff and make the scrolling go mad.
A read from $2007 at any time will cause it to increase by 1 or 32. Naturally during refresh this will have an effect on scrolling, that doesn't mean, however, that it is banned. Has the mighty Quietust made an error?
During rendering the PPU is constantly accessing the bus lines. Reading/writing $2007 during this time will not have expected results (there will be bus conflicts, and ultimately you may end up writing nothing or garbage instead of the intended byte -- and may get random garbage when reading).
To "safely" read/write $2007, you must do so in VBlank, or when the PPU is off.
Quote:
Has the mighty Quietust made an error?
Nope, Quietust and me just said that $2007 writes and reads during rendering are worthless and will just scew up the screen, so no reads/writes should be "allowed". That don't mean they cannot happen, unlike what you seem to understand.
Disch wrote:
During rendering the PPU is constantly accessing the bus lines. Reading/writing $2007 during this time will not have expected results (there will be bus conflicts, and ultimately you may end up writing nothing or garbage instead of the intended byte -- and may get random garbage when reading).
To "safely" read/write $2007, you must do so in VBlank, or when the PPU is off.
Can anyone provide anything further on this?
I think WedNESday's point is that the NES hardware has no way of banning a program from doing things; if the CPU reads from address $XXXX, it will read from that address no matter what. The only question is what happens when the CPU reads. "Banned", "disallowed", "illegal", "invalid", etc. are descriptive of human activities, but there's usually never a human around to police what a NES program does. The only things a NES program can't do are those that are logically impossible, like reading from address $10000.
WedNESday wrote:
Can anyone provide anything further on this?
Sure, try
this post.