GDEMU FW 5.20.5

[Stump909]

Thank you for the explanation @ateam! Chances are that I don't need to update any time soon, but I'll definitely save this info for the future.

Just got confirmation from another user, you must do the pre-update steps on the clone for successful update. So, just follow the steps in RazorX's ZIP there, and be sure to download latest 5.20.5 from the GDEMU website.

Sorry, I tried looking myself, but no luck…

Can you link the RazorX zip in question?

[ItalianGrandma]

Thank you for the explanation @ateam! Chances are that I don't need to update any time soon, but I'll definitely save this info for the future.

Just got confirmation from another user, you must do the pre-update steps on the clone for successful update. So, just follow the steps in RazorX's ZIP there, and be sure to download latest 5.20.5 from the GDEMU website.

Sorry, I tried looking myself, but no luck…

Can you link the RazorX zip in question?

Scroll down to ateam’s post right after mine on page 1 of this very thread: viewtopic.php?f=5&t=16420

[Panja0]

I actually just purchased a clone yesterday that's 5.20 and I also saw that they are supposedly updateable.

That said, I saw a video from ModzvilleUSA that suggested that the update process is different than a genuine GDEmu and for the life of me I can't find any instructions anywhere that walk through the steps of updating these newer clones.

By any chance, have you seen instructions for this around anywhere? Perhaps it's somewhere in this forum?

My apologies for the question, I'm brand new here

Non c'è problema, nonna =)

I'm actually not sure if Modzville was correct in stating the update process is different. He was just citing what the clone seller told him. I cannot verify one way or the other.

In hopes that it helps you, attached here is a ZIP containing info those same clone sellers provided to a friend of mine, which he organized/rewrote for better English.

Clone_GDEMU_v5.20_Update_Guide_By_RazorX.7z

As you can see from his READMEs, the firmware files given to him were identical to those hosted by deunan himself. The only real difference from that README to what deunan has on his site is that the "pre-update" firmware seems to be required every time you want to update these new 5.20.x clones, whereas with the authentic GDEMUs, it was only a requirement for older devices (prior to 2020) on a pre-5.20.x firmware.

Take a look at the official firmware update page (https://gdemu.wordpress.com/firmware/updating-gdemu/):



#2 describes the typical update process. The steps from #1 are, as I mentioned above, only used when using an authentic GDEMU shipped prior to 2020 while also going from pre-5.20.x firmware to newer 5.20+ firmware.

So, do the 5.20.x clones require this "pre-update" step every time? Well, the manufacturer seems to suggest that they do. However, I haven't heard of a single person actually trying to perform an update on their new clone, so I couldn't say. The only thing I can say for sure is that the special "updater FW" from #1 in that screenshot is identical to the pre-updater supplied by the clone manufacturer.

All of this said, I don't see how performing the pre-update steps from #1 could hurt anything. If it's a requirement on these new clones, then it'll check that box. If it's not, I'm pretty certain no harm can be done. I realize that probably isn't a strong hunch that you'd ideally want to gamble $150 or so on, but it's the best information I have!

Thanks for the instructions! I just updated my 5.20 clone (which was on fw 5.20.3) to 5.20.4 and after that to 5.20.5 with success!

[nuggetreggae]

the new firmware 5.20.5 :

When I updated to it half the games on my SD became unreadable, notably truncated GD-Rips with only four tracks (ISO/RAW/ISO/ISO)... I contactacted deunan who suggested adding Image_Tests=0 to the INI file, but it was still slow reading these "unsupported" discs. Adding a 4 second Audio as track04.raw and placing it 450 sectors below track05.iso (was originally track04) fixes this and makes them correct again.

A couple of the dreamon disc demos that were supposed to have cdda but had failed to put it on the GD started chiming "this is a dreamcast disc" over and over while playing! to be expected, I guess.

Clone CD images seem to be broken on the new firmware. Certainly Ghost Blade from CD Romance shows in the menu as a load of garbled characters. Seems this game is the only one i'm aware of that uses subchannels for protection (not raw, subchannels!). Mounting the same CCD on Daemon tools and setting disc juggler to read all subchannel data makes a working image. ripping to MDS/MDF also seemed to work although the image didnt seem to be (subchannel bytes) bigger.....

I have some discs i hacked images into in the old firmware just by adding an image to free space on the disc (probably leadout!!!!) and adding the LBA and filename on the ISO 9660 filesystem. If the disk has joliet extensions the new firmware will now read from that by default for the GDMenu icon (so my pics disappeared and I had to add the entry to the joliet filesystem as well!)

I will report other things as I find them. -Nugget

[ateam]

the new firmware 5.20.5...

I've been on 5.20.5 since it was released (which under the hood is very similar to 5.20.3, which I beta tested before it was released). The issues you're encountering are interesting to me...

The only one of your problems I've been able to reproduce is CD Romance's "Ghost Blade" CCD/IMG/SUB image. However, I cannot personally verify that this disc image ever worked with previous GDEMU firmware versions.

That said, if you see a corrupt name label in GDmenu, it's more than likely that the game's IP.BIN is malformed. There's nothing GDEMU itself nor its firmware is doing to affect game name labels in GDmenu. That's 100% a software issue (i.e., GDmenu and/or your SD card management tool).

Regarding truncated GDIs, none that I tested have failed to boot or play. If you can point me at some specific problematic disc images, I'm more than happy to test/verify.

Note for those wanting to rip "Ghost Blade" from their own legally purchased disc, these DiscJuggler settings do the trick for subchannel data (at least in my testing).

[fafadou]

This is Work also with a.cdi mount via a virtual drive ?

I'm interested about this special game.

[ateam]

This is Work also with a.cdi mount via a virtual drive ?

I'm interested about this special game.

If the CDI was ripped properly, you wouldn't need to reauthor the CDI

If the CDI wasn't ripped to include subchannel data, then reripping it by mounting it to a virtual drive won't solve it.

[fafadou]

This is Work also with a.cdi mount via a virtual drive ?

I'm interested about this special game.

If the CDI was ripped properly, you wouldn't need to reauthor the CDI

If the CDI wasn't ripped to include subchannel data, then reripping it by mounting it to a virtual drive won't solve it.

Thank you, i hoped it bypass the protection in order to build a gdi.

[ateam]

Thank you, i hoped it bypass the protection in order to build a gdi.

If the game truly uses subchannel data as a form of copy protection, then doing so would be impossible without taking out such checks in the code. There's also a very high chance the game won't work if treated as a GD-ROM disc without additional extensive modifications.

[nuggetreggae]

sorry, i dont think its a malformed IP.BIN, I quite clearly stated that mounting THE SAME CLONECD IMAGE on daemon tools, and re-ripping to either an MDF/MDS alcohol OR subchannel CDI then works. If the garbled name was a result of an IP.BIN it would be messed up in both those subsequent images as well.....

maybe someone with a genuine cloneCD can see if the parsing of the .CCD is indeed brogen as I suspect.... I am making images using UltraISO, would trust proper output from CCD much better!