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	Nov 23, 2024, 15:48

Tester	jkburks	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS
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) Nov 21, 2024, 15:57 Uploaded by Haze chanbara gfx glitch
Attached Files	RD+CS_OR_OUTPUT.jpg (167,096 bytes) Nov 23, 2024, 15:46 Uploaded by hap

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 edited on: Nov 21, 2024, 21:25	Adding Guru's recent video for another hardware sound reference. (removed link to deleted video)
No.22466 hap Developer Nov 21, 2024, 15:37	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 Nov 21, 2024, 15:50	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 Nov 21, 2024, 15:57 edited on: Nov 21, 2024, 16:07	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 Nov 21, 2024, 16:11	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 Nov 21, 2024, 16:25 edited on: Nov 21, 2024, 18:01	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 Nov 21, 2024, 16:46	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 Nov 21, 2024, 17:02	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.
No.22473 hap Developer Nov 21, 2024, 22:08	All sprites have attr & 1 set. And if you assume that attr & 8 is an invalid sprite size, garbage sprites are gone. Though like that, those enemies spawn from nothing instead of transforming from flying garbage into human.
No.22475 hap Developer Nov 22, 2024, 08:50 edited on: Nov 22, 2024, 10:15	From Guru: YM 2203 /RD pin 36 is tied to 74LS04, the input for that goes back to YM2203 pin 35. pin 35 is also ties to pin 1 of LS245 (DIR) and 2x LS32 on pin 13 (both) near the CPU. One of those LS32 inputs comes from a 2k SRAM WE pin near the ceramic square chip, also tied to several LS157. It's the usual convoluted mess of spaghetti wiring lol ~~ Not conclusive yet that the hw can read from YM2203. The above can just mean when it does a write, it makes sure to invert RD (CS=0, RD=1, WR=0). Wouldn't you normally connect RD and WR separately if you want to be able to read and write from the chip?
No.22477 AJR Developer Nov 22, 2024, 15:05	The MC6809E CPU used here produces a single R/W output, which has to be decoded into separate RD and WR strobes by external logic.
No.22486 hap Developer Nov 23, 2024, 15:48	Guru measured RD+CS pin, I attached his picture where you can see the pulse. Meaning: The PCB does read from YM2203, and the cause of the slowdown remains a mystery. I don't think there's a different ym2203 revision that does not have the busy flag.