GDIBuilder - Tool for building GDI data tracks

I think he meant some files are missing, maybe corrupted.

Thanks for the bios I will flash it soon!

FG

 

You don't.

If the game was originally a GDI and got converted to CDI for self boot purposes, you can probably do it but there's no definitive guide. Track01 and Track02 and a corresponding .gdi can be borrowed from an existing valid GDI, they don't matter for booting on the DC. If it's homebrew or unofficial, you're out of luck because there's a 95% chance it won't work unless the software doesn't load any data from disc. As suggested previously, this is mostly useful for making modifications to existing games.

Short list of advice:
- If 1ST_READ.BIN is scrambled, unscramble it.
- Use a clean IP.BIN that works with the game you're trying to build. (Newer CDI images might contain IP.BIN designed for unscrambled 1ST_READ.BIN, you won't want this logic for a GDI because GD-ROM's are not scrambled.)

I suppose at some point I could add functionality to generate tracks 1 and 2, but this part is not complicated and doesn't require custom tools to accomplish. The tool exists for track03 and above, since the file position stuff is complicated to manage by hand.

 

JUST is the extraction ok but the file content wrong......

1. ISO_Make_pack\\HB05A002.PMC
2. GD-ROM Explorer\\HB05A002.PMC


0x80000: 6E 00
0x80001: 79 FF
0x80002: 75 FF
0x80003: 79 FF
0x80004: 7A FF
0x80005: 92 FF
0x80006: 86 FF
..................
0x8016F: 4D 00
0x80174: 50 00
0x80175: 4F 00
0x80176: 46 00
0x80177: 30 00


206 difference is found.

I upload two files：

https://mega.co.nz/#!rZ8STDZY!w7tpVm4ZRcaXOOKNWLChhEgSHtC9nQq-2B3L1NjS8kQ

 

Hi all!

First, I would like to thank S4pph4rad for making this tool, as I had no idea about the 1ST_READ.BIN LBA restriction and probably never would have figured out how to boot a modified track03 on my own.

I seem to have found a few quirks that I wanted to ask about. Firstly, at least as far as GDEMU is concerned, it doesn't seem possible to boot a track03.bin with a sector size of 2048. If I try, the DC asks me to insert a disc. I have to name the file track03.iso and change the name in the GDI, and then it boots.

Secondly, does your -raw mode actually generate EDC for the extra bytes in each sector, or do you just pad with zeroes? I tried compiling the same image in 2352 mode, but it doesn't boot in GDEMU; instead, the DC asks me to insert a disc. An original GDI with track03.bin in 2352 mode works fine, so I'm not sure what's wrong.

 

AFAIK, it works fine with gdemu. Just make sure to change also the sector size from 2342 to 2048 for the track03.ISO in the GDI file.

 

Idk how deunan coded gdemu, but maybe he simply checks the blocksize via the file extension. This would explain your issue.

 

I did. That's the strange thing.

3 45000 4 2048 track03.iso 0

works

3 45000 4 2048 track03.bin 0

asks me to insert a game disc when using the same track03. The only difference is the extension. FamilyGuy is probably right, in that GDEMU may only check the extension to determine the sector size as a firmware simplification measure. My inability to load a track03.bin built with GDIBuilder and a sector size of 2352 is still baffling me, though.

 

Insert "Works on my machine" emblem here. Both 2048 mode and 2532 modes work for me on my GDEMU unit, with the latest firmware. I've rebuilt several games without issues, and the track extensions are .bin since that's what I got when I dumped my games with httpd-ack.

The raw 2532 mode does generate valid EDC/ECC data.

My suggestion would be to try the .gdi in an emulator. Every game I rebuilt had identical behavior in NullDC as it did on hardware. If it didn't work on nullDc, it didn't work on hardware. If it did boot on nullDC, it did boot on hardware. If it works in an emulator and not on GDEMU, something could be wrong with your SD card, the way you copied the files, or maybe your OS put some hidden files on the drive that GDEMU doesn't like.

For example, any time I build a GDI on OSX I won't use OS X to copy the files to my SD card, because OS X will litter the card with hidden files that GDEMU doesn't like. I'll use a Windows virtual machine to do it. (You shouldn't have issues with Linux littering though)

 

@-=FamilyGuy=-

i test gditools There is no problem

There is an opinion, sorttxt.txt file with the number can not be set?


For example
Data/1ST_READ.BIN 1
Data/ABSTRACT.TXT 2
.........................



Can be set to


Data/1ST_READ.BIN 2000
Data/ABSTRACT.TXT 2001
...................................

 

There's no option for it, but I could tell you what to change to add it.

Why do you want to do this?

 

In my experience it can be helpful to number the files with huge numbers so that if you decide to tweak the order of a few files later on you can change the order without having to renumber the entire list. I prefer to just keep separate order files and sort files, though. If I want to change the order, I alter the order file, renumber it, then overwrite the sort file.

 

Because the original sort array are not optimized, sometimes need to change it, for example this is the MSR

 

I just added the option!

Get it on sourceforge: https://sourceforge.net/projects/dcisotools/
Or directly: http://sourceforge.net/projects/dcisotools/files/gditools-20150529.zip/download

The command-line option is --sort-spacer [num]
Each number of the sorttxt will be multiplied by the provided number.

e.g.

Data/1ST_READ.BIN 1
Data/ABSTRACT.TXT 2

With "--sort-spacer 10" become:

Data/1ST_READ.BIN 10
Data/ABSTRACT.TXT 20

So you can change easily the priority of the files manually!

Cheers!

FG

 

THANK YOU VERY MUCH!