gc-forever - Gamecube/Wii Forums

Hi,

I've read about how to run SDLoad using an older Action Replay which allows entry of new codes.

Is it possible (or would it in theory be possible) to set up an SD card so that a different program (e.g. Swiss) gets loaded directly via the AR codes? By changing the PPC bootstrap code corresponding to the AR codes, it could be possible to have Swiss load from an SDHC/SDXC card. The from-the-factory partitioning on most SDHC cards has the partition starting at sector 8192, so there is ~4MB of free space before the first partition, if that's relevant for the loading process.

Currently I think you need to use a non-SDHC card to run SDLoad, then launch Swiss, then swap cards in order to load programs from an SDHC card. And repeat the process whenever you reset.

Does anyone know specifically what SDPATCH.EXE and SDLOADER.BIN do? And how could I convert the AR codes for running SDLoad to and from PPC assembler?

It's definitely possible. It's been a long time but I believe SDLOADER.BIN contains the bulk of SDLoad. In your case, you'd stick Swiss.bin there, probably needs to be compiled for a specific entrypoint too unless you extend the action replay codes. The Action replay codes I'm guessing simply init the SD card and read SDLOADER.BIN from SD to main RAM and jump to it.

I don't know how they converted the instructions to codes - but that's probably the most difficult part in it for me to figure out

Is it worth the effort? I'd say no, but if you're keen, by all means, go for it

I've looked into this some more...

The GameCube AR code format is explained at http://doc.kodewerx.org/hacking_gcn.html. There's also a link there to GCNCrypt which is used to encrypt/decrypt AR codes.

I looked at the SDPATCH.EXE source. SDPATCH writes boot-loader code to sector 0 (offset 0x40 bytes) of the SD card. The PPC code corresponding to the AR codes will init the SD card, load sector 0 and jump to the code. SDPATCH installs different code depending on whether the SD card has an MBR. Given the small size, it's likely that the boot-loader code requires the SDLOADER.BIN file to be unfragmented.

According to the SDLoad readme.txt, SDLOADER.BIN is assembled to 0x81700000 (the high 1MB of RAM). The uncompressed version of Swiss is too big to fit there. Would the compressed version work? That would at least allow SDLOADER.BIN to be replaced directly with a version of Swiss built for address 0x81700000.

Hopefully I'll get around to figuring out what instructions the AR codes correspond to.

There could be a better way to get Swiss (or another program) running via AR codes. Here's what would need to be done:
- Change the AR-codes PPC code to work with SDHC cards
- If necessary, change the boot-loader code installed by SDPATCH.EXE to work with SDHC cards. This may be non-trivial since larger SD cards use FAT32, not FAT16.

As I mentioned though, it seems the default partitioning for modern (high capacity) SD cards typically has an MBR with the first partition starting at sector 8192. So there's plenty of free space before the first partition. It should be possible to come up with a new set of AR codes which load binary code starting from SD sector 1 (or some other low number). That would avoid the need to use SDPATCH. You'd just write your binary code to the SD card (using e.g. dd under Linux).

http://gcemu.dcemu.co.uk/tutorial-to-ge ... 45125.html

yeah, that was how i used to run homebrew on my cube before i installed my qoob chip, now my action replay disc broke, i miss him

So, what happens if you make a mistake while entering that code? (talking about the long one obviously )

Nothing permanent I hope >_>

at first i mistyped a character in that secuence, nothing booted
my disc broke, literally, maybe bc of poor quality materials used to make it, i still keep it for old times sake

mark_k, yeah that sounds about right from what I can remember. Let me know if you have any trouble with it and I'll be willing to help out.

I'm not sure we need 0x81700000 compiled swiss, you can probably make the stub relocate itself to 0x80001800 and then you have all the RAM at your disposal.

Figuring out what PPC code corresponds to the AR codes seems to be harder than I thought it would be...

I entered the AR codes into GCNCrypt and got this.

Original (master?) codes:
7YPR-RKZZ-MH6W5
D26A-PE4J-1XX2W
ZJHY-B1ZH-6P00G

Those decrypt to
0F420000 88000000
04001DD8 4BFFFB50 RAM write, 32-bit. Address 0x80001DD8, value 0x4BFFFB50
01100000 1FFFFF00 RAM write & fill, 8 bit. Address 0x81100000, # bytes to write 0x1FFFFF + 1, value 0x00.

