Some of my tools
I downloaded and installed the latest version of the free programming software, connected everything up, checked that I could send programs to the PICAXE-08 (with the amazing capacity for 128 bytes of code) and found an old broken TI cable. Cut it open, bared the wires, verified the plug worked with a multimeter and hooked it up directly to the IO pins 1 and 2 on my PICAXE-08. I created a blank program, sent it to the PICAXE-08. I connected the TI to the board and powered up. I was running CalcSys on my calculator, so could check the link port status. To my relief, when a pin on the PIC is acting as an input it doesn't drag the data line low (which is pretty damned important). I knocked out a series of routines that would set the individual data lines low or high, wait for the other line to acknowledge by switching to that state then resetting to the old state (which always ends up with both lines being inputs - the "INPUT" instruction sets a particular pin to be an input again.
With that done, I encapsulated all these instructions into a for...next loop that could (hopefully) send a whole byte. I then stepped through the 0-255 range in another for...next loop outputting each byte in turn. Plugged in my TI, ran Telnet83 on the calculator, sent the program to my PICAXE and ran it. Huzzah! There was the entire ASCII set, in order. To check that it was sending the right values, I looked up H,e,l and o in QBASIC and sent those values (the l twice) to see "HelloHelloHelloHelloHel..." and so on on the TI's screen. It worked!
The PICAXE-08 chip and surrounding circuitry
Next it needed a getByte routine. Not a tricky task, with the stuff already in place to show that it was possible. Once written, I wrote a program that got a byte, sent it back then looped. In Telnet83, this should have meant that when typing on the keypad I should have seen my keys echoed back. How odd, I thought, when they weren't, and was getting garbled messages. I found a few keys did echo letters back, not just odd characters and noted them down. I then worked out what they should have been, in binary, then what they really were in binary. No relation whatsoever! They weren't shifted, they weren't inverted, they weren't in a flipped bit order - nothing.
I added the "debug" instruction to my code. This outputs the values of all the variables via the serial port to a window in the programming editor. Typing keys next to eachother showed that in fact I was getting the bits in the wrong order. I swapped the order around by replacing the addition of a 1 to an addition of 128, and divided the received byte each loop by 2 rather than multiplying by 2 (no shift operators in PICAXE basic). It worked! The reason that I hadn't seen any relation between what was happening before was that I was getting uppercase chars back from the PICAXE, and assumed that I was also sending uppercase chars. In fact, I was sending them in lowercase.
The serial connection and power board
I optimised the code as best I could, wrote the documentation, then wrote a quick sample program that would send a variable (real A) to the calculator with a set value (pinched from the link docs I had). Sadly, I ran out of room on the EEPROM at this point. I need the PICAXE-08M, as that doubles the amount of memory available for programs. Maybe I can write a useful program on that..? The sample program that comes with the link routines is basic remote control stuff that sends the keycode for kCatalog, so the calculator will open the catalogue every 10 seconds or so when running my program.
Ideas
With the link routines as they are there is VERY little space for a useful program. However, there are some really simple programs that could be written. I'm sure that you could, with a little extra bother, write a program that allows the PIC to act as a RS232 serial device that translates serial commands into TI link protocol commands and vice versa. The problem here is that my link routines will lock up if they lose the connection and never time out, so working out how and when to transfer between the two could be interesting to say the least. It might need a few extra loops and timers to allow for graceful error handling, which are probably beyond the capabilities of 128 bytes of BASIC. However, rather than just acting as a serial bridge, why not try and build real extra bits of hardware? The PICAXE has internal functions for (in example) the Sony IR protocol. So, with a bit of extra work, I could turn my TI into a Sony-compatible TV remote control. Or, even easier, the PICAXE has simple monophonic sound routines. It would be no problem (even on this simple PICAXE-08 ) to send a "ready" byte, get two bytes (pitch, duration) then issue the instruction to play a tone then loop... and with this arrangement, all your TI would have to do is wait to see until something is trying to send it a byte inside the game loop. If it is, it grabs two bytes from the "tune" lookup table in your ASM game, outputs them via the link port, then carries on. This way you could have in-game music! Naturally, having a PIC dangling off the end of your calculator isn't great, but you've seen how much supporting circuitry a PICAXE requires - none. All you'd need is a smallish box with a 3.5mm stereo jack in it (maybe also a potentiometer for volume control). The fact that your headphones would be powered would also mean that you could also smooth the sound a little. Add a small transistor amp in there and a mini-loudspeaker (the connection to which is broken by the switch on the 3.5mm stereo jack) and you have sound hardware fit for a king.
I hope I've given you guys food for thought!
Download the code here: http://benryves.com/bin/piclink/tiLink.bas
.
That's so cool! You always do such cool things in such short time... it keeps amazing me! It took me weeks to get a PIC, make a programmer, make hardware to connect it to the calculator, and come to the conclusion that my programmer didn't work or something 
At which point there was no time left and we kinda gave it up...