What's new
Non-volatile RAMs?I don't know, I never tried.It could work, I can do some test.
I've read the documentation of the DSP and in case of battery power loss (it's an input pin) it resets the keys. That said if you tie it to the +5V rail on the PCB (maybe through a diode or resistor to lower level since there's might also be a voltage check) it might do the trick.
 
The DS5002FP is a little "bastard", it can suicide also if you fiddle with it with a logic probe or multimeter, tried on my skin!
 
Apologies in advance, I'll probably be asking a bunch of dumb newbie questions in the coming few weeks, since this thing is completely new to me, and the documentation here is kind of sparse/spread out.
I'll be documenting my own progress, so maybe the result will help others in the future.

One thing that's confusing me is @Apocalypse 's post on neo-geo.com stating that the VCC pin isn't used when connecting to the TTL(?) interface on the board. Am I to assume that the entire PCB needs to be powered via the JAMMA connector for this to work?
And in this case, does it matter what the game is doing? Just do this while attract mode is running?
And pin 4 (/PROG) can just be connected to one of JAMMA ground pins, then?

I replaced the battery yesterday and I'm still waiting for my USB thing to arrive in the mail. The battery still measured 3 volts, so I hope I'm not doing something futile here.
 
We'll be glad to see your progress here. Let us know how it goes. :thumbsup:
 
@Sumez yes you must power the PCB (preferably through JAMMA).
The prog pin can simply bridged to the nearby gnd pin.
 
Can, or should?
As far as I can tell I'm also going to need that pin to interface with my PC.

Of course, it's not like it's going to be a problem to use a couple of alligator clips to "split" that connection, but I'm just trying to figure out the most simple, direct approach.
 
Can. If you ground it from the JAMMA edge it will also work.
To connect the required signals I simply used male strip pins with wires soldered to them.
 
I think I've done everything as suggested, but I'm still getting the "coprocessor not ready" after resetting the board.
My best guess is that I didn't upload the file correctly.

The whole converting the data into intel hex format is a bit confusing to me. Even finding a utility that was able to do that correctly was a hassle.
I downloaded the wrdallas.hex file from @Apocalypse 's neo-geo.com thread, and comparing to the one I got from converting "aligator_ds5002fp_sram.bin" from mame, mine was one line longer, despite both sources being exactly 32KB.

Here are the first few lines from my file:

Code:
:020000040000FA
:20000000020040020040FFFFFFFFFF020040FFFFFFFFFF020040FFFFFFFFFF32FFFFFFFFB9
:20002000FFFFFF32FFFFFFFFFFFFFF02042EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF76
:2000400075814075C67875D80075C180E5874408F58790F106E4F090FF7CE0A3F4F5F0E0DE
:20006000A3F4F524E0A3B5F0EEE0B524EA12008F12008612039D90A00EE060FD14F012009B
:20008000AF12038280F078247907E41203E922E4F5F0F8F97B007A30901000E029F95001B8
So I assumed the first line was some kind of header that wasn't used in this context, and selected and copied the text from the second one forward, and after sending the L command in putty (L, then carriage return) I right clicked to paste (no visual feedback until the prompt comes back up after several minutes).

I did the next stuff, and it seemed to do what it should, but I'm still not any closer to a functioning PCB.
So what's the problem here? Should I have included the first line too? Did the file not convert correctly? (I used an utility called srec_cat.exe from a project called SRecord). Or did I do some other mistake?

Here's what my resulting PuTTy window looked like:

putty4.PNG
 
The hex file is different for each game. Your aligator_ds5002fp_sram.bin is probably correct for your game. Just convert it to .hex then upload it.
And yes keep that first line.
 
Last edited by a moderator:
The hex file is different for each game. Your aligator_ds5002fp_sram.bin is probably correct for your game.
I don't doubt the .bin file, I doubt the .hex file, or maybe my method for transferring it.
If I do include the first line I get an error message from the terminal (can't recall it, "ERR:BADCMD" or something like it), but if I paste the whole thing without that line, it acts like it works. Except the game is still suicided.

If you had success with your .hex file, can you tell me the exact method you used to convert it?
 
Why does this have to be this hard?

Of course that was the first thing I searched for. :P
I found two "bin2hex" projects on the Internet, one was from 1999 and didn't work on anything much newer. I think it requires a 16-bit OS version, and doesn't run on Windows 10 at least.
The other must have been something different entirely, because the stuff it outputs doesn't look like the intel hex format at all.
 
Binary is just data. It doesnt have any specific format. Hex file does. It has some offsets, checksums, etc. Moreover it depends on the manufacturer sometimes, but let's assume it uses Intel's HEX format. I just took my eprom programmer Software, opened the file as binary and then SAVE AS Hex. The result is attached.

I don't know why you say that you are far from getting it working. Looks like you can connect and communicate with the Dallas, you are almost there!

Maybe instead of loading the file, try pasting it into Putty.

Let us know how it goes.

Thanks.
 

Attachments

  • alligator_new.zip
    9.9 KB · Views: 175
  • Like
Reactions: nem
Thanks a lot, Darksoft! Unfortunately, it looks like your file is completely identical to the one I had managed to create, minus the weird first line (see the Code bit that I pasted, lines 2-6 are the same as your lines 1-5).
So it seems my issue might not be with the file I'm using, but maybe with the method I use to transfer it, or maybe there's another issue? I've replaced the battery, so I'm assuming it should be working.

I don't know why you say that you are far from getting it working. Looks like you can connect and communicate with the Dallas, you are almost there!

Maybe instead of loading the file, try pasting it into Putty.
That's what I'm doing. Or at least that's what I think I'm doing:
and after sending the L command in putty (L, then carriage return) I right clicked to paste
It's a little unclear what's happening because Putty itself doesn't give me any feedback (which makes sense, it relies on the hardware I'm connecting to to give me any feedback). After pasting the file, it just waits for several minutes, and then returns to the default ">", prompting me for input (see the image in my attachment above). No errors or anything.

I don't think I ever said that I was far from getting it working. I'm just confused, because it looks like I'm doing stuff correctly, but the board still shows the same error when starting up.
 
@Sumez that happened to me before, there were some severed traces on the solder side under the battery area.
 
Thanks a lot, Darksoft! Unfortunately, it looks like your file is completely identical to the one I had managed to create, minus the weird first line (see the Code bit that I pasted, lines 2-6 are the same as your lines 1-5).
So it seems my issue might not be with the file I'm using, but maybe with the method I use to transfer it, or maybe there's another issue? I've replaced the battery, so I'm assuming it should be working.

I don't know why you say that you are far from getting it working. Looks like you can connect and communicate with the Dallas, you are almost there!

Maybe instead of loading the file, try pasting it into Putty.
That's what I'm doing. Or at least that's what I think I'm doing:
and after sending the L command in putty (L, then carriage return) I right clicked to paste
It's a little unclear what's happening because Putty itself doesn't give me any feedback (which makes sense, it relies on the hardware I'm connecting to to give me any feedback). After pasting the file, it just waits for several minutes, and then returns to the default ">", prompting me for input (see the image in my attachment above). No errors or anything.

