I have a super weird bug in my emulator. Whenever Zelda moves horizontally into a new area, the whole screen appears black. But after a while, whenever I transition, it first shows the previous area(the area i was in before transitioning) before correctly switching to the right one(the area i should be in).
Here's a picture about the initial transition:
https://imgur.com/a/PruIdFJ(had to directly link the site because [img] isn't working sorry)
A video : https://streamable.com/s1m1bf
and this video 2 showing that after i move vertically the black screen disappears but then i initially see the wrong area first: https://streamable.com/3rpmbo
My vertical transitions on the other hand work just fine?
Does anyone have any idea as to what the problem might be?
this is my repo: https://github.com/sORTaC/BlueNes
could anyone help please? I don't know how to fix it
Weird Zelda transition screen bug?
Moderator: Moderators
Re: Weird Zelda transition screen bug?
It's a mirroring bug (i've been there!)
Re: Weird Zelda transition screen bug?
MMC1 is able to switch mirroring modes by writing to bits 1-0 of register $8000-9FFF (https://wiki.nesdev.com/w/index.php/MMC ... .249FFF.29). It sounds like you don't currently support this. Zelda switches mirroring depending on the direction it is going to scroll.
Re: Weird Zelda transition screen bug?
All I can remember is that my attempt at mirroring was completely wrong to begin with
after having a peek at your ppu I'd recommend: when reading and writing from/to the nametables make sure you translate the addresses properly. for example (pseudocode from memory)
uint16_t translate_nt(uint16_t address) {
switch (mirroring_type) {
case HORIZONTAL: return ((address / 2) & 0x0400) + (address & 0x03ff);
case VERTICAL: return address & 0x7ff;
}
}
writing to ppu ram:
ppu_ram[translate_nt(addr)] = data;
reading from:
return ppu_ram[translate_nt(addr)];
hope this helps,
best regards,
- dink
after having a peek at your ppu I'd recommend: when reading and writing from/to the nametables make sure you translate the addresses properly. for example (pseudocode from memory)
uint16_t translate_nt(uint16_t address) {
switch (mirroring_type) {
case HORIZONTAL: return ((address / 2) & 0x0400) + (address & 0x03ff);
case VERTICAL: return address & 0x7ff;
}
}
writing to ppu ram:
ppu_ram[translate_nt(addr)] = data;
reading from:
return ppu_ram[translate_nt(addr)];
hope this helps,
best regards,
- dink
Re: Weird Zelda transition screen bug?
I'm not so sure it's a problem with dynamic mirroring switching - I just tried modifying my own emulator to hardwire MMC1 to a single mirroring type, and I was unable to reproduce the exact effect shown in the original post (Vertical mirroring messed up the status bar, and Horizontal mirroring would start scrolling into an exact copy of the current playfield and then draw the new playfield over it from one side to the other).Fiskbit wrote: ↑Mon Jun 14, 2021 12:13 pm MMC1 is able to switch mirroring modes by writing to bits 1-0 of register $8000-9FFF (https://wiki.nesdev.com/w/index.php/MMC ... .249FFF.29). It sounds like you don't currently support this. Zelda switches mirroring depending on the direction it is going to scroll.
I also tried breaking the two nametable select bits in $2000 but was only able to trigger different-looking errors.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Weird Zelda transition screen bug?
You're right, modifying the game to not switch mirroring modes doesn't produce this behavior.
I'd be interested in seeing the full nametables during horizontal and vertical screen transitions; that might provide some clues.
I'd be interested in seeing the full nametables during horizontal and vertical screen transitions; that might provide some clues.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Weird Zelda transition screen bug?
Video 1 looks like four nametables being emulated.
Re: Weird Zelda transition screen bug?
I tried that too, but the resulting "blank" nametables were filled with white "0" characters - if 4-screen VRAM is being emulated, then there's got to be another PPU bug somewhere else causing it to render tile 0 incorrectly.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.