News: 11 March 2016 - Forum Rules

Author Topic: Decoding the bootleg CPS1 rom dumps  (Read 5633 times)

Drakon

  • Sr. Member
  • ****
  • Posts: 277
    • View Profile
    • 16 Bit Gamer
Decoding the bootleg CPS1 rom dumps
« on: March 15, 2012, 06:02:13 pm »
Lately I've been converting my street fighter 2 arcade board into different versions using a rom burner.  I successfully converted a turbo pcb into rainbow set 3.  I'm interested in seeing if I can get the M5 bootleg romset to work on my cps1.  I know that the M5 pcb isn't a CPS1 but the rom image looks like a hacked up champion edition rom in a hex editor so it may be possible.  Unfortunately the M5 rom dumps are anything but cps1 compatible the information is shuffled in a certain way that needs to be decoded before it will run right.  I tried downloading the mame source but I really have no idea where I'd find the programming that would decode the rom information so it'll run on a regular cps1.  I was wondering if someone who's good with this sort of thing could help convert the M5 bootleg roms so they're cps1 friendly.

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: Decoding the bootleg CPS1 rom dumps
« Reply #1 on: March 15, 2012, 08:54:13 pm »
src/mame/drivers/cps1.c is the first place to look, that’s as much as I can say for certain without saying something balls-out stupid. Disclaimer: I am not an expert, I don’t own a single square inch of arcade PCB, and I couldn’t solder a resistor, replace a joystick, or flash an EEPROM to save my life. I have simply mucked around in MAME’s code more than I care to admit.

Code: [Select]
todo: move the bootleg sets with modified hardware into their own
      drivers, like fcrash.c
heh.

Okay, first, check the GAME macros
Code: [Select]
  GAME( 1992, sf2ce,       0,        cps1_12MHz, sf2,        cps1,     ROT0,   "Capcom", "Street Fighter II': Champion Edition (World 920513)", GAME_SUPPORTS_SAVE )  // "ETC"
Code: [Select]
  GAME( 1992, sf2m5,       sf2ce,    cps1_12MHz, sf2hack,    sf2hack,  ROT0,   "bootleg", "Street Fighter II': Champion Edition (M5, bootleg)", GAME_SUPPORTS_SAVE )              // 920313 - based on World version
macro prototype is
Code: [Select]
GAME(YEAR,NAME,PARENT,MACHINE,INPUT,INIT,MONITOR,COMPANY,FULLNAME,FLAGS)
In other words, the inputs and the initialization are done differently, but at least whoever coded this considered the systems similar enough to be the “same”. Still, to get this working in hardware would require compensating for at least those two things.

What’s different ROMs do these use? Well, look at ROM_START( sf2m5 ) and ROM_START( sf2ce ) and compare. If we ignore the cosmetic difference of ROM names, this is what’s different between those two sections; these are two "maincpu" ROMs (out of three) that it loads
Code: [Select]
      ROM_LOAD16_BYTE( "u222",              0x000000, 0x80000, CRC(03991fba) SHA1(6c42bf15248640fdb3e98fb01b0a870649deb410) )
      ROM_LOAD16_BYTE( "u196",              0x000001, 0x80000, CRC(39f15a1e) SHA1(901c4fea76bf5bff7330ed07ffde54cdccdaa680) )

and this is what sf2ce loads instead of those two (note that different macros are used to load these; no, I don’t know what’s up with that, but this is probably half the problem right here):
Code: [Select]
      ROM_LOAD16_WORD_SWAP( "s92e_23b.8f", 0x000000, 0x80000, CRC(0aaa1a3a) SHA1(774a2b52f7c1876c0e10d8d57a0850ad2d016cf6) )
      ROM_LOAD16_WORD_SWAP( "s92_22b.7f",  0x080000, 0x80000, CRC(2bbe15ed) SHA1(a8e2edef62fa99c5ef701b28bfb6bc42f3af183d) )

In addition, sf2ce loads ROMs to the aboardplds, bboardplds, and cboardplds regions. Beats me what those actually do; at least in the (11-month old) code I have on my machine, these regions don’t seem to be referenced in any other way, so my guess is they aren’t needed for emulation to work; that says nothing about the actual hardware, of course.

Finally, let’s check on those sf2hack init/input things.
Code: [Select]
  static INPUT_PORTS_START( cps1_6b)
      PORT_INCLUDE( cps1_3b)
 
      PORT_MODIFY("IN1")
      PORT_BIT( 0x0010, IP_ACTIVE_LOW, IPT_BUTTON1 ) PORT_NAME("P1 Jab Punch") PORT_PLAYER(1)
      PORT_BIT( 0x0020, IP_ACTIVE_LOW, IPT_BUTTON2 ) PORT_NAME("P1 Strong Punch") PORT_PLAYER(1)
      PORT_BIT( 0x0040, IP_ACTIVE_LOW, IPT_BUTTON3 ) PORT_NAME("P1 Fierce Punch") PORT_PLAYER(1)
      PORT_BIT( 0x1000, IP_ACTIVE_LOW, IPT_BUTTON1 ) PORT_NAME("P2 Jab Punch") PORT_PLAYER(2)
      PORT_BIT( 0x2000, IP_ACTIVE_LOW, IPT_BUTTON2 ) PORT_NAME("P2 Strong Punch") PORT_PLAYER(2)
      PORT_BIT( 0x4000, IP_ACTIVE_LOW, IPT_BUTTON3 ) PORT_NAME("P2 Fierce Punch") PORT_PLAYER(2)
 
      PORT_START("IN2")      /* Extra buttons */
      PORT_BIT( 0x01, IP_ACTIVE_LOW, IPT_BUTTON4 ) PORT_NAME("P1 Short Kick") PORT_PLAYER(1)
      PORT_BIT( 0x02, IP_ACTIVE_LOW, IPT_BUTTON5 ) PORT_NAME("P1 Forward Kick") PORT_PLAYER(1)
      PORT_BIT( 0x04, IP_ACTIVE_LOW, IPT_BUTTON6 ) PORT_NAME("P1 Roundhouse Kick") PORT_PLAYER(1)
      PORT_BIT( 0x08, IP_ACTIVE_LOW, IPT_UNKNOWN )
      PORT_BIT( 0x10, IP_ACTIVE_LOW, IPT_BUTTON4 ) PORT_NAME("P2 Short Kick") PORT_PLAYER(2)
      PORT_BIT( 0x20, IP_ACTIVE_LOW, IPT_BUTTON5 ) PORT_NAME("P2 Forward Kick") PORT_PLAYER(2)
      PORT_BIT( 0x40, IP_ACTIVE_LOW, IPT_BUTTON6 ) PORT_NAME("P2 Roundhouse Kick") PORT_PLAYER(2)
      PORT_BIT( 0x80, IP_ACTIVE_LOW, IPT_UNKNOWN )
  INPUT_PORTS_END
Code: [Select]
  static INPUT_PORTS_START( sf2 )
      PORT_INCLUDE( cps1_6b )
      ...
INPUT_PORTS_END
Code: [Select]
  static INPUT_PORTS_START( sf2hack )
      PORT_INCLUDE( sf2 )
 
      PORT_MODIFY("IN2")      /* Extra buttons */
      PORT_BIT( 0x00ff, IP_ACTIVE_LOW, IPT_UNKNOWN )
      PORT_BIT( 0x0100, IP_ACTIVE_LOW, IPT_BUTTON4 ) PORT_NAME("P1 Short Kick") PORT_PLAYER(1)
      PORT_BIT( 0x0200, IP_ACTIVE_LOW, IPT_BUTTON5 ) PORT_NAME("P1 Forward Kick") PORT_PLAYER(1)
      PORT_BIT( 0x0400, IP_ACTIVE_LOW, IPT_BUTTON6 ) PORT_NAME("P1 Roundhouse Kick") PORT_PLAYER(1)
      PORT_BIT( 0x0800, IP_ACTIVE_LOW, IPT_UNKNOWN )
      PORT_BIT( 0x1000, IP_ACTIVE_LOW, IPT_BUTTON4 ) PORT_NAME("P2 Short Kick") PORT_PLAYER(2)
      PORT_BIT( 0x2000, IP_ACTIVE_LOW, IPT_BUTTON5 ) PORT_NAME("P2 Forward Kick") PORT_PLAYER(2)
      PORT_BIT( 0x4000, IP_ACTIVE_LOW, IPT_BUTTON6 ) PORT_NAME("P2 Roundhouse Kick") PORT_PLAYER(2)
      PORT_BIT( 0x8000, IP_ACTIVE_LOW, IPT_UNKNOWN )
  INPUT_PORTS_END
Code: [Select]
  static DRIVER_INIT( sf2hack )
  {
      /* some SF2 hacks have some inputs wired to the LSB instead of MSB */
      machine.device("maincpu")->memory().space(AS_PROGRAM)->install_legacy_read_handler(0x800018, 0x80001f, FUNC(cps1_hack_dsw_r));
 
      DRIVER_INIT_CALL(cps1);
  }
whut.

Well, that’s about as much as I can decipher. Hope that speeds things up, at least.
we are in a horrible and deadly danger

Drakon

  • Sr. Member
  • ****
  • Posts: 277
    • View Profile
    • 16 Bit Gamer
Re: Decoding the bootleg CPS1 rom dumps
« Reply #2 on: March 15, 2012, 11:25:29 pm »
I made some major strides on this project last night / today.  It turns out after I interlaced the roms back together I had been splitting them at the wrong spot.  I split the roms at the proper spot and copied them into the sf2ce folder and it ran but unfortunately the sprite layer is flickering.  The good news is that everything else works perfectly, audio is fine, controls are fine, even all the m5 hacks are running great even though the system is running it like it would be on a normal cps1.  So I've managed to decrypt these roms on my own using tools I found on the net.  I even managed to get the accelerator part 2 hack running in the normal cps1 profile just by padding one of the rom dumps.  I tested this M5 dump running as CE in multiple emulators and each emulator has the graphics flickering.  I even did the same process on the m7 hack and got the same results, it ran but gave me flickering graphics in the emulator when loaded under the normal cps1 profile.

I also seem to have found the code that makes it run right.

This's taken from the latest release of cps1.c

1336      /* from here onwards the CPS-B board has suicide battery and multiply protection */

1262      /* name         CPSB          gfx mapper   in2  in3  out2   kludge */

1359      {"sf2ce",       CPS_B_21_DEF, mapper_S9263B, 0x36 },
1379      {"sf2m5",       CPS_B_21_DEF, mapper_S9263B, 0x36, 0, 0, 1 },

it seems to be calling kludge, found the kludge code

1840      /* Some of the sf2 hacks use only sprite port 0x9100 and the scroll layers are offset */
 1841      if (state->m_game_config->bootleg_kludge == 1)
 1842      {
 1843          state->m_cps_a_regs[CPS1_OBJ_BASE] = 0x9100;
 1844          state->m_obj = cps1_base(machine, CPS1_OBJ_BASE, state->m_obj_size);
 1845          scroll1xoff = -0x0c;
 1846          scroll2xoff = -0x0e;
 1847          scroll3xoff = -0x10;
 1848      }
 1849      else
 1850      {
 1851          state->m_obj = cps1_base(machine, CPS1_OBJ_BASE, state->m_obj_size);
 1852          scroll1xoff = 0;
 1853          scroll2xoff = 0;
 1854          scroll3xoff = 0;
 1855      }

also I'm pretty certain this's what causes the sprite flickering issue.

2337      /* some sf2 hacks draw the sprites in reverse order */
 2338      if (state->m_game_config->bootleg_kludge == 1)
 2339      {
 2340          base += state->m_last_sprite_offset;
 2341          baseadd = -4;
 2342      }
 2343      else
 2344      {
 2345          baseadd = 4;
 2346      }
 2347 

I'm going to assume that the graphic flickering is caused by it drawing the sprites in reverse order.  The sprite offeset just makes sprites draw in the wrong areas in the menu


(later in the c file)

434  /*                     CPSB ID    multiply protection      unknown      ctrl     priority masks   palctrl    layer enable masks  */

448  #define CPS_B_21_DEF 0x32,  -1,   0x00,0x02,0x04,0x06, 0x08, -1,  -1,   0x26,{0x28,0x2a,0x2c,0x2e},0x30, {0x02,0x04,0x08,0x30,0x30}

Link is here:
http://mamedev.org/source/src/mame/video/cps1.c.html

It looks like someone would need to hack the roms to not draw sprites in reverse order...don't think I could do that...  The sprite offset doesn't cause any real issues but the sprite reverse order thing causes flickering and that's no good
« Last Edit: March 16, 2012, 05:28:31 pm by Drakon »