What's new
By:

Can Someone School me on Taito G-Net with CF cards?

Hmmm md5 matches on the working one versus the one I'm having so many issues with. The archive of chd files I obtained came with 0.131 (Apr 23 2009) however I have also tried using the latest version of chdman and neither seem to be working properly.
 
The question remains, what is the command you're supplying to chdman for extraction?
 
kuze said:
The question remains, what is the command you're supplying to chdman for extraction?
Click to expand...
for the older one chdman -extract input.chd output.img
for the newer one chdman extracthd -i input.chd -o output.img

dd if=./output.img of=/dev/disk2 bs=1m or use selfimage or the image writing utility
 
try the chdman and bat file in my link above and see if the resultant image works for you.
 
sammargh said:
kuze said:
The question remains, what is the command you're supplying to chdman for extraction?
Click to expand...
for the older one chdman -extract input.chd output.imgfor the newer one chdman extracthd -i input.chd -o output.img

dd if=./output.img of=/dev/disk2 bs=1m or use selfimage or the image writing utility
Click to expand...
Try using extractraw instead
 
  • Like
Reactions: nem
Well the 64MB card I bought came DOA so I guess the hunt is on for compatible cards that aren't $20/pop
 
I'm on a Mac and having troubles extracting the CHD to IMG to burn to the cards. Anyone have any ideas?
 
djsheep said:
I'm on a Mac and having troubles extracting the CHD to IMG to burn to the cards. Anyone have any ideas?
Click to expand...
I'm not familiar Mac options, but I'm pretty sure you're just supposed to write the CHD file to a card?

This is how ArcadeModBios' windows-based "GNETFlasher" program would work--you would just select the CHD and it'd write it to the card.
 
aoiddr said:
I'm pretty sure you're just supposed to write the CHD file to a card
Click to expand...
the chd still need to be extracted to an img file before it can be written. this is the step he's having a problem with.

according to the guide in the 2nd post you'll need to use chdman from mame (presumably a mac compile), the problem is identifying exactly which version of mame needs to be used.
 
If I remember correctly there's a switch in chdman that reads the header from a CHD and lists what version it was compressed with and the disk geometry details.

think its -info or -verify with -verbose

so chdman -i filename -info -verbose should give you the details of the drive/image.
 
I'll have to try that on mine when I get home tonight then we can ID which version of MAME the GNET CHD are based on.
 
With OSX you need to grab a build of Mame built for OSX and inside the archive you will find a file named "chdman"

Move that to where your chd files are located and do the following:

from terminal type "chmod +x chdman"
Insert a compact flash card and launch disk utility
Click the mounted flash card's volume in disk utility and click the unmount button - this is different from ejecting and says unmount specifically
from terminal type "diskutil list" and you will see the compact flash card as something like /dev/disk2s1

Code: 
sambookpro:~ sampson$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Macintosh HD            218.5 GB   disk1s1
   2:                APFS Volume Preboot                 19.2 MB    disk1s2
   3:                APFS Volume Recovery                509.9 MB   disk1s3
   4:                APFS Volume VM                      6.4 GB     disk1s4

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *4.0 GB     disk2
   1:                 DOS_FAT_16 NO NAME                 40.9 MB    disk2s1

sambookpro:~ sampson$
Now with the disk unmounted to write a file you need to type ./chdman and see the output. Depending on the version there's two command formats:
sudo ./chdman extracthd -input file.chd -output /dev/disk2 -f
sudo ./chdman -extract input.chd /dev/disk2 -f

Be very careful with these commands as this will write the chd directly to your compact flash card and if you specify the wrong disk you will clear out the contents of whichever you specified. Once completed eject the compact flash from disk utility and you're good to go.
 
has anybody tried using one of the micro-SD to CF adapters off ebay yet?
 
Thanks for the help ya'll, worked like a charm on OSX 10.10.5 (Yosemite)

Used chdman from mame0192-64bit and the ever so slight different parameters:

chmod +x chdman
(unmounted CF card in disk utility)
diskutil list

sudo ./chdman extracthd -i FILENAME.CHD -o /dev/disk? -f
 
Got 5 Sandisk 64MB cards from eBay today! 4 of them are busted so boo there. It seems these fixed all of the issues I was having on the Transcend cards with one exception - I still cannot boot G Darius Ver 2 no matter what card I use. I know that "B" button works in the selector because I can change regions in Raystorm so I'm not really sure what can be done.


