"Let's make GD ROM emulation happen" Facebook group.

My tools are all compatible with 64bits. See my signature.

 

I can't seem to see anyone's signature :<

 

It seems it was not showing by default somehow. I fixed it. You still got to ensure your settings are set to show them if you wanna see them. Otherwise it's in the profile of each user. Here are the pertinent links in any case:

My SelfBootDATA pack for 45000 data/data backup 32bit edition: http://bit.ly/RymfFG
My gditools.py program/library to extract GDI files: http://bit.ly/1zFyRpT
Binhack32/64 with complete sourcecode: http://bit.ly/1wraPaI

 

Well, so far I've used the tools to convert Namco Museum, and Crazy Taxi 1 and 2 to nice tiny .CDI's with nothing ripped or downsampled. This is a dream come true! I'll be working on ripping all my discs now

 

Well I should be working on a script to shrink GDIs soon, it should have perfect compatibility as long as GDEMU doesn't care that there's a "hole" in the dump. I believe it won't be a problem as long as no data is accessed in that region (e.g. don't try to dump a mounted gdi to serial-sd-card).

 

Very interesting projects guys, I'd love to save some space on my SD card from full fat GDIs. Thanks in advance

 

Your tools are amazing!

 

I don't think you're going to have luck, unfortunately. I just tried it myself. Tried a fresh card with no images except 01, the DC doesn't even detect a disk as being inserted. image_tests is set to 0, so maybe those tests only apply to CDI? I took a working card with 19 other images and added a shrunk GDI as 20. Switching to that disc via the button just acts like no disc is inserted. If I hit the button again, it goes back to 01. So GDEMU attempts to use the disc, but doesn't want to. The exact same shrunk GDI does boot in NullDC, so I think GDEMU is being the bad guy here since the DC doesn't even see Track 2 in the Music player.

I'm guessing we'll need a firmware update.

(I added an additional argument to GDIBuilder for the purpose of trying this, I'll include it in the next release if it's actually possible to make it work. It just omits padding from the generated image and creates 2 data tracks without CDDA between them.)

 

So you say for a 5+tracks game, if you remove padding on track03 it doesn't work? That's bad then. We can still rebuild the gdi completely but it's more complicated! This could totally work with a firmware revision, as there's no good reason for those unused bytes to actually ever be accessed. Deunan probably made checks for the image integrity, which is a problem for us as we're trying to stretch the format.

My preliminary code to shrink 5+tracks gdi works well (in under 40 lines!). But I can't test them for now. Code for 3 tracks will be more complicated as parsing the gdi is needed, but it shouldn't be too hard. I'll just have to test a bit more.

@Nukkus, you're welcome!

 

I didn't actually test a 5 track game. I took the SA2 Demo, and rebuilt it as data+data with track03 containing the TOC and no padding at the end, and track04 containing the files in the correct locations. NullDC boots it fine, but GDEMU doesn't even tell the DC a disc is inserted.

 

Try adding a track04.raw that's only 300 blank extents.

Make sure the .gdi is consistent too, although if it works on nullDC it mean it should be.

Also, maybe gdemu or the dc/gd-rom firmware checks for the TOC in the bootsector, we could edit that easily.

 

Try disabling the disc integrity check in GDEMUs ini file.

 

If I am not mistaken, although there is the level limit for the directory records (up to level 8, and the counting starts from 1 for the root dr) it seems that there is no directory record limit a folder can contain, except maybe the disc size. So yeah you don't have many choices here: either browsing the entries till the end or using an empiric value. For the latter, iirc, 300 sectors should be enough (so 300x2048 bytes for ISO or 300x2352 for mode 1 track). That is what echelon used to do for data/data images.

 

So far I'm at least having awesome results with the gdi2data +selfboot pack. Only games I've had problems with are ones with masses of cdda, pal or japanese games, or anything over 700mb. So far I have 50 GDI's downsized to 24gb of tested and working .CDI's with nothing downsampled or ripped. Makes me extremely happy, as I still have all the rest of the space on my 64gb card for the ones I can't optimize. All my faves fit now.

 

I already coded an adaptative step reverse search for last empty sector. So no need for that. Thanks for the idea though. Edit: In fact, I might do something like this in the end, as a fast mode for people with HDDs, to reduce seeking!

My pack doesn't support CDDA. So be aware that you won't have in-game music if you're using it on games with used CDDA tracks. Some 5tracks games don't use their track04.raw though so it can be ignored.

 

----

Everything is where it should be, the TOC and the files. If it wasn't, NullDC wouldn't boot it either since it's emulating using the BIOS and flash dump from my actual DC that I'm testing against.

I can upload the image if you want to play around with it yourself. (Or if you'd rather, a beta build of gdibuilder command-line with the new argument allowing you to build a non-padded image with a huge gap in it.) I still think this is being enforced by GDEMU though. I may just send D an email to see what he thinks.

 

By "TOC in bootsector" I meant the one in the ip.bin header. Have you tried inserting a track04?
What about 5+track games, does removing the track03 padding works?

I'll upload a preliminary code to shrink a 5+track gdi later tonight. I won't work on a 3-tracks version until we know if it'd be usable or not.

FG

 

I don't understand your 3 track plan. How do you expect that to work? IP.BIN needs to be at LBA 45000 and 1ST_READ.BIN needs to be after 100 minutes.

So never mind on my previous comments. I have both 4 track (data+data with no CDDA) and 5+ track images working. The problem I ran into yesterday: They don't work unless the image is RAW 2352. If I generate them at 2048, (which is what I was doing yesterday) GDEMU won't boot them. It doesn't matter if there's CDDA in the middle or not. As soon as switched to 2352, which uses additional space, it works. So I have a working GDI of the SA2 demo that is 105MB instead of 1.11GB. I'll post the new version of GDIbuilder with the -truncate argument once I finish testing some more, and adding the option to the GUI version.

 

It's weird that it wouldn't work in ISO format ... The .gdi is correct with .iso files and 2048 blocksize?

My plan for 3tracks is to convert it to 4 tracks like you. 3-trakcs version referred to the input gdi. My approach is to modify the bins/isos directly, not extracting and rebuilding the filesystem. But I have to parse the filesystem to do 3tracks games as I got to figure out where the first file is written so it's a bit more complicated. I have all the tools required for it though, via gditools.

Here's my python code for gdi with more than three tracks: http://pastebin.com/3rie5yHk
Keep in mind it comes with no warranty whatsoever and is a first draft.

It outputs iso files though... I could create a version for bin files if someone wants it. It would be actually much more simple.

FG

EDIT:

Here's a much cleaner python program that unpads a BIN file: http://pastebin.com/GbwbpXBK
The original file is backed up, adding a .bak to its filename. A bak file is never overwritten.

 

The same settings work fine for a full-sized disc, so I don't think I'm doing something wrong.

New version of GDIBuilder (1.2) is also available now, with the truncate option. (For what it's worth I'm not building first then truncating afterward. It generates the image from scratch without the padding. I just called the option truncate since it was easier to understand.) RAW mode is now defaulted to on in the GUI version, since it's the only way the images were working on my GDEMU unit if I enable truncate mode.