Hey all, I'm wondering if anyone knows how the serial SD card mod allows retail games to work with sdiso/dreamshell. I would have thought that games would directly try to access the optical drive and thus even if you could start to run the ISO, as soon as they wanted any data they would try to use the GD drive and crash? Or is the code to access the GD-ROM normally stored in or loaded from ROM and when using the SD card mod the code is replaced by the dreamshell/sdiso when it launches the game? This is the only way I can think of it working. The reason I'm asking is because I've been thinking about the possibility of adding an SD card reader to the G2 bus. If you could get a fast enough micro (maybe a low end ARM or an AVR32) with DMA and hook it up to the G2 bus and an SD card you ought to be able to load things from SD fast enough to play retail games... maybe even a little quicker. The question though is how to get the games to load from SD while still thinking that they're loading from GD-ROM?
There are some threads in this section that cover all that. A few members here are working on GD-ROM emulators that use either a SD card or the old school IDE protocol. These guys are using FPGA for that since it is easier to program than an ARM based solution.
"I'm wondering if anyone knows how the serial SD card mod allows retail games to work with sdiso/dreamshell" ...by redirecting syscalls that handle access to gdrom on the low level.
I'm not sure about that, sonicdude. lol It might have saved me a lot of pain if I'd used the FPGA just for the low-level stuff, then used an ARM or AVR for the actual programming (like @cybdyn or Duenan's approach). @Munchausen - Yep, 99.9% of games use the BIOS's GD Syscall routines to access the GD drive at a slightly higher level. (a bit of info here in case it's useful for anyone else looking into a GD redirect project. I'm just starting out with DC programming, so there will probably be mistakes / wrong assumptions. lol)... A syscall is just like any other routine, but when the DC boots, the BIOS puts some address pointers (vectors) into specific RAM addresses. These "vectors" point the actual GD routines (which could be placed anywhere in RAM). All the game has to do is call the specific (fixed) vector address for the GD syscall, and the vector transfers the commands to actual routines (placed elsewhere in RAM). Here's a list of most of the vectors (not complete, but covers almost all of the important commands)... http://mc.pp.se/dc/syscalls.html (You can see that the GD syscall vector is written to 0x8C0000BC, right near the start of System RAM.) I was confused at first about how the commands / parameters get put into r4/r5/r6/r7 before a syscall is made... What happens is that the C compiler for the DC's SH4 CPU (and most other modern CPUs) is set up to use the CPU's internal registers in a standardized way (hopefully). This is known as the ABI (Application Binary Interface) for the specific processor.... http://www.kpitgnutools.com/manuals/SH-ABI-Specification.html So, when you pass some parameters / values in a C function call, the compiler will fill the CPU registers starting with r4... Here is an example of doing a DC syscall in C (not my code, LOTS of extra code omitted)... /* Submit a command to the system */ static int gdc_req_cmd(int cmd, void *param) { MAKE_SYSCALL(return, cmd, param, 0); } The first part is just the C definition for the function call, the second part (in squiggly brackets) is the syscall itself. (On Marcus's page, this syscall is named "GDROM_SEND_COMMAND" instead. The actual GD "send command" codes are not listed either)... http://mc.pp.se/dc/syscalls.html#fC0_0 So, when the C call happens, "cmd" gets put into the R4 CPU register, the "param" pointer gets put into the R5 CPU register, and the "0" actually gets put into the R7 reg. (In the current code, the "MAKE_SYSCALL" routine always sets R6 to 0 because all the GD syscall routines have R6 = 0 anyway). EDIT: Oh yep: when doing the syscall redirect, you obviously overwrite the syscall vectors with addresses that point to your own GD routines. Your own routine needs to accept / process the usual GD syscall parameters, grab the sector data from your SD / CF / HDD instead, then pass the data pointer back to the game code... You also need to "emulate" ALL of the expected GD status stuff to keep the game(s) happy. AND, many games will try to jump back to the DC menu when they start to boot; the normal syscall routines will prevent them doing this if they find a genuine / correct disk. The "jump to menu" thing has a separate syscall. This was a very kind tip from Mr SWAT. The lxdream source is probably the best way to understand these syscalls... http://www.lxdream.org/hg/lxdream/file/844a3f2a76ff/src/bios.c I still couldn't get the damned thing to boot though. I was just left staring at a stupid license screen for about three months. :dejection: Hope this helps somebody. :friendly_wink:
Thanks for the replies, especially OzOnE for that very in depth answer! I imagined something more-or-less like this happened but didnt know how to find out more. I've now read all the other topics on this here and see that you've almost cracked it already and that Swat may now be doing something with your IDE drive hookup work, so I think I'll leave it for now and see what happens. I'm curious though about how much is known about those missing DMA commands - do you know any more OzOnE? I presume Swat must do. I wonder if the reason certain games don't work with the SD card is more down to not having full knowledge of the sys call semantics or down to the low speed causing some games to crap out. I guess the thing to do is disassemble the sys calls to find out more....
Keep an eye on my thread "Let's Make Sega GD-ROM Emulation Happen Facebook Group." That seems to be where all the news on this project ended up going instead of the other 2 dedicated threads...
my update for sd mod (http://www.dc-swat.ru/forum/thread-1787-post-24181.html#pid24181) http://s58.radikal.ru/i160/1301/0f/63a559987c42.png http://s018.radikal.ru/i520/1301/d7/683985503c91.png
Aha - very nice. So you use flip-flops as a shift register, then use TX to push a single logic 1 in to the input. Then you toggle RTS once to select SD card, twice to select SPI2 and three times to select SPI3 etc. And potentially you can have up to 8 SPI devices. So far I know of two that you would want - SD card, and ethernet transceiver. What will you do with the spare? Or it's just for future expansion? For sure there are lots of SPI devices out there. Have you considered a layout with either a built in ENC28J60 or with a pin header to simply plug in something like the following?: http://www.skpang.co.uk/catalog/enc28j60h-ethernet-controller-module-p-604.html (just an example, I notice similar modules available for just ~ £9 on ebay) Will you be making these available for sale? Has SWAT got the software working yet? Well done! EDIT - if you are selling them, I will definitely take one!
yep, Swat tryed find a way for support additional SPI devices in "sd-mod", i offered little update on flip-flop register. one of the purposes was add eth spi board. but there are few models of such add-on based on ENC28J60 , so i decide make a coule of free SPI. it's just prototype, if many other people is interesting in this i'll help you create few of them. or update it as you wish. SWAT palns update sowtware for support such device, but all steps are slow))) i think, if we gift him such thing proccess will run faster))) i can give you all necessary info and files, if you have big wish to make it.
I just heard about supporting ENC28j60, could it be possible to simply store SD-ISO images on a network location instead of the SD card?? That would be great!
it sounds like some kind of "virtual SD-card" on pc by ethernet. it's possible, but low speed. better wait "self-made" ehternet adaptor on G2, for such purposes.
