01459: bigkong, ckong, ckonga, ckongalc, ckongb, ckongg, ckongo, ckongs, ckongjeu, monkeyd: Hammer disappearing on Rivet Stage

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
01459	Graphics	Minor	Always	Mar 5, 2008, 14:30	Oct 6, 2010, 02:34

Tester	Tafoid	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	Bugs That Aren't Bugs	OS	Windows 2000
Status [?]	Resolved			Driver	nichibutsu/cclimber.cpp
Version	0.123u3	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	01459: bigkong, ckong, ckonga, ckongalc, ckongb, ckongg, ckongo, ckongs, ckongjeu, monkeyd: Hammer disappearing on Rivet Stage
Description	All Crazy Kong sets I could test exhibit an odd behavior. When you use the Hammer on the left side of the 3rd floor in the Rivet Stage - after that Hammer is used and disappears, the Hammer sitting on the 4th floor in the center also vanishes, but it still obtainable by jumping for it. The reverse of this (getting 4th Floor Hammer first) does not make the other Hammer disappear.
Steps To Reproduce	Use Save States (0.125) for either: ckong (cclimber.c) ckongg (~~galaxian.c~~ galaxold.c) (changed in 0.124u1) ckongs (scramble.c) All are set to STATE #1. Jump immediately to get the Hammer - allow the Hammer to disappear and notice the 4th Floor Hammer also vanishes.
Additional Information	Given that it's a bug that spans multiple platforms (cclimber.c, ~~galaxian.c~~ galaxold.c, scramble.c) - it might be an original bug of the whole bootleg line. PCB verification would be very useful here!
Github Commit

Flags	Verified with Code
Regression Version
Affected Sets / Systems	bigkong, ckong, ckonga, ckongalc, ckongb, ckongg, ckongo, ckongs, ckongjeu, monkeyd

Attached Files	Crazy Kong Save States.zip (5,694 bytes) May 6, 2008, 01:59

No.00204 Tafoid Administrator Mar 17, 2008, 20:52 edited on: Apr 30, 2008, 15:22	I had -cheat set on in these recordings. You can play them back if you set this to on. When 0.125 comes around, I'll re-upload the save states for a main released to make the replays more accessible and without -cheat.
No.00888 Tafoid Administrator May 6, 2008, 01:59	Created Save States with 0.125 and without -cheat toggled for ready testing.
No.05494 phantomdj Tester Jan 12, 2010, 07:42 edited on: Jan 12, 2010, 07:43	This bug also occurs on the girders screen, if you manage to grab the upper hammer first, and on the conveyors screen, if you grab the upper hammer first. This appears the be a bug in the original program. I don't have access to an actual PCB to test on, but my code analysis reveals that buggy code (the hack to make donkey kong into crazy kong) is to blame. Basically the code runs a new patch for every frame when a hammer is active. The problem is that this patch also runs once right after a hammer has been made inactive. The patch is supposed to erase the proper hammer from the screen when it is grabbed. Due to the buggy code, right when the first hammer runs out, the code assumes that the 2nd hammer must be active, when it is not, and erases it. This does not appear to be a MAME bug. Here is the relevant code section, which deals with the code for the rivets , with my comments , for those who want the details. This is from the ckong romset. ; called from #3F3F during active hammer 46C0: DD 77 05 ld (ix+$05),a 46C3: 3A 27 62 ld a,($6227) ; load screen number 46C6: FE 01 cp $01 ; screen 1 ? (girders) 46C8: CA 99 42 jp z,$4299 ; yes, skip ahead 46CB: FE 02 cp $02 ; screen 2 ? (conveyors) 46CD: 28 29 jr z,$46F8 ; yes, skip ahead ; else it must be the rivets [there are no hammers on elevators] 46CF: 3A 81 66 ld a,($6681) ; load A with 1st hammer indicator. (other is at #6691) 46D2: E6 01 and $01 ; is the 1st (lower) hammer active? 46D4: 20 11 jr nz,$46E7 ; yes, skip ahead and erase it ; else erase the 2nd (upper) hammer [runs every frame the hammer is active... sloppy] ; [this is buggy programming. will also arrive here right after 1st hammer finishes] 46D6: 21 EC 91 ld hl,$91EC ; load HL with 2nd (upper) hammer screen location 46D9: 3E FD ld a,$FD ; A := #FD = code for clear 46DB: CD 89 42 call $4289 ; draw. this call erases the 2nd (upper) hammer 46DE: 21 EC 9D ld hl,$9DEC ; load HL with location of 2nd (upper) hammer colors 46E1: 3E 00 ld a,$00 ; A := 0 = clear color 46E3: CD 89 42 call $4289 ; erase the hammer colors 46E6: C9 ret ; return ; else clear the lower hammer [runs every frame the hammer is active... sloppy] 46E7: 21 71 93 ld hl,$9371 46EA: 3E FD ld a,$FD 46EC: CD 89 42 call $4289 46EF: 21 71 9F ld hl,$9F71 46F2: 3E 00 ld a,$00 46F4: CD 89 42 call $4289 46F7: C9 ret ; return
No.05495 Tafoid Administrator Jan 12, 2010, 12:23	Thank you very much for the research and writeup. Such information is extremely useful in many possible cases. Labeling as BTANB.
No.06747 CrazyKongFan Tester Oct 6, 2010, 02:34	I can verify this is a bug that happens on a real PCB. I've got 5 CK PCB's: 2 running Falcon CK Part 2, 2 running what looks like the Alca bootleg (one is an Orca 2-board set, one is a Falcon style board), and another Falcon board with a similar version to the Alca bootleg (the one recently added to MAME), and it does it on all of them, on both player 1 and player 2 (in cocktail mode) on all 3 scenarios described above.