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

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • I built my own little drag and drop tool for creating img files from the chds. you're welcome to try it:

      take a chd file for a games and drag it onto the chd_to_img.bat file. this will create a .img file that you can then program to a card using win32discimager.
      Buy My 3D Printed Parts:
      Follow my projects: instagram | blog
      My PCB list: VAPS
      My Cabs: VOOT | RFM | Vewlix F| FiF Jr. | KI2 | UMK3 | E29 | E29| Net City | DDR
    • aoiddr wrote:

      I'm pretty sure you're just supposed to write the CHD file to a card
      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.
      Buy My 3D Printed Parts:
      Follow my projects: instagram | blog
      My PCB list: VAPS
      My Cabs: VOOT | RFM | Vewlix F| FiF Jr. | KI2 | UMK3 | E29 | E29| Net City | DDR
    • 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.
      Buy My 3D Printed Parts:
      Follow my projects: instagram | blog
      My PCB list: VAPS
      My Cabs: VOOT | RFM | Vewlix F| FiF Jr. | KI2 | UMK3 | E29 | E29| Net City | DDR
    • 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

      Source Code

      1. sambookpro:~ sampson$ diskutil list
      2. /dev/disk0 (internal, physical):
      4. 0: GUID_partition_scheme *251.0 GB disk0
      5. 1: EFI EFI 209.7 MB disk0s1
      6. 2: Apple_APFS Container disk1 250.8 GB disk0s2
      7. /dev/disk1 (synthesized):
      9. 0: APFS Container Scheme - +250.8 GB disk1
      10. Physical Store disk0s2
      11. 1: APFS Volume Macintosh HD 218.5 GB disk1s1
      12. 2: APFS Volume Preboot 19.2 MB disk1s2
      13. 3: APFS Volume Recovery 509.9 MB disk1s3
      14. 4: APFS Volume VM 6.4 GB disk1s4
      15. /dev/disk2 (external, physical):
      17. 0: FDisk_partition_scheme *4.0 GB disk2
      18. 1: DOS_FAT_16 NO NAME 40.9 MB disk2s1
      19. sambookpro:~ sampson$
      Display All
      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.
    • sammargh wrote:

      you need to grab a build of Mame built for OSX
      right but which build... it needs to be the correct version for the CHDs being used.
      Buy My 3D Printed Parts:
      Follow my projects: instagram | blog
      My PCB list: VAPS
      My Cabs: VOOT | RFM | Vewlix F| FiF Jr. | KI2 | UMK3 | E29 | E29| Net City | DDR
    • twistedsymphony wrote:

      sammargh wrote:

      you need to grab a build of Mame built for OSX
      right but which build... it needs to be the correct version for the CHDs being used.
      You can use almost the same that came with the archive, 0.131 (Apr 23 2009)

      It's 0.147 but there were no major changes to chd from 0.131 to 0.147 that I can see.
    • 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
      Multis: CPS-2, CPS-3, F3, ST-V, MVS, M72, G-Net
      PVMs: 2043MD, 20M2MDA, 20L2MD
      Supergun: Sentinel / XRGB-mini
      PCBs: VAPS Profile

    • 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:

      Source Code

      1. ROM_REGION32_LE( 0x01000000, "bankedroms", 0 )
      2. ROM_LOAD16_BYTE( "e39-06.4", 0x0000001, 0x100000, CRC(2980c30d) SHA1(597321642125c3ae37581c2d9abc2723c7909996) )
      3. ROM_LOAD16_BYTE( "e39-05.3", 0x0000000, 0x100000, CRC(750e5b13) SHA1(68fe9cbd7d506cfd587dccc40b6ae0b0b6ee7c29) )
      4. ROM_LOAD( "e39-01.1", 0x0400000, 0x400000, CRC(bdaaa251) SHA1(a42daa706ee859c2b66be179e08c0ad7990f919e) )
      5. ROM_LOAD( "e39-02.2", 0x0800000, 0x400000, CRC(a47aab5d) SHA1(64b58e47035ad9d8d6dcaf475cbcc3ad85f4d82f) )
      6. ROM_LOAD( "e39-03.12", 0x0c00000, 0x400000, CRC(a883b6a5) SHA1(b8d00d944c90f8cd9c2b076688f4c68b2e6d557a) )
      7. ROM_REGION( 0x080000, ":taito_zoom:mn10200", 0 )
      8. ROM_LOAD( "e39-07.14", 0x0000000, 0x080000, CRC(2252c7c1) SHA1(92b9908e0d87cad6587f1acc0eef69eaae8c6a98) )
      9. ROM_REGION32_LE( 0x400000, ":taito_zoom:zsg2", 0 )
      10. ROM_LOAD( "e39-04.27", 0x0000000, 0x400000, CRC(6ee35e68) SHA1(fdfe63203d8cecf84cb869039fb893d5b63cdd67) )
      Display All

      Looking at the md5 for the g-darius image you get:

      Source Code

      1. MD5 (SYSTEM.INF) = 5b7241e8b8123890c4535195256e9365
      2. MD5 (SYSTEM.TIM) = 40e43ba18c3d4bcee3cd249aeb1a1930
      3. MD5 (loader.bin) = ccf36cee123dc0ce2ea7459f5b70325e
      4. MD5 (wave0.bin) = b0222da50450f2e5c35f25a241536456
      5. MD5 (wave1.bin) = 2b7d7d6a257778d52b03b09b9c5c62ce
      6. MD5 (zoom.bin) = 246f0b30dd292f0dbbcfa7cf232ce441
      And mame roms:

      Source Code

      1. MD5 (e39-01.1) = f6195fd696c23951f9b8bd519db06adc
      2. MD5 (e39-02.2) = 26dbb31b6519e78edb14accd3a43960c
      3. MD5 (e39-03.12) = b1ef99c01dd7f292d3f163c437ad0614
      4. MD5 (e39-04.27) = 39cd162f32b0c89ff6701cb6dacfe87e
      5. MD5 (e39-07.14) = 246f0b30dd292f0dbbcfa7cf232ce441
      6. MD5 (e39-11.3) = 3d3eed2bfd8531da411098bfd1fc517b
      7. MD5 (e39-12.4) = 6cc456cfa267465966be43b28a8f4d4f
      8. MD5 (e39-05.3) = 9cad28de3216387febddf6359436fb62
      9. MD5 (e39-06.4) = 587a80c2c36755c7fd184f66bfc2b881
      10. MD5 (e39-08.ic4) = dab3ae4e2fc40fa8ace616513031f847
      11. MD5 (e39-10.ic3) = 45dfffc6c79eecdc6192e635c0a4aeb3
      Display All
      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.

      Source Code

      1. MD5 (part1.bin) = b0222da50450f2e5c35f25a241536456
      2. 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:

      Source Code

      1. :feh sampson$ strings gdarius1.bin | head -n1
      2. Licensed by Sony Computer Entertainment Inc.(SCEI)
      3. :feh sampson$ strings /Volumes/NO\ NAME/* | grep "SCEI"
      4. :feh sampson$ strings ../img/gdarius.img | grep SCEI
      5. Licensed by Sony Computer Entertainment Inc.(SCEI)
      6. Licensed by Sony Computer Entertainment Inc.(SCEI)
      7. :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.

      The post was edited 1 time, last by sammargh ().