EMS Action replay 4-in-1 - recovery suggestions

Hi,


Wow I've been a member here for 861 days and haven't posted until now! I'm sure I had - was the forum rebooted around that time? Maybe I lost my login details or something?


Anyway...

I've recently reacquired a Saturn and I decided to get a USB DataLink from Ken (which is awesome BTW) and a PAR 4-in-1 to use it with. I've just copied over my saves from SSF today with it and then I decided to fix the saving ability of my PAR which seemed to be corrupted. I burned off Rockin'-B's All-Stars CD and reflashed my PAR. Now it will not boot the PAR menu. It doesn't crash the SS at all and the RAM portion still works. Having a look at the PAR memory area with the hex editor in SGM shows that every other byte is FF throughout the whole of the firmware.


Is there any way to recover this?


After reading through "How to reflash a BROKEN PAR cart" (yes I didn't read it till after I performed the reflash) the key point is to get to SGM without the PAR menu loading. I booted the All-Stars CD through the PAR menu. Is this why it didn't work?


vendorid is 0xBFBF


On a side note concerning the EMS 4-in-1's without the Parallel Port. As you can see from the EMS site they appear to be manufacturing them in this way now. Maybe you could solder a parallel port onto the newer models? They also make them in black now, sans port as well, to match European/American SS models.


Any input would be appreciated, and no I didn't back up my existing PAR firmware first with the DataLink because I am an idiot.


Cheers,

eddebaby (Who will console himself with a bit of Guardian Heroes)
 
I'm not sure what's going on exactly, but the fact that saving didn't work before suggests some kind of hardware fault related to writing. I can't think of anything that would explain what you've reported, though. Just being able to read the ID on both chips means that all the major signals are working.


As for the versions of the carts lacking the parallel port, I haven't seen one but I would expect that the pads are still there and the port could be added, because I think they'd have to totally redesign the PCB to save any space. They'd probably also leave out the bus transceiver chip attached to it, a 74HC245 (not terribly expensive or hard to get, but more pins to solder).
 
ExCyber said:
I'm not sure what's going on exactly, but the fact that saving didn't work before suggests some kind of hardware fault related to writing. I can't think of anything that would explain what you've reported, though. Just being able to read the ID on both chips means that all the major signals are working.

Is there anything you could suggest to test for a hardware writing fault? Is it possible that it's the fault of my Saturn's cartridge port? I am able to use memory cards normally but I don't know if that would use the same pins.

edit:Also arflash reports the chip as SST29EE010 whereas my cart seems to have 2 Sanyo LE28C1001AT chips. Could this be the issue or are the chips functionally identical?
 
I can't find a datasheet for the 28C1001, but I do know the 29EE010 had a very unique programming method that no other modern devices use IIRC. Chances are they are not compatible.

I am surprised the two devices had the same manufacturer ID and device ID.

The new EMS carts seem interesting, I'd certainly like to see a scan of the PCB someday.
 
If memory serves, the unique part about the 29EE010 is that it doesn't actually need to be explicitly erased; you can just issue a write command and the erasure happens transparently. However, I think it uses the same basic command set as most other byte-width flash memory. I managed to find a crappy scan of a Japanese datasheet for the Sanyo part here, and from what I can tell it seems to be the same as the SST part, including the vendor and device ID. It may be that Sanyo licensed the design from SST.
 
I have some clone Action Replays (without RAM or parallel port) that exhibited the same behaviour - a small number of flash sectors in one of the chips could only be erased, not programmed. The rest of the chip could be programmed, so I guessed it was something in the PLD, accidental or intentional.


FWIW I used ExCyber's flash utility for the programming.
 
Thank you for all the input guys.


antime said:
I have some clone Action Replays (without RAM or parallel port) that exhibited the same behaviour - a small number of flash sectors in one of the chips could only be erased, not programmed. The rest of the chip could be programmed, so I guessed it was something in the PLD, accidental or intentional.


FWIW I used ExCyber's flash utility for the programming.


If this is the case then I guess this cart is unrecoverable? Or is this maybe something that could be fixed with the PC Comms Card? Or would I need to be able to boot to the PAR menu to communicate with it?


If I pick up another I guess I should check inside to see what chips are in there first? If they are manufactured by SST a reflash should be safe.
 
edde_baby said:
Thank you for all the input guys.





If this is the case then I guess this cart is unrecoverable? Or is this maybe something that could be fixed with the PC Comms Card? Or would I need to be able to boot to the PAR menu to communicate with it?


If I pick up another I guess I should check inside to see what chips are in there first? If they are manufactured by SST a reflash should be safe.
arflash was originally tested with AT28C010 and SST29EE010. The guy I originally wrote it for also had a cart with SST29VE010 (that's the 3.3V version), which also worked after I patched the AR firmware to recognize its device ID. The thing is, it should be safe with the parts you have as well, but I'm pretty sure something is wrong with your hardware. This is pointed to by your original problem of not being able to save anything on it, which means that the AR firmware itself wasn't able to write to it successfully. I can't rule out a bug in arflash, though, as the methods it uses to time writes are far from ideal (though that mostly just makes it slow) and its error checking is minimal.
 
ExCyber said:
...but I'm pretty sure something is wrong with your hardware. This is pointed to by your original problem of not being able to save anything on it, which means that the AR firmware itself wasn't able to write to it successfully. ...


That's good to know. It's quite possible I borked it a few months ago. A failed attempt at doing a 50/60Hz mod made my last Saturn a bit spazzy. My new saturn I modded properly. Well I think I'll try to get a new cart anyway, at worst I now have a 1MB/4MB RAM cart that I don't have to go through the Action Replay menu to use. I don't think I can justify asking for a refund from consolegoods as It's more likely I broke it rather than receiving a faulty unit.


As for the alternate blank bytes (FF's) in the flash, do you think that is from the deletion of the data (i.e. the cart only deletes every other byte as that's good enough) or is in in the writing where the cart only allows every other byte to be written to?


I've just answered my own question with a bit of testing. It's 100% faulty writing rather than completely unsuccessful writing. It does write but only to every other byte.


I used your flash util again ExCyber, this time the vendor was BFFF (from what I've read this means it was only reading from one chip). I proceeded anyway to see what would happen. It left the whole area blank (FF). I took out the card, reseated it and the vendor ID showed as BFBF again. Flashed it with ARP_201.BIN - still blank. Flashing it with EMS_202.BIN populated up to 500 but no further (Still missing every other byte). Flashed with ARP_202.BIN which populated up to E2FE. Flashed with ARP_201.BIN again and it got to the end of the data (14BF1 or thereabouts) at least - it may have done the rest but it's impossible to tell seeing as the data is blank any way all the way up to 3FFFF (EOF).


Don't know if this pattern of results would shed more light on the specific hardware fault.


Is the data mirrored on each chip? I'm just wondering if it's stored alternately byte by byte and the second chip is malfunctioning. Probably not eh?


Again thanks for all the information. I'm only just getting into ICs and the like and I have a lot to learn. My only experience really so far is a failed LM1881N video sync separator circuit which I must try again soon. I wish I'd done more electronics in school!
 
It's a 16-bit bus populated with two 8-bit chips, so even byte addresses go on one chip and odd bytes go on the other. Basically, all of the address/control lines are shared between the two chips, but one has its data lines connected to the upper half of the data bus and the other has its data lines connected to the lower half of the data bus, so it "looks like" a single 16-bit memory (and that's how arflash treats it, although it's possible to write/erase them separately by only unlocking one chip).
 
ExCyber said:
It's a 16-bit bus populated with two 8-bit chips, so even byte addresses go on one chip and odd bytes go on the other. Basically, all of the address/control lines are shared between the two chips, but one has its data lines connected to the upper half of the data bus and the other has its data lines connected to the lower half of the data bus, so it "looks like" a single 16-bit memory (and that's how arflash treats it, although it's possible to write/erase them separately by only unlocking one chip).


So the second or odd chip isn't being written to but the first or even one is? I hope I understood that correctly.

In theory then if I desoldered the chips (or rather the more convenient package they are on) and soldered them back in each others place I would get the reverse results? Or are they configured differently?


If one chip is busted then this won't fix anything - but if the fault lies elsewhere on the board then surely I could write the odds and evens separately to each chip. BTW I did a quick search for replacement chips and they cost more each that a new cartridge would cost!
 
edde_baby said:
So the second or odd chip isn't being written to but the first or even one is? I hope I understood that correctly.

In theory then if I desoldered the chips (or rather the more convenient package they are on) and soldered them back in each others place I would get the reverse results? Or are they configured differently? If one chip is busted then this won't fix anything - but if the fault lies elsewhere on the board then surely I could write the odds and evens separately to each chip.
Yeah, it all depends on where the actual fault is. The chips are basically configured the same and just sitting on different halves of the data bus.


BTW I did a quick search for replacement chips and they cost more each that a new cartridge would cost!
I'm not sure where you can order from, but Mouser and Future seem to both have the SST29EE010 for reasonable prices, and a couple other places seem to have the AT29C010 at decent prices. I'm not sure about availability or packaging, though.
 
ExCyber said:
Yeah, it all depends on where the actual fault is. The chips are basically configured the same and just sitting on different halves of the data bus.

I might give the chip swap a go then. update: Not successfully resoldered the chips yet. I'm going to try to make some legs for them as it will be easier to solder. I'll repost once I get any further.

ExCyber said:
I'm not sure where you can order from, but Mouser and Future seem to both have the SST29EE010 for reasonable prices, and a couple other places seem to have the AT29C010 at decent prices. I'm not sure about availability or packaging, though.

I'm in England so ordering from both of those sites is possible. I only had a quick look but the few pages I found seemed to list the chips in the 10's of dollars. Thanks for the links.
 
11 Year later, I finally redid my soldering on this cart - and I managed to flash the latest Pseudo Saturn Kai to it.

It seems the issue was likely the cartridge port, after many failed attempts with different configurations of cardboard holding the cart in different places, I finally managed to write to the cart and verify the ROM was written properly. I can use my USB DataLink with this cart again :)

"Almost working" outcomes, where the write to cart ROM was not verified by the flasher program, included:
  • only the even bytes written
  • only the odd bytes written (when I experienced these first two results, I knew there was a chance of getting it to work)
  • mostly correct data written with random corruption throughout the written ROM
  • enough correct data written to boot to Action Replay 2.02 logo screen
  • enough correct data written of PSK ROM to get the SEGA logo, then the Saturn hangs
  • enough correct data written to allow Saturn to boot in to PSK, and then hang on booting CD
I flashed this cart with PSK Save Data Manager 6.437, for reference.
 
That's awesome. Especially someone bumping an 11 year old thread with an update.
 
Back
Top