gc-forever - Gamecube/Wii Forums

Note that I do not sell these. All the documentation and source is available to make one yourself, or have someone else make it for you.

I needed one so I made one.


Confirmed working but I didn't test it much. Build at your own risk. I had to remove the (never used) 16 bit commands to make the code fit into the CPLD, but I'm thinking of redoing the whole protocol from scratch anyway to be more efficient.
There is no case for it, keep in mind that the memory card slots are not made for using bare PCBs in them, I had to stick a strip of PVC below mine to keep the contacts in place.

I added labels for the JTAG pads and fixed (I hope) the non masked ground plane on the version I uploaded which should make your life easier.

BoM (with Farnell part numbers) :
- FT245RL (USB transmitter) - 1146034
- XC9572XL (CPLD) - 1605849
- 100nF 0603 SMD ceramic capacitor
- 2x 10uF 1206 SMD tantalum capacitors
- 3.3V LM1117 fixed voltage regulator - 1202826
- Mini-USB type B receptacle/female connector (SMD) - 1626766

Board is available on OSH Park : https://oshpark.com/shared_projects/oyzl6GcX
Design, VHDL and CPLD programming files are attached (includes PDF versions of the Eagle files for easier viewing when assembling).

You need to program the FTDI with the attached EEPROM file using FT_Prog.

Old FTDI programming method (deprecated)

Show

You will have to flash the FT245R's EEPROM with the file from there using MProg (NOT ft_prog !!!).

Note that I do not sell these. All the documentation and source is available to make one yourself, or have someone else make it for you.

Streetwalker wrote:I needed one so I made one.


Confirmed working but I didn't test it much. Build at your own risk. I had to remove the (never used) 16 bit commands to make the code fit into the CPLD, but I'm thinking of redoing the whole protocol from scratch anyway to be more efficient.
There is no case for it, keep in mind that the memory card slots are not made for using bare PCBs in them, I had to stick a strip of PVC below mine to keep the contacts in place.

I added labels for the JTAG pads and fixed (I hope) the non masked ground plane on the version I uploaded which should make your life easier.

BoM (with Farnell part numbers) :
- FT245RL (USB transmitter) - 1146034
- XC9572XL (CPLD) - 1605849
- 100nF 0603 SMD ceramic capacitor
- 2x 10uF 1206 SMD tantalum capacitors
- 3.3V LM1117 fixed voltage regulator - 1202826
- Mini-USB type B receptacle/female connector (SMD) - 1626766

Board is available on OSH Park : https://oshpark.com/shared_projects/oyzl6GcX
Design, VHDL and CPLD programming files are attached (includes PDF versions of the Eagle files for easier viewing when assembling).

Wow this came out of nowhere thank you so much. I will give this a go when i get around to it. I just ordered 3 boards. This has less components then the shuriken usb very nice and is open source.

I sent in gerbers for the real usb gecko SE but the FPGA is very expensive about 14.50usd. So its in my projects page on oshpark. I also have the IDE-EXI, shuriken video v1, shuriken video v2, and a pcb that I have been working on for sometime now on and off.

You're welcome, have fun with it.

Needs moar blue LEDs.

Interesting, I think I will build myself one. I am about to look into writing a GC program (if what I want to do is possible at all). Currently I would have to copy the new .dol file to my SD card all the time and then load it through SD Gecko. I suppose with this thing I will be able to upload my code directly through USB, kinda like with Everdrive64/64Drive? If yes, which program do I need to do this?

Edit: in another thread you mentioned that you wanted to add some improvements compared to USB Gecko SE, such as an interrupt line. Does this board have that?

Edit2: is there a chance that a thicker PCB could do without the PVC? What thickness would be needed? Hrmm, it seems the oshpark boards are already pretty thick.

love the title made me laugh

Meneerbeer: to load programs over USB you can use the one emu_kidid posted, it's probably in the homebrew section. That's exactly why I made this, development with just an SD card is a pain.
For the interrupt line, it's hooked up to the CPLD but unused at the moment as this is a 1:1 clone device based on the original code. Once I redesign the protocol from scratch I'll see if it's needed at all.
The PCB is indeed pretty thick already, but yes thickness is the trick here.

Here's that link again for my crappy tool (no command line args support but that wouldn't be hard to add in): viewtopic.php?f=37&t=2962

emu_kidid wrote:Here's that link again for my crappy tool (no command line args support but that wouldn't be hard to add in): viewtopic.php?f=37&t=2962

Cool, thanks!

I am currently rerouting this board a bit to my preferences (adding the LED as well ). I had a look at the original USB Gecko PCB. It seems they take 3.3V from the EXI connection. May I ask why you are using a regulator?

It might be possible as well to take the 3.3V from the FT245RL, but that would be pretty tight, I guess.

You can actually power the board entirely from EXI if you want. I didn't because that would cause the USB device to be killed every time you reboot the GC. I removed the LED in my code but it should be easy to add it back from the original (just run diff and see what you need).

Yeah I'd want the USB Gecko to have power before boot personally rather than have to wait for it to enumerate @ boot and potentially miss some output.

A little word of warning to anyone who builds this or buys a Shuriken USB. Do not use geckoloader.exe it will erase your CLPD and your PCB will stop working. I learned this the hard way but thanks to streetwalker making his programming files pubic I was able to reflash the board.

In case anyone is wondering this PCB will not fit inside the shuriken USB case because its smaller overall. I guess it could work if you glued it down

There's also the PCB thickness. OSHpark PCBs are way too thick to fit into a case, I'd have modded my official 59 block memory card otherwise.

The CPLD erasing issue sounds really weird, I have no idea how it could do that as there are only GPIO pins hooked up to the FTDI and the GC. The JTAG pins are exposed on the flipside pads and that's all.

Mind posting a picture of your build ? I'd like to see how the revised PCB looks like.

I have ordered the PCB for mine a few days ago. I did some changes to the PCB, such as changing component sizes to ones I have in stock and I added an LED. I suppose I could post that to github, when I confirm the board is working.

Is the LED ever used in software? I had a quick look at libogc and I could not find functions for it, but in the VHDL there seem to be commands to turn it on or off.

There's also the PCB thickness. OSHpark PCBs are way too thick to fit into a case, I'd have modded my official 59 block memory card otherwise.

I measured the PCB thickness of a cheap, crappy memory card of mine and that one was about 1.0 mm, so that is the thickness I ordered.

The LED was only added to the "SE" version, in the original the same commands were used to read/write from the onboard NAND.

I received my boards, but I am having some trouble unfortunately. I think the FT245RL is not working like it should. I have soldered four of these now and only two actually show up with 'lsusb'. The other two report errors in dmesg.

The other two show unexpected behavior, I think. When I plug it in, the RXF# signal is low. However, I have not sent anything yet from the PC, so should it not be high? It seems the GameCube must be confused by this as well, as the low level indicates that there is new data.

It tried emukidid's usb-load and it does not work for me. It gets stuck on 'awaiting upload ack', but I think that is not very surprising as something seems to be wrong anyways as described above.

Streetwalker, do you use Linux, what does the FT245RL show up with for you with lsusb? For me it is as follows: Bus 001 Device 027: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

Is it correct that it should show up as FT232? I got the FT245RLs from China, so I am starting to get suspicious by now.

The CPLD seems to be working like a charm. I can control the LED based on input levels.

Edit: maybe some more relevant info. I made the LED show the status of usb_rxf: led <= not usb_rxf;
When I plug in the USB cable, the LED will shine. This makes sense, as usb_rxf is low when I plug it in the first time. Whenever I write something to it using: echo "hello" > /dev/ttyUSB0, the LED flashes shortly. I do not even need to have the board plugged into the Cube. So it seems that usb_rxf goes high shortly, but it goes low again without the Cube having to do anything. That does not make sense at all. Normally the Cube would have to instruct a read to make usb_rxf high again.

I indeed use Linux, it's listed as ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC, pretty sure that's a Linux thing (the driver reports the device name, it's not read from the device itself, and I think they use the same interface on the USB side). I suppose your chips have a problem indeed. I haven't really messed much with it, I used the data sheet and the original schematic as a reference for the pinout. Once soldered and flashed it worked pretty much out of the box (well I did have to fix my faulty UCF but that's all).

Streetwalker wrote:I indeed use Linux, it's listed as ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC, pretty sure that's a Linux thing (the driver reports the device name, it's not read from the device itself, and I think they use the same interface on the USB side).

That is what I thought would be the case.

Did you flash the EEPROM? I did that for one of the "working" ones, but it did not make a difference.

I will try to figure out what is going wrong. Problem could also be in my PCBs, although the design is quite simple. I guess I will have a better look at the FT245RL's behavior.

I flashed the eeprom on windows yes, not sure that would make any difference, that's only supposed to give the chip an internal ID for software to use.
You should post a picture of you schematic and layout.

off subject, but just thought i would ask:

meneerbeer wrote:I measured the PCB thickness of a cheap, crappy memory card of mine and that one was about 1.0 mm, so that is the thickness I ordered.

how did that 1mm size work out?



depending on the manufacturer or brand of memory card / SDGecko you will find they use different thickness
ive even measured some at about 0.3mm and 0.5mm yet those manufactures never modify the internal thickness of the shell to compensate for the different thickness of PCB...

this is what causes issues with recognition or intermittent connectivity at times, hence the reason some devices need the blue tape fix

Hrmm, I think the chips I received are FT232RLs disguised as FT245RLs (as that is stated on the package). I had a look at the datasheet from the FT232RLs. The FT232RL is a USB to serial converter, meaning it will output the data you send to it over a single pin with the well known serial protocol. The FT245RL will just place the data you send parallel on 8 pins and you need to provide read signals yourself to retrieve the next data.

Pin 1 of the FT232RL is the TXD pin. I probed this pin on the "FT245RL" with my logic analyzer and what I get seems to be serial data and also exactly what I sent:

I tried FT Prog with Windows and when I read the FT245RL it says the device type is 'FT232R'. Does it say that for you as well, Streetwalker? Because if it says it is a FT245R for you, then I guess that will settle the matter.

Still, I do not get how someone would think it is a good idea to package FT232RLs as FT245RLs.

how did that 1mm size work out?



depending on the manufacturer or brand of memory card / SDGecko you will find they use different thickness
ive even measured some at about 0.3mm and 0.5mm yet those manufactures never modify the internal thickness of the shell to compensate for the different thickness of PCB...

this is what causes issues with recognition or intermittent connectivity at times, hence the reason some devices need the blue tape fix

I measured it for one memory card I am willing to throw away. My PCBs seems slightly thicker than the one in the memory card. I guess that one is 0.8 mm. I used this memory card:


I guess it is not really a problem if it is slightly thicker. I have not really looked at the memory card port, but I suppose the connections act like springs?

Sure enough :

Looks like you got scammed by the chinese. :/

I'm fairly sure there are spring contacts in the connector, it's hard to see without destroying one.

Thanks for checking it. I will take a look on Google if others have similar complaints and ask around a bit. But it looks like I got scammed for the first time ever and if it really is the case I will try to get my money back.

I will post some pics of the board tonight. The jtag writing is on the back of PCB I'm trying to post the pictures but there to big. So I will post them tonight

Maybe you could make the pcb thicker because the IDE EXI I ordered last year from oshpark are thicker then your geckos

There's only one thickness available from oshpark. They claim it's 1.6mm thick, seems accurate enough and that's already very thick for a PCB.