What's new
By:

Magic Sword Completely missing text (resolved)

duffcon

duffcon

Professional
Joined
Feb 5, 2018
Messages
403
Reaction score
401
Location
Concord, CA
I have a Magic Sword board where the gameplay is missing all text elements, no high score, no bottom information area. Just characters and backgrounds in the main area. Sound works fine.

Also missing is the startup copyright text, title screen, & the "winners don't use drugs" screen. The first visible screen is the sword in the attract mode.

I'm leaning on bad graphics ROMs. Tried another A board, same results. So I know the A board is good. i've read that a b-custom failure on the C board generally looks like garbled graphics, but in my case they're missing. The 4 graphics roms are on HN62404P mask chips. on my GQ-4X4, I set it as 27c400 and it reads them, but if I upload to rom ident, it is unable to identify any of them. I guess the easy/simple thing to try would be to just burn new graphics roms, but am I on the right path?
D19947F0-7750-4E81-99BF-53B9B674F19F.jpeg
 
Last edited:
Sounds like bad RAM, but that'd be on the A board. Have you tried a different a different B+C board on the A?
 
Try comparing your ROM dump checksums to the MAME dump checksums. If they don't match then burn new graphics roms.
 
Kujako said:
Sounds like bad RAM, but that'd be on the A board. Have you tried a different a different B+C board on the A?
Click to expand...

I've tried another known good A board, same results

ShootTheCore said:
Try comparing your ROM dump checksums to the MAME dump checksums. If they don't match then burn new graphics roms.
Click to expand...

I've dumped the graphics roms using my GQ-4x4 set as 27C400. Basically read and then save the file. I uploaded the dumps to:

http://www.arcaderestoration.com/romidentification.aspx

They come as unknown; Am I doing something wrong? I'm not familiar with the process to check checksums against MAME, is there a reference somewhere?
 
Ok, I did some reading here:

https://www.jammarcade.net/rom-dumping-and-checking/

Based on the instructions I have this output

C:\mame>mame64.exe -romident magic.zip
Identifying magic.zip....
ms1.bin NO MATCH
ms3.bin NO MATCH
ms5.bin NO MATCH
ms7.bin NO MATCH
No roms matched.

So my dumps can't be identified.

So doing a compare to a downloaded romset:

C:\mame>romcmp magic.zip
4 files

C:\mame>romcmp magic.zip msword.zip
4 and 19 files
ms_09.12b 1xxxxxxxxxxxxxxx = 0xFF
ms5.bin ms-5m.7a 99.323845%
ms1.bin ms-1m.3a 99.323273%
ms3.bin ms-3m.5a 97.871780%
ms7.bin ms-7m.9a 97.867393%
buf1 NO MATCH
ioa1 NO MATCH
iob1.11e NO MATCH
ms-32m.8h NO MATCH
ms24b.1a NO MATCH
ms_09.12b NO MATCH
ms_18.11c NO MATCH
ms_19.12c NO MATCH
mse_30.11f NO MATCH
mse_31.12f NO MATCH
mse_35.11h NO MATCH
mse_36.12h NO MATCH
prg1 NO MATCH
rom1 NO MATCH
sou1 NO MATCH

Looks like the Graphics roms are mostly correct. When I did the dump I did not read the article about doing multiple reads and comparing the checksum values, so I pulled the first rom again and found that even without moving the chip, the checksum value changed every read. I tried this setting the reader to 27c400 and HN27C4000 (per an article from the same site) and i got different values every time:

051DDE4F
051DFEB2
051DFB44
051DFA07
051DF8B3
051DF369

Does this possibly mean the chips are bad? Or is my testing method flawed?
 
Your process sounds right, but it strikes me as very strange that (A) you're seeing so many ROMs that don't match up with anything, and (B) the same ROM is giving a different checksum on every read. Try dumping with a different EPROM programmer If you have access to one; otherwise, I suggest programming up some fresh 27C400 EPROMs and seeing how they behave in the board.
 
I've not had good luck with this GQ-4x4 programmer to be sure. this rom requires the adp-054 adapter, which as you know wouldn't give me good burns for the s16b multi kit either.

https://www.arcade-projects.com/thr...th-adp-054-adapter-burning-27c322-roms.15708/

Now looking back, i've used it to write MK2+ roms, all do not require the adapter. These worked perfectly.

Now with these chips, I also can't get consistent reads on the adapter. I've tried with and without power adapters, I know my jumpers are right, j1 1-2 closed is for 27c400 which is on the right side zif socket as indicated on the pcb. I've also tried j5 (compatibility) on both settings. Same results, inconsistent reads. I believe the adapter is the older v3 as the v4.1 indicates that on the PCB. I ordered a new 4.1 version adapter, I hope that works better. MCUMalls tech support is shit, I should have bought something else.
 
Last edited:
Sorry for the headaches. If you like, I could dump your ROMs and program any needed replacement EPROMs for just the cost of parts and shipping.
 
