Hey guys,
Just following on from a previous topic:
http://forum.arcadecontrols.com/index.php/topic,130917.0/all.htmlI was going to submit a reply to that thread, but it advised to consider making a new topic due to age.
I have a Hornet Hardware NBA Play by Play board. It recently suffered the inevitable fate of the timekeeper chip's internal battery dying, losing all its' data and suiciding the board. Dreaded RTC DEVICE ERROR 35D
I have been reaching out to various avenues to get as much info as I can, so I can decide which path I will be taking with it. Everyone has been really helpful in my endevaours so far and I am very grateful for such a great community.
Namely, there is an excellent repairer on the other side of the country who can guarantee a working repair, but advised me there may be a little bit more to it for him to get it going successfully (including possibly converting all the program roms to another region, so as to be able to get a working matching RTC for it to boot).
I'm still getting some final details on that, as well as needing to still check out a postage quote as these boards are large and heavy. Also waiting on some feedback in regards to what options I will have down the track after the repair is successful, when it inevitably fails again from another dead battery (i.e. does the whole board need to be sent there every time it fails, or will it be easier next time it fails and a chip could be posted to me , or what happens when he retires, etc.). In short, I'm trying to look to a more permanent or manageable solution long term.
The game itself is great, but ultimately their working value is likely around $300, so I need to assess how much is worth investing in it as well.
Also, I'm really curious how it all works as well
Okay, so all of that aside, back to looking into the technical side of the problem. Ideally I'd like to be able to have an RTC file compatible with my version game board, so that I can maybe even invest in a programmer and have a future proof solution.
Removal of the chip and soldering in either a new chip or a socket for that chip is not a concern.
A replacemnt M48T58Y chip from mouser with a new internal battery is also not a concern. There's even a guy who modifies these chips to have an external coin cell battery holder - another thing to consider.
Long and short of it - the issue lies in being able to get a compatible file to program to one of these chips for the current version of my board UAB
Only two versions of NBA Play by Play have been dumped for MAME
JAA (Jap)
AAB (Asia)
Whomever dumped the AAB version however, has copied across the M48T58Y file from the JAA version (imagine due to the hassle of needing to desolder their own chip to dump it).
Ultimately MAME does not emulate the security so that file was not relevant to dump I'd say.
So in short - I have access to one M48T58Y file - the JAA Japanese version.
My version however, is UAB (USA).
The way the security works on these boards, based on the previous thread, is that it looks at the data in the first 14 bytes, followed by the next two bytes being a checksum. The previous thread can explain more.
I don't know if this checksum remains steady once its programmed, or if its continually rolling and changing *shrug*?
I guess thats' my first question.
Porchy has a tool which can be used to check these RTC files for Silent Scope 2 and it will tell you the checksum found VS what it should be, based on an algorithm.
http://www.jammarcade.net/files/Programs/ss2check.zipThe only concern I have is that it works great when I test it on a silent scope games M48T58Y file (MAME rom), but when I tested it on Gradius, or even the dump of the Japanese NBA Play by Play (JAA version) - none of them match the expected checksum? How were these functioning on working PCB's out there? Is the algorithm different for games other than Silent Scope?
Please see my screenshot:
https://imgur.com/a/E4gxgI thought that I could simply edit the japanese file in Hex, change region to match UAB, then use the tool to verify the checksum and update the 15th and 16th byte to the expected checksum, save it and use that to program a M48T58Y
But based on the checksum tool, it might not be the case.
Thanks all in advanced for any input