Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06474 Graphics Minor Always Jan 22, 2017, 19:17 Sep 8, 2018, 11:54
Tester abelardator2 View Status Public Platform MAME (Official Binary)
Assigned To Resolution Open OS Windows Vista/7/8 (64-bit)
Status [?] Confirmed Driver segas16b.cpp
Version 0.181 Fixed in Version Build Normal
Summary 06474: goldnaxe: scroll issues
Description Scroll failure, happens when the character moves. Best observed by watching the dead enemies incorrectly move along with the scrolling as you progress/move forward.
New in 0.181, perhaps the cause is the new use of "I8751 317-0123A".
Steps To Reproduce Check Note 13552
Additional Information
Regression Version
Affected Sets / Systems goldnaxe
Attached Files
There are no relationship linked to this issue.
User avatar
Jan 22, 2017, 20:15
Can you explain further? I can see no scrolling issues as I progress in the game. The moving characters all seem to stay in sync to the background as it scrolls.
Some details of your setup or any non-defautl settings might help too.
User avatar
Jan 22, 2017, 20:47
My configuration is by default. This is not the case with others "Golden Axe" sets.
Can be seen in the background when the player walks, it is seen more when there is an enemy corpse on the ground.

I have an original PCB "Golden Axe (set 6, US)(8751 317-123A), with its chip 8751 317-123A.
User avatar
Jan 22, 2017, 21:21
I can't spot any peculiar behavior attempting to reproduce. More information might be needed.
User avatar
Jan 22, 2017, 21:49
Ok, I did some close observation of the dead bodies and then scrolling them on the screen as I walk (right or down/up) and I can detect that there are frames that the bodies 'shift' on the ground non-logically (either lag or misplacement) - not moving smoothly. I can confirm the behavior on that aspect at least Kill enemies until there are none alive on screen then as you scroll right to progress, use "SHIFT-P" to frame advance slowly and see the movement. A version tested from November didn't show this behavior and I'll have to check further to see if there is not another reason for the issue.
User avatar
Senior Tester
Jan 23, 2017, 02:40
right, in order to stop the game from crashing due to the MCU and the 68k fighting I had to put a fairly big delay on the 68k, which causes the sprites to end up being written later, and the frame desync you see.

I'm not really happy with the delay, but it seemed better than crashing.

Somebody really needs to trace out the board to see when the interrupts are generated on the MCU vs. the main CPU, or if there's some other semaphore to indicate when comms should happen.
User avatar
Jan 23, 2017, 07:18
Haze, I do not know how to help, but I have a PCB with this chip (i8751 317-123A).
I could donate if that helps.
User avatar
Senior Tester
Jan 23, 2017, 15:31
I think there are plenty of other people with the PCBs who could trace them / work out the sources, but unless somebody does, it's pure guesswork, and not much to go on in this case.
User avatar
Sep 8, 2018, 07:30
I couldn't see any problem, is it still an issue?
User avatar
Sep 8, 2018, 11:54
Yes it still happens (0.201 official), see Haze's reply above for the cause.