@ShootTheCore Thanks again for your generous help. I have the new adapter and eproms on order; if I run out of options i'll take you up on it.

I'd like to try to learn and be more self-sufficient.
 
I got my new adapter today and it looks like my old adapter was faulty. Reading the graphics roms, I get identical checksums every time now. After dumping the whole set, I believe I have the USA 900725 version and compared it to a dump downloaded online:

C:\mame>romcmp magic.zip mswordu.zip
12 and 19 files
ms09.bin 1xxxxxxxxxxxxxxx = 0xFF
ms_09.12b 1xxxxxxxxxxxxxxx = 0xFF
ms09.bin ms_09.12b IDENTICAL
ms1.bin ms-1m.3a IDENTICAL
ms18.bin ms_18.11c IDENTICAL
ms19.bin ms_19.12c IDENTICAL
ms3.bin ms-3m.5a IDENTICAL
ms30.bin msu_30.11f IDENTICAL
ms31.bin msu_31.12f IDENTICAL
ms32.bin ms-32m.8h IDENTICAL
ms35.bin msu_35.11h IDENTICAL
ms36.bin msu_36.12h IDENTICAL
ms5.bin ms-5m.7a IDENTICAL
ms7.bin ms-7m.9a IDENTICAL
buf1 NO MATCH
ioa1 NO MATCH
iob1.11e NO MATCH
ms24b.1a NO MATCH
prg1 NO MATCH
rom1 NO MATCH
sou1 NO MATCH

C:\mame>mame64.exe -romident magic.zip
Identifying magic.zip....
ms09.bin = ms_09.12b msword Magic Sword: Heroic Fantasy (World 900725)
= ms_23.13b mswordj Magic Sword: Heroic Fantasy (Japan 900623)
= ms_09.12b mswordr1 Magic Sword: Heroic Fantasy (World 900623)
= ms_09.12b mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms1.bin = ms-1m.3a msword Magic Sword: Heroic Fantasy (World 900725)
= ms-1m.3a mswordr1 Magic Sword: Heroic Fantasy (World 900623)
= ms-1m.3a mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms18.bin = ms_18.11c msword Magic Sword: Heroic Fantasy (World 900725)
= ms_30.12c mswordj Magic Sword: Heroic Fantasy (Japan 900623)
= ms_18.11c mswordr1 Magic Sword: Heroic Fantasy (World 900623)
= ms_18.11c mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms19.bin = ms_19.12c msword Magic Sword: Heroic Fantasy (World 900725)
= ms_31.13c mswordj Magic Sword: Heroic Fantasy (Japan 900623)
= ms_19.12c mswordr1 Magic Sword: Heroic Fantasy (World 900623)
= ms_19.12c mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms3.bin = ms-3m.5a msword Magic Sword: Heroic Fantasy (World 900725)
= ms-3m.5a mswordr1 Magic Sword: Heroic Fantasy (World 900623)
= ms-3m.5a mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms30.bin = msu_30.11f mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms31.bin = msu_31.12f mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms32.bin = ms-32m.8h msword Magic Sword: Heroic Fantasy (World 900725)
= ms-32m.8h mswordr1 Magic Sword: Heroic Fantasy (World 900623)
= ms-32m.8h mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms35.bin = msu_35.11h mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms36.bin = msu_36.12h mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms5.bin = ms-5m.7a msword Magic Sword: Heroic Fantasy (World 900725)
= ms-5m.7a mswordr1 Magic Sword: Heroic Fantasy (World 900623)
= ms-5m.7a mswordu Magic Sword: Heroic Fantasy (USA 900725)
ms7.bin = ms-7m.9a msword Magic Sword: Heroic Fantasy (World 900725)
= ms-7m.9a mswordr1 Magic Sword: Heroic Fantasy (World 900623)
= ms-7m.9a mswordu Magic Sword: Heroic Fantasy (USA 900725)

I determined this by seeing that only ROMs 35&36 fit 900725. So If all ROMs are identical to the downloaded dump, this means all ROMs are good? If that's the case, then I may have a bad B board or C custom :(

The only other thing I noticed is that the security sticker had been peeled back and there are some exposed traces that run between RA7 and the area near ROM socket 25. That whole area is empty so I don't think it should be an issue? I'll have to meter it out later.
 

Attachments

  • 09745D1D-DFB8-494C-A005-BBB7119B043F.jpeg
    09745D1D-DFB8-494C-A005-BBB7119B043F.jpeg
    194.1 KB · Views: 178
  • 4891F7BF-41BB-4018-AF54-B1AA370F40C0.jpeg
    4891F7BF-41BB-4018-AF54-B1AA370F40C0.jpeg
    244.1 KB · Views: 186
Great! I'm glad you have a working adapter now. :thumbsup:

You are correct about the ROMs generally being good if the checksums match MAME (there are rare cases where an EPROM dumps properly but doesn't function properly in a running PCB but I've encountered that only once out of hundreds of EPROMs). It's not a problem that your dumps of the GALs (buf1, ioa1, etc) didn't match - the original GALs are secured and require special techniques to dump properly.

