C352: Add divider for System 23, change enum format

[superctr]

I measured the clock divider for System 23 games as 296.

I also changed the enum format to represent the systems and the value to represent the actual divider. Thus, if an adjustment is necessary, it only has to be adjusted in c352.h.

A final thing about the dividers: I have not found any undocumented registers (like in the case of the X1-010) that control the divider. I have found registers at offsets 0x400 and 0x404, but they are unrelated.

0x400 appears to be some kind of flags register, games usually write 0xe0f on bootup, then 0xe1f or 0xe9f before playing a song.

The value written to 0x404 is garbage. Low byte is always 0x20, this a leftover from a for loop where the driver runs through the channels and writes registers. High byte is leftover from a pointer on M37702-based drivers and 00 on H8-based games.

[ghost]

I've spoken about this kind of obfuscation in the past. putting the divider somewhere else just forces someone who needs to know the real clock rate to look for another file and work it out.
IMO putting it in another file isn't helping documentation(which is the primary purpose of MAME).
if the final clock is wrong just fix it in the driver. a couple of repeated texts in several drivers isn't going to blow out MAME to several gigs. as RB says 'MAME can use your HDD space with impunity'

[superctr]

I'm not sure exactly what you're suggesting. My intention is not to use as little hard drive space as possible, it is just to make it as easy as possible to change a value (all the values are in one file now and only one line needs to be changed)

So do you want me to either

• Get rid of the enums and define the constants in the driver file instead
• Go back to putting the divider value inside the enum (this would require a change in every source file whenever a value needs to be changed)

I'm not concerned about the clock rates, they have been measured directly from the board from what I know. The clock dividers is what I'm talking about, the only way to measure themis though audio comparison.

[ghost]

I'm just saying it obfuscates the code. anyway, if there is an internal divider inside the chip, surely the divider should be exclusively in c352.c and the game driver shouldn't need to be touched?

[superctr]

Ah. I didn't mean to obfuscate anything. I can get rid of the enums and define the dividers inside each drivers' source file instead.

The internal divider was previously thought to be 288 but this is not the case, since using this divider value with the measured clock speeds causes incorrect pitch in the games that used a different value. My hypothesis is that there's a base divider that can be adjusted (increased), probably through pin configuration. As I wrote earlier I haven't found a register that controls it.

[rb6502]

We can probably put together a list of games that Guru could go multimeter hunting on to try and find the divider pins.

[ghost]

yeah. I've got plenty of time now :-)

[happppp]

IIRC the C352 gets its clock from a programmable clock generator chip. How
about emulating that instead?

plenty of time? ^____^ Namco Technodrive pls. (even though not my donation)

On Wed, Jul 22, 2015 at 10:09 PM, Guru notifications@github.com wrote:

yeah. I've got plenty of time now :-)

—
Reply to this email directly or view it on GitHub
#265 (comment).

[superctr]

It does, and it has been measured. Part of the pull request I sent a few weeks ago involved using the measured clock frequency from the clock generator instead of using a multiple of the MCU or CPU frequency that was incorrect but happened to sound OK.

I guess it could always be worth it to try measuring it again, in case no divider pins are found.

[ghost]

I measured the clock frequency on the clock generator IC on at least one of my boards and that is what was documented. no guesses there.