Help with Copier RAM Test
Moderator: BigEvilCorporation
Help with Copier RAM Test
I have a Copier for MD called the Double Pro Fighter. I've had some issues with it that I've heard could be caused by the RAM on the RAM module going bad. I would like to be able to perform a software test on it, but the BIOS provides none so it must be done indirectly.
I don't have much of any experience with the 68000 or Genesis yet, so it would take me awhile to get used to and figure out how to start assembling ROMs to build this test but if someone here would be nice enough to help me it would be greatly appreciated.
What this test program needs to do is very simple. The program needs to read every byte in the 32 Megabit Cartridge ROM with the exception of the code portion. All bytes other than the Code should be 00 in one test, and FF in another test program. The idea is to test if the RAM is holding bits in the correct state or if part of it is bad as suspected. The output of the program can be as simple as changing the screen color Green or Red (or whatever other colors) for success or failure. If someone decides to take this on for me and wants to go an extra bit further it would be interesting to have the address of a failure and the value at the address printed on screen.
If someone can do this I would really appreciate it. If no one has time but could point me toward some good resources to do this myself I would appreciate that too. I am not new to programming or old systems like these, but most of my experience is with the NES, Gameboy, and SNES.
I don't have much of any experience with the 68000 or Genesis yet, so it would take me awhile to get used to and figure out how to start assembling ROMs to build this test but if someone here would be nice enough to help me it would be greatly appreciated.
What this test program needs to do is very simple. The program needs to read every byte in the 32 Megabit Cartridge ROM with the exception of the code portion. All bytes other than the Code should be 00 in one test, and FF in another test program. The idea is to test if the RAM is holding bits in the correct state or if part of it is bad as suspected. The output of the program can be as simple as changing the screen color Green or Red (or whatever other colors) for success or failure. If someone decides to take this on for me and wants to go an extra bit further it would be interesting to have the address of a failure and the value at the address printed on screen.
If someone can do this I would really appreciate it. If no one has time but could point me toward some good resources to do this myself I would appreciate that too. I am not new to programming or old systems like these, but most of my experience is with the NES, Gameboy, and SNES.
I'm not sure if this is exactly what you wanted, but here you go: http://jiggawatt.org/badc0de/testram.7z
These are two 4MB ROMs. One is padded with 0x00, the other with 0xFF. Each of them check every byte of themselves (except for the actual code + data) and print "TEST FAILED" or "TEST OK" depending on the result. Keep in mind that they will take a while to finish.
These are two 4MB ROMs. One is padded with 0x00, the other with 0xFF. Each of them check every byte of themselves (except for the actual code + data) and print "TEST FAILED" or "TEST OK" depending on the result. Keep in mind that they will take a while to finish.
Thank you so much. I'm going to try them out as soon as I get a chance.
notaz, people kept telling me that but all the 32 megabit games I tested didn't care if I changed random bytes in them. And I did not have auto-fix checksum on. Also, the other reason you suggestion won't work is because with bad ram certain bits might be stuck in a favorable or unfavorable state for each game. So it could just so happen that every 32 megabit game I try would be lucky enough to match. This sort of test is much better.
notaz, people kept telling me that but all the 32 megabit games I tested didn't care if I changed random bytes in them. And I did not have auto-fix checksum on. Also, the other reason you suggestion won't work is because with bad ram certain bits might be stuck in a favorable or unfavorable state for each game. So it could just so happen that every 32 megabit game I try would be lucky enough to match. This sort of test is much better.
I'm not sure on the hardware differences between the SMD and the DPF, but Charles MacDonald's smdutil includes a facility to do a RAM test on the copier, which he does by uploading Z80 code and executing it. Perhaps this code could be modified to handle the full range of the DPF and any hardware differences?
No, I had confirmed from another owner of a Double Pro Fighter that the game itself works fine on their Copier. So the problem is a fault in my Copier. Either a hardware issue with bad RAM or some other hardware issue, or possibly my BIOS is an older version and maybe something was changed there later.
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
Are you sure they aren't using a cracked version of the ROM?MottZilla wrote:No, I had confirmed from another owner of a Double Pro Fighter that the game itself works fine on their Copier. So the problem is a fault in my Copier. Either a hardware issue with bad RAM or some other hardware issue, or possibly my BIOS is an older version and maybe something was changed there later.
What is the symptom that you see?
While I do not know for a fact that he did, I have not see any roms of Gunstar Heroes floating around that are cracked.
The symptom is when loading Gunstar Heroes, like every game does the system resets into Genesis mode and you see the License Text Screen just as if you were starting a cartridge. It goes black, and stays black. Nothing ever happens. But, by cracking the checksum routine, the game runs just fine. No apparent bugs or faults happen when playing the game. I think Rocket Knight may have a problem too, as I recall that one didn't start either so there may be a second game which would suggest a hardware issue and not a software issue with the games.
The symptom is when loading Gunstar Heroes, like every game does the system resets into Genesis mode and you see the License Text Screen just as if you were starting a cartridge. It goes black, and stays black. Nothing ever happens. But, by cracking the checksum routine, the game runs just fine. No apparent bugs or faults happen when playing the game. I think Rocket Knight may have a problem too, as I recall that one didn't start either so there may be a second game which would suggest a hardware issue and not a software issue with the games.
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
That does sound an awful lot like a bad RAM module. There's a number of different ways a memory module can fail though so a simple test like all 0 or all 0xFF isn't going to catch.MottZilla wrote: The symptom is when loading Gunstar Heroes, like every game does the system resets into Genesis mode and you see the License Text Screen just as if you were starting a cartridge. It goes black, and stays black. Nothing ever happens. But, by cracking the checksum routine, the game runs just fine. No apparent bugs or faults happen when playing the game.
If the memory in the DPF is writeable after the system resets, it shouldn't be too hard to make a more thorough memory test ROM.
The problem is that the DPF BIOS runs in Sega Master System mode with the Z80 as the CPU. It doesn't load Master System software though, only Genesis. I'm not aware if you could use the Z80 in a Genesis program to interface with the DPF and test the RAM.
Someone did offer me a replacement RAM board to try and I should be getting it someday and hopefully that will fix the issue. I suppose it was a bit simplistic of a test to just test all 00s or all FFs. But I wanted to make my request for atest ROM as simple and clear as possible.
Someone did offer me a replacement RAM board to try and I should be getting it someday and hopefully that will fix the issue. I suppose it was a bit simplistic of a test to just test all 00s or all FFs. But I wanted to make my request for atest ROM as simple and clear as possible.
I realize this topic is a bit old now but I thought I'd post what may be the conclusion to this issue. I found out from someone that deals in hardware like this that my DPF apparently has a regular 40pin Pro Fighter RAM board in it, not the Double Pro Fighter RAM board which is I think 50pins. So it seems all my issues are related to whomever had the Copier before had replaced the RAM board with the wrong kind. It may be that it made sense for them and that the SNES functionality works perfectly like this. I haven't really tested the SNES side other than loading up a 32M game, and testing if it supported plugin DSP like the Super Wild Card or other copiers.
I am supposed to be getting the appropriate RAM board rather soon and I'm hoping it will solve my issues. Whether it does or doesn't I'll post or edit this post.
Also I realized later that the whole idea of testing bit states was inferior to a realistic checksum routine like in Gunstar Heroes. Probably the thing to have done would have been to get a debugger, modify the range Gunstar Heroes checks, get the correct checksum from an emulator, and test it on the DPF to see the results. But since I know I have an hardware issue now there isn't any point in testing.
I am supposed to be getting the appropriate RAM board rather soon and I'm hoping it will solve my issues. Whether it does or doesn't I'll post or edit this post.
Also I realized later that the whole idea of testing bit states was inferior to a realistic checksum routine like in Gunstar Heroes. Probably the thing to have done would have been to get a debugger, modify the range Gunstar Heroes checks, get the correct checksum from an emulator, and test it on the DPF to see the results. But since I know I have an hardware issue now there isn't any point in testing.