I try to build a USB Gecko replacement with an ATmega16 microcontroller. It's a bidirectional RS232 to EXI (SPI) converter which comunicates pretty well with other microcontrollers SPI interfaces, but not with the Wii. I my opinion that's because of the USB Gecko is operating @ 32 MHz, and the maximum SPI frequency of my controller is just 2 MHz. I know that there are 6 different speed modes of the EXI down to 1 MHz, as shown on http://devkitpro.org/libogc/group__exi__speed.html (http://devkitpro.org/libogc/group__exi__speed.html).
I took a look at the Gecko OS source code and found this line in the codehandler.s file:
stw r21, 0x643C(r24) # exi speed up
Is it possible to downscale the EXI frequency to 2 MHz in the codehandler?
Quote from: da_winschi on May 07, 2011, 10:01:34 PM
I try to build a USB Gecko replacement with an ATmega16 microcontroller. It's a bidirectional RS232 to EXI (SPI) converter which comunicates pretty well with other microcontrollers SPI interfaces, but not with the Wii. I my opinion that's because of the USB Gecko is operating @ 32 MHz, and the maximum SPI frequency of my controller is just 2 MHz. I know that there are 6 different speed modes of the EXI down to 1 MHz, as shown on http://devkitpro.org/libogc/group__exi__speed.html (http://devkitpro.org/libogc/group__exi__speed.html).
I took a look at the Gecko OS source code and found this line in the codehandler.s file:
stw r21, 0x643C(r24) # exi speed up
Is it possible to downscale the EXI frequency to 2 MHz in the codehandler?
Nuke would have to say for sure, but it's probably possible; there are some USB Gecko apps that offer a choice between 16MHz and 32MHz (I think USB-Boot was one?). That said, 2MHz would be very slow.
You could probably load the code handler with an 04 code that patches the EXI bus speed down. Then you might be able use an MCU.
I would still highly recommend using an FTDI USB->Serial adapter on the other side of your ATMega. I know at least Gecko.NET talks to it using the D2XX API to communicate directly with the FTDI chip.
There's a few thru-hole PICs that can get SPI up to like 8 MHz I think. SMT PICs can get up to 16 MHz, I think.
Quote from: dcx2 on May 08, 2011, 01:23:59 AMYou could probably load the code handler with an 04 code that patches the EXI bus speed down.
How to do so?
Quote from: dcx2 on May 08, 2011, 01:23:59 AMI would still highly recommend using an FTDI USB->Serial adapter on the other side of your ATMega.
I would like to use the RS232, because I want to code a Delphi programm for comunication between MCU and PC. Serial handling is much more simple with Delphi. That's why I don't plan to use Gecko.NET.
Quote from: dcx2 on May 08, 2011, 01:23:59 AMThere's a few thru-hole PICs that can get SPI up to like 8 MHz I think. SMT PICs can get up to 16 MHz, I think.
Most PIC MCUs with 16 Bit cores have clock dividers of minimum 4 to set the SPI frequency. With a clock frequency of 40 MHz you could get max SPI frequencys of 10MHz. Besides, I use BASCOM to programm my MCUs, so I'm fixed on AVR (ATmega, ATxmega, ATtiny). With an ATxmega @ 32 MHz and divider of 4 I could get 8 Mhz SPI frequency.
Quote from: biolizard89 on May 08, 2011, 12:03:55 AM2MHz would be very slow.
Yes, 2MHz is quite slow. I don't know if it affects any peripheral devices connected to EXI like RTC or ROM. (http://www.wiibrew.org/w/images/a/aa/Wii_hw_diagram.png (http://www.wiibrew.org/w/images/a/aa/Wii_hw_diagram.png))
Are you asking how to use an 04 code to patch the code handler, or what instruction you're supposed to patch?
The original WiiRD console application was programmed in Delphi, I believe. .NET has a Serial class object, so it wouldn't take too much effort to add an RS232 interface to the USBGecko class. Although I should warn you, if you want to hack games you would be re-inventing a very large and complicated wheel.
I honestly thought there was a PIC with Fosc/2 for the instruction clock frequency. I might be thinking of 32-bit PICs, though. I was once interested in making a thru-hole type USB Gecko, so I poked around Microchip's website for details. But if you have an AVR programmer then it makes sense you'd prefer AVR.
The EXI bus speed is independent for each channel, I believe.
Is there a reason you can't just use a USB Gecko SE?
I thougt about editing the Gecko OS source code and recompiling it, but patching would be much nicer. What do you mean by 04 code? Do you know the adress where the EXI speed is stored?
Yes, I want to hack games, but I don't think I need to re-invent the whole wheel. The codehandler, if I can slow down its EXI speed, is the biggest part of the wheel.
Many 16-bit PICs have max Fosc/4 for SPI frequency, just read some datasheets. I'm not sure if there are Fosc/2 types. But what happened to your plans making a MCU-Gecko?
Sure, it would be much easier to buy a ready-to-use USB Gecko, but MCU-programming is my hobby and I love challenges.
The Gecko OS Source that is available is very old. brkirch owns the source for Gecko OS now, and it's closed. The codehandler.s that you found is old. For instance it does not support F6 code types.
An 04 code is a Gecko OS code type. They are the codes that make cheats possible. Here's the codetype doc. http://www.geckocodes.org/index.php?arsenal=1
I don't know precisely where the EXI speed is set. But you found the instruction that writes it to the EXI bus; stw r21, 0x643C(r24). All you have to do is find the instruction where r21 is set, and then make an 04 code that would change that instruction to "something else". "something else" would be whatever bits are necessary to set the EXI frequency you want.
---
The code handler is not the biggest part of the wheel. The code handler is only the central hole, extremely important but because of size constraints it focuses on only doing two things; debugging (read/write memory, set breakpoints), and processing cheat codes. The code handler source can fit in a single file, a mere 1700 lines or so.
All of the actual data processing is done on the PC.
---
Yeah, I know the PIC is typically Fosc/4. I use PICs at work. That's why I said 32-bit PICs might be the Fosc/2 that I'm thinking of.
I just never bothered with an MCU Gecko, because I saw no potential benefits. I would rather spend my time adding more features to Gecko.NET for which they are benefits (like parsing the call stack), or hacking games.
FYI, the PIC32 family datasheet shows that the SPI runs at Fosc/2. See table 23-3. http://ww1.microchip.com/downloads/en/DeviceDoc/DS-61106F.pdf
They get up to 50 MHz, so that means in theory you could run the SPI at 25 MHz. Not quite the 32 MHz that Nuke's CPLD is doing, but it could get the 16 MHz mark. Unfortunately, they're all SMT. =(
EDIT: I was half-wrong. There are in fact 16-bit PIC24's available in thru-hole DIP packages that use Fosc/2 as the limit for SPI, but unfortunately they also impose a hard 8 MHz limit on SPI. PIC24FJ64GA002 is the part #.
Have you considered trying to get a PLD or some other type of programmable logic to make an SPI->Parallel or SPI->RS232 converter? That could ease the strain on your AVR. That's basically what the USB Gecko does...CPLD converts the EXI to parallel and feeds it to the FTDI FIFO.