What's new

Itobandito

Beginner
Joined
May 24, 2021
Messages
5
Reaction score
3
Location
Massachusetts
Was wondering if anyone has seen this message at boot up for any CPS2 pcb. This is an original board not a multi kit. This Emulator 1111 comes up instantly at boot up on my Street Fighter Alpha 2. Not the usual CPS2 suicide screen I’ve seen before and battery is reading 3.7v so don’t think it’s that. Any tips? See attached pics. Not that I’ve come across a ton of CPS2 boards but this is the first one I’ve come across with a daughter board. Opened up the case to look for any visa or damage but didn’t see anything. Any thoughts?
 

Attachments

  • 3C9C292F-E805-431C-8E19-60F3E0BD490A.jpeg
    3C9C292F-E805-431C-8E19-60F3E0BD490A.jpeg
    112.5 KB · Views: 187
  • 4762A9DB-51E5-48E2-A93D-E9B33AD2430E.jpeg
    4762A9DB-51E5-48E2-A93D-E9B33AD2430E.jpeg
    293.9 KB · Views: 188
I have no special insight but this looks interesting. That definitely looks like 68k CPU state. I’m guessing “emulator” is referring to something like an in-circuit emulator. Maybe this is part of a debug/dev setup?
https://en.wikipedia.org/wiki/In-circuit_emulation
Hopefully someone who knows more can chime in.
 
Finally got some free time to look into this one again. Anyone have any additional input?
 
The screen is indicating the cpu was asked to run an illegal instruction, which triggered that exception screen. The instruction was at address 00013a82, which should be within the 03 rom. I would dump it and make sure its not corrupt.

Illegal instructions that start with 1111 and 1010 have their own exception handling instead of the normal illegal exception one. I believe this was a way for older model 68k cpus to emulate (through code) instructions that were added in newer model 68k cpus. You would catch the instruction in the 1111 or 1010 exception handler, then use instructions you do have available on your 68k model to emulate the new instruction.
 
The info from the debugger looks not as it should. There are some missing information. I agree with Ack, that you have a problem with the 03 rom. Of some reason the contents can't be properly decrypted. Could be the eprom itself that is faulty. Can you dump the rom(s) for verification? Just make sure that you keep a copy of it's contents in case it's an undumped revision of the game.

The best would be to dump rom 03 to 08 and verify them against the Mame. It's probably revison US960306 but since you got an development pcb it's interesting to verify the contents to make sure that it matches the already dumped revisions in Mame.
 
Thanks for the info guys. thread update notifications were going in my spam so just seeing this. Fixed that so I should see them now. I'm going to re-read the roms, I believe I tried and ended up having to do a mix of rom version numbers to get them to verify but they did. Take that with a grain of salt though as it was a year ago and going to try and go through them all again. Will defintialy start with 03 and 08. Will update the group shortly. Thanks!
 
So took some time today to go over this board again. I did a full eerpom check and in doing so remember where I left off. Eeprom 01 kept testing bad originally and I reprogrammed a new one with a spare 27C010 I had, leaving the original intact. Reading all the other chips though, everything verified fine. For the heck it since I still had it, I popped in that original 01 eeprom chip and I do get the exact same Emulator 1111 screen, all text was the same. So if what ACK and Pyhagoras pointed out is the issue (eeprom 03 and potentially 08 ) I think this may be a bad trace issue?? I'm not to familiar with tracing out the boards, anyone know someone who could help with that or have any other recommendations? Also I dumped the original SFZ201 rom as well if you think that would help here. I was verifying the roms with SFA2 960430.
 

Attachments

  • original SFZ2 01a ITOBANDITO.zip
    74.4 KB · Views: 76
I would try using a logic probe to check the pins on the 03 rom. See if any of them are floating.

Is the information always the same on the 1111 screen? if not can you provide pics?

The PC in your picture is 013a82

Code:
 013A78  dbra    D5, $13a2c                                  51CD FFB2
 013A7C  rts                                                 4E75
 013A7E  moveq   #$0, D0                                     7000
 013A80  tst.b   ($9a,A5)                                    4A2D 009A <--
 013A84  beq     $13a88                                      6702
 013A86  moveq   #-$1, D0                                    70FF
 013A88  move.b  D0, $619ffd.l                               13C0 0061 9FFD

But that seems to be right in the middle of an instruction and even if it was there it shouldn't have cause the 1111 exception. Maybe the screen has bad data on it like @Pythagoras was suggesting.
 
Rom 01a is for sound, so your faulty one is not what causes the problem and since your other roms verified ok against Mame, there must be some hardware problems.

What I mean, there is missing information. For example some of the D and A registers are not shown. The memory dump at the lower part of the screen are missing entirely. The stack pointer (USP) are out of reach.

I don't know anything about hardware fixing, but could a faulty ram cause problems like this? or like you suspect a bad trace somewhere on the pcb. We know at least that some of the data from eprom 03 can be accessed since the debugger is partly working.

Compare with this example crash I made in Mame:
crash.jpg
 
Back
Top