Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|05604||Speed||Minor||Always||Jun 9, 2014, 03:44||1 day ago|
|Tester||zaxxon||View Status||Public||Platform||MAME (Official Binary)|
|Assigned To||Resolution||Open||OS||Windows XP|
|Version||0.153||Fixed in Version||Build||Normal|
|Summary||05604: hunchbak, hunchbaka: suffers from slowdowns|
compared to the actual arcade pcb (see youtube video below), the mame version suffers from slowdowns.
the first instance is when you start a game. during the intro sequence you see hunchback bouncing along the screen from right to left. you will notice in mame that halfway during this sequence the game incorrectly slows down, and then speeds up again.
the second instance where you experience some very noticeable slowdown in the mame version, is on the second screen where you have the fire pit and the swinging rope.
there are probably further slowdowns on later levels but i didnt test further than screen 2.
perhaps something to note: for a 'cheap fix', i noticed that by enabling cheats in mame.ini, and then in the 'slider controls' menu, overclocking the cpu to 150%, eliminates the slowdowns.
another note: i dont know the exact regression version, but i have noticed under mame 0.37b16 (0.52), the slowdowns do not exist. this older version does have some sounds missing though, which are present in the later mame versions.
|Steps To Reproduce|
|Affected Sets / Systems||hunchbak, hunchbaka|
|There are no relationsihp linked to this issue.|
Jun 9, 2014, 23:58
I can acknowledge the slowdown in the 2 places mentioned and that overclocking appears to fix it, but it might not be the correct fix.
Anyone with an original CVS CPU with this cartridge or possibly another game in the library could be used to scope for clock speeds.
Jun 10, 2014, 16:48
|i doubt that the emulated clockspeed is wrong, I'd look elsewhere for causes of this slowdown|
4 days ago
edited on: 4 days ago
Overclocking the CPU, as mentioned, fixes the problem with the swinging ropes scene. However, there is another issue in that parts of the emulated game are actually running too quickly regardless of whether the CPU is overclocked or not. Compare the title screen animation with the hunchback and the girl and you'll see that MAME is far too fast. So there appear to be two different issues: the first is that there is a CPU problem causing slowdown on the fire pit stage, and the second is that the emulated game is running ahead of the pcb.
As these Century games were produced in the UK I think it's a fair assumption that they were developed using a PAL 50Hz system. With this in mind (and with the game CPU overclocked - 150% or 200%, it didn't seem to matter), I tried to sync the title screen to MAME and found that they synced up almost perfectly at 51Hz. Also, the hunchback jumping from right to left in the opening scene is also indistinguishable from the video at this speed.
Obviously proper measurements need to be taken from the pcb to know for sure, but I just thought I'd share my observations.
2 days ago
edited on: 2 days ago
Century driver is kludge. Given it's derivative nature hardware wise, the raw screen params should presumably be similar to that used in the Lazarian driver, which give a 50.541416Hz refresh rate. Galaxia hardware emulation in MAME also suffers from the same problem. All except the Lazarian driver need a big rewrite to properly function.
1 day ago
|Lazarian is pretty whacky hardware - it's abusing a Signetics PAL sync generator to generate a non-standard resolution. It (ab)uses some flipflps to do a symmetric divide-by-three on the pixel clock so it can run layers at different resolutions, and visible lines aren't a whole multiple of three clocks long. I wouldn't believe anything has similar timings unless someone produces a schematic or traces a board and shows that it's hooked up the same way.|