So it seems the first set of codes clear memory from 0x81100000 to 0x812FFFFF (according to the explanation at http://doc.kodewerx.org/hacking_gcn.html). So far so good. The remainder of the decrypted codes are confusing me though. The original codes are (I won't paste them all here to save space):
AF4H-JPF5-H1B5J
MVAB-7TQE-ABZPB
...
D4R8-MVJ5-QGR21
1G3C-APD7-1CUVD

The first few lines decrypt to
0F420001 08000000 (Gives region & game ID(?))
7C6000A6 5463045E 7C = Conditional: If bitwise AND (next 2 lines, 32-bit). Addr 0x806000A6, value 0x5463045E
7C600124 3C60CC00 7C = Conditional: If bitwise AND (next 2 lines, 32-bit). Addr 0x80600124, value 0x3C60CC00
38A004C9 3FA0FF00 38 = Conditional: If bitwise AND (next line, 8-bit). Address 0x80A004C9, value ???
7CA903A6 48000071
4200FFFC 38C00000
38E00000 48000079
3CC00100 48000071
48000055 77FFFF00

The explanations are what I derived from the hacking_gcn.html page. They don't make sense to me. Did GCNCrypt incorrectly decrypt them, or am I missing something? How do the conditional codes work? For example the 7C6000A6 5463045E code. Does that AND the 32-bit word at 0x806000A6 with 0x5463045E, and only execute the following two code lines if the result is zero? Or non-zero? The decrypted codes don't seem to be doing what I expected, which was basically stuffing fixed values into memory.

According to this, the lines will be skipped if the result of the AND was zero.

mark_k, if you're still interested: http://www.youtube.com/watch?v=7uKiAXQMpbE

Check changes in SVN here: http://code.google.com/p/swiss-gc/source/detail?r=239

emu_kidid wrote:mark_k, if you're still interested: http://www.youtube.com/watch?v=7uKiAXQMpbE

Check changes in SVN here: http://code.google.com/p/swiss-gc/source/detail?r=239

Is there a way to download it emu? I can't get sdload to boot anymore and maybe swiss would work instead. You don't seem to have a problem with getting it to work. Must the files be De-fragmented for it to boot? I don't know how to compile those file or download them.

Well, if you're really that lazy I packed 2 nightly builds here, the latest kinda broken one (r240) and the latest good one (r221) 'converted' into SDBOOT.

If you have problems with the SD card, I recomend using HDD Low Level Format Tool to wipe the partitions then format it with FAT32 Format. Always use the 'quick' option in both programs.
I've had a microsd card that wouldn't be read by Swiss or R4 cards and neither SD Formatter nor any other tool could make it work again. Only that HDDLLFT + FAT32 Format combo was able to fix it.

piratesephiroth wrote:Well, if you're really that lazy I packed 2 nightly builds here, the latest kinda broken one (r240) and the latest good one (r221) 'converted' into SDBOOT.

If you have problems with the SD card, I recomend using HDD Low Level Format Tool to wipe the partitions then format it with FAT32 Format. Always use the 'quick' option in both programs.
I've had a microsd card that wouldn't be read by Swiss or R4 cards and neither SD Formatter nor any other tool could make it work again. Only that HDDLLFT + FAT32 Format combo was able to fix it.

Thanks! It now works again! And swiss is better than SDLOAD itself. Ahh I get it, you just cut off a few bytes from the dol header to get it to boot.

47iscool wrote: Thanks! It now works again! And swiss is better than SDLOAD itself. Ahh I get it, you just cut off a few bytes from the dol header to get it to boot.

It's attached to a DOL relocator and the header of that is stripped to be exact.

emu_kidid wrote:

47iscool wrote: Thanks! It now works again! And swiss is better than SDLOAD itself. Ahh I get it, you just cut off a few bytes from the dol header to get it to boot.

It's attached to a DOL relocator and the header of that is stripped to be exact.

Oh okay, you aren't upset with me are you? I noticed you haven't replied back on your 'Goals for Swiss 0.4' thread since we got too off-topic.

No way, I've probably just forgot about it as I always have too much on my plate so to speak. I'll see what you wrote in there.

emu_kidid wrote:No way, I've probably just forgot about it as I always have too much on my plate so to speak. I'll see what you wrote in there.

Okay, thanks for accepting my friend request at psx-scene.

Does loading Swiss in this way mean that I can use an SDHC card as my boot media or will I still need to hot swap? I am getting the adapter at the end of the week and already have a 16GB MicroSD (with the MicroSD to SD adapter) and would like to avoid buying a 2GB card.

If that doesn't work, then I can try partitioning the 16GB card so that the first partition is a 2GB FAT 16 partition and the rest is FAT32. If that don't work I could try one of those rare non-SDHC 4GB cards I found online. But I have yet to hear from anyone if those will work or not with this launch method so won't buy one of those until I know for sure.


At this point I would like to avoid using mini DVDs for my game backups and a 2GB card isn't going to hold very many ISO images.

You need a SD to swap because the code to initialize the card lives in the Action replay code (which I didn't re-write).

Ahh well damn. Will the non SDHC 4GB cards work? (once formatted they would be like 3.6 or so GB, so it should be within FAT16 limits) I will try and get one of those. That should be enough for what I need for now.

They might, but I don't recommend those, they're all sorts of crazy.

Well I already ordered one. If it doesn't work I can just give it to my sister for her Wii since it's softmodded. I let her borrow my 2GB SD card I had from my 3DS. (sold the 3DS off while back though. ).

So worst case scenerio, I just trade it with my sister for the 2GB card which I know for sure will work. If the 4GB card works I'll let you all know.

This was the 4GB card I bought:

Topram 4GB Non-SDHC

It's pretty much the only 4GB card out there that's non SDHC that I know about.

nice, i wanted to try those topram non-SDHC cards (not Action Replay related) but have not had the opportunity
make sure to post results..id like to know if you have a full 3.xGB usability with it...

I don't know if they're still available but I've got a Transcend 4GB non-SDHC card. It actually works in both SDHC and non-SDHC mode (block addressing or byte addressing) depending on how the card is initialized i.e. SDHC mode is used only if CMD8/SEND_IF_COND is received.

According to Amazon, I should get it around Friday next week. Looks like my SD adapter will arrive before then though. Might fiddle around with my 16GB card to see if I can get that working. (even though it likely won't, I could just kill time trying while I wait. )