1 (edited by diego-rbb-93 2018-05-19 11:28:32)

Topic: [Note] About our DC dumps functionality

As ive been talking recently with JHMiller, our DC dumps made by Redump method are totally functional over Inolen's Redream emulator.

I decided to bring this up as this emulator will probably take the lead officialy over DC emulation in the next months, as soon as some fixes over sound and MMU emulation are done (beyond the specific issues that you can always find like visual glitches). A port for Android is coming to and the emulator is working flawlessly for the moment (beyond the open/closed source debate...). Setting it up is really easy and confortable to use for the moment.

Im not trying to sell the emulator, but is fair to recognise that is becoming finally a serious contender and im sure lot of us are tired seeing how NullDC, Reicast, Demul, Chankast... Never managed to master a confortable DC emulation or provide a non-extremly-slow development road.

TOSEC 2 Redump is a wonderful tool that still matter a lot, but in case there's still some problems with the format conversion, i advice you go and use Redream for testing.

Ive been talking with Inolen and he told me he already supported our dumps, specially because it seems our method allowed the "ip.bin" of the game to be dumped. This contains info that Redream preject used for building the Art DB (instead of using hashes to attach image art when displaying the game info over the UI, is searches the Ip.bin). Nobody has complained about them for the moment, so it seems Redream manages the GDI+Bin format with no problem for the moment.

As i said, i know lot of people were upset about seeing the emulator becoming closed source, but i respect Inolen's view of this and... He's delivering. tongue

Re: [Note] About our DC dumps functionality

I still insist on switching to 2xcues+bins smile

3 (edited by diego-rbb-93 2018-05-23 21:26:03)

Re: [Note] About our DC dumps functionality

F1ReB4LL wrote:

I still insist on switching to 2xcues+bins smile

Thats a question that the DC dumpers and the rest of the gang with enough technical skills to understand the process should talk on your side. xD

We already are in the way to have the DC EUR Fullset done before the summer ends if everything goes ok (except some Revisional country revisions that will still be missing).

Soon, only USA will be needing a push over DC, so if you still want to talk about the format, it isnt a bad time to do it.

Re: [Note] About our DC dumps functionality

diego-rbb-93 wrote:

As ive been talking recently with JHMiller, our DC dumps made by Redump method are totally functional over Inolen's Redream emulator.

I've just checked its Windows build and I couldn't get any CDDA sound of it, so I'm not sure if it's truly supports Redump-style gdis. Also it crashes every time you try to close it and doesn't seem to support the controllers. Maybe the Android build is better, but clearly not the Windows one.

diego-rbb-93 wrote:
F1ReB4LL wrote:

I still insist on switching to 2xcues+bins smile

Thats a question that the DC dumpers and the rest of the gang with enough technical skills to understand the process should talk on your side. xD

The process and tracks will be the same, just the db should generate cues instead of broken gdis.

5 (edited by diego-rbb-93 2018-05-31 08:41:09)

Re: [Note] About our DC dumps functionality

F1ReB4LL wrote:

I've just checked its Windows build and I couldn't get any CDDA sound of it, so I'm not sure if it's truly supports Redump-style gdis. Also it crashes every time you try to close it and doesn't seem to support the controllers. Maybe the Android build is better, but clearly not the Windows one.

diego-rbb-93 wrote:
F1ReB4LL wrote:

I still insist on switching to 2xcues+bins smile

Thats a question that the DC dumpers and the rest of the gang with enough technical skills to understand the process should talk on your side. xD

The process and tracks will be the same, just the db should generate cues instead of broken gdis.

Thats strange, he actually fixed the CDDA problem recently. The UI got recently a total upgrade, specially on the Controller customisation.  Are you sure you are using the last build?

Redream still needs some polishing over the next months and Inolen is right now totally focus on the Android version.

But, if you think something is wrong i would advise you to report. Their Discord/Gitlab place works great for asking/reporting.

Re: [Note] About our DC dumps functionality

should anyone know how to actually use the quickbms tool, here's a .bms script in which you can use with that exact tool

open FDDE "gdi"

get GDI_BNAME basename

get tracks line
xmath last_track "tracks - 1"
math track_last_size = 0

log MEMORY_FILE10 0 0
for i = 0 < tracks
    get track_info line
    string track_elements S track_info track_number track_offset track_filetype track_blocknumber track_filename track_unknown
    
    string cue_struct01 p "FILE"
    string cue_struct02 p "BINARY"
    string cue_struct03 p "TRACK"
    string cue_struct04 p "%02d" track_number
    string cue_struct05 p "MODE1/2352"
    string cue_struct06 p "AUDIO"
    string cue_struct07 p "INDEX"
    
    putct cue_struct01 string -1 MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    put 0x22 byte MEMORY_FILE10
    putct track_filename string -1 MEMORY_FILE10
    put 0x22 byte MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    putct cue_struct02 string -1 MEMORY_FILE10
    put 0x0d byte MEMORY_FILE10
    put 0x0a byte MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    putct cue_struct03 string -1 MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    putct cue_struct04 string -1 MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    if track_filetype == 0
        putct cue_struct06 string -1 MEMORY_FILE10
    elif track_filetype == 4
        putct cue_struct05 string -1 MEMORY_FILE10
    endif
    put 0x0d byte MEMORY_FILE10
    put 0x0a byte MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    put 0x20 byte MEMORY_FILE10
    if track_filetype == 0
        putct cue_struct07 string -1 MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        putct "00" string -1 MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        putct "00:00:00" string -1 MEMORY_FILE10
        put 0x0d byte MEMORY_FILE10
        put 0x0a byte MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        putct cue_struct07 string -1 MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        putct "01" string -1 MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        putct "00:02:00" string -1 MEMORY_FILE10
    elif track_filetype == 4
        /*
        if last_track == i
            putct cue_struct07 string -1 MEMORY_FILE10
            put 0x20 byte MEMORY_FILE10
            putct "01" string -1 MEMORY_FILE10
            put 0x20 byte MEMORY_FILE10
            putct "00:01:00" string -1 MEMORY_FILE10
        else
            putct cue_struct07 string -1 MEMORY_FILE10
            put 0x20 byte MEMORY_FILE10
            putct "01" string -1 MEMORY_FILE10
            put 0x20 byte MEMORY_FILE10
            putct "00:00:00" string -1 MEMORY_FILE10
        endif
        */
        putct cue_struct07 string -1 MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        putct "01" string -1 MEMORY_FILE10
        put 0x20 byte MEMORY_FILE10
        putct "00:00:00" string -1 MEMORY_FILE10
        #putct "00:01:00" string -1 MEMORY_FILE10 # <- you can try this one too
    endif
    put 0x0d byte MEMORY_FILE10
    put 0x0a byte MEMORY_FILE10
next i

get CUE_FSIZE asize MEMORY_FILE10
string CUE_FNAME p "%s.cue" GDI_BNAME
log CUE_FNAME 0 CUE_FSIZE MEMORY_FILE10

simply put, it converts a single .gdi file into the simplified .cue format in case no one is happy with the obtuse .gdi format at all