Hello,
I've googled the hell out of this game and all I find is people saying they can't get the save to work on multicarts like the everdrive or single pcb donors.
That or if I do find postings about a working copy it's only from people looking to SELL the english transated copy of the game.
The most I've been able to gather is there is an issue with the SRAM saving. One person even mentioned that it might be cause it uses more than 8k to save which 8k is the norm on most common sports title donors from my experience. Is it probable that replacing the 8k sram with 32k sram would fix this issue or prehaps it's a bigger issue than that?
Anyhow I really look forward to finding out how to make the translated english version of King Colossus work cause I will spread the info freely on the net so the next person or persons don't have to go crazy looking for info to get this game working correctly on real hardware. Any and all help is greatly appricated and will be sure to get echoed in the futrure.
Thanks!
And what sort of donor do you use? Photo of PCB, please
80sFREAK wrote:
And what sort of donor do you use? Photo of PCB, please
Here are pics of the front and back of the donor board:
The stock sram was a gm76c88ALK-15 (6264 compaitble 8k) and I want to replace it with a MS62256L-70PC (32k) with 16k of the ram addressed and A14 pulled high to shut it off so only 16k is active. I think that *should* work from what I've gathered??
I sent you wiring instructions to try.
MottZilla wrote:
I sent you wiring instructions to try.
Attaching A13 with a 62256 didn't work. It still won't save at all. It doesn't even bring the save in game let alone save it after powering off. Maybe I got a bunk binary too. Damn this is a headache but I'm gonna see it threw!
What is the voltage on back up battery?
80sFREAK wrote:
What is the voltage on back up battery?
All 2032 coin batteries are 3v are they not? I've not seen any different ever myself.
80sFREAK wrote:
Did you measured it?
I'm not sure what the voltage of the battery has to do with anything
in this case but I'm sure you have reason for mentioning it so could you please explain it to me?
OMG
You might have old dead battery. Measure voltage, come back, we can talk after.
80sFREAK wrote:
OMG
You might have old dead battery. Measure voltage, come back, we can talk after.
I made sure it was a good battery. If you read my posts you would see its not even registering the save in game at all as it doesn't even show up on screen. It's not just the SRAM not saving the state after the machine is off.
Any particular reason your being a jerk to me??
nintendo2600 wrote:
Any particular reason your being a jerk to me??
Probably not, he's a jerk to everyone. If you look around you'll see he always acts like he's the god of electronics and everyone else should be laughed at because they are always wrong. He usually just laughs at people instead of actually helping.
nintendo2600 wrote:
80sFREAK wrote:
OMG
You might have old dead battery. Measure voltage, come back, we can talk after.
I made sure it was a good battery. If you read my posts you would see its not even registering the save in game at all as it doesn't even show up on screen. It's not just the SRAM not saving the state after the machine is off.
Any particular reason your being a jerk to me??
Ok, is your ROM image original or patched?.
2 tokumaru why so much butthurt?
You don't need any extra logic, Genesis SRAM decoding is so simple for <=16M games, basically the upper half of the 32M of game address space (all 16M of it) is decoded to the SRAM.
Why do you think the game needs 128 kbit/16 KiB of RAM? They don't make chips that size... It's also very unlikely that an 8M 1992 game would use a 256 kbit chip, much less waste half of it.
Most likely the problem is that your donor boards are wired for odd addresses (using /LDS) and this game uses even addresses (using /UDS), or vice versa.
kyuusaku wrote:
You don't need any extra logic, Genesis SRAM decoding is so simple for <=16M games, basically the upper half of the 32M of game address space (all 16M of it) is decoded to the SRAM.
Why do you think the game needs 128 kbit/16 KiB of RAM? They don't make chips that size... It's also very unlikely that an 8M 1992 game would use a 256 kbit chip, much less waste half of it.
Most likely the problem is that your donor boards are wired for even addresses (using the /LDS) and this game uses odd addresses (using the /UDS), or vice versa.
If that is the case how would I compensate for that?
I think the signals he's talking about are B28 and B29. On what I think is an old World Series Baseball board I have, B28 (LDS) is what connects and UDS doesn't.
Seeing the original board would ofcourse be the easiest way to figure it out. But if you want to try you could cut the trace from B28 and connect it to B29 swapping the signals.
I can't remember exactly how this works... When you use byte mode writes the 68K puts the byte on both D15..8 and D7..0 so to handle writes you'd would only need to swap the write strobes, but I don't *think* it'll work for reads. For it to work the 68K would need pullups on the data bus, it'd AND D15..8 and D7..0 into a single 8-bit byte, then maybe replicate that byte back into a word. This is all horribly undocumented... Even if that works, if a game decides to do word access it will fail. The only sure way to swap even/odd addresses would be to swap the /UDSW to /LDSW (big endian typo in my last post), and swap D7..0 to D15..8. The easiest way to find out whether you actually need to do this is to look at the game's Sega header.
The Sega header in the game is identical to World Series Baseball as far as SRAM field. It declares SRAM at $200001 - $203FFF. Unless there is more data that is useful.
Maybe his donor expects the game to write where ever, I forget where, to enable SRAM and not ROM to appear at $200000 and up first? As opposed to the original board that might always enable SRAM when that area is attempted to be accessed.
MottZilla wrote:
The Sega header in the game is identical to World Series Baseball as far as SRAM field. It declares SRAM at $200001 - $203FFF. Unless there is more data that is useful.
Maybe his donor expects the game to write where ever, I forget where, to enable SRAM and not ROM to appear at $200000 and up first? As opposed to the original board that might always enable SRAM when that area is attempted to be accessed.
Thing that really pisses me off is there are members of this very site that actively sell reproductions of this game and know damn well exactly how to make it work. Some of them are people who even ask others on this site for help figuring out various hardware troubles but when it comes time that anyone asks about info they could share they stay silent hoping they can keep peddling "the warez" and god forbbid someone else would openly share the info so people that want could make the games themselves VS paying out the ass for a repro from them.
No worries, I have a japanese copy on the way to disect and trust me I'm gonna spread the info like the plague as soon as I know exactly how
this works.
I got my japanese copy in the mail from Japan today. Scans to follow. There are some differences in ram handling I can see just from a quick glance. So glad this problem is nearly a thing of the past.
There shouldn't be any differences... It's a Sega licensed game right? All licensed games follow the same rules. The only obscure configuration could be that the game is on a 24/32M board which has logic to swap ROM and RAM (and lock the RAM), but that board wasn't developed yet when this game was released. The lock logic would be apparent because it uses a 74'74 flip flop.
kyuusaku wrote:
There shouldn't be any differences... It's a Sega licensed game right? All licensed games follow the same rules. The only obscure configuration could be that the game is on a 24/32M board which has logic to swap ROM and RAM (and lock the RAM), but that board wasn't developed yet when this game was released. The lock logic would be apparent because it uses a 74'74 flip flop.
Here are the scans of the PCB below:
Yes it is a sega released game and on a 1st party board (obviously). So your sure there is nothing different about it?
Positive... It uses the standard decoding for <= 16M games. From the scan I see it uses /LDSW (odd addresses) which IIRC is the most typical configuration as well. Also as to be expected you can see the game has 8 KiB/64 kilobits of SRAM too. There is absolutely nothing special about this cart.
Then perhaps his donor board has the setup to switch between RAM and ROM for 24M and up? And since it's powering up disabled/select ROM perhaps that is the issue?
MottZilla wrote:
Then perhaps his donor board has the setup to switch between RAM and ROM for 24M and up? And since it's powering up disabled/select ROM perhaps that is the issue?
You are correct! Mottzilla is the winner! He found the solution. The game is now saving perfectly with the modifications he made. If anyone is looking for the BIN just shoot me a PM and I will be glad to share. I have it sitting here and ready to burn to a 27c160 for your Colossal pleasure!
I see. Well the donor does not have ROM switching but it appears Sega introduced the lock feature with this specific 1992 board. The second '00 implements the discrete latch.