nesdev.org

So for some reason whenever my hack is played on Nestopia or a Powerpak, the text is glitched up. Oddly enough this does not occur on any FCEU emulator it seems. I've been able to deduce that this either due my DTE routine that I coded or another ASM hack I did that affects the text. But what I really need to do is step through the code in a debugging emulator to see what the problem is. But I am not aware of any emulator that has a debugger and triggers this odd glitch on the hardware.

What game is it? What mapper is the game? FCEUX simulates Bus Conflicts, Nestopia does not. But I'm not sure if that would account for the differences. If it's a mapper with bus conflicts, make sure your mapper writes exactly match the values in the ROM at that address.
Get a third opinion from Nintendulator. If it's glitching there too, use its debugger to find out why.

It's Jesus Kyoufu no Biomonster, a mapper 1 game. It works fine on Nintendulator so that doesn't help me.

Okay... MMC1 with CHR RAM.
So we need to check for unexpected mapper writes that would bankswitch the CHR pages. A few emulators don't emulate bankswitching for CHR RAM, but most modern emulators do.
Did you expand the game to 512K? That would screw up CHR bankswitching if it used that.

Nestopia has source code, so I think it's possible to debug the emulator in Visual Studio as a replacement for a NES debugger. Breakpoints at certain kinds of mapper writes might reveal where the unexpected bankswitching is occurring.

Edit: Or it might not be related to bankswitching at all, possibly bugs in the ASM code. Who knows.

Nope, but I'm planning on expanding to 512K in the near future.

I actually think it's my DTE code as I just replaced it with the original text loading routine and now the game's not behaving strangely anymore.

Here's my code.

Have you tried Nintendulator?

rainwarrior wrote:Have you tried Nintendulator?

Pennywise wrote:It works fine on Nintendulator so that doesn't help me.

I'm looking at your DTE routine, but I'm not seeing anything the mapper could be interpreting as mapper writes. However, I'm probably missing something.

What assembler is this written for? I ask because the "$=$FF80" and "DEC $07F0 = #$00" directives aren't familiar to me. Also, could you point out what the hard coded addresses are used for.

Also, your code might be fine, but violating the calling conventions some other function expects. It would be nice to compare the original routine to yours. I want to check that the preserved and trashed registers line up.

Also, sometimes code expects a register to be trashed in a specific way. (For example, the bankswitch code in Final Fantasy trashes A, but it always leaves a zero there. When I replaced it to do an MMC3 mapper hack, I broke this assumption, which was being relied upon by at least one caller.)

Best of luck.

Intentional CHR bankswitching for games using 8K CHR-RAM and no other CHR-ROM is exceedingly rare, the only game I can think of that actually uses it is Lagrange Point.

Since I never got any screenshots of what "messed up text" looked like, I was just assuming some timed write was screwing up all graphics by rebanking CHR.

I made an edit at the end of my post where I threw out the entire idea of errant bankswitching, since it's unlikely that any CHR bankswitching code even existed in the first place. CPU code bugs (trashing registers and memory) are far more likely to cause problems that are affecting just the text.

But anyway, if you want to expand to 512K, you need to be careful of any CHR bankswitching code if there is any, since the CHR banking bits control which 256k of PRG-ROM is mapped in.

And I can't wait for the translation, I was always wondering what a game called "Jesus" would contain!


Edit: merging double post

Karatorian wrote:What assembler is this written for? I ask because the "$=$FF80" and "DEC $07F0 = #$00" directives aren't familiar to me. Also, could you point out what the hard coded addresses are used for.

I know that ASM6 lets you reassign $. When you do that, it does not change where generated code goes, but it changes the address of defined labels in that area.

The " = #$00" is probably a relic from disassembly. ASM6 seems to allow that kind of trailing junk on a line.

Based on these, I think it's code for ASM6.

Dwedit wrote:And I can't wait for the translation, I was always wondering what a game called "Jesus" would contain!

The Jesus is apparently a space station. Wikipedia explains.

The " = #$00" is probably a relic from disassembly. ASM6 seems to allow that kind of trailing junk on a line.

Is that relic causing the line to be assembled wrong, as if the = were a boolean equality operator?

Ok this is what the text looks like on Nestopia/Powerpak.



And this is what it looks like on every other emulator.



Yeah, I recently started using ASM6 recently. I have never a been a programmer and learned pretty much everything I know from hacking games. So, this code was done via the old-fashioned way of caveman hacking. I'm trying to become more programmer-like in my approach to ASM hacking.

We're shooting for an Easter release for JESUS, but the text editing needs to be finished, the compressed/encrypted title screen needs to be hacked, and I need to finish my double line hack. Then there's this annoying issue that boggles my mind.[/img][/list]

To me it looks like it's writing to the PPU during rendering. Maybe your code is too bloated, if you changed any.

I will admit that my routine might not be the best routine in the world, but aside from a few extra instructions, I've reused the code base for a bunch of other games and have never run into this problem.

Here's the original routine.

Does it behave any differently if you put the emulator(s) in PAL mode?

I checked PAL emulation in FCEUX and the game runs fine aside from a slowdown.

How does it behave in PAL mode on the other emulators, apart from the slowdown? The difference is that PAL consoles have 312 lines instead of 262, which gives your program much more time to upload changes to the PPU during vblank.