That said, there is a possibility that a failed GAL chip is the cause of your trouble. Here are three diagnostic paths you could take:

1) You could purchase a batch of programmable PAL16L8 chips, and swap out the original GALs in your C board and B board with the programmed PALs one at a time and see if that changes the symptoms. Start with the C board first.

PAL files for the CPS1 games are here:
http://wiki.pldarchive.co.uk/index.php?title=CAPCOM_CPS1

2) You could use a logic probe to check the Address, Data and Control lines on each graphics EPROM for pulsing activity. If one of those lines is "stuck" - ie it reads high, low or not at all with the probe - then that could indicate either a damaged trace on the line, or a problem with the GAL or custom chip that drives that line.

I have a YouTube video tutorial that covers using a logic probe to check graphics EPROMs lines for activity here:
View: https://www.youtube.com/watch?v=2PAtTIAijeA&t=517s


3) You could try swapping your C Board out for a different CPS1 C board that has a CPS-B-21 custom on board. If you do that and also swap EPROMs 30 and 35 out for deprotected code, this would let you know if your C board has gone bad. If the game runs fine with the different C board and deprotected EPROMs, you'd know that your B board is fine and you could then source a replacement C board (Street Fighter II Hyper Fighting JPN region uses the same CPS-B-13 custom as Magic Sword).

I'd be happy to loan you a C board with the CPS-B-21 for troubleshooting for the cost of shipping and I can provide the two files you'd need to program to EPROMs to use it as well.
 
Last edited:
Hey @ShootTheCore , thanks for the very helpful information.

Note I only dumped the matching chips, the unmatched ones I did not dump.

In your video example, would the bad mask rom dump and verify correctly? In other words, could it not work in production, but the information on the chip read correctly when dumped? I have some of the graphics EPROMs in transit; is it worthwhile to burn new chips and toss them in at this point?

In your list of ideas:

A is hard because the gq-4x4 doesn't write PALs

B: I don't have a logic probe (although they are not expensive). I should probably think about learning to use one!

C is probably the easiest test; I have a couple of b-21 c-boards. For ROMs 30 & 35 I would need to source some chips I think. My chips are M5M27c100k (mitsubishi). Apparently 27c010 chips are equivalent, is that the cheapest/easiest to find?
 
Great questions! Answers:

In my tutorial video, the ROM had failed because all of the Address and Control lines showed activity but all of the Data output lines were inactive. Replacing the failed ROM with a fresh EPROM solved my problem because there was nothing wrong with the data traces or the chips that read the ROMs. I tried dumping the ROM later after it was removed and it wouldn’t dump.

In you case, you know your EPROMs are all good, but we don’t know if the custom chip(s) that access the graphics EPROMS are functioning correctly. Probing the Address, Data and Control lines for all the graphics EPROMs will help confirm that the EPROMs are being read properly. If any line except Vcc, GND, NC, PGM or OE is inactive, you should follow that trace back to its source and check the line for continuity on both ends with your multimeter. If the continuity is good then the source chip that connects that line to the EPROM may be faulty.

OE (Output Enable) is Active Low, so it’s fine if it doesn’t pulse as long as it’s reading Low on the probe.

This is the logic probe I use - it’s $20 from Amazon and works very well:
https://www.amazon.com/gp/product/B000Z9HAP4/

Since you already have a suitable C Board on hand, definitely go ahead with trying it-you may want to try that first before messing with the logic probe since C Board custom failures are so common. I’ll PM you the two files for the EPROMs in the morning when I’m at my computer. You’ll want to use 27C1000 chips, not 27C010 - the pinout is different. Make sure your programmer can write 27C1000 chips.

One more thing - the B-21 C Board you use with the de protected EPROMs has to be battery-free. If your C Board still has a battery then it’s likely storing a protected configuration that is specific to the game it’s currently paired with.
 
Last edited:
Ok, burned the new ROMs, tossed in 2 different b-21 c-boards. One legit from SFII turbo (92631-c) the other from Chinese hackjob (92641-c) both boot to just this screen:

57A6AB59-8C14-465A-A773-D45D0F919A1A.jpeg
 
Hmmm…the plot thickens. Now the Scroll RAM is showing up as bad. Try dumping the EPROMs you just programmed and make sure the dumps match the original files.
 
So I pulled the ROMs. Opened the file for 30 and did a "verify" this came back ok. Did the same for 35. Also good. For giggles I swapped the chips around in case the filenames got transposed. That made some interesting results, coin counter started turning and got some weird sounds.

1623691441550.png
 
duffcon said:
So I pulled the ROMs. Opened the file for 30 and did a "verify" this came back ok. Did the same for 35. Also good. For giggles I swapped the chips around in case the filenames got transposed. That made some interesting results, coin counter started turning and got some weird sounds.
Click to expand...
Check the sockets for dirt?
 
You must log in or register to reply here.
Back
Top