This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Hack working on FCEUX, but not on Nestopia/real console

Hack working on FCEUX, but not on Nestopia/real console
by on (#90922)
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.

by on (#90924)
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.

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

by on (#90928)
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.

by on (#90933)
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.

Code:
$=$FF80
LDA $07F0
BNE @@Branch1
LDX #$13
LDA ($00,X)
CMP #$40
BCS @@Branch2
@@Branch3:
INC $0013
BNE $FF93
INC $0014
RTS
@@Branch2:
CMP #$91
BCS @@Branch3
INC $07F0
SEC
SBC #$40
ASL
TAX
LDA $DEA0,X
RTS
@@Branch1:
DEC $07F0 = #$00
LDX #$13
LDA ($00,X)
SEC
SBC #$40
ASL
TAX
LDA $DEA1,X
INC $0013
BNE @@Branch4
INC $0014
@@Branch4:
RTS

by on (#90940)
Have you tried Nintendulator?

by on (#90942)
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.

by on (#90954)
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.

by on (#90959)
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.

Quote:
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?

by on (#90969)
Ok this is what the text looks like on Nestopia/Powerpak.

Image

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

Image

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]

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

by on (#90971)
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.

Code:
F:C31D:A2 13     LDX #$13
0F:C31F:A1 00     LDA ($00,X) @ $01AE = #$FF
0F:C321:F6 00     INC $00,X @ $0000 = #$AE
0F:C323:D0 02     BNE $C327
0F:C325:F6 01     INC $01,X @ $0001 = #$01

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

by on (#90974)
I checked PAL emulation in FCEUX and the game runs fine aside from a slowdown.

by on (#90975)
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.

by on (#90977)
Pennywise wrote:
I checked PAL emulation in FCEUX and the game runs fine aside from a slowdown.

Err... I was asking you to test the game on PAL mode on the emulators where it doesn't work, not the one where it works. I should have made this clear.

Apart from the slowdown (which is caused by the fact that PAL video has 50 frames/sec while NTSC has 60), other things might screw up, such as the pitch of the music and raster effects, all because of the different CPU/PPU frequencies. If the text looks right though, that's proof that VRAM writes are extending past VBlank time in NTSC mode, since the vertical blank is much shorter in NTSC.

by on (#90978)
As an alternative to trying PAL you could also try disabling the PPU before your code runs, and restoring it after. If the problem is that you're over, you'll black out part of the top of the screen, but at least the text should show up.

by on (#90980)
Switching PAL on Nestopia does not stop the text from glitching. Not sure how to disable the PPU on Nestopia though.

by on (#90981)
He means in code.

by on (#90984)
I don't think the problem is with the PPU though. The names are stored separately and are triggered in the text with a control code. So it should just pass by the DTE checks and continue on normally. The problem is probably that I altered the code that changes the text offsets in RAM. I should probably rework it and see if it fixes the problem.

by on (#90985)
I doubt it myself, HIGHLY. Think about it, that's just a code backend. Why would emulators have CODE run differently? Plus, there's letters in the right place on the trashed version too. It's bad PPU writes. I know it. FCEUX does emulate those and I've seen it, but something weird is going on deeper than that.

by on (#90986)
Emulators initialize ram differently.

by on (#90987)
If nothing is different on PAL, I bet on RAM initialization too. How are you initializing $07F0?

EDIT: I just checked, and it seems that both FCEUX and Nintendulator initialize $07F0 to $00, while Nestopia sets it to $ff. So yeah, this is looking like the programmer forgot to initialize the variable and is relying on a startup value of $00.

by on (#90989)
Yeah, that's the problem alright. I'm not initializing it all and just assuming it's automatically $00 when I load it. I guess was supposed to never assume it was already initialized and to initialize myself, but well that little fact slipped past me when I was learning this stuff on my own.

by on (#90991)
Well, you'll have to initialize it for it to function correctly on hardware. Real SRAM is essentially random on a cold boot and keeps the old value (probably) on a warm boot.