I don't think I ever said that I was far from getting it working. I'm just confused, because it looks like I'm doing stuff correctly, but the board still shows the same error when starting up.
Hi! It's my first post!

Been there.

Actually you can input T to toggle echoing the incoming data before you hit L and paste the file. Here you can find some useful info: https://www.keil.com/dd/docs/datashts/dallas/secure_ug.pdf

This way I learned there were missing characters in pasted strings resulting in E:NOTHEX error - "A non–hexadecimal character was found when expected". The intel hex file was ok, it was the terminal program that skipped some characters when I was pasting it. Weird but true. After some digging I found out it is a known issue. The solution for me was to use TeraTerm and add some chracter transmit delay, lets say 1ms.



It took a lot of time to load the data but it finally worked. I successfully desuicided TH Strikes Back this way.
 
Last edited:
The DS5002FP is a little "bastard", it can suicide also if you fiddle with it with a logic probe or multimeter, tried on my skin!
I just finished resuscitating my WR and I put two battery slots so when one battery is about to go out all I need to do it's put another one in the empty slot and remove the old one... but every time that i tested the solution the board suicided on me.

Caius is right this Dallas chip it's a Mother....
 
but every time that i tested the solution the board suicided on me.
IIRC someone pointed out the fact some battery holders actually short + and - when inserting a new battery due to the mechanical way they are designed.
 
Back
Top