18 Oct 2017

Conversions/Desuicide on Sega System 32 hardware - SegaSonic & Dark Edge (& more)

1) SegaSonic

It all started when i saw a conversion of Sega Sonic for sale for big $ on a french forum (seller asked 500€ for it). It seemed a lot of money to me for a conversion so I decided to have a look at the protection, expecting something terribly complicated, hence the price. It was not...

Using MAME I could see game stopped (actually MAME crashes) when starting a new game if protection was disabled (function sonic_level_load_protection commented in file segas32.cpp).
According to MAME driver game read/writes to the protection chip from/at 0x20E5C4 & 0x20E5C5

void segas32_state::init_sonic(void)
 /* install protection handlers */
 m_maincpu->space(AS_PROGRAM).install_write_handler(0x20E5C4, 0x20E5C5, write16_delegate(FUNC(segas32_state::sonic_level_load_protection),this));

I set a watchpoint when reading/writing to these addresses: wpset 0x20E5C4,2,rw

First stop was @ 0x006F3:

0006F3: mov.h   R0, 65C4[R25]
0006F8: mov.b   #6, 65D3[R25]
0006FE: mov.w   #0, 7050[R25]

This is where I inserted a call to a first subroutine to simulate the protection:

0006F3: jsr     1F600
0006F9: nop
0006FA: nop
0006FB: nop
0006FC: nop
0006FD: nop
0006FE: mov.w   #0, 7050[R25]

There's plenty of space at the end of ROM IC17.

Second stop was @ 0x00764

000764: inc.h   65C4[R25]
000768: cmp.b   #E, 65C4[R25]
00076E: ble     776
000770: mov.b   #E, 65C4[R25]
000776: test.b  70E8[R25]
00077A: bn      77F
00077C: bsr     1CF1

I inserted a call to a second subroutine there:

000764: jsr     1F700
00076A: nop
00076B: nop
00076C: nop
00076D: nop
00076E: nop
00076F: nop
000770: nop
000771: nop
000772: nop
000773: nop
000774: nop
000775: nop
000776: test.b  70E8[R25]
00077A: bn      77F
00077C: bsr     1CF1

First subroutine consists only in writing the expected value to the correct address and copies the move instruction I've noped caused the call to the subroutine needed 6 bytes when the original instruction needed 5 (therefore I've overwritten the first byte of the following instruction). Then it returns:

01F600: mov.h   7500[R25], 706E[R25]
01F608: mov.b   #6, 65D3[R25]
01F60E: rsr

Second subroutine copies overwritten instructions first then writes the expected value to the correct address before returning:

01F700: inc.h   65C4[R25]
01F704: cmp.b   #E, 65C4[R25]
01F70A: ble     1F712
01F70C: mov.b   #E, 65C4[R25]
01F712: movz.hw 65C4[R25], R0
01F717: mov.h   7500[R25](R0), 706E[R25]
01F720: mov.w   #0, 70BC[R25]
01F726: rsr

Finally I edited checksum of ROM IC17 which is stored @ 0x1F08C in ROM IC8 (changed to 0x74CC).

2) Dark Edge

Not that I'm a big fan of this game but I did it for an old acquaintance which owned a suicided copy.

I used the same method, setting watchpoints where reading/writing to the security chip (wpset 20F072,2,rw / wpset 20F082,2,rw / wpset 20a12c,2,rw / wpset 20a12e,2,rw):

void segas32_state::darkedge_fd1149_vblank()
 address_space &space = m_maincpu->space(AS_PROGRAM);
 space.write_word(0x20f072, 0);
 space.write_word(0x20f082, 0);
 if( space.read_byte(0x20a12c) != 0 )
  space.write_byte(0x20a12c, space.read_byte(0x20a12c)-1 );
  if( space.read_byte(0x20a12c) == 0 )
   space.write_byte(0x20a12e, 1);
 logerror("%06x:darkedge_prot_w(%06X) = %04X & %04X\n",
  space.device().safe_pc(), 0xa00000 + 2*offset, data, mem_mask);

 logerror("%06x:darkedge_prot_r(%06X) & %04X\n",
  space.device().safe_pc(), 0xa00000 + 2*offset, mem_mask);
 return 0xffff;

First protection caused missing flame effect before title screen:

01E2C2: test.h  7072[R25]
01E2C6: bne     1E2FD
01E2C8: test.b  206C[R25]

Replaced by:

01E2C2: test.h  7072[R25]
01E2C6: nop
01E2C7: nop
01E2C8: test.b  206C[R25]

Second protection caused a black screen when starting a new game however sound and controls were still working (game played blind):

01F716: test.h  7082[R25]
01F71A: be      1F74D

Replaced by:

01F716: test.h  7082[R25]
01F71A: br      1F74D

Third protection caused bad sprite scaling:

01F74A: sub.h   R0, R14
01F74D: add.h   7082[R25], R14
01F752: movs.hw R13, R13

Replaced by:

01F74A: sub.h   R0, R14
01F74D: nop
01F74E: nop
01F74F: nop
01F750: nop
01F751: nop
01F752: movs.hw R13, R13

[EDIT 2017/10/19]
Found an other protection where game would just hang when starting a 2 player mode:

005AF0: mov.h   #82, 212C[R25]
005AF8: mov.b   #0, 212E[R25]

Replaced by:

005AF0: mov.h   #0, 212C[R25]
005AF8: mov.b   #1, 212E[R25]

Now the last thing to do was to correct the cheksum for the ROM IC8 to pass the memory test.
It's stored in ROM @ 0x7F08C, I simply edited the value to 0x0F43 new value = 0x5BD5.

Patched files for sale, contact apocalypse-mods@outlook.co.nz

Also available:
- Golden Axe 2
- DBZ V.R.V.S.
- F1 Super Lap
- Air Rescue
- Burning Rival
- Arabian Fight
- The J.League 94 [EDIT]2017/10/25

Golden Axe 2 can be downloaded for free here:

So as SegaSonic here:

I do not guarantee those files are bug free and won't provide any support for them as they were patched by other people.


  1. Hi,

    I did the Sega Sonic hack Guru has published without asking on his website, and it's pretty much identical to yours. I just never had a Sonic pcb to try it on so I didn't publish it. Unfortunately I got a guy in the UK to test it on his pcb, and you can guess what happened. (I did however put a bit of text in the end of the 7 rom file.. :)

    Good job on the other conversions. Good to see there's another arcade hacker in New Zealand.


    1. ApocalypseWed Oct 25, 07:29:00 am 2017

      whereabout are you in NZ? Also I think you're working on Sega System 24. Me too, I took the route of converting floppies to ROMs and it works well in MAME, however I'm still looking for the real hardware to test my work.


      P.S.: I never sign my work, I'm a minimalist hacker, the less bytes I modify, the better.

    2. Morning. I'm in Auckland.

      I've been working in System 24 for many years. A lot of the FD1094 dumps are done by me. I've got a Scramble Spirits upright too.

      I've gone the cheaper Sd card route so far although there is still the issue of supporting the rom board. I guess putting the floppy in rom and using a serial eeprom for the highscore track would work.

      P.S. It's useful when someone else claims your work as their own (or starts selling it in competition), but ultimately we know how the web works and it makes no difference.

    3. Hi, I'm in Ham but go to Akl quite often.
      Could you help me finding a System 24 game (whatever the title, even with bad floppy or suicided)?

    4. I'm in Ham every other weekend. I've never seen sys24 games here. I got mine from the UK, and need them for my cab.