GDEmu vs SD Card

[nickbailuc]

I want to create this to make a complete comparison between the 2 for others to see and I want an answer myself to know which would be better in what situations.

What I know about the GDEmu:

• -Has a user interface (released later, at first it didn't)

• -Cannot load disks since it replaces the drive

• -Only works on DC's with the number "1" in the circle under region

• -Is 100Euro's before shipping and import charges

What I know about the SD Card reader:

• -Much cheeper but hard to find

• -Uses a more advanced Unix-based OS (DreamShell)

• -Can still play disks

• -You can solder your own adapter

I have a model 1 DC so in the end the price and performance is what matters. If it's worth it I'd buy the GDEmu, I bought an advanced VGA box called "Hanzo" (google it, worth reading about) and I wont mind spending money on this but only if it is lots better than the SD Card adapter. Adam Koralik posted video's of both and said the GDEmu is much better but that means nothing as both devices have been updated in both hardware and software. Also, I heard that to play anything, ISO's have to be modified. Is that true? Does that apply to both of the devices? Does anyone have both or can give me a suggestion based on performance? Also does anyone know a link where I could order the SD Card reader because I can't find them anywhere. This is my first post and I hope to get an answer, so thanks in advance!

[Aleron Ives]

There are two main differences between the two, and GDEMU is superior on both counts.

The first is that GDEMU has superior performance, since it connects in place of the GD-ROM drive. The DC's serial port isn't meant for playing games, and the DC's CPU has to waste cycles to read from the port. If you have a game with ADX or CDDA for the BGM, the serial port won't work, because the DC can't read fast enough from that port to play the music. As such, your game will stutter or run in slow motion.

The second is that since GDEMU emulates the GD-ROM functions through its firmware, the DC can't tell the difference between a GDEMU game and a real disc. As such, you can use raw GDI dumps of your games, whereas using the serial port requires you to package games in the "SDISO" format that DreamShell expects. The lack of a menu also prevents boot problems with games that have increased security and consequently don't work correctly with DreamShell, no matter what you do.

[krssn]

I tried Half-Life on my GDEMU and all I can say is it's bliss. Loading times are but a fraction of what they were on a disc... ^^

Only thing I haven't figured out yet is how to change the names in the GDmenu. Half-Life registers as Crazy Taxi, and the Mega Man ultimate collection registers as Ghetto Pong... lol

[Aleron Ives]

You'd have to ask on assemblergames.com, probably. GDmenu isn't affiliated with GDEMU to my knowledge, as GDEMU doesn't have any kind of menu of its own.

[krssn]

No worries. It doesn't bother me enough to look into it...

And if I wait long enough, the answer's probably going to come to me...

[TuxTheWise]

I tried Half-Life on my GDEMU and all I can say is it's bliss. Loading times are but a fraction of what they were on a disc... ^^

Only thing I haven't figured out yet is how to change the names in the GDmenu. Half-Life registers as Crazy Taxi, and the Mega Man ultimate collection registers as Ghetto Pong... lol

GDMenu gets the name from it's IP.BIN file. A lot of MIL-CDs releases are made with generic IP.BIN since any one will work.

To change it "correctly" you would need to extract the files, change the IP.BIN and rebuild it. Since HL won't boot at any LBA except 17002, it's too much work.

You could also try hex editing the entries directly in the image. It would break the CRC sectors, so maybe the image won't work anymore.

[Aleron Ives]

Most commercial games are fixed to boot from LBA 45000, so Half-Life was patched to boot from 17002. You can change it a third time to boot from some other address, although that has nothing to do with the naming problem. Emulators ignore the ECC, so you can edit the image directly for nullDC. If you want the image to work on a DC, you must replace the ECC for every sector you modify, too.

[krssn]

Think I'll just leave the names as they are...