SpritesMind.Net

I'm having a problem dumping only ONE of my Games. All of my other games work, but "Revolution X" always freezes at 91%.

The game is apparently a 34 MegaBit game according to the PC app when I select "Auto" on the Genesis.

It never completes the 4MB dump (stops at 3.93MB).

Any ideas? Computer is fine, EPP (not ECP), and as said, works on all other game.

EDIT: Oh, and on the Genesis side, it goes back to the main dumping screen, inferring the dump was complete.

EDIT 2: I tried again, made it to 92% and it did 3.99MB, but still wouldn't run in an emulator.

I don't think dump can properly dump a 34 MegaBit cartridge, cause when the dump is viewed in an hex editor, it's full of the ascii character "D", no actual data is dumped.

I have a 4MByte (32Mbit) dump on my HDD and it works fine... and I doubt that game is 34Mbit, because then it would have to use bank switching, and AFAIK there's only one method emulated and that game doesn't use it. Maybe the header is just incorrect.

Hold on, so it's 32Mbit? I was sure 4MB was 34Mbit. (33.554Mbit to be precise, round off to 34)

how come ? 8Mbits = 1Mbyte

But 34Mbit is 4.0531MB..

I still think this game is 34Mbit.

Just in case, I'm forcing a 32Mbit dump.

Where the hell do you get this 34Mbits ?

TmEE co.(TM) wrote:Where the hell do you get this 34Mbits ?

From MoD's transfer suite, it auto detects Revolution X as 34Mbits..

Didn't you read my original post?

The game is apparently a 34 MegaBit game according to the PC app when I select "Auto" on the Genesis.

Jeez.

I forced 32Mbit, and it successfully did a dump.

Here's the header from a sucessfull dump.

http://img.photobucket.com/albums/v395/ ... n/head.png

I saw 32Mbits in the header (3F FF FF FF)...

TmEE co.(TM) wrote:I saw 32Mbits in the header (3F FF FF FF)...

Then it's settled. MoD needs to make a minor fix, as some games with correct header still get incorrectly dumped.

I doubt this is a bug in the dump program. Usually when you see funny megabit values you have one of two problems:
1) The connection between the Genesis/MD and the cart isn't quite right and so it can't properly read the header
2) The Genesis/MD and the PC didn't sync properly and so the PC didn't receive the size properly

Anyway, I've got the rewrite of my transfer suite working well enough that auto-detect dumping works. It's just not feature complete yet. You can't do fixed size dumping, BIOS dumping, 40Mb dumping, or program transfer for dev stuff. I'd also like to optimize the transfer code a bit before release. It's measurably faster than the old protocol (at least if you don't include checksum calculation time), but I think it can still be faster.

My problem isn't number 1 that's for sure. I constructed a cable of very high quality, with cold plated connectors. I tested the cables with a continuity tester for every pin under stress testing, no faults.

Number 2 sounds more plausible.

I'll wait for a re-release.

evildragon wrote:My problem isn't number 1 that's for sure. I constructed a cable of very high quality, with cold plated connectors. I tested the cables with a continuity tester for every pin under stress testing, no faults.

No, no. I wasn't talking about the cable connection. I was talking about the connection between the cartridge and the MD/Genesis itself. That said, since you do seem to have gotten a clean dump by forcing the size, it would appear that the first option isn't the issue (unless you removed and re-inserted the cart between your auto-detect and manual size tries).

oh my bad, misread it.

i didn't remove the cart, i left it in the whole day with pin B32 taped up. (no 32X attached just in case)