Unofficial Deunan's GDEMU Thread

When Dumpcast started dumping, 2007 it was, we are talking about a dozen years ago now, things were different. We knew it was possible to dump with a PC drive (hackers like Yursoft demonstrated it as early as 2004), but it was very unreliable and only works on specific CD drive models you had to buy used, there were no special tools to correct offsets, no descrambling tools to dump the entire disc in audio mode (or else you would need to do multiple trap/swap discs), etc. etc. It was too much of a pain in the ass, not to mention I was a teenager with no money and couldn't afford to hunt down and test specific disc drives but everyone had a Dreamcast and could just get a BBA at $100 or at least settle for a cheap serial cable. Dreamcast SD card reader did not yet exist at this time.

On top of that, we were not very well organized, there were lots of people willing to dump but with little technical expertise, and there were language barriers with Japanese dumpers who were just uploading dumps casually to Underground-Gamer to no standard and we needed to convince them to join with us and that meant making it as easy as possible to make it worth their time to dump those discs again. So we all quickly settled on doing it the Dreamcast way. Now with SD card readers going for $15 there is no reason people can't dump with that method.

As for ECC/EDC, at the time there was no GDI format and so we communicated with NullDC developers who were adding the GDI format to their emulator. One of the NullDC developers believed that several later DC titles likely had copy protection schemes that relied on false/invalid ECC/EDC data or even modified subchannel data to deter pirates. There were PlayStation titles that did this. We had no way of knowing if that was true or a rumor, since dumps did not exist on the internet for us to check, not to mention there was no way to play GDIs on a real DC, and nullDC did not have good enough compatibility yet, and everything available online was old shitty scene rips with a bunch of bragging and no solid info on what sorts of copy protections had been broken. Some even advocated for full subchannel dumping. But that made dumping substantially longer. In the end we settled on just dumps with ECC/EDC. It was easy to dump, it was still fast, and anyone could always remove the data if they wanted, and it gave us insurance that we wouldn't have to go back and dump everything again if the ECC/EDC was used in a copy protection scheme.

You are right though. 12 years later and we have never seen evidence that the ECC/EDC was ever part of a copy protection scheme. So all dumps are about 10%+ larger than they need to be. But a simple script will remove all the ECC/EDC so I just do that before I export my games to an SD card.

 

Well, as an update I decided to just don't bother with the shrinking/rebuilding business, no mater how enticing it is. I'd rather have 2 SD cards that I have to swap with images that I know for certain work flawlessly rather than test the entire library thoroughly. If checking by seeing whether the game boots or not were enough to know the shrinking/rebuild didn't cause issues, I'd be willing to go through with that, but sadly it seems it can cause further issues, such as selecting certain stages/tracks resulting in crashing in certain games.

 

You should at least convert all the BIN files to ISO (converting from 2352 bytes/sector to 2048 bytes/sector). This will save you 10% of space with absolutely 100% compatibility.


Here's how I do it on Mac (should work on Linux too):
1. Download gditools by @-=FamilyGuy=- here: https://sourceforge.net/projects/dcisotools/files/gditools_20150714.zip
2. Unzip to somewhere convenient for you
3. Copy gditools/addons/bin2iso.py to gditools/bin2iso.py
4. Execute in parent folder and it will traverse all folders and convert BIN files to ISO within:
(make sure you change the path to the path on your computer)

Code:

for file in ./*/*.bin;
do python /path/to/gditools/bin2iso.py "${file}" "${file/.bin/}.iso";
rm "${file}";
done

5. Execute in parent folder and it will traverse all folders and change 2352/BIN references in GDI files to 2048/ISO instead

Code:

for file in ./*/*.gdi;
do sed -i '' 's/4\ 2352/4\ 2048/' "${file}";
sed -i '' 's/\.bin/\.iso/' "${file}";
done

 

It would be dead easy to add a *only strip EDC/ECC* option to gdishrink, would that be a popular feature?

I'm also thinking of adding a check to gdishrink so that it verifies that it's only removing zeros, else it only strips the largest zeros-only section. It would be slower but it should increase compatibility.

BTW, if you know python and modify anything in gditools for your own use, feel free to submit a pull request or at least pm me.

Also, the code your linked to is also very old, but it'll work for the use case you described; the most up to date version is in the "code" section.

 

I think both would be worthwhile features to add.

- Just stripping EDC/ECC would both save about 10%-13% of space and leave the files as completely valid images. A lot of people don't have extra space to leave a second copy of the set around, so probably don't want to risk ruining their files if compatibility is unknown.
- Checking for zeros should increase the compatibility a lot, I'd think.

 

