I've been writing my own NES emulator for fun over the last couple of weeks. I really only intended for it to play one game at first (Final Fantasy I, and thanks a million Disch for the commented assembly, it was priceless for my early debugging.)
After getting FF1 to where it seemed like it was working fine, I got the itch to try to see if I could get it to run a handful of other games well.
Shortly afterward, I got Super Mario Bros. working and looking great, except for one issue. Whenever Mario dies and falls off of the screen, he continues falling from the top of the screen, all the way down and wrapping back to the top again, all the while flashing colors kinda like when he is invincible after picking up a star, although the game still goes on to the next life when the death music ends. When Mario dies from falling into a pit, the same thing happens, except that Mario can still be steered left and right while falling until the death music ends.
When playing the Legend of Zelda 1, the title and explanation screens look correct, but when entering the character's name, there is no response to any buttons other than Start, 'A' and 'B'. Therefore the player can not use Select to move down to end registration nor move the cursor with the d-pad to select letters other than a.
Other than the mentioned issues, everything seems to work fine in FF1 and Super Mario Bros, and all legal-opcode tests pass in nestest.nes. Has anyone experienced similar problems and have some insight into what is happening here?
P.S. Many thanks go out to everyone on these boards whose documents and forum posts have helped me so far. Way too many to remember and list at the moment.
Even though nestest passes, the SMB problem still sounds like a CPU bug to me. Try blargg's CPU test too.
I was only able to find cpu timing test roms, is this the one you were referring to?
CaptainMuscles wrote:
I was only able to find cpu timing test roms, is this the one you were referring to?
http://www.fly.net/~ant/misc/
Just out of curiosity, what is the trick to getting the vertical scrolling to work in Final Fantasy? I have a bug in my emulator where when you scroll vertically in that game there are graphical glitches at the top and bottom, but horizontal scrolling works just fine. Zelda 2 and Metroid both scroll vertically just fine.
It goes through 3 distinct phases (ex: scrolling up):
The bottom tiles show at the top (for 8 frames)
Then the top tiles show up at the top and bottom. The top tiles are correct, but with incorrect attribute data (only for 1 frame)
The top tiles still show up at the bottom (for 7 frames)
I don't feel too bad since Nestopia v1.40h doesn't scroll it correctly either, but I'd like to know if you got it scrolling right and what the trick was.
MrSketch wrote:
I have a bug in my emulator where when you scroll vertically in that game there are graphical glitches at the top and bottom, but horizontal scrolling works just fine.
This is probably correct (specially since other emulators are showing the same thing). Many commercial games have vertical scrolling glitches. It is quite hard to have glitch-free scrolling in both directions with the NES. Most games that scroll in both directions have glitches either vertically or horizontally.
I guess I find it hard to believe that this really popular game has this bad of a glitch that isn't talked about more or mentioned on the wiki. I also checked Nintendulator which has the same problem. Here are some screenshots of what I'm talking about:
According to the entry on emuverse, my dump has the correct CRC and MD5 so it should be a good dump.
http://dorando.emuverse.com/html/final-fantasy.html#na
Edit:
This page on the wiki explains the overscan issues present with the NTSC PPU and that the top and bottom 8 rows are sometimes not displayed on NTSC TVs.
There isn't enough VRAM in the PAL NES for glitch-free scrolling in all directions. The issue is alluded to in
Mirroring, and I just added an example of a mirroring glitch in a different game to
Game Bugs.
NTSC NES games' scrolling engines were designed to run on NTSC television sets that
crop the picture at the top and bottom, and you'll see occasional glitches like this unless either A. your emulator emulates NTSC overscan (like pretty much everything since Nesticle), or B. your game uses raster effects to crop the glitches off (like Jurassic Park).
Thank you tepples for clearing this up. I always wondered why
Virtual NES had a one tile border around the edges and I guess this explains why.
Quote:
NTSC NES games' scrolling engines were designed to run on NTSC television sets that crop the picture at the top and bottom, and you'll see occasional glitches like this unless either A. your emulator emulates NTSC overscan (like pretty much everything since Nesticle), or B. your game uses raster effects to crop the glitches off (like Jurassic Park).
What he said. My screen looked just like yours before I started skipping the top and bottom 8 scanlines to emulate the visibile NTSC area.
tokumaru wrote:
IMO, people think too high of the programmers of the time. They were not better than the hobbist programmers of today (generally speaking), they just had a consistent working schedule and the financial incentive to get things done, even if that meant doing some sloppy coding to simplify things and get the games out in time.
I'm on the same opinion about this part too. If you read what Neil said, they didn't even have an english instruction manual when they started to work on it and they had to figure out how it work by guessing.
So any team of programmers with enough time and pressure from their publisher will be about to churn out a game. The difference with us is that we don't have the team, time and money to put on it.
Thanks for the references to Blargg's test roms. It turns out that the issue was caused by the way I am handling the functions for my operations. ASL, LSR, ROL, and ROR were all handling a zeropage, x that pointed to the memory location $00 as the accumulator version of those commands.
Also, as I mentioned in the CPU test thread, anyone experiencing massive failures in Blargg's test rom number 5 despite a seemingly working emulator should take a look at how they are handling the setting of processor status flags 5 and 6 during IRQ/NMI/BRK/PHP. As per a post I found by Disch somewhere on these boards, Flag 5 should be pushed as set for BRK/PHP and clear for NMI/IRQ. Flag 6 should be pushed as set for all four commands.
MrSketch wrote:
Thank you tepples for clearing this up. I always wondered why
Virtual NES had a one tile border around the edges and I guess this explains why.
I think, that if I didn't, I'd get complaints from the users, and they're a fickle bunch. This is why you don't do things in Java. I can't even really change the palette much without a dozen emails in my inbox.
But really, it provides a more user-friendly experience, but for an actual program with menus and settings, it's probably worth it to have an option to turn this on and off.
tokumaru wrote:
I find these glitches terribly distracting when I'm playing...
Me too.
tokumaru wrote:
... even though in practive they are not as big as the vertical ones because the leftmost column is hidden by hardware.
I think I may have mentioned this before, but I have to disagree with you on this one. People tend to notice things more horizontally rather than vertically, simply because our eyes are laid side by side rather than one on top of the other. It's true that you can hide one column on the side for horizontal mirroring, but sometimes I think all that does is make the screen look like it's shifted over too far and then you're stuck with crap colors on the other side. I don't notice vertical mirroring problems (I don't know if glitch is a good word, it kind of implies something isn't functioning properly) as much because my eyes are more focused on the mid section (including the sides) of the screen. This could be a bunch of crap, but that's kind of how I see it.
I think that's why Kirby's Adventure puts its attribute clash on the trailing edge of the scroll: because you're supposed to be looking ahead of Kirby.
tepples wrote:
I think that's why Kirby's Adventure puts its attribute clash on the trailing edge of the scroll: because you're supposed to be looking ahead of Kirby.
Yes, but I'm not sure if this works as intended. The one I found least distracting was Mega Man 6 I think, which distributed the glitched column as evenly as possible between both sides of the screen. This results in smaller glitched areas.
