I was recently watching videos on the fds version of ice climber and came across this video:
https://www.youtube.com/watch?v=bpC0V_G-mc4Apparently, some emus, namely nestopia and virtuaNES exhibit some strange behavior in later bonus stages, (crashing on nestopia, cpu jam) sprite garbage with virtuaNES.
At around 35:42 the game starts glitching and the video uploader even makes a comment about it. Not sure if any other emus do this but figured id ask here as other emus could be having this issue. Why would re-using sprites on the bonus stages cause nestopia to crash?
Is this an emulator issue or something else with the game itself?
Could this be something similar to what happened to
Kiki Kaikai - Doutou Hen?
In that sense, as far as I know according to the above link, the game itself could be the issue!
Do you mean where some files upon startup where missing? If that's the case, then why would the game jam up or crash or have garbled sprites after re-using the vegetable graphics?
Ice Climber FDS loads the initial CHR RAM from a file, then overwrites the graphic for the vegetable with a new sprite every bonus stage. (Graphics data is stored in PRG-RAM at 613F, loaded from the disk and unchanged)
But that alone isn't enough to account for the game picking garbage data to write in there.
Edit: Set RAM address 0056 to 13 to get the last valid vegetable, then 14 to get the first glitch.
Thanks for the info Dwedit! So apparently it is a game bug then or is it something wrong with nestopia's fds emulation? (and virtuanes and others)
Seems to be a game bug. $0056 is incremented at the end of every level (increments game difficulty and vegetable number), to a maximum value of 255.
When they multiply the level number by 2 and add to a pointer table to find the address of the vegetable graphics, they don't do any checks or limits there, so it reads garbage data as graphics.
Seems like they just didn't think you'd make it that far.
thanks dwedit for the informative info and posts. So, is there any way to fix this through a bug fix patch or is out of the realm of possibility and too messsed up? Weird they thought we would never make it past a certain point. haha.
*Spitfire_NES* wrote:
Weird they thought we would never make it past a certain point.
I thought that was shorthand for "nobody tested it that far before it shipped".
Don't like the bug? ASM hack the code:
Code:
> :6667:A5 56 LDA $0056 = #$00
<- Insert fix here: while A >= 0x14, subtract 0x14
:6669:0A ASL
:666A:AA TAX
:666B:BD 3F 66 LDA $663F,X @ $663F = #$3F
:666E:85 02 STA $0002 = #$2E
:6670:BD 40 66 LDA $6640,X @ $6640 = #$61
:6673:85 03 STA $0003 = #$61
:6675:AD 02 20 LDA PPU_STATUS = #$00
:6678:A5 10 LDA $0010 = #$1A
:667A:29 FB AND #$FB
:667C:8D 00 20 STA PPU_CTRL = #$1A
:667F:A9 05 LDA #$05
:6681:8D 06 20 STA PPU_ADDRESS = #$18
:6684:A9 20 LDA #$20
:6686:8D 06 20 STA PPU_ADDRESS = #$18
:6689:A0 00 LDY #$00
:668B:B1 02 LDA ($02),Y @ $6132 = #$67
:668D:8D 07 20 STA PPU_DATA = #$00
:6690:C8 INY
:6691:C0 40 CPY #$40
:6693:D0 F6 BNE $668B
:6695:60 RTS -----------------------------------------
Thanks for the info again dwedit. I have no idea how to code in assembly or what hack to even put in that place. Are there graphics that are supposed to be in place of the garbage graphics?
Perhaps someone who knows assembly could help here maybe.
Tried doing a fix for this, but FCEUX seems to ignore my breakpoints with FDS-games. :/
oRBIT2002 wrote:
Tried doing a fix for this, but FCEUX seems to ignore my breakpoints with FDS-games. :/
What fix did you have in mind oRBIT? Also great work on all the patches you have done thus far! I hope a solution presents itself.
Was wondering exactly what kind of fix you had in mind?
oRBIT2002 wrote:
Tried doing a fix for this, but FCEUX seems to ignore my breakpoints with FDS-games. :/
FCEUX breakpoints seem to work for me with FDS games. Can you give a specific example of the problem? If we can reproduce it, someone might be able to fix it.
Perhaps I'm doing something wrong but I've played alot with the FCEUX debugger earlier..
I set a breakpoint at $6667 but it is never triggered.
*Spitfire_NES* wrote:
oRBIT2002 wrote:
Tried doing a fix for this, but FCEUX seems to ignore my breakpoints with FDS-games. :/
What fix did you have in mind oRBIT? Also great work on all the patches you have done thus far! I hope a solution presents itself.
Was wondering exactly what kind of fix you had in mind?
The .fds could probably be patched with a fix quite easily (in theory), however FCEUX isn't cooperating at the moment..
Try a read breakpoint at $56 instead.
oRBIT2002 wrote:
Perhaps I'm doing something wrong but I've played alot with the FCEUX debugger earlier..
I set a breakpoint at $6667 but it is never triggered.
I can't find an FDS file for Ice Climber, but I can set execution breakpoints in the $6000-7FFF range and have them trigger for other FDS files.
Did you choose "execute" for the breakpoint type? A "read" type breakpoint will not trigger for an instruction read, it's only for reads that are the effective address of an instruction.
Also, it's easy to accidentally disable a breakpoint by double clicking on it. (There should be an E next to the breakpoint if it's enabled. There's a field of ------, might look like ECRWXF if all of the various breakpoint modes were active. E = enabled, C = CPU memory, R = read, W = write, X = execute, F = forbid.)
I finally fixed this. I've uploaded an ips-patch to my website (check signature for URL). Thanks guys for finding this! This stuff is pretty entertaining to do..
Thanks for taking the time to fix this orbit! Im about to play it now.
Address $56 also seems to set the difficultylevel. At $13 it's pretty stressful.
"Ice Climber" however will always have a special place in my heart, it was the first NES game I played back in the 80's.
That fix is a difficulty level cap, not a graphics fix by itself.
Dwedit wrote:
That fix is a difficulty level cap, not a graphics fix by itself.
Are you talking about the previous post dwedit or the patch on orbits site?
Dwedit wrote:
The patch on the site.
Hmm i thought orbit fixed the sprite garbage? I'm currently testing the patch but have only gotten a few levels in. It says in his patch notes he fixed it. What does he need to do to fix the bug?
The patch does fix the sprite garbage, but due to the way it was implemented, puts a cap on the difficulty level. Same variable is used for difficulty level/flags and which vegetable appears.
My suggestion was to modify only the A register, as opposed to writing a smaller number back to the difficulty variable (which that patch does).
Ah thanks Dwedit, I'll fix this!
EDIT:
Hm, what would the expected behaviour be for "bonusfruits" assuming address $56>=$14? Should they start over from $00?
oRBIT2002 wrote:
Ah thanks Dwedit, I'll fix this!
EDIT:
Hm, what would the expected behavior be for "bonusfruits" assuming address $56>=$14? Should they start over from $00?
Is there a way to make an option for differing difficulty settings if you can poke around with the values?
I was going to ask about the bonusfruits question you had. When the graphics were going into garbage sprites, were they trying to reset back to the first set of bonus fruit sprites? I hope im making sense, lol!
In the bugged FDS game, it wasn't trying to go back to any earlier bonus fruits, instead it was just going beyond the last one into garbage land.
The VS System version of the game properly wraps back to the first bonus fruit.
So the behavior should be MOD 0x14.
As in something like this:
-:
SEC
SBC #$14
BCC -
CLC
ADC #$14
I can't get your example to work Dwedit. Perhaps it's because it's beginning to get late here in Sweden and I'm tired.
Anyway, my current code looks like this ("inserted" at $6667) but obviously it needs work assuming someone reaches a really high difficultlevel (not sure that's possible, I think there are checks for this so it can't continue to increment all the time).
Code:
start: lda $56
cmp #$14
bcc bonus_ok
clc
sbc #$13
bonus_ok:
asl
jmp $666a
Thanks for your continued work orbit! Were you able to work past the issue you were having last night?
I've uploaded a slightly modified version to my website. It's still not 100% (but few will probably notice anyway
).