Most of this text is from ackmed. I have no GD-R discs to swap in, so I tried loading a system 2.0 which worked just great for some reason. ------------ You want to download and burn the following 2 images http://www.gotwalls.com/files/bbapassport_dj3.zip http://www.gotwalls.com/files/httpd-ack-20080711.zip boot with the bbapassport one first. You will want to use that disc configure an ip address/netmask/gateway for the dreamcast. This data will be saved to the dreamcast's flash area and is what httpd-ack uses for its ip. Then boot the httpd-ack disc. On screen you should see the url to use to access it. Should be http://<ip you did for bbapassport>/. Swap in system 2.0 Fire up your browser on your desktop and put in that url. It should bring up a webpage listing the disc info for httpd-ack disc along with track01.raw track02.bin. Open, load in GDR. No need to spin down, no need to tape lid switch. Perhaps due to the system 2.0 special magic. If you are using httpd-ack to dump, by default its going to abort on any read error. This can be overridden by changing the dumping options. If you hover over the track urls you can see them. I would suggest adjusting the following options abort1 -> abort0, continue on read error sector_read16 -> sector_read1, read 1 sector at a time
Nice! Now it's possible to easily dump a GD-R in 2352/data format! Still needs a BBA though... I think it could be feasible with a SD-Card too but I got no GD-R to test it on! Cheers, FG
Basically the target disc is unreadable if I put it in right after httpACK If I swap in a system 2.0, then http the contents, then open the top and swap in the other disc it becomes readable on refresh of the http list. I don't know if this is because the system 2.0 has three tracks or if it's because it is loading the special program it has in the security area.
Shit that would've been nice to know when I had a System Disc, BBA and a few GD-R betas all in one place. I had the same exact problems and the best I ever managed was to get something pulled off the disc but I never got usable data, just what amounted to garbage.
The garbage was usable data you had to do something with it, decrypt or something forget how - I hope you kept the files
To verify if its the 3 tracks or the Magic Ring, just put another retail gd-rom with 3 tracks, like Sonic Adventure or Resident Evil. It's possible that the Ring Check, that identify a disc as a gd-rom or not, load some kind of code somewhere somehow (ram, gd-rom board memory, anything) when it's the SD2 that's being authenticated. Then the next Ring Check could be bypassed by the aforementioned code and the HD TOC could be directly read at 45000LBA. The "software" on the SD2 (except ring) might only be a soft-reset tool, the "magic" occurring in the ring check. This would also explain why it does nothing when selfbooted (tried it first hand) beside soft-reseting. Maybe it's impossible to load the Magic Code from a running program in memory, maybe only the gd-rom board does it on its own. Speculations of course, but I think it's plausible. FG
Nope, long gone. But nothing of value was lost as they were GD-Rs of games that not only got released on the DC but were ports from other platforms to start with. WIP betas really, never found any major differences between them and the final product.
This works wonderfully, thanks ASSEMbler! I didn't believe it at first because I was sure I tried that but obviously I didn't. It works just as well with the 2007 version of HTTPD-Ack (I had that lying around on disc), the new version just adds auto disc spindown. I did the network setup with XDP LE (again, what I had lying around). All my dumps were successful on 1st try with ASSEMbler's method, there was no need to modify the abort/sector_read switches or to mess around with the lid. Thanks for HTTPD-Ack! And that's exactly what happens, I believe FamilyGuy's speculation about the system disc magic is pretty close to the truth. I'm trying to find a suitable beta to selfboot & upload as a small token of appreciation. Oh, and maybe this should be merged with the GD-R dumping sticky? Or at least mentioned there.
See, one don't even need to boot the code that is on the system disc for it to unlock the drive. All it takes is the drive detect that it's a GD-ROM then it reads the special barcode on the security area. Voila. Drive is FULLY unlocked. :thumbsup: It's possible that the program on the system disc is there just to prevent the bios from reseting the drive when a warm boot happens (which would cause the drive to require the barcode again)... :shrug:
