Dreamcast GDEMU info

[sonik]

Yes it fixed some games.
I will have to test the others that still crash and take note of the exact problem.

 

[darcagn]

On my card I have all US games, all PAL exclusives, about 50 japanese titles, and a bunch of unreleased games
I don't know what terminology you guys are using for 'shrink' since there's a few different things that can be done to reduce filesize, but all of my games are converted from GDI+BIN (2352) to GDI+ISO (2048). This only saves about 10% per image but makes 100% fully compliant images that should never be at fault for an error.
The only one of all of those that crashes for me upon highlight is Sega Worldwide Soccer Euro Edition. (edit: sorry, not Euro Edition, it's the regular edition)
On that disc the 0GDTEX.PVR file is a smaller resolution than the 0GDTEX.PVR on all other discs.
Rather than rebuild the disc or try to find/make a better 0GDTEX.PVR for a game I frankly couldn't care less about, I just hex-edited the ISO file and changed the filename in the file table from 0GDTEX.PVR to 1GDTEX.PVR.
Now GDEMU doesn't try to load the artwork, doesn't crash, and the game loads fine

 

[Anthony817]

I honestly wish we had a full set of the 2019 TOSEC DC release, with all GDI's run through GDI Shrink with edited PVR textures to show the proper box art covers instead of disc art images.

 

[FamilyGuy]

On my card I have all US games, all PAL exclusives, about 50 japanese titles, and a bunch of unreleased games
I don't know what terminology you guys are using for 'shrink' since there's a few different things that can be done to reduce filesize, but all of my games are converted from GDI+BIN (2352) to GDI+ISO (2048). This only saves about 10% per image but makes 100% fully compliant images that should never be at fault for an error.
The only one of all of those that crashes for me upon highlight is Sega Worldwide Soccer Euro Edition.
On that disc the 0GDTEX.PVR file is a smaller resolution than the 0GDTEX.PVR on all other discs.
Rather than rebuild the disc or try to find/make a better 0GDTEX.PVR for a game I frankly couldn't care less about, I just hex-edited the ISO file and changed the filename in the file table from 0GDTEX.PVR to 1GDTEX.PVR.
Now GDEMU doesn't try to load the artwork, doesn't crash, and the game loads fine

I should add iso-ification to gdishrink.

Also, an option to not remove data from session 1 would make the process 100% reversible.

 

[darcagn]

I honestly wish we had a full set of the 2019 TOSEC DC release, with all GDI's run through GDI Shrink with edited PVR textures to show the proper box art covers instead of disc art images.

I've thought about doing so in the past and DATing the set on Dumpcast (since the set would probably need updates and bugfixes) but there were some big cons to doing this:

- I already have the entire scene, redump, trurip, and tosec sets stored on my fileserver, I don't need to store and update yet another damn set...
- I would really hate for yet another set to be floating around, people already ask for GDIs, CDIs, and SDISOs as Dreamcast standards, we don't need another...
- I am not really a fan of shrinking the games (using truncated files) because it can create problems and 400GB SD cards that hold everything are only $55 now, so this is a lot of headache for people to save $20 and put the fullset on a 256gb card instead of a 400gb, esp when memory costs will only continue to drop in price where soon this isn't even remotely a concern. So I would personally desire for my own use yet another set of DC images that aren't shrunken but have new 0GDTEX.PVR images

So, IMO, there might be better ways to accomplish this because I agree the ODE UI experience on Dreamcast is lacking (I want something that looks more professional and "official" for my frontend... I have been working on some themes for my DC, like this one below that I use on my black Dreamcast:



That being said... injecting new 0GDTEX.PVR files in GDIs should not be difficult to automate so that people can just apply the textures to their images. A theoretical utility can just look up the 0GDTEX.PVR entry in the filesystem and replace the LBA with the earliest possible useable LBA in the dummy data area of track03 and then plop the 0GDTEX.PVR data in that area. gdishrink's sanity check should prevent it from being stripped out and it won't modify or move around any of the existing game data in a way that would set off copy protection.
For the games that don't have a 0GDTEX.PVR at all though, it would have to insert a new file record
A new version (or outright replacement) for GDEMU SD Card Maker could be created with options to insert artwork from packs (so different region artwork could be used based on user preference) in addition to shrinking or bin2iso'ing GDI files as they are transferred. It could even support theming the GDMenu entirely

But also, yet again, I think there's an even better way to accomplish this, and that is to support and help @neo on his OpenMenu replacement for GDMenu, which if done right could natively support all of the above features without hackery plus include stuff like a patching engine for cheats, widescreen/60hz fixes, etc...

 

[FamilyGuy]

I've thought about doing so in the past and DATing the set on Dumpcast (since the set would probably need updates and bugfixes) but there were some big cons to doing this:

- I already have the entire scene, redump, trurip, and tosec sets stored on my fileserver, I don't need to store and update yet another damn set...
- I would really hate for yet another set to be floating around, people already ask for GDIs, CDIs, and SDISOs as Dreamcast standards, we don't need another...
- I am not really a fan of shrinking the games (using truncated files) because it can create problems and 400GB SD cards that hold everything are only $55 now, so this is a lot of headache for people to save $20 and put the fullset on a 256gb card instead of a 400gb, esp when memory costs will only continue to drop in price where soon this isn't even remotely a concern. So I would personally desire for my own use yet another set of DC images that aren't shrunken but have new 0GDTEX.PVR images

So, IMO, there might be better ways to accomplish this because I agree the ODE UI experience on Dreamcast is lacking (I want something that looks more professional and "official" for my frontend... I have been working on some themes for my DC, like this one below that I use on my black Dreamcast:

View attachment 5402

That being said... injecting new 0GDTEX.PVR files in GDIs should not be difficult to automate so that people can just apply the textures to their images. A theoretical utility can just look up the 0GDTEX.PVR entry in the filesystem and replace the LBA with the earliest possible useable LBA in the dummy data area of track03 and then plop the 0GDTEX.PVR data in that area. gdishrink's sanity check should prevent it from being stripped out and it won't modify or move around any of the existing game data in a way that would set off copy protection.
For the games that don't have a 0GDTEX.PVR at all though, it would have to insert a new file record
A new version (or outright replacement) for GDEMU SD Card Maker could be created with options to insert artwork from packs (so different region artwork could be used based on user preference) in addition to shrinking or bin2iso'ing GDI files as they are transferred. It could even support theming the GDMenu entirely

But also, yet again, I think there's an even better way to accomplish this, and that is to support and help @neo on his OpenMenu replacement for GDMenu, which if done right could natively support all of the above features without hackery plus include stuff like a patching engine for cheats, widescreen/60hz fixes, etc...

When I get some free time (in probably well over six months, so don't hold your breath anyone) I plan on investigating what makes gdishrinked images not work with gdemu and fix it. There's a reason why I don't make it convenient yet to shrink images; it's still experimental and comes with no warranty or support for the foreseen future.

I think in the end, what I should do is to add a "strip" and "dress" function in GDITools to respectively remove or add EDC/ECC. I experimented with lidedc in the past and I should be able to make some python bindings relatively easily.

On the GDIShrink side, I think the final design should be reversible. I plan on not removing the content of the low density area and the new sanity check should make it 100% reversible, worst-case I can generate a small json file to add some infos for the "GDIExpand" function. A GDIShrink—GDIExpand loop should leave checksums unchanged.

I could also add a GDITools option to patch/replace a file in a "stripped" GDI, as long as the final file has the same size as the original. It'd be a pain to mess with the files record safely in general, but I could maybe add an option to add a file in the padding area. Although it might not be a good investment in terms of effort/usefulness if there's a more flexible menu on the way.


In the end, I would like to provide a utility to add to the tosec package that'd allow users to patch and shrink/strip/dress/expand their GDI dumps. Would that sound good @darcagn?

Main missing resource right now is time.

 

[darcagn]

When I get some free time (in probably well over six months, so don't hold your breath anyone) I plan on investigating what makes gdishrinked images not work with gdemu and fix it. There's a reason why I don't make it convenient yet to shrink images; it's still experimental and comes with no warranty or support for the foreseen future.

I think in the end, what I should do is to add a "strip" and "dress" function in GDITools to respectively remove or add EDC/ECC. I experimented with lidedc in the past and I should be able to make some python bindings relatively easily.

On the GDIShrink side, I think the final design should be reversible. I plan on not removing the content of the low density area and the new sanity check should make it 100% reversible, worst-case I can generate a small json file to add some infos for the "GDIExpand" function. A GDIShrink—GDIExpand loop should leave checksums unchanged.

I could also add a GDITools option to patch/replace a file in a "stripped" GDI, as long as the final file has the same size as the original. It'd be a pain to mess with the files record safely in general, but I could maybe add an option to add a file in the padding area. Although it might not be a good investment in terms of effort/usefulness if there's a more flexible menu on the way.


In the end, I would like to provide a utility to add to the tosec package that'd allow users to patch and shrink/strip/dress/expand their GDI dumps. Would that sound good @darcagn?

Main missing resource right now is time.

I think that would be fantastic functionality!

As for the "more flexible menu on the way," well, it kinda is, problem is that @neo has other projects and I don't think he's actively dedicating any time to OpenMenu at the moment. So I definitely don't want to discourage anyone (not necessarily you, I understand you might not have the time) from making a solution for the menu we already have.

 

[megavolt85]

The only one of all of those that crashes for me upon highlight is Sega Worldwide Soccer Euro Edition.

i'm check Sega Worldwide Soccer 2000 - Euro Edition v1.030 (2000)(Sega)(PAL)(M4) TOSEC
this image don't contain 0GDTEX
Which version of the game are you using?

 

[darcagn]

i'm check Sega Worldwide Soccer 2000 - Euro Edition v1.030 (2000)(Sega)(PAL)(M4) TOSEC
this image don't contain 0GDTEX
Which version of the game are you using?

Sorry, you are correct. I checked and it is Sega Worldwide Soccer 2000, not Sega Worldwide Soccer 2000 Euro Edition.
On that GD-ROM, 0GDTEX.PVR is 128x128 while all other GD-ROMs are 256x256 as far as I am aware.
GDMenu will hang if that game is highlighted

 

[sonik]

- I am not really a fan of shrinking the games (using truncated files) because it can create problems and 400GB SD cards that hold everything are only $55 now...

It's not cheap on every part of the world ;-)
Where I live anything larger than 64GB costs a fortune. Shrinking the data is the way to go!

A theoretical utility can just look up the 0GDTEX.PVR entry in the filesystem and replace the LBA with the earliest possible useable LBA in the dummy data area of track03 and then plop the 0GDTEX.PVR data in that area. gdishrink's sanity check should prevent it from being stripped out and it won't modify or move around any of the existing game data in a way that would set off copy protection.
For the games that don't have a 0GDTEX.PVR at all though, it would have to insert a new file record

I was thinking about that functionality. Inserting the texture file in the padding area or even appending it at the end of the disc (don't know if would work).
@FamilyGuy the file table have fixed size? would be possible to add a new file to the table and append the file to the end of the iso image without having to rewrite the entire iso?

 

[FamilyGuy]

@FamilyGuy the file table have fixed size? would be possible to add a new file to the table and append the file to the end of the iso image without having to rewrite the entire iso?

It doesn't have a fixed size, but it can really be a pain to add a file to it in some cases. ISO9660 wasn't designed with edition in mind at all.

1. To patch a file with another one of the same size should be relatively easy.
2. To replace it with a smaller one shouldn't be too complicated.
3. To replace it with a larger one would require some annoying planning of the location of the new file. I'm not sure we could append it after 122m, we'd have to find some blank space to put it.
4. To add a completely new file is a PITA, some corner cases in the TOC or an issue with folders and subfolders and it gets tangled and buggy quickly. At that point it's almost easier to rebuild the whole TOC rather than patch it for your file. Which is a real PITA.

I could add 1 to GDItools without too much problem.
For 2 and 3, to do it manually is easier than to automate it for now.
The 4th case is also easier by hand, unless you're not lucky with available room in the image, headspace for the TOC or subfolder record alignment.

These operations should only be done on 2048bytes/sector (.iso) files, as rebuilding EDC\ECC isn't straightforward and frankly not at all important aside from comparing with TOSEC dat files or preservation. I still plan on implementing EDC/ECC rebuilding for a proper "GDIDress" function, but it's for the far future. I might do it using lidedc, or study Galois fields a little and do it in pure python for better portability.

 

[cta]

I for one am hoping we'll eventually get an alternative menu implementation, where you can simply put a pvr file alongside the disc image instead of having to deal with all the injecting bs. But maybe that's just me.

 

[FamilyGuy]

I for one am hoping we'll eventually get an alternative menu implementation, where you can simply put a pvr file alongside the disc image instead of having to deal with all the injecting bs. But maybe that's just me.

That's highly unlikely as the Menu Software is basically only a game with custom commands to control the GDEMU in a very basic way, like swapping GD-Rom or returning firmware version. It can't read the GDEMU SD-Card, unless that feature is added to GDEMU in the future (unlikely).

What IS possible, but would require someone with the time/inclination to implement it, is to make a menu software with baked in disc images/cover-art. When building the list you'd also put the media files in the Menu's CDI/GDI file and use those for the menu.

 

[Greg2600]

I'm simply hoping somebody comes up with a new device so I can get rid of GDEMU and USB-GD. They're both way too much trouble.

 

[darcagn]

I unfortunately don't see that happening anytime soon, Chinese cloners are pumping these things out so cheaply that I don't see any profit to be made trying to compete with them. The clones work well enough. I could see maybe a DIY project, as some people already have dabbled in writing code for an alternative, but I don't see anyone investing the money to manufacture them

 

[sonik]

@Greg2600 what's the problem with gdemu/usb-gd?

 

[psydefx]

I'm simply hoping somebody comes up with a new device so I can get rid of GDEMU and USB-GD. They're both way too much trouble.

what? for usb-gdrom just put tosec isos on a usb and thats it. no trouble at all

 

[megavolt85]

I checked and it is Sega Worldwide Soccer 2000

enjoy

MEGA

MEGA provides free cloud storage with convenient and powerful always-on privacy. Claim your free 20GB now

mega.nz

 

[Greg2600]

what? for usb-gdrom just put tosec isos on a usb and thats it. no trouble at all

The menu is horrible, can't stand using it.

 

[cta]

First world problems... How much time do you spend in the menu versus in-game?

I get where you're coming from tho, for me it's the RetroArch menu "system".