Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06773 Speed Major Always Nov 23, 2017, 02:12 Dec 13, 2022, 17:35
Tester Fortuna View Status Public Platform MAME (Official Binary)
Assigned To Resolution Open OS Windows 10 (64-bit)
Status [?] Confirmed Driver
Version 0.191 Fixed in Version Build 64-bit
Fixed in Git Commit Github Pull Request #
Summary 06773: esckids, esckidsj: Slowdown in game
Description This is a old problem, but not was fixed in a old updates

Is simple, in this game, the game runs a -50% of actual speed, this problem only happen when playing and the demo (when the runners "runs")

Too has a little "flickering" (transparent) sprites

Only modified the CPU clock to 150% and runs correctly again

Only happen in this moments (the instructions and the title runs ok)
Steps To Reproduce
Additional Information
Github Commit
Flags
Regression Version
Affected Sets / Systems esckids, esckidsj
Attached Files
 
Relationships
There are no relationship linked to this issue.
Notes
6
User avatar
No.14485
Kale
Developer
Nov 30, 2017, 07:46
Inserting a coin during attract grants you two credits.
Likely related.
User avatar
No.20948
hap
Developer
Dec 12, 2022, 00:54
It is improved here: https://github.com/mamedev/mame/commit/1074e4057803c211e5adcb460f2ec8a4ae3f905e
Completely fixed? I don't know.

And the reason it worked ok in old versions of MAME, was because the cpu was overclocked * 2.
User avatar
No.20949
Haze
Senior Tester
Dec 13, 2022, 12:07
edited on: Dec 13, 2022, 12:08
The slowdown still makes the game play really really badly, and happens when you'd least expect it on and off the entire time.

Makes me wonder if the internal divider in that KONAMI CPU is a bit less or some of the opcode timings were also improved.

Of course it could just be an awful game, that was plagued with this problem, not exactly a common PCB to find reference for.
User avatar
No.20950
hap
Developer
Dec 13, 2022, 16:18
Divider: don't think so.
Opcode timing: probably.

And since it's a custom HD6309 (the Hitachi version, not Motorola), it's probably faster.
I enabled 'native mode' here, now esckids runs ok? https://github.com/mamedev/mame/commit/814ef88c1a63884ba0e7cee81e98b46992e98262
User avatar
No.20951
Haze
Senior Tester
Dec 13, 2022, 17:07
yeah, that seems much better

there's still some weirdness with the driver which explicitly defines a screen size with comments about black bars, which the game then overrides with its own anyway (and a slightly odd one at that, 321 pixels with a corruption at the side) I imagine the driver was written before some CRTC device was implemented to override the hardcoded resolution? that's entirely separate though.
User avatar
No.20952
Haze
Senior Tester
Dec 13, 2022, 17:35
edited on: Dec 13, 2022, 18:08
this also makes 'aliens' run at a pace much closer to the arcade

it doesn't stop the flickering in the driving sections, the root cause of that could just be k051960.cpp
where it hardcodes

// vblank
if (y == 240)
m_irq_handler(ASSERT_LINE);

the code also only uses a uint8 for the scanline counter, so even with the raw settings the max scanlines can only be 255

maybe in that case this isn't really correct? I think the raw screen params are specifying 16 border lines, but I don't know if vpos counts those.. triggering that earlier prevents the flicker / sprite breakup there as it gives it more time to create the spritelist before MAME attempts to draw with it but it would need verifying when that actually is.

anyway again that probably belongs in another discussion.