Tech: Moonwalker Suicide Board - Attempted Fix
Todd George
repair my Moonwalker board. (It was working, but this was a
preventative measure).
I got a new 68000, using the numbers on a System16 board as a
reference that I was purchasing the correct part. The one I got is a
MC68000P12 (12 Mhz, as opposed to the 10 Mhz on the other board).
I also burned a new EPR13233 on a new 27C020-15 (I couldn't find the
27C2001D-15's, but everything I read tells me that these are supposed
to be compatible).
Upon replacing the 68000, and the EPR13233, the game does not work.
You may be asking yourself, "Hey, but the dox say you need to replace
the 13232 also". That's what the documentation says, but it is wrong
(I think). The EPR13232 rom that I got from one of the mame sites, in
the same ZIP as the unencrypted 13233, matches the one that was on the
board previously. (Did a Binary compare on them... The image from the
mame site, and the chip that was on the board are identical.)
I get nothing but a black screen when I try to boot the board. I
verified it's operation before trying this hack, and it worked fine.
What did I do wrong? If I did everything correctly, does anyone have
any suggestions on what to try to repair this?
Thanks!
-Todd
http://www.mspac.com
Brian Penzone
mean, if you were a board, the only board i would LESS like to be is a Warp
Warp (ok, maybe a Rough Ranger...)
Just messin with ya...best of luck ;-)
Brian
See me *LIVE* 24 hours a day at:
http://member.aol.com/mknox13415
Todd George
>I think that the board realized that it was a Moonwalker, and killed itself. I
>mean, if you were a board, the only board i would LESS like to be is a Warp
>Warp (ok, maybe a Rough Ranger...)
Believe me, I'm not fixing this for the sake of playing Moonwalker...
I'm fixing it for the "challenge". Moonwalker itself SUCKS, but I
have some other suicide System16 boards that I am going to fix if the
fix works on this one. :)
-Todd
http://www.mspac.com
Tim
Sounds like you're using the wrong ROMs. A quick peek at the MAME
sourcecode shows the protected ROMs as such:
ROM_REGION( 0x080000, REGION_CPU1 ) /* 68000 code */
// custom cpu 317-0159
ROM_LOAD_EVEN( "epr13235.a6", 0x000000, 0x40000, 0x6983e129 )
ROM_LOAD_ODD ( "epr13234.a5", 0x000000, 0x40000, 0xc9fd20f2 )
or
ROM_REGION( 0x080000, REGION_CPU1 ) /* 68000 code */
// custom cpu 317-0158
ROM_LOAD_EVEN( "epr13233", 0x000000, 0x40000, 0xf3dac671 )
ROM_LOAD_ODD ( "epr13232", 0x000000, 0x40000, 0x541d8bdf )
Depending on which custom CPU you have.
And, the bootleg set is thus:
ROM_REGION( 0x080000, REGION_CPU1 ) /* 68000 code */
ROM_LOAD_EVEN( "moonwlkb.01", 0x000000, 0x10000, 0xf49cdb16 )
ROM_LOAD_ODD ( "moonwlkb.05", 0x000000, 0x10000, 0xc483f29f )
ROM_LOAD_EVEN( "moonwlkb.02", 0x020000, 0x10000, 0x0bde1896 )
ROM_LOAD_ODD ( "moonwlkb.06", 0x020000, 0x10000, 0x5b9fc688 )
ROM_LOAD_EVEN( "moonwlkb.03", 0x040000, 0x10000, 0x0c5fe15c )
ROM_LOAD_ODD ( "moonwlkb.07", 0x040000, 0x10000, 0x9e600704 )
ROM_LOAD_EVEN( "moonwlkb.04", 0x060000, 0x10000, 0x64692f79 )
ROM_LOAD_ODD ( "moonwlkb.08", 0x060000, 0x10000, 0x546ca530 )
So, try it with the correct bootleg ROMs and see what happens. You should
be able to get them from www.mame.dk.
Good luck.
Tim
Shatter Proof
with the battery???
"Brian Penzone" <mknox...@aol.com> wrote in message
news:20001224012500...@ng-md1.aol.com...
Tim
Todd George
wrote:
>I believe Moonwalker is System 18, BTW.
Yeah, duh. My bad. I gotta stop surfing the NG so late at night.
:-)
>Sounds like you're using the wrong ROMs. A quick peek at the MAME
>sourcecode shows the protected ROMs as such:
That is what I figured.
> ROM_REGION( 0x080000, REGION_CPU1 ) /* 68000 code */
>// custom cpu 317-0158
> ROM_LOAD_EVEN( "epr13233", 0x000000, 0x40000, 0xf3dac671 )
> ROM_LOAD_ODD ( "epr13232", 0x000000, 0x40000, 0x541d8bdf )
I have this one ^^^ .
>And, the bootleg set is thus:
>
> ROM_REGION( 0x080000, REGION_CPU1 ) /* 68000 code */
> ROM_LOAD_EVEN( "moonwlkb.01", 0x000000, 0x10000, 0xf49cdb16 )
> ROM_LOAD_ODD ( "moonwlkb.05", 0x000000, 0x10000, 0xc483f29f )
> ROM_LOAD_EVEN( "moonwlkb.02", 0x020000, 0x10000, 0x0bde1896 )
> ROM_LOAD_ODD ( "moonwlkb.06", 0x020000, 0x10000, 0x5b9fc688 )
> ROM_LOAD_EVEN( "moonwlkb.03", 0x040000, 0x10000, 0x0c5fe15c )
> ROM_LOAD_ODD ( "moonwlkb.07", 0x040000, 0x10000, 0x9e600704 )
> ROM_LOAD_EVEN( "moonwlkb.04", 0x060000, 0x10000, 0x64692f79 )
> ROM_LOAD_ODD ( "moonwlkb.08", 0x060000, 0x10000, 0x546ca530 )
So this is what I'm missing. What is the correllation between the two
rom sets? The numbers don't seem to jive. Like, if I were to burn
the new roms, I am guessing that I do a binary file-merge on the four
bootleg ROMs marked "EVEN", and then do another binary file-merge on
the ones marked "ODD", then I take those two resulting images and burn
them to two 27C020's, and replace the existing 13233 and 13232 roms
(matching the EVEN for the 13233 and the ODD for the 13232)?
Correct? (I am guessing this is right, but I dunno.)
Thanks again for all your help, and Happy Holidays everyone!
-Todd
http://www.mspac.com
Tim
Todd George wrote:
>
> So this is what I'm missing. What is the correllation between the two
> rom sets? The numbers don't seem to jive. Like, if I were to burn
> the new roms, I am guessing that I do a binary file-merge on the four
> bootleg ROMs marked "EVEN", and then do another binary file-merge on
> the ones marked "ODD", then I take those two resulting images and burn
> them to two 27C020's, and replace the existing 13233 and 13232 roms
> (matching the EVEN for the 13233 and the ODD for the 13232)?
>
> Correct? (I am guessing this is right, but I dunno.)
>
Without looking at a board, I'm guessing the bootleggers used smaller,
cheaper EPROMs and the board has the empty sockets to support them. If
you're in doubt as to where the smaller EPROMs would go, then you could,
indeed, join the files just like you described above.
Please post your results.
Tim
Todd George
wrote:
>Without looking at a board, I'm guessing the bootleggers used smaller,
>cheaper EPROMs and the board has the empty sockets to support them. If
>you're in doubt as to where the smaller EPROMs would go, then you could,
>indeed, join the files just like you described above.
>
>Please post your results.
>
>Tim
I tried joining the ROMS just like I described. 01-04 into the EVEN
ROM, 05-08 into the ODD ROM. No good.
For sanity's sake, I tested the "motherboard" portion of the
Moonwalker board by throwing a Shadow Dancer daughter card into it.
That worked fine, so I am nearly certain it is something wrong with
the ROMS (or ROM board). (This also tested the "new" 68000 processor
I had, which I had not been 100% sure was working up until this
point.)
There aren't 8 positions on the ROM board to allow for burning the
bootleg ROMs onto separate chips.
Also, I have been verifying my ROM burns each time, just to prove that
the burns have been successful. I also tried swapping the two new
chips (a5 and a6) with each other, to prevent the possibility that I
did something backwards. No success there either.
One other note, I have an "extra" mystery chip on the Moonwalker
board. It is a ROM-looking chip installed right above the 68000
(assuming that you have the JAMMA connector towards you). It is
labelled 315-5437 and is an Intel D8751H / L0079003. It has the UV
Rom Window under the label, so I assume it is some sort of ROM. It is
physically too large for my burner, and I don't have an adaptor for
it, so I am unable to dump it to see what it is. This chip is not
present on my Shadow Dancer (non suicide) board. I removed this chip
when testing the Moonwalker motherboard with the Shadow Dancer
daughter card.
Thanks for all your help so far, and I am willing to do what I have to
in an effort to help you with your valiant attempts to conquer this
suicidal board nightmare. Just let me know what you want me to try
next!
Thanks again,
-Todd
http://www.mspac.com
Tim
Todd George wrote:
The 8751 is a microcontroller used for copy protection. It has an on board
EPROM and has a security bit that, when set, prevents the EPROM from being
read by a reader. They usually aren't used in conjunction with encrypted
68000 program ROMs. What was the part number on the Hitachi block on your
Moonwalker? Did you try removing the 8751 and running it with the bootleg
ROMs? MAME does not emulate the 8751 to run the bootleg code, so it's not
needed.
Something else I noticed while looking through the MAME sourcecode, they do
a lot of patching of the program ROMs at run time for something. You might
want to try manually applying these patches to the ROMs:
patch_code( 0x70116, 0x4e);
patch_code( 0x70117, 0x71);
patch_code( 0x314a, 0x46);
patch_code( 0x314b, 0x42);
patch_code( 0x311b, 0x3f);
patch_code( 0x70103, 0x00);
patch_code( 0x70109, 0x00);
patch_code( 0x07727, 0x00);
patch_code( 0x07729, 0x00);
patch_code( 0x0780d, 0x00);
patch_code( 0x0780f, 0x00);
patch_code( 0x07861, 0x00);
patch_code( 0x07863, 0x00);
patch_code( 0x07d47, 0x00);
patch_code( 0x07863, 0x00);
patch_code( 0x08533, 0x00);
patch_code( 0x08535, 0x00);
patch_code( 0x085bd, 0x00);
patch_code( 0x085bf, 0x00);
patch_code( 0x09a4b, 0x00);
patch_code( 0x09a4d, 0x00);
patch_code( 0x09b2f, 0x00);
patch_code( 0x09b31, 0x00);
patch_code( 0x0a05b, 0x00);
patch_code( 0x0a05d, 0x00);
patch_code( 0x0a23f, 0x00);
patch_code( 0x0a241, 0x00);
patch_code( 0x10159, 0x00);
patch_code( 0x1015b, 0x00);
patch_code( 0x109fb, 0x00);
patch_code( 0x109fd, 0x00);
// * SEGA mark
patch_code( 0x70212, 0x4e);
patch_code( 0x70213, 0x71);
Tim
Todd George
wrote:
>The 8751 is a microcontroller used for copy protection. It has an on board
>EPROM and has a security bit that, when set, prevents the EPROM from being
>read by a reader. They usually aren't used in conjunction with encrypted
>68000 program ROMs. What was the part number on the Hitachi block on your
>Moonwalker? Did you try removing the 8751 and running it with the bootleg
>ROMs? MAME does not emulate the 8751 to run the bootleg code, so it's not
>needed.
I have tried it with and without this chip at each stage of the
testing. It seems to make no difference if it is installed or not.
The part number of the Hitachi chip is FD1094 A-12 9K4 and a label
that says Sega 317-0158.
>Something else I noticed while looking through the MAME sourcecode, they do
>a lot of patching of the program ROMs at run time for something. You might
>want to try manually applying these patches to the ROMs:
<snip>
I am trying this right now. I am waiting for my EEPROM's to erase.
Hopefully I patched the ROMs correctly. Procedure used was to open
them in a hex editor, then change the offset-location byte to the one
listed. I assumed that the EVEN rom was the offsets from 00000 to
3FFFF, and the ODD rom was the offsets from 40000 to 7FFFF. I will
post back with my results.
-Todd
Tim
Todd George wrote:
> I assumed that the EVEN rom was the offsets from 00000 to
> 3FFFF, and the ODD rom was the offsets from 40000 to 7FFFF. I will
> post back with my results.
Actually, no, it's harder on the brain than that. It's all odd bytes in one and
even bytes in the other, so, if you have to patch something like this:
8000: 4E
8001: 71
Then address 8000 is in the even ROM and 8001 is in the odd ROM. But, wait, it
gets even more confusing. If you want to patch address 8000, it's actually 4000
of the even ROM and 8001 would be 4000 of the odd ROM, because the addresses
are split between the two. Look at it like this:
Address:
0000000: Even ROM, offset 0000
0000001: Odd ROM, offset 0000
0000002: Even ROM, offset 0001
0000003: Odd ROM, offset 0001
0000004: Even ROM, offset 0002
0000005: Odd ROM, offset 0002
0000006: Even ROM, offset 0003
0000007: Odd ROM, offset 0003
0000008: Even ROM, offset 0004
0000009: Odd ROM, offset 0004
See?
Tim
Todd George
wrote:
>Actually, no, it's harder on the brain than that. It's all odd bytes in one and
>even bytes in the other, so, if you have to patch something like this:
<snip>
>See?
Yep. I'll do that, and post back (hopefully tonight!) with my
results.
Yer right... That hurts the brain quite substantially. :)
-Todd
Todd George
wrote:
<snip>
>See?
I went through the list, patching accordingly (the patching process
made more sense this time, the values I was patching tended to make
more sense, like patching 00 00 over values of 10 10 repeatedly, it
just seemed to "jive" better). I have previous experience doing some
very slight rom hacks, working off of documents similar to the one
that is in MAME. This time, using the method you describe, the
Moonwalker patch just seemed to make more sense.
Nonetheless, the patches did not fix the problem. I have the 27C020
EPROMs installed in A5 (odd) and A6 (even), and verified the
positioning of all of the other chips according to their labels, and
the information contained in the MAME driver source code. Again, I
tried flipping the A5 and A6 chips with each other, just to verify
that I wasn't insane. It still didn't work. I also have completely
removed the 8751 chip (and am not testing with it at all anymore),
just so you know.
I thank you, again, for all of your help on this problem. What should
I try next? Just so you know, I am definitely done playing with this
problem tonight, so I will get your reply and act accordingly tomorrow
night.
-Todd
Tim
Todd George wrote:
Try putting the 8751 back just in case. If it's still no-go, I'll dig out
my Moonwalker and see what I can do. If I fail, too, I'll ask for some
help on the MAMEdev list.
Tim
Todd George
wrote:
>Try putting the 8751 back just in case. If it's still no-go, I'll dig out
>my Moonwalker and see what I can do. If I fail, too, I'll ask for some
>help on the MAMEdev list.
>
>Tim
Still a no-go. I'm considering re-burning the ROMs, but this time
using the following method:
MOONWLKB.01 \
MOONWLKB.05 --\ MoonWalker 13232
MOONWLKB.02 --/
MOONWLKB.06 /
MOONWLKB.03 \
MOONWLKB.07 --\ MoonWalker 13233
MOONWLKB.04 --/
MOONWLKB.08 /
I was digging on some Pac-Man pages for some other information, and
stumbled across this Crush Roller reference:
The CR images should be combined as follows:
CR1 \ pacman.6e
CR5 /
CR2 \ pacman.6f
CR6 /
CR3 \ pacman.6h
CR7 /
CR4 \ pacman.6j
CR8 /
CRA \ pacman.5e
CRC /
CRB \ pacman.5f
CRD /
Which tipped me off that it might not be a bad idea to look at the
mame source code, and see if they load the Crush Roller roms similarly
to the way the Moonwalker ROMs are loaded. Well... Here's the code
snippet:
ROM_REGION( 0x10000, REGION_CPU1, 0 ) /* 64k for code */
ROM_LOAD( "tp1", 0x0000, 0x0800, 0xf276592e )
ROM_LOAD( "tp5a", 0x0800, 0x0800, 0x3d302abe )
ROM_LOAD( "tp2", 0x1000, 0x0800, 0x25f42e70 )
ROM_LOAD( "tp6", 0x1800, 0x0800, 0x98279cbe )
ROM_LOAD( "tp3", 0x2000, 0x0800, 0x8377b4cb )
ROM_LOAD( "tp7", 0x2800, 0x0800, 0xd8e76c8c )
ROM_LOAD( "tp4", 0x3000, 0x0800, 0x90b28fa3 )
ROM_LOAD( "tp8", 0x3800, 0x0800, 0x10854e1b )
... etc ...
It seems very similar to my untrained eye. I will be trying this "new
method" of combining and burn the new roms sometime in the next day or
two.
Thanks again for all your help!
-Todd
Tim
Todd George wrote:
> Still a no-go. I'm considering re-burning the ROMs, but this time
> using the following method:
>
> MOONWLKB.01 \
> MOONWLKB.05 --\ MoonWalker 13232
> MOONWLKB.02 --/
> MOONWLKB.06 /
>
> MOONWLKB.03 \
> MOONWLKB.07 --\ MoonWalker 13233
> MOONWLKB.04 --/
> MOONWLKB.08 /
>
>
I'm pretty sure that won't work. That mixes even and odd bytes into the same
ROM, which won't fly.
Turns out I no longer have a Moonwalker board to tinker with, so I will ask
the MAMEdev list for some advice.
Tim