08024: chanbara: BGM emulation is slower than PCB

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
08024	Sound	Minor	Always	Jul 5, 2021, 07:20	4 hours ago

Tester	jkburks	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows 10 (64-bit)
Status [?]	Confirmed			Driver	dataeast/chanbara.cpp
Version	0.233	Fixed in Version		Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	08024: chanbara: BGM emulation is slower than PCB
Description	The emulated music plays more slowly than on the game hardware.
Steps To Reproduce
Additional Information	There is no regression. It has always run this speed in MAME. Compare emulation with game video output from PCB.
Github Commit

Flags
Regression Version
Affected Sets / Systems	chanbara

Attached Files	chan3.zip (11,772 bytes) 5 hours ago Uploaded by Haze chanbara gfx glitch

No.19082 Haze Senior Tester Jul 7, 2021, 12:58 edited on: Jul 7, 2021, 13:09	there's also a missing priority effect I wasn't aware of where you can see some enemies in the background before they appear... (first time I've seen original footage of this one) looks like my sprite enable bit is actually sprite priority, not sure why this wasn't pointed out when the game was first dumped and I did the driver.
No.19084 Haze Senior Tester Jul 7, 2021, 20:08 edited on: Jul 7, 2021, 20:10	the music tempo is odd, drivers says the 2203 clocks are measured, only way to speed it up I can see is to adjust them. might be like Street Fight which also has a 2203 and need a hack. I fixed the sprite priority to match the video, unfortunately the video doesn't repeat the steps to trigger another annoying visual bug that i'm almost sure is a real game issue. (force scrolling the enemy at the top off rather than fighting them results in sprite glitches before a new enemy appears abruptly)
No.19179 jkburks Tester Aug 26, 2021, 18:53	Adding Guru's recent video for another hardware sound reference.
No.22466 hap Developer 5 hours ago	Adjusting the 2203 clocks or that prescaler thingie will also change the pitch, not just the tempo, so that can't be it. There's an excessive YM busy wait loop at 0xcd45, if you optimize it, music tempo will be correct: ROM_FILL(0xcd48, 6, 0x12) If you overclock the CPU to 3MHz, music tempo will be correct. CPU is max rated 2MHz, so 3MHz is way too much. Besides, it was measured 1.5MHz. If you remove ym2203 read from the memory map altogether, music tempo will be correct. This is also unrealistic., since it will write to the chip while it's busy. Any chance there's an undumped 2nd revision where they fixed some bugs? Such as that silly ym busy check.
No.22467 Haze Senior Tester 5 hours ago	the set is from Guru's board, the videos are from Guru. I could also never get to the bottom of the issue whereby sometimes you just get a corrupt enemy coming across the screen and then phasing in where it shouldn't be. Guru said that never, ever happens on real hardware, but there's nothing really fancy about this set-up at all.
No.22468 Haze Senior Tester 5 hours ago edited on: 4 hours ago	I've uploaded an inp for the gfx glitch, but probably worth moving to a new report to be honest - it seems to mostly happen if you force scroll another enemy off the left edge, but Guru said he tried that many, many times and it never happens on the PCB. I'm only mentioning it here because it makes me wonder if there's something more significant missing here which is making the overall timing / logic of the game run incorrectly and both of these things are somehow a side-effect. (the game and music are both driven by only a single CPU, so if something is breaking in the CPU logic or said YM status, it could potentially be having an adverse effect on both)
No.22469 Haze Senior Tester 4 hours ago	this is the video glitch shown in the inp btw, yes it's really that easy to trigger. It's not a sprite rendering issue from what I can tell either, it just ends up with that enemy in a weird corrupt state while it appears. if you feel this is completely unrelated to the audio problems, feel free to split into a different report.
No.22470 hap Developer 4 hours ago edited on: 3 hours ago	Another possibility: does the YM busy flag really go through the fm prescaler? 3rdparty/ymfm/src/ymfm_opn.cpp line 830 orig: m_fm.intf().ymfm_set_busy_end(32 * m_fm.clock_prescale()); this works: m_fm.intf().ymfm_set_busy_end(32); *edit* woops, I still had the ROM_FILL hack in place, so disregard this ~~ The gfx glitch is easy to repro yes, just walk under one of the roof enemies.
No.22471 Haze Senior Tester 4 hours ago	you might need to talk to Aaron about the busy flag/prescaler stuff, AFAIK there were a number of other sensitive cases. of course it could be bugs in certain hardware revisions / chips with MAME trying to assume everything was always the same.
No.22472 hap Developer 4 hours ago	I googled around, and people that tested it say it's FM ticks, which would mean it goes through the prescaler. I think the most likely cause is that it doesn't have YM2203 RD connected.