CPS A-Board Differences

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • donluca wrote:

      I'm talking about A-board.
      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?
      "Information wants to be free"
      VOOT | RFM | Kraylix V3 | FiF Jr. | KI2 | UMK3 | E29 | E29| TOTD | DDR
      Follow my projects on Instagram: instagram.com/twistedchu

      Buy my 3D Printed Parts: bit-district.com
    • 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:

    • 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.
    • GadgetFreak wrote:

      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.
      post that routine please.
      * Arcade-projects, the site where you get the most of your arcade games.
      * If you want Drama go to Neo-Geo forum ---Darksoft
    • Darksoft wrote:

      GadgetFreak wrote:

      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.
      post that routine please.
      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...
      Selling files for conversions/desuicide on Sega System C2/Sega System 24/Sega System 32, Capcom CPS1, Irem M92/M107 and more (just ask)
      Money is reinvested in boards, parts and tools in order to release more stuff.
      Contact me through my blog: arcadefixer.blogspot.co.nz/
    • PascalP wrote:

      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
      Yes just as expected.
      Here's my quote (for the last time?):

      Apocalypse wrote:

      You just have to replace then 10Mhz crystal by a 12Mhz. The 68k supports quite well overclocking.Also there are many wrong beliefs regarding the CPU speed. The 12Mhz just gives extra CPU "power" when needed.
      In other terms:
      - playing a 10Mhz game on a 12Mhz motherboard won't make the game faster. However it may suppress eventual slowdows.
      - playing a 12Mhz game on a 10Mhz motherboard can cause slowdowns.
      Selling files for conversions/desuicide on Sega System C2/Sega System 24/Sega System 32, Capcom CPS1, Irem M92/M107 and more (just ask)
      Money is reinvested in boards, parts and tools in order to release more stuff.
      Contact me through my blog: arcadefixer.blogspot.co.nz/
    • Does that hold true for Forgotten worlds also? I've heard some people say that game specifically will only work with certain A-Boards.
      "Information wants to be free"
      VOOT | RFM | Kraylix V3 | FiF Jr. | KI2 | UMK3 | E29 | E29| TOTD | DDR
      Follow my projects on Instagram: instagram.com/twistedchu

      Buy my 3D Printed Parts: bit-district.com
    • donluca wrote:

      I guess that's what aje_fr multi did? I remember you could use any C Board, just had to set it in the menu and the games would work (patched on the fly?).
      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.
    • GadgetFreak wrote:

      donluca wrote:

      I guess that's what aje_fr multi did? I remember you could use any C Board, just had to set it in the menu and the games would work (patched on the fly?).
      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.
      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?).
      Selling files for conversions/desuicide on Sega System C2/Sega System 24/Sega System 32, Capcom CPS1, Irem M92/M107 and more (just ask)
      Money is reinvested in boards, parts and tools in order to release more stuff.
      Contact me through my blog: arcadefixer.blogspot.co.nz/
    • donluca wrote:

      I have a Pang! 3 set and can confirm that the A Board is slightly different from a Capcom 12mhz one. For example, the ICs don't have "Capcom" on them and I *think* but I'm not 100% sure that the placement of some of the components are slightly different.

      Can someone try using a Mitchell A board with other B-Boards and see if they work correctly? They should by all means, but who knows...
      10MHz and 12MHz A-BOARD are the same (same ICs used and same board layout), no differences apart the oscillator, I can confirm it.
    • caius wrote:

      donluca wrote:

      I have a Pang! 3 set and can confirm that the A Board is slightly different from a Capcom 12mhz one. For example, the ICs don't have "Capcom" on them and I *think* but I'm not 100% sure that the placement of some of the components are slightly different.

      Can someone try using a Mitchell A board with other B-Boards and see if they work correctly? They should by all means, but who knows...
      10MHz and 12MHz A-BOARD are the same (same ICs used and same board layout), no differences apart the oscillator, I can confirm it.
      Thanks Caius, finally someone to support me!
      Selling files for conversions/desuicide on Sega System C2/Sega System 24/Sega System 32, Capcom CPS1, Irem M92/M107 and more (just ask)
      Money is reinvested in boards, parts and tools in order to release more stuff.
      Contact me through my blog: arcadefixer.blogspot.co.nz/
    • donluca wrote:

      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:


      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 review :)

      The post was edited 2 times, last by caius ().

    • Apocalypse wrote:

      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?).
      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.
    • GadgetFreak wrote:

      several games actually specifically look for them and fail to boot if they are wrong
      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.
      Selling files for conversions/desuicide on Sega System C2/Sega System 24/Sega System 32, Capcom CPS1, Irem M92/M107 and more (just ask)
      Money is reinvested in boards, parts and tools in order to release more stuff.
      Contact me through my blog: arcadefixer.blogspot.co.nz/