Alright I'll try to find the time to implement at least the EDC/ECC stripping soon™.

 

Ideally it would have been nice if GDEMU supported compressed images by default then you would not necessarily need to consider shrinking any GDI's.

More manufacturers are pushing out 1TB SDXC cards, hopefully insane prices will come down enough (in a few years :S) everyone can afford to own one and have the ability to enjoy the entire Dreamcast library on one card...

Ted.

 

Then he would have people complaining that their single-file solid-compressed 7z-format complete TOSEC dump doesn't work.

That, and also it would be more expensive in order to use a more powerful fpga with enough gates and speed to handle the decompression on the fly.

Really I think not enforcing image integrity is a good compromise. It's simple on his side, but still allow us to save quite some space.

I'm working on the aforementioned gdishrink feature currently. Hopefully it increases compatibility to nearly 100%.

 

I like to remove the 12v from my psu, but i have a japanese PSU. I found only information what to do for the US or PAL PSU. The JP PSU looks different, anyone can help? I played Maken X for an hour and the psu got really hot ..
Still have the Fan mod with a noctua.

 

I'm considering buying the same SD card just to be on the safe side since it works perfectly for you. What cluster size did you format it in, 32k or 64k? I'm not going to shrink rips as well... just pure TOSEC GDIs.

 

I used 64k size.

 

I am trying to make my gdemu (clone) to work but im still having problems. Dont have the known to work 256 kingston but im trying 5 sd cards and the dreamcast just boots (with some it just doesnt) and it displays the audio cd menu of the dreamcast.
I formated the cards with the fat32format software 32k or 64k cluster but nothing.
Does the sd card need to be on the lock or unlock setting? it behaves differently between the two but still no luck.

I Didnt update the gdemu with new firmware, i know i shouldnt...
My DC is the (1) version, had a 3.3v yamaha board.
I used the GDEMU_SD to build my card,

What program do you use to format the card?

 

Fixed it, i noticed that in the audio disc menu if i pressed the gdemu button it was switching disks, i selected the gdemu menu (01) and it loaded it. Eversince the menu loads automatically everytime i turn the dc on.
Well it works fine now.... it even reads all the other sd cards now.
Weird...

UPDATE: the deamn thing did it again. While in game the console crashed (froze with the sound stuck too) and for some time the gdemu could recognise no SD cards. After some time it worked again...
Any thoughts? Could it be a power (pin cleaning) issue or shoyld I return it?
My PSU is the original one but its new, bought ii new some years ago.

ps. What software do you people use to format with fat 32 and cluster size adjustment (fat32format, Rufus...)?

 

My gdemu clone was defective afterall. Made a quick pass with solder and flux on all pins of the two main chips and now its all good.

 

My official GDEMU needed the exact same thing so they really nailed the clone it seems.

 

Lol, thats right....

and here we see the guilty pins on the Altera chip... my phone has really good optical magnification, these are not even slightly visible to the naked eye. Yep, three pins shorted by these two solder balls.

 

deunan will update his gdemu fw for bleem and for skies of arcadia main intro issues. the gdemu new fw will work of same speeds as gdrom. since the increased data speed transfers cause these issues plus some game breaking bug in resident evil code veronica (all versions) so patience. and cloners will suck it big time

 

Well, I hope he does (for his sake mostly).
On the other hand, me personally am pretty happy with my clone and the 60 euros I paid (and got it within 10 days), just the way it is. Which by the way does not have any issue with skies of arcadia main intro.

I would get the original gdemu don't get me wrong. I wish I could order it but I can't.

 

Why do you have to say something confrontational like that? Did you forget that Japanese-Cake is removing ALL bleem protections? I have no sympathy for Denuan, I waited 4 years to get one of the official ones, and just got sick and tired of waiting. How he handles things was bad as well too, no warranty, ect. At least the UK seller I bought my clone from offered a 30 day warranty no questions asked return policy. Can't say as much about the official ones. I could care less about firmware updates, they are already using all of the updates from the first few years, so it isn't like a lot was left to fix.

 

the cloners suck it big time was a joke. although i have it with the ones that cloning it. not with the owners of the clone i can undreastand that patience has a limit. anyway one of the issues with gdemu is that the data transfere speeds are higher than the stock gdrom 12x speed is ~1.3 mb/s and some issues are coming from that. about waranty my gdemu had a problem and he fix it although the waranty criteria could be better