One Final Step?

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
One Final Step?
by on (#25525)
Hi, I have one more (and I hope final) problem. Many mapper 0 games run fine on my emu now, I even made Contra (UNROM mapper) to work. But my emu produces some graphic corruption under certain circumstances.

Ice Climber runs fine, but when I pause the game, I get the following pixel garbage:
Image
The same goes for Balloon Fight (it could have something in common with the fact that these games hide the sprites during pause). Before I implemented scrolling, pausing was not problem (if I remember correctly).

Lode Runner in-game runs fine, but the title screen is really messed up:
Image
Again, this problem has arisen after implementing the scrolling.


Contra runs fine until I get a power-up (one of those winged letters) or I cross the second bridge - then the sprites become very weird.
Image


Galaxian title screen is fine, but when the actual game starts, I see no invaders. It seems to me like wrong name or pattern table is selected, but I can't find any error in my code :cry:
Image
Maybe same scrolling-related problem as in Ice Climber, Balloon Fight and Lode Runner.


Does anyone have any idea what could cause these graphical glitches and errors? I have revised my code for many hours now but I couldn't find the mistake.
Re: One Final Step?
by on (#25533)
ZeroFusion wrote:
Hi, I have one more (and I hope final) problem.


Haw. Unfortunately, there are always problems ;D. It's part of the challenge!


Anyway... getting on point:

This does not look like 1 problem to me. Sprites borking and scrolling are seperate and totally unrelated areas. The problem with ice climber *looks* as if the game is locked in some sort of $2005 write loop. Does the game crash when you pause? Or does it begin to work normally again when you unpause?



That said -- I unfortunately don't have a clue as to what could be causing these. In times like this... it REALLY helps to have a CPU tracer built into the emu. Then you can dump a log for the offending frame(s) to find out exactly what the game is doing, and get more info on the problem from there.

It's a lot of extra work to write a tracer, yeah... but it will pay off bigtime. Not only will it save you loads of time with this paticular problem, but you certainly will get use out of it further down the road (for other mappers, etc).

by on (#25536)
Are you emulating the scrolling as described in loopy's document - that is, using the VRAM address for all rendering, rather than keeping separate "X" and "Y" scroll counters? Remember that, in addition to $2005 and $2006, $2000 also affects the VRAM address latch (nametable bits).

Is the VRAM address being incremented every active scanline, but only if background and/or sprites are enabled? (I had some debugging trouble a while back when I was updating it on every scanline even when the PPU rendering was off. That messed up a lot of graphics since the game code relies upon a stable address to transfer bulk data at the start of a level or before displaying the title screen.)

Are you correctly handling the flag that determines whether it's the 1st or 2nd write to $2005/6, including resetting it on a read from $2002?

by on (#25537)
Also, what language is all this written in? If it's in C/C++, I might be able to look over it and see if I can spot any obvious problems. No guarantees, though.