gc-forever - Gamecube/Wii Forums

WiiPower wrote:Apparently all memory card <-> sd card adapters "support" sdhc, meaning, all connections are there in the hardware and sdhc is "only" a matter of the used software. Swiss should be able to load games from sdhc cards put in SD Geckos, but don't expect all sdhc cards to work. If you plan to buy one for this, wait for compatibilty lists.

I'm quite a bit confused now. I found many places where it's stated that the gecko only works with sd (or non-sdhc <4gb, because these are alway sd backwards compatible) cards. Other places say it should be working with sdhc up to 16gb. Can anyone confirm what's really working?

Just to give an example, one of the places that state it does not work is found in the link below, but I've also read it often on forums like gbatemp.
http://shop.konsolenchips.de/sd-gecko-o ... p-612.html

What size SD card can I used with SD Gecko?
Any Size SD card up to 2GB (max size) will work with SD Gecko. SDHC (Secure Digital High Capacity) which are 4GB or more are not supported at this time.

I'd be very thankful if anyone is able to clear things up for me... Thanks alot!

it works with sdhc. wipower already said it only needs a software to handly sdhc. I use a 8GB Sandisk SDHC Card for years with sdboot and it works perfect.

Ah, great! Thanks for pointing this out for me. Just got irritated because of the countless contradictory informations.
So nothing left but to look forward to the release of Swiss (can't wait!)

WiiPower wrote:It will most likely only play GC retail discs on a softmodded wii if that's what you are asking.

Yep, that's what I was getting at. I've been running homebrew through SDML on a Wii. That's where I run into the system resetting or not booting through GCOS when I swap discs.

Hey emu_kidid is it possible to load gamecube linux-elf with this, I cant load my elf file with 2.6.32 kernel with any method except usb-gecko, i would like to get support for elf-files. (I cant create dol with doltool, someone help me!!)

I upgraded my(from gc-linux website) filesystem of debian 3.1 "sarge" to 5.0 "lenny", I have aram-swap and one 256 loopfile-swap enabled, xorg works and also advancemame emulator, mfe/mplayer mediaplayer works flawless already in my filesystem from nfs-share (divx quality playback no slowdowns), are you intrested adding linux support for this? Filesystem should work from hdd when creating device nodes, i guess. I created already support for sd cards like this. Can this load whole filesystem from hdd in linux when I hexedit the elf-file like this ""Root=/dev/gcn-sda2 udp ip=on video=gcn-vifb:tv=auto force_keyboard_port=4 -placeholder- "

somebody would need to add a linux driver for the ide-exi and compile the kernel again - after that you should be able to get hdd support

also, try elf2dol not doltool

When you release Swiss... Will you release the source code?

Cowa! wrote:When you release Swiss... Will you release the source code?

When you read the second line of text:

emu_kidid wrote:It will be 100% open sourced and available online (probably googlecode) so you can see changes as I make them and I'll be releasing binary versions with every new feature/improvement.

emu_kidid,I have a small question:
The NGC console memorycard port max transmission rate?
This may will be a bottleneck of Swiss Army Knife's compatibility?

i dont think so.
my last knowledge is that sd-boot can use the full exi bus speedwhich shouldnt be slower than the dvd drive.
i think all peripherials are connected to the exi bus and are having the same speed and bandwith.

i hope i explained it right.

i believe exibus has 2mb/s

sm4rty wrote:i dont think so.
my last knowledge is that sd-boot can use the full exi bus speedwhich shouldnt be slower than the dvd drive.
i think all peripherials are connected to the exi bus and are having the same speed and bandwith.

i hope i explained it right.

sounds correct. iirc this is true, a lot of the internal components are using the EXI bus. so no bottleneck there.

in theory the EXI bus has 3mb/s transfer rate using DMA. We cannot use DMA because of the hardware bug that exists on the EXI bus with the shift register destroying data. So instead we use PIO (Polled I/O) which is a lot slower, around the 1.2mb/s mark.

The DVD Drive does not lie on the EXI bus and can be a lot faster (but isn't, it's about 2mb/s max transfer rate on the GC).

I plan to reduce the slow down by removing the DVD callback which is still executed in games since this is what is taking up the most time at the moment. We'll see how it goes once I start working on it publicly and I have a few more testers.

emu_kidid wrote:I plan to reduce the slow down by removing the DVD callback which is still executed in games since this is what is taking up the most time at the moment. We'll see how it goes once I start working on it publicly and I have a few more testers.

Removing the DVD callback? Any technical details on that? Is the game still trying to read the DVD? If yes, how does it get it's data passed then via SD/EXI IDE?
And how will you remove the DVD callback? Patching it out on load?

Maybe my sentences don't make sense at all, since I'm not even sure how the technical way of loading via SD/EXI IDE works. (Any technical info/source on that, would be awesome)

Sorry for my flood of questions btw, but I since I've discovered that the GC scene isn't dead, I'm excited as hell and want to learn everything.

Darkmystery wrote: Removing the DVD callback? Any technical details on that? Is the game still trying to read the DVD? If yes, how does it get it's data passed then via SD/EXI IDE?
And how will you remove the DVD callback? Patching it out on load?

Currently this is what happens in swiss/sd-boot:

When the game performs a DVD read, I patch in so that just before it, I read from SD or the IDE-EXI, then after that I make it read 32 bytes (cached) from offset 0 on the DVD to trigger the callback which fools the DVD state machine in the SDK that the read was a success. What I'd like to do is call the callback myself after reading from SD/IDE-EXI, or do the same functionality that it does without needing the DVD at all - this would greatly reduce the time taken since the read itself is quite slow as it goes through a interrupt/exception.

Swiss when booting the game will let you know if the game isn't patchable/etc and it will refuse to boot it if it isn't (since it will just black screen). It'll have a code which you'll notify me of and I'll look at the game and add support for it.

Any word on how good the 480p forcing compatibility will be? I'm hoping I can force RE/RE0/RE2 which doesn't natively support 480p.

emu_kidid wrote:

Darkmystery wrote: Removing the DVD callback? Any technical details on that? Is the game still trying to read the DVD? If yes, how does it get it's data passed then via SD/EXI IDE?
And how will you remove the DVD callback? Patching it out on load?

Currently this is what happens in swiss/sd-boot:

When the game performs a DVD read, I patch in so that just before it, I read from SD or the IDE-EXI, then after that I make it read 32 bytes (cached) from offset 0 on the DVD to trigger the callback which fools the DVD state machine in the SDK that the read was a success. What I'd like to do is call the callback myself after reading from SD/IDE-EXI, or do the same functionality that it does without needing the DVD at all - this would greatly reduce the time taken since the read itself is quite slow as it goes through a interrupt/exception.

Swiss when booting the game will let you know if the game isn't patchable/etc and it will refuse to boot it if it isn't (since it will just black screen). It'll have a code which you'll notify me of and I'll look at the game and add support for it.

Thanks, clears it up.

Can the GC output beyond 480p if software was made to force it similair to GSM? the only two games on the PS2 that had 1080i support where Tourist Trophey and Gran Turismo 4 so nearly everybody thinks the maximumum of the PS2 was 480p also but with GSM you can force a selection of outputs from 480i to 1080i the same as PS2 Linux. Could PAL 576p be added to swiss?

The callback stuff sounds very strange to me, i guess there's something i don't understand. NeoGamma patches the the dvd read function of the game itself(parameters: buf, size, off, callback), to jump to a replacement function. And that replacement function executes the reads and then calls the callback with the result 1 when/if the read was successful. I would think this is the way to do it in case your actual read function needs more space(code) than the original read function.

I can't wait to take a look at Swiss' sourcecode.

interesting - I'll take a look at Neogamma then

Today is the day to release, right? I'm very excited. Thanks emu_kidid for the hard work.

Hello emukidid, I have some questions. I have a Qoob SX moded Gamecube. But the DVD-drive is broken (dont read anything). I want to know... If I buy that IDE-EXI hardware, with your new software... will i be able to load games from SD/HDD without using the DVD drive?... Be cause I bougth a GC "un-chiped" and changed the drive... but it still doesnt work...
Thanks!

JPnintendo, I'd say hold off from it buying an ide-exi. I plan to 100% support Driveless GC's but at the moment it needs a Cube that can at least read that a disc is inserted.

What do you mean now? Will it need a disc in the drive? Or does the GC have to have a drive that could read a disc if one was inserted?

On usb loading for wii games there are similar issues. With recent usb loaders, you don't need a disc in the drive, but you need to have a dvd drive in the wii.

Yes, it all depends how much of the DVD subsystem I patch out. I don't think I'll ever properly support a GC with no drive (disregard what I said earlier) - but I will support one with no disc inserted later on. To support no drive is just too much in my honest opinion - better leave that for the DVD emulator project