Converting cdi images to GDI for use in reicast for Android

Since reicast cannot read cdi images right now, is there a way to convert cdi image games (a few I can only find as a cdi image) and convert them to GDI? (Then in turn I convert them to CHD which reduces the file size sometimes drastically)

 

I have done this but it is a long drawn out process. If I can find it on my pastebin account I will post it. It is basically reversing all the hacks done and recalculating the lba and so forth.

 

It's completely doable, but really not worth the hassle. Get a GDI instead.

If you still wanna do it: you'd have to extract all the data, find which executable have been hacked, unhack them back to LBA 45000 and undo non-lba hacks, put back an untouched ip.bin, then rebuild the iso as a multisession session one starting LBA45000 and name it track3 and create a matching .gdi file.

It'd be even more complex for cdda games.

 

Sorry to bump a 6 month thread but its on topic.

I would like to convert CDI to GDI

The device im using has no support for CDI only GDI. I would love to test some homebrew apps and games with it but must convert it to GDI

@Razel did you find your paste bin steps?
@FamilyGuy care to share some more info? most of what im testing is homebrew but there are 11 games that are also CDI i would like to waste space as GDI

 

You'd have to reverse any ahck that was done to the binaries, mainly finding "CD001", rewinding 8 bytes and writing 6EB0 0000 there, for the rest I can't help as it's on a per-game basis.

Then you have to rebuild the gdi, which is kinda complex manually but sapharad made a tool for that recently. For homebrew, only sapharad tool might be required.

FG

 

Thanks for the tips i was lost in many tools to like your kit and was not sure what was need to unhack everything. ill give homebrew a spin since that's only thing missing. Some originals are cdi only so might pass info of how i got it working to another who owns those games.

And the prosess haults at track 3 guess most homebrew has no use for track 3

 

Most homebrew will ONLY require track03. IIUC, using sapharads tool with homebrew would be straightforward, as long as they work on non-mil-cd format (idk if homebrew are designed for that).

My pack is designed for the exact opposite, GDI -> CDI. Doing that looses informations so it's not straightforward to reverse the operation, especially if non-standard hacks were applied.

 

seems first go was a mistake of sorts

im shooting in the dark but the app did create track03.bin and size seems correct it was saying would modify disk.gdi with info i in folder but no luck on that

made a .gdi in note++

1
1 45000 4 2352 track03.bin 0

in GDI explorer app gives the boot sector has no valid TOC

and the hunt continues

 

You still need a ip.bin? And I guess you'd have to descramble the homebrew. Homebrews are made to be loaded from cd-r (mil-cd) with a homebrew-only bootsector (ip.bin, or initial program). They are normally scrambled, now you're booting them like a gd-rom, which mean they won't get descrambled and so you should do it yourself. Also you have to use a standard ip.bin, not one made for homebrew, as those are made for programs booting from a mil-cd. It isn't so easy after all.

Good luck!

FG

 

ah ok i get it now let me rip a ip.bin from original.

Descramble the homebrew would guess modifying the hex of 1st run.bin from homebrew with the string in prior post

will keep at this all info helps

trying wow 80's mame works cdi not sure it helps

 

You can't have a 1 track GDI, that's not valid and a real system wouldn't accept it. Every GD-ROM has at least 3 tracks. GDI Builder won't update a .gdi file for you unless it already exists and the high density data starts on track03 like it's supposed to. Just copy track01 and 02 and the .gdi from any existing GDI rip you have, it shouldn't matter what's in those. Then GDIBuilder will update the line for track03.bin for you once it generates that file. If the line for track 3 doesn't exist in the GDI, the tool has nothing to update. GD-ROM explorer isn't opening your image because it's also looking for the DC data on track 3.

What you're trying to do probably won't work anyway. Most homebrew is built with KOS, which intentionally won't read from GD-ROM's. If you try something that doesn't need to read from a disc (as in, 1ST_READ.BIN is the only file and nothing else) that will probably work if the IP.BIN is correct and 1ST_READ is not scrambled.

 

thanks for the info on the missing tacks was not sure how to generate them from an existing cdi.

 

well now i get a get a boot loop after the sega logo so seems the correct structure with three tracks has it booting correctly. I did check the clean ip.bin and the 1st_read is correct.
I think ill try and find a homebrew with just one bin to help make this testing simpler as this one has 1st read and boot.bin not sure where my error is yet but a single bin homebrew should help get it sorted.

Thank you all for input, it helps guide my path