I did everything in the correct order as described on the sega cd transfer website: I've chosen every header option (from 2 up to 32 mb) besides the 'auto' one, and tested each corresponding dump. None of them work I'll give it a another try this afternoon. Any tips would be greatly appreciated.
So Egel, any particlular reason you removed the link to LocalH's dump of his Sonic 3 "proto" that you mentioned in the article? I don't know why you didn't want to link to it.
The link could be added, but my Sonic 3 pirate isn't the same as his 'proto' EPROM version, its just a pirate that misses the save feature and is the same as owned by Hivebrain, sorry for the mix-up lol. Edit: Tried dumping without 32X and my Mega Key, same result as expected. Did a little browsing and it seems I'm not the only one hitting a wall here.
Cool find! Would be nice to get a dump of this. This is definitely the copy that was on SoSTH, here's proof: http://2003.sonicresearch.org/ssrg.emulationzone.org/secret/sonic_2/s2p3.html Now interestingly on page 5 there is this anomaly: http://2003.sonicresearch.org/ssrg.emulationzone.org/secret/sonic_2/s2p5.html If we get this dumped it will be very interesting to see if that is true! Perhaps you could test this out egel?
SONIC 4 BAETA Nice to see the details about the pirate cart/box. And what a blast from the past that site is! I didn't realise it was still available. Hello, evening of nostalgia. :v:
That's the first time I've ever heard HPZ's music at 50 Hz. It sounds so wrong! More evidence that PAL territories got totally screwed over for decades. ;P
Actually, Sonic 2 PAL runs at more or less the same speed as the other versions music-wise and is optimized for the PAL region. It's definitely not like Sonic 1, which ran much slower (IIRC at 11% slower). I have NO idea why it runs so slow in that video above, but I am certainly happy to video my Sonic 2 PAL and show you the difference if need be. I can only assume perhaps that the BETA is not optimized and thus runs slower on actual hardware (being a build off Sonic 1), but the final is absolutely fine
I'm trying to find the actual e-mail I have that confirms it so the fact police don't jump down my throat, but basically the prototype we have comes from a Sega BBS breach by Taiwanese pirates. The file we have was being transferred between STI and SOJ. Given the state it's in, I'm inclined to believe it was being used to press local copies to mail out to magazines, but that's a wild guess.
Wow... interesting. The New York proto must be still out there somewhere then? Also shows that the "Chinese hacking into companies" scandals that have been going around recently aren't exactly a new thing!
How fast are the ROMs dumping? Do you have your parallel port set to the right mode? (this is very important, I think it you had to set it to bi-directional mode from your computer's bios) Open up one of the bin files in a hex editor and see if there's even a header. It's been a while, but I remember that sometimes games don't dump even when everything is set up right. Plus the transfer cable sometimes has trouble with some pirate carts IIRC.
I changed the bios setting and it worked, thanks a lot! Seems to dump fast and somewhat correctly now using the EPP setting, wasn't the case yesterday. However I'm still getting a "weird" .bin - all the header info is there now, but it is screwed up (QMLIA THE HEDEEHME lol), fixing that won't help either. I actually tried out every other bios setting and dump size available, but I'm getting the same weird result each time... Here's the test dump .bin I made of a Sonic 1 cart: Sonic 1 dump test.
Notice: The incorrect letters are all two ASCII characters earlier than they should be. Analysing further, it seems that this is because none of the relevant bytes have bit 1 (%00000010) set. Something is wrong with the data transfer itself. It could be as simple as the pin responsible for that bit not being connected on either side, or the wire being broken somewhere along the way.
It's a brand new cable, I don't think thats the cause... I tried it with my Crackers too, exact same result "QMLIA QTUDIUM". Have messed about with the parallel port options in windows too, but that didn't solve this problem either. I really want to get these dumped ASAP
Cable or not, the fact is that bit 1 is being dropped from each of your input bytes. I highly doubt that's caused, or fixable, by any of your software. Something must be wrong with some element of the hardware performing the transfer. Perhaps someone else can provide more specific suggestions than me, but you'll be looking at the same problem in any case.
Are you sure you only have tape covering the rightmost pin on the cart? I would also make sure the cart slot is clean and all the cords are connected firmly with no bent or missing pins in the 2P controller port. I never had this problem when I used my cable. (I guess it's possible you got a faulty cable)
I've cleaned everything and tried everything possible to get these dumped. I'm always getting the same weird result. Guess I better contact tototek about the cable?
