My mistake, I thought you were talking about B-Board since that's what Pascal's comment was about.
Can you get a good picture of the Mitchel A-Board for comparison purposes?
CPS A-Board Differences
- Thread starter twistedsymphony
- Start date
Can you get a good picture of the Mitchel A-Board for comparison purposes?
Not sure what the heck I was high on last night, but today I checked the A board and besides some ICs which are missing on other boards (socketed but unpopulated), the different brand of the Motorola68k (mine is Hitachi), different power amp+heatsink and other minor brand differences, the A-Board is exactly the same as a standard Capcom short 12Mhz A-board.
Even the code 89626A-4 is the same.
Anyway, here it goes:
Even the code 89626A-4 is the same.
Anyway, here it goes:
PascalP
Legendary
that's what i figured when you started talking about Mitchell A boards
Interesting though the sound amp + heatsink is completely different...
And also it is missing the 'Dash' sticker
GadgetFreak
Student
Well I have 4 Pang3 board sets, 2 of the A boards are 10Mhz, 1 long and 1 short. The other 2 A boards are 12Mhz. It doesn't matter which boards I pair, they all work fine.
I agree with Apocalypse's previous posts about the games basically being controlled by the display refresh speed. I have used Varth with both 10Mhz & 12Mhz boards, on the 10Mhz boards the slow downs were slightly more frequent than the 12Mhz board when there was lots of action on the screen. In my examination of the code on CPS 1 games there would appear to be no way for the game code to determine the CPU speed unless they use a dedicated loop and count vblanks's.
BTW I have developed a dynamic patch routine for C boards. So once a rom set is patched you can swap and change C boards (B01-B21) and the game still runs correctly. So far I have applied it to all versions of 9 of the CPS1 games.
I agree with Apocalypse's previous posts about the games basically being controlled by the display refresh speed. I have used Varth with both 10Mhz & 12Mhz boards, on the 10Mhz boards the slow downs were slightly more frequent than the 12Mhz board when there was lots of action on the screen. In my examination of the code on CPS 1 games there would appear to be no way for the game code to determine the CPU speed unless they use a dedicated loop and count vblanks's.
BTW I have developed a dynamic patch routine for C boards. So once a rom set is patched you can swap and change C boards (B01-B21) and the game still runs correctly. So far I have applied it to all versions of 9 of the CPS1 games.
post that routine please.
A
Apocalypse
Finally someone understanding my pain!
I hope your message won't get ignored as were mines...
I already explained all of that before, more than once actually...
PascalP
Legendary
Not a programmer or anything so i don't know the code behind it, but as a 'gamer' I experienced the same with Final Fight compared on 10 and 12MHz boards.
Less apparent slow downs on the 12MHz board
Less apparent slow downs on the 12MHz board
A
Apocalypse
PascalP
Legendary
Yes I know your quote, I even quoted it myself on page 1 post #9 of this thread 
Does that hold true for Forgotten worlds also? I've heard some people say that game specifically will only work with certain A-Boards.
LHantz
Enthusiast
Just tried Forgotten Worlds (USA) with both a 10Mhz and a 12Mhz A Board and it works with both
GadgetFreak
Student
Possibly, I started out by just patching the code for a specific C board but found there were so many places the Layer Enable Mask bits were set that this became a pain. So I did some more digging and found that the main register updates were done in one block in the interrupt, so I decided to do a dynamic patch that sets up a ram based routine on startup which is modified for the detected C board. I had to do lots of testing with different C boards to fill in the holes in the Mame CPS 1 tables, mainly for layer enable flags. I have some ID, register & flag updates that I need to pass onto the Mame team really.
A
Apocalypse
Yes you can select your B board type with the OLED screen included in the kit. Then C-board accesses are patched on the fly.
Regarding games conversion I simply converted at least one version of each game (32 or 34 titles), then having identified addresses to be modified in the code ROMs I use a kind of dynamic IPS file: I select the C-board to use and values are patched accordingly (register addresses, layer mask values including bit XORing or ANDing).
Last thing is MAME is really not accurate regarding registers, for instance MAME drops unused bits for a specific B-chip but on real hardware, although normally not used by the game, they do have an impact. To sum up real hardware is more "strict" regarding bit setting.
Oh and B-chip IDs aren't consistent, some chips don't return anything (0xFFFF), some return different values for the same reference (different production batches?).
10MHz and 12MHz A-BOARD are the same (same ICs used and same board layout), no differences apart the oscillator, I can confirm it.
A
Apocalypse
Thanks Caius, finally someone to support me!
We are not talking about different brand of the ICs (it's normal to find ICs of different manufacturer on a same PCB, this depend from their availability at time of manufacturing) but about design difference.Then, no Mitchell A-BOARD exists, simply you found this A-BOARD coupled with Mitchell B-BOARD of your Pang3.I suggest you take a good sleep and reviewNot sure what the heck I was high on last night, but today I checked the A board and besides some ICs which are missing on other boards (socketed but unpopulated), the different brand of the Motorola68k (mine is Hitachi), different power amp+heatsink and other minor brand differences, the A-Board is exactly the same as a standard Capcom short 12Mhz A-board.
Even the code 89626A-4 is the same.
Anyway, here it goes:
Last edited:
GadgetFreak
Student
I did think about doing it a similar way but after seeing that they just update a block in ram with register changes, then copy them in one place in the interrupt, I came up with a translation routine. Then I thought how it would be easier still to put this in ram and make it dynamically detect the C board on startup. Regarding board ID's, in my testing B2-5 & B11-18 do all have unique ID's and several games actually specifically look for them and fail to boot if they are wrong. Mame only mimics bits used for specific games on their original C boards, so if the game always sets 2 layers on at the same time Mame doesn't identify which bit is which, it just sets both. The star layer bits are not defined for many C boards, but remapping Strider requires them to look correct.
A
Apocalypse
Yep, that's included in my patches.
I'm almost sure CPS-B-21 always returns 0xFFFF regardless if it's battery powered or not.
CPS-B-01 (not really a problem as it's found on C-board-less games and is directly soldered on the B-board) and CPS-B-03 return 0x0000.