With regards to the conversions though I started peaking at them because curiosity got the best of me. It seems that the creator of them did some intentional obfuscation to deter figuring out the process of how things were done. Take G-Darius's image for example. The mame romset is ~20.5 MB for all the data to include both G-Darius and G-Darius ver 2. Looking at the mame romset you get:
Code: 
ROM_REGION32_LE( 0x01000000, "bankedroms", 0 )
	ROM_LOAD16_BYTE( "e39-06.4",     0x0000001, 0x100000, CRC(2980c30d) SHA1(597321642125c3ae37581c2d9abc2723c7909996) )
	ROM_LOAD16_BYTE( "e39-05.3",     0x0000000, 0x100000, CRC(750e5b13) SHA1(68fe9cbd7d506cfd587dccc40b6ae0b0b6ee7c29) )
	ROM_LOAD( "e39-01.1",            0x0400000, 0x400000, CRC(bdaaa251) SHA1(a42daa706ee859c2b66be179e08c0ad7990f919e) )
	ROM_LOAD( "e39-02.2",            0x0800000, 0x400000, CRC(a47aab5d) SHA1(64b58e47035ad9d8d6dcaf475cbcc3ad85f4d82f) )
	ROM_LOAD( "e39-03.12",           0x0c00000, 0x400000, CRC(a883b6a5) SHA1(b8d00d944c90f8cd9c2b076688f4c68b2e6d557a) )

	ROM_REGION( 0x080000, ":taito_zoom:mn10200", 0 )
	ROM_LOAD( "e39-07.14",    0x0000000, 0x080000, CRC(2252c7c1) SHA1(92b9908e0d87cad6587f1acc0eef69eaae8c6a98) )

	ROM_REGION32_LE( 0x400000, ":taito_zoom:zsg2", 0 )
	ROM_LOAD( "e39-04.27",    0x0000000, 0x400000, CRC(6ee35e68) SHA1(fdfe63203d8cecf84cb869039fb893d5b63cdd67) )
Looking at the md5 for the g-darius image you get:
Code: 
MD5 (SYSTEM.INF) = 5b7241e8b8123890c4535195256e9365
MD5 (SYSTEM.TIM) = 40e43ba18c3d4bcee3cd249aeb1a1930
MD5 (loader.bin) = ccf36cee123dc0ce2ea7459f5b70325e
MD5 (wave0.bin) = b0222da50450f2e5c35f25a241536456
MD5 (wave1.bin) = 2b7d7d6a257778d52b03b09b9c5c62ce
MD5 (zoom.bin) = 246f0b30dd292f0dbbcfa7cf232ce441
And mame roms:
Code: 
MD5 (e39-01.1) = f6195fd696c23951f9b8bd519db06adc
MD5 (e39-02.2) = 26dbb31b6519e78edb14accd3a43960c
MD5 (e39-03.12) = b1ef99c01dd7f292d3f163c437ad0614
MD5 (e39-04.27) = 39cd162f32b0c89ff6701cb6dacfe87e
MD5 (e39-07.14) = 246f0b30dd292f0dbbcfa7cf232ce441
MD5 (e39-11.3) = 3d3eed2bfd8531da411098bfd1fc517b
MD5 (e39-12.4) = 6cc456cfa267465966be43b28a8f4d4f
MD5 (e39-05.3) = 9cad28de3216387febddf6359436fb62
MD5 (e39-06.4) = 587a80c2c36755c7fd184f66bfc2b881
MD5 (e39-08.ic4) = dab3ae4e2fc40fa8ace616513031f847
MD5 (e39-10.ic3) = 45dfffc6c79eecdc6192e635c0a4aeb3
You can see that zoom.bin is e39-07.14 byte-for-byte. Makes sense, the file is named zoom after all. Wave0 and wave1 are interesting in that they are 2MB files and the other sound file e39-04.27 is a 4MB file. If you split it in half you get matching sums.
Code: 
MD5 (part1.bin) = b0222da50450f2e5c35f25a241536456
MD5 (part2.bin) = 2b7d7d6a257778d52b03b09b9c5c62ce
So that covers everything but loader.bin and where things get interesting. After interleaving the first portion of the program rom and put the entire binary together you end up with a 14MB program. The filesystem however shows only 5MB used. Something doesn't add up. You also have a very helpful string to try and find this binary:

Code: 
:feh sampson$ strings gdarius1.bin | head -n1
Licensed by Sony Computer Entertainment Inc.(SCEI)
:feh sampson$ strings /Volumes/NO\ NAME/* | grep "SCEI"
:feh sampson$ strings ../img/gdarius.img | grep SCEI
Licensed by Sony Computer Entertainment Inc.(SCEI)
Licensed by Sony Computer Entertainment Inc.(SCEI)
:feh sampson$
What this shows is that the licensing doesn't exist on any file that you can view from your computer. The interesting part though is if you do a check through the entire image that gets written to the CF card the string appears twice which makes sense since there's G-Darius and G-Darius ver 2. At offset 0xC00000 of the disk image you will find the exact same starting string as the G Darius program rom. Doing some comparison on hex you will find this one is G-Darius ver 1 and the other is G-Darius ver 2. It seems like loader.bin does some sort of direct-level access to the compact flash card as you can find the other program roms elsewhere - e39-01.1 starts at 0x200000, e39-02.2 starts at 0x600000 and e39-03.12 starts at 0xA00000. These are byte-for-byte matches to the actual game code and the protection chip is nowhere to be found in the disk image. This leads me to believe you could potentially inject another game into one of these so long as you match a rom set with a similar layout to whatever you're porting but I can't be 100% certain because I haven't investigated what loader.bin actually does.

Edit: @Apocalypse this is most likely why you couldn't get these conversions to work with the g-net driver on Mame, I highly doubt it mounts the CHD in a format to where the loader can jump to the raw blocks on the chd in a fashion that satisfies the loader. I noticed in another thread you had tried poking at the images with regards to conversion bounty so thought this might be of interest to you.
 
Last edited:
@sammargh: it seems we're at the same point (I've figured out the same regarding how data are arranged in the chd image). However I thought it would load in MAME by replacing the BIOS file.
 
You must log in or register to reply here.
Back
Top