cim2gdi Tool

Hello, everyone. I created a tool to convert CIM files to the GDI format for use with emulators and the DC2CD tool. This may be useful if any HDC files are discovered on a development kit (or CIM files on a development PC), which could be converted to a CIM file via the CIM Utility.

Download cim2gdi from ftp://213.138.103.149/cim2gdi.tar.xz (using ftp:// links seems to be broken).
GitHub repository.
CIM File Format explanation.

Please note that this will only work with 3-track CIM files at the moment (2 SDA, 1 HDA) and it will only work on Windows as it's what I'm running with the Katana SDK. I will be adding more functionality later, though I believe it to be good enough to use for the time being. I hope this tool will be useful to the Dreamcast development community.

 

Nice! Do you have documentation on the cim format? I could add support for it in gditools!

 

I can put what I've found on the GitHub wiki for the project. There are a few things I haven't figured out yet (such as what I'm presuming are flags for each area) though I'm working on it. I'll update the first post with a link to the CIM format.

For now, I have added comments in the code, the CIM.hpp/cpp files contain everything from a basic implementation standpoint.

 

Thanks, I'll have to look into that! Great work again!

 

Just added the wiki document. If there any points which need clarifying, I'll do my best to make it crystal.

 

Very cool, nice work.

 

I've made several corrections, so now it works fine with >3 track images. you cant review / pull changes there
https://github.com/p1pkin/cim2gdi

 

This is truly bizarre (and fortunate). I started working on supporting GNU/Linux, getting the memory usage down, and getting 5+-track CIM files working last night.

Looking at your changes, I was really wrong about the way tracks worked. I thought the pre-/post-gap was per session. I also thought that, having looked at other GDI rips, tracks had to be 2352. Thanks for correcting those among the other mistakes I made.

Would you be able to create a pull request on my repository?

 

sure.
note: my current code does one by one sector read/write, so it may become slower (however not notable on my PC)

add: as far as I know GD-ROMs actually have no "sessions", i.e. LD Lead-In TOC doesn't have pointers to HD area TOC.
so GD is somewhat 2 separate disks, one starting from 00:00:00 and another starting from 10:00:00

 

I'd be interested in linux support.
I was toying with the idea of implementing it in python or add support for it in gditools, but I have no real time for this.

 

That's fine, it wasn't much slower on my machine either. I was being incredibly lazy with it in terms of optimisation.

I'm looking at getting it done by the weekend, as I want to run it natively on my build server rather than rely on WINE to run it. Time is always the enemy of personal projects =P.