I’ve been looking into different possibilities for programming autonomous through the programming port on the RC. One of the possibilities I’ve been looking at is using the Game Boy Advanced link port as a means of communicating data to the RC. Since the link port can be used as a simple serial interface through a schematic I’ve found on the internet, I think it would be feasible to send/receive data to the RC. Looking at that schematic it seems as though it uses a 9 pin SUB-D Female connector. The RC also uses that type of connector. Since this is probably the best spot to post this type of question, I was wondering if it is possible to make this work just by using a Male connector and switching the Tx and Rx data cables going from the MAX3222 chip. Any help would be appreciated. 
One question: How does the GBA know what to do with that? Last I checked, you couldn’t exactly program cartridge systems yourself.
To answer your question: You would swap Rx (2) and Tx (3). There is also 7 and 8, which are RTS (Request To Send) and CTS (Clear To Send) respectively. Since you’re essentially translating the circuit from DCE (Data Carrier Equipment) to DTE (Data Terminal Equipment), One would think that you could just swap RTS and CTS, but that also changes the meaning of them slightly. You could also just short the RTS/CTS pins on both ends; that is, short 7 to 8 on the DB-9 and 4 to 5 (include the resistor on the GBA end.)
Of course, I don’t think any of the handshaking lines (RTS/CTS and DTR/DSR) are used by the loader.
Can anyone more experienced shed some light?
You can program GBAs. You need a special cartage that accepts an SD/SD micro card, but it is possible.
As for the physical connection I don’t know it what you’re trying to do is even possible.
If all you want is a terminal/configuration you may want to look into getting a used PDA(with a serial port), and writing a simple terminal app.
If I can get a serial connection from the GBA to the RC could I not do potentially the exact same thing as hooking a laptop up to the RC? The GBA’s link port acts almost exactly like a serial port, just arranged differently. I’d rather have to carry a GBA in my pocket out to the field rather than a laptop . Plus, how could would people think it would be if you programmed your autonomous through a Game Boy 
.
Oh and Astronouth, looking at the IFI programming port pinout it seems as though they do use CTS and RTS in their communication. Do these two pins have to go CTS-CTS and RTS-RTS or does it have to be CTS-RTS and RTS-CTS just like it has to be Tx-Rx and Rx-Tx?
In addition, you can program on your computer insanely easily with an emulator. I’ve got both versions of VisualBoyAdvance on my computer, which together have MPLab quality debugging tools, including direct memory access, a disassembler, various types of breakpoints (break at address, break on write, break on read, etc.) and so on. I learned assembly with it. If you want it, send me a Private Message. You could try to download them online, but I doubt you’d have much success with the debugger version. Oh, and definately take a look at this.
If anyone wants to get into actual Game Boy Advanced development for fun, I suggest using devkitPro. It’s completely legal and it’s what I’ll be using to program my little auton app once I get the cable done (any electrical/wiring gurus out there? 
).
I am NOT familiar with GBA programming, but I would think it is possible, if the serial port of a GBA is what you say.
You would not be able to compile code on the GBA, but if you wrote some type of script that would be saved in EEPROM on the RC then it is possible you could use the GBA as a terminal to modify the script.
If you wanted to do something like that I would recommend creating the script and the PC editor, and then porting an editor to GBA.
What my plan was to do is make a pre-compiled list of commands for the GBA that could be compiled into a list of ID numbers that the user could select and make a list of editable (speed, time, distance) commands, which would then store the commands in the RC through EEPROM. Once stored, when autonomous mode started, the RC would read the EEPROM and run the corresponding function related to the ID number that was stored by the GBA.
Sounds a lot like Kevin’s terminal menus used in his camera code.
I’ve been thinking about writing a script that generates those menus and the EEPROM code to deal with it, and the idea that the menu could be driven in different ways (serial terminal, GBA, …) makes it that much more interesting.
Also, standard serial cables are wired straight (pin 1 goes to pin 1). All labels in RS-232 specs are relative to the DTE (the computer, or in your case the GBA). Which means that the line that the GBA transmits on is connected to the pin labeled Tx.
It seems that “UART” mode would be what you want. If you look at http://www.work.de/nocash/gbatek.htm#siouartmode, you’ll notice that there’s a CTS mode flag. I recommend setting it to 0 (Send blindly) and wiring GBA SD (GBA pin 4) to the RTS pin. Then you may wire the CTS pin to GBA SC (GBA pin 5). (Pinouts from http://www.hardwarebook.info/Game_Boy_Link.)
One thing that has not been described in the documents is how the GBA’s “UART” mode relates to RS-232 settings. Specifically baud, parity, data bits, and stop bits. 8 data and 1 stop bit has become something of a de facto standard. Which leaves parity and baud. I can’t remember what the RC uses for these, and I can’t find what the GBA’s settings are. I guess this is an exercise left to the reader! 
Funny you bring this up. I thought I was an original thinker…
I had an idea similar to this a while back. I wanted to make an open source inertial navigation system for FRC with focus on ease of use and availability of parts. INS’s are tough, as you need to have pretty custom hardware including the correct sensory and the horse power to process your signals. So, I figured I could “borrow” and hack up hardware thats available in the market place. Also, I wanted this system to be able to handle other robot functions, such as autonomous control, so it needed to have a screen.
I stumbled upon this., which gave me means to get pretty accurate 3 axis acceleration and yaw rate readings on the nintendo DS. I looked into the DS linux and homebrew projects, along with how to grab hold of an RS-232 serial connection through the SPI port it uses to read games. Running Linux would be my first choice on this, as I could write all of the software with little overhead and its just plain cool.
So, the DS enables you to have an INS with touchscreen for a pretty good price. Unfortunately I haven’t had time/money/motivation to follow up on this. Oh well, maybe next year.
In case anybody is interested, the most recent versions of the Botball controller have been using the GBA for I/O and processing.
https://botballstore.org/catalog/product_info.php?products_id=118
On the gbatek site you gave me there are bits you can set to fix the baud rate, parity and data rate, so setting those bits to match the settings of the RC should work. Setting them to the right bits would probably be easier through assembly, I find it easier to directly access the memory rather than using C. Using devkitPro though you can use assembly opcodes right inside your C code (as per they do with the initialization of the RC).
Heck, if it’s legal to have one on the robot during competition, you could have a whole set of pre-programmed cartridges, containing autonomous routines, and then maybe a separate one for running calibration routines. Personally, I love the idea, and as a fairly experienced GBA programmer (hacker) it’s all entirely possible. Heck, I might just try this myself. I can’t even remember the last time I palyed my old GBA. And it’s not like you’d have to destroy the whole thing to use it. That’s gotta be the coolest part.
Im pretty sure the above is just a fancier version of the xport controller.