Welcome, Guest!

Here are some external resources you may find helpful

Dreamcast GDEMU info

sonik

Registered
Registered
Joined
Jul 24, 2019
Messages
28
Reaction score
17
Points
3
AG User Name
sonik
AG Join Date
Mar 15, 2004
Yes it fixed some games.
I will have to test the others that still crash and take note of the exact problem.
 

darcagn

Registered
Registered
Joined
May 30, 2019
Messages
144
Reaction score
182
Points
43
Location
Louisiana
Website
dcemulation.org
AG User Name
darcagn
AG Join Date
May 12, 2007
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
 
Last edited:

Anthony817

Registered
Registered
Joined
Jun 2, 2019
Messages
310
Reaction score
410
Points
63
AG Join Date
May 12, 2010
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

2049 Donator
2020 Donator
2019 Donator
Registered
Joined
May 31, 2019
Messages
304
Reaction score
304
Points
63
AG User Name
-=FamilyGuy=-
AG Join Date
March 3, 2007
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.
 
Last edited:

darcagn

Registered
Registered
Joined
May 30, 2019
Messages
144
Reaction score
182
Points
43
Location
Louisiana
Website
dcemulation.org
AG User Name
darcagn
AG Join Date
May 12, 2007
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:

Annotation 2020-02-01 152707.png

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

2049 Donator
2020 Donator
2019 Donator
Registered
Joined
May 31, 2019
Messages
304
Reaction score
304
Points
63
AG User Name
-=FamilyGuy=-
AG Join Date
March 3, 2007
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.
 
Last edited:

darcagn

Registered
Registered
Joined
May 30, 2019
Messages
144
Reaction score
182
Points
43
Location
Louisiana
Website
dcemulation.org
AG User Name
darcagn
AG Join Date
May 12, 2007
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

DreamShell Developer
Registered
Joined
Jun 17, 2019
Messages
166
Reaction score
470
Points
63
Location
Russia
Website
www.dc-swat.ru
AG User Name
megavolt85
AG Join Date
01.09.2015
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

Registered
Registered
Joined
May 30, 2019
Messages
144
Reaction score
182
Points
43
Location
Louisiana
Website
dcemulation.org
AG User Name
darcagn
AG Join Date
May 12, 2007
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

Registered
Registered
Joined
Jul 24, 2019
Messages
28
Reaction score
17
Points
3
AG User Name
sonik
AG Join Date
Mar 15, 2004
- 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

2049 Donator
2020 Donator
2019 Donator
Registered
Joined
May 31, 2019
Messages
304
Reaction score
304
Points
63
AG User Name
-=FamilyGuy=-
AG Join Date
March 3, 2007
@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.
 
Last edited:

cta

Registered
Registered
Joined
Jun 7, 2019
Messages
185
Reaction score
85
Points
28
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

2049 Donator
2020 Donator
2019 Donator
Registered
Joined
May 31, 2019
Messages
304
Reaction score
304
Points
63
AG User Name
-=FamilyGuy=-
AG Join Date
March 3, 2007
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.
 
Last edited:

Greg2600

Registered
Registered
Joined
Jun 3, 2019
Messages
153
Reaction score
160
Points
43
AG User Name
Greg2600
AG Join Date
Jun 23, 2010
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

Registered
Registered
Joined
May 30, 2019
Messages
144
Reaction score
182
Points
43
Location
Louisiana
Website
dcemulation.org
AG User Name
darcagn
AG Join Date
May 12, 2007
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

Registered
Registered
Joined
Jul 24, 2019
Messages
28
Reaction score
17
Points
3
AG User Name
sonik
AG Join Date
Mar 15, 2004
@Greg2600 what's the problem with gdemu/usb-gd?
 

psydefx

Registered
Registered
Joined
Jul 6, 2019
Messages
61
Reaction score
19
Points
8
AG User Name
psydefx
AG Join Date
March 27, 2016
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
 

Greg2600

Registered
Registered
Joined
Jun 3, 2019
Messages
153
Reaction score
160
Points
43
AG User Name
Greg2600
AG Join Date
Jun 23, 2010
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

Registered
Registered
Joined
Jun 7, 2019
Messages
185
Reaction score
85
Points
28
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".
 
Top