Expanding Through the Joystick Port

[Stuart]

Some of you might have heard of an "I2C" interface - "I Squared C" or "Inter-Integrated Circuit". The ICs in your old VCR would have used it to communicate with each other, and your digital STB likely uses it internally as well. Devices with an I2C interface are getting popular in the hobbyist market also because that is also one of the interfaces that comes as standard on the Raspberry Pi and Arduino. There are loads of types of I2C device available - LED drivers, LCD drivers, serial memory (RAM and EEPROM), clocks, analogue-to-digital converters, digital-to-analogue converters, and so on.

 

Electrically, the interface is very simple - just two wires plus ground. One wire is for a clock (SCL) and the other is for serial data (SDA). When writing to a 'slave' device, the 'master' drives both the clock and the data lines. When reading from a slave device, the master controls the clock line and the slave drives the data line. Multiple devices can be connected to the clock and data lines. Each device has a unique address, and the master sends the address of the device to access before reading or writing data to it. The clock frequency is very flexible - most devices have an upper limit of about 100 kHz, and anything below that is OK.

 

So how can we use this on the TI? Well the joystick port has two lines we can control individually, and we can feed the data line back in through a third pin to sense its state. All we need is a 74LS06 inverter and two pullup resistors hooked onto the joystick port and we're all set to go. (I connected a pair of LEDs to help with debugging as well). You'll need a +5V power supply as well. You won't be able to use the console keyboard scanning routine while using the I2C interface as that will send out some spurious signals over the interface (you actually need the interface powered down or disconnected for the keyboard to be read properly), but you could probably write a bespoke keyboard scanning routine that scans just certain keys on the keyboard matrix rows/columns that aren't connected to the joystick port. Oh - Alpha Lock needs to be up as well!

 

Software wise, the code needs to be able to control pins on the joystick port directly over the CRU interface, so that means assembly code. It should be possible for an XB program (for example) to pass data to/from the assembly routines. Cortex BASIC should also work as that includes instructions to control the CRU interface. The routines fall into two groups:

 

(1) Routines that provide raw control of the I2C interface - send the start sequence, send the I2C device address, send (or read) a byte, and send the stop sequence. These routines will be common to any type of I2C device being controlled.

 

(2) Routines that determine the actual bytes to send or receive according to the I2C device type. So for a serial memory device you would need to send one or more bytes specifying the memory address to access, then read or write the contents of that address. For a clock device you would need to send bytes to set or read dd-mm-yy and hh:mm.

 

For a simple proof of concept, I've connected up a 20 character by 4 four line LCD display with an I2C interface - £7.00 on eBay. The LCD display itself has a parallel interface but comes with an I2C interface 'backboard' already soldered on that performs the serial I2C interface to parallel conversion. The code I've used to display a message on this is below.

 

To prove it all works, photo below.

 

Stuart.

 

=====================

DEF START

SCL EQU 19 CRU BIT FOR SCL SIGNAL.
SDA EQU 31 CRU BIT FOR SDA SIGNAL.

 

START LWPI WS LOAD WORKSPACE.

LIMI 0 DISABLE ALL INTERRUPTS.

*CONFIGURE TMS9901.

CLR R12 9901 CRU BASE ADDRESS.

SBO 20 SET 9901 P4 HIGH TO SELECT DEMUX 1 IN U302.
SBZ 18 SET 9901 P2 (A) LOW ...

*TO CONTROL SCL:
*- SBO SCL TO SET SCL HIGH
*- SBZ SCL TO SET SCL LOW

*TO CONTROL SDA:
*- SBO SDA TO SET SDA HIGH
*- SBZ SDA TO SET SDA LOW

*SET INITIAL CONDITION, WITH SCL AND SDA BOTH HIGH.

SBO SCL
SBO SDA
BL @DELAY1

*INITIALISE POINTER TO ADDRESS/DATA TO SEND.

LI R4,I2CDAT

*SEND START SEQUENCE - SDA LOW, SCL REMAINS HIGH.

SBZ SDA
BL @DELAY1

*SEND I2C DEVICE ADDRESS.

MOVB *R4+,R9 GET ADDRESS INTO MSB OF R9.
BL @SNDBYT SEND ADDRESS.

*SEND COMMANDS AND DATA.
*HAVE TO SEND TO LCD DISPLAY AS TWO GROUPS OF 4 BITS,
*WITH CONTROL SIGNALS ALSO SET APPROPRIATELY.
*THIS SECTION OF CODE IS SPECIFIC TO THE TYPE OF I2C DEVICE
*BEING CONTROLLED.

LI R7,>0800 RIGHT NIBBLE CONTAINS DATA FOR LCD CONTROL PINS.
CLR R6 COUNTER FOR THE 6 LCD INIT COMMANDS.

GETBYT MOVB *R4+,R2 GET DATA INTO MSB OF R2.
CB R2,@BFF >FF TERMINATOR CHARACTER?
JEQ STOP YES, JUMP.

* DO LEFT NIBBLE.

MOVB R2,R5 MAKE COPY OF ORIGINAL DATA BYTE.
ANDI R5,>F000 SET ALL BITS OF RIGHT NIBBLE TO 0.
SOC R7,R5 SET BACKLIGHT ON, RS, R/W, E ALL LOW.
MOV R5,R8 COPY BYTE.
MOV R5,R9
BL @SNDBYT
ORI R5,>0400 SET E HIGH.
MOV R5,R9
BL @SNDBYT
MOV R8,R9 SET E LOW AGAIN.
BL @SNDBYT

* DO RIGHT NIBBLE.

MOVB R2,R5 COPY ORIGINAL DATA BYTE AGAIN.
SLA R5,4 SHIFT RIGHT NIBBLE TO LEFT NIBBLE.
ANDI R5,>F000 SET ALL BITS OF RIGHT NIBBLE TO 0.
SOC R7,R5 SET BACKLIGHT ON, RS, R/W, E ALL LOW.
MOV R5,R8 COPY BYTE.
MOV R5,R9
BL @SNDBYT
ORI R5,>0400 SET E HIGH.
MOV R5,R9
BL @SNDBYT
MOV R8,R9 SET E LOW AGAIN.
BL @SNDBYT
INC R6 INCREMENT COUNT OF LCD INIT COMMANDS TO SEND.

CI R6,6 DONE ALL 6?
JNE GETBYT NO, DO NEXT BYTE.

AI R7,>0100 CHANGE TO SET RS HIGH.
JMP GETBYT DO NEXT BYTE.

*SEND STOP SEQUENCE - SDA TAKEN HIGH WHEN SCL ALREADY HIGH.

STOP SBZ SCL SET SCL LOW.
BL @DELAY2 WAIT 1/2 CLOCK PERIOD.

SBZ SDA SET SDA LOW AGAIN AFTER ACK BIT.
BL @DELAY2 WAIT 1/2 CLOCK PERIOD.

SBO SCL SET CLOCK HIGH.
BL @DELAY1 WAIT 1 CLOCK PERIOD.
SBO SDA SET SDA HIGH.

FINISH JMP FINISH

*
*SEND BYTE IN MSB OF R9.
*R9 IS DESTROYED.
*

SNDBYT MOV R11,@SAVR11 SAVE RETURN ADDRESS.

LI R3,8 LOAD BIT COUNTER.

SBITS SLA R9,1 SHIFT MSb OF BYTE INTO CARRY STATUS BIT.
JOC CARRY1

MOV @SBZ31,@SETSDA NO CARRY - WRITE OP-CODE TO ROUTINE BELOW.
JMP CARRY2

CARRY1 MOV @SBO31,@SETSDA CARRY - WRITE OP-CODE TO ROUTINE BELOW.

CARRY2 SBZ SCL SET SCL LOW.
BL @DELAY2 WAIT 1/2 CLOCK PERIOD.

SETSDA DATA >0000 SET SDA - OP-CODE WRITTEN ABOVE.
BL @DELAY2 WAIT 1/2 CLOCK PERIOD.

SBO SCL SET SCL HIGH.
BL @DELAY1 WAIT 1 CLOCK PERIOD.

DEC R3 INCREMENT BIT COUNTER.
JNE SBITS LOOP UNTIL ALL BITS DONE.

SBZ SCL SET CLOCK LOW.
BL @DELAY2 WAIT 1/2 CLOCK PERIOD.

SBO SDA SET SDA HIGH SO SLAVE CAN SEND ACK BIT.
BL @DELAY2 WAIT 1/2 CLOCK PERIOD.

SBO SCL SEND ANOTHER CLOCK PULSE FOR ACK BIT - IGNORE IT.
BL @DELAY1 WAIT 1 CLOCK PERIOD.

MOV @SAVR11,R11 RESTORE RETURN ADDRESS
B *R11 RETURN.

*
*DELAY LOOP - ONE PERIOD.
*

DLYPRD EQU >0002

DELAY1 LI R1,DLYPRD
DEL1 DEC R1
JNE DEL1

B *R11

*
*DELAY LOOP - HALF PERIOD.
*

DELAY2 LI R1,DLYPRD/2
JMP DEL1

*STORAGE.

WS BSS 32 PROGRAM WORKSPACE.

SAVR11 DATA >0000 SAVED RETURN ADDRESS FOR SUB-ROUTINES.

SBO31 DATA >1D1F OP-CODE FOR 'SBO 31'.
SBZ31 DATA >1E1F OP-CODE FOR 'SBZ 31'.

*NOTE ABOUT I2C ADDRESS:
*RASP PI REPORTS LCD DISPLAY AS ADDRESS >27.
*NEED TO SHIFT THAT LEFT ONE BIT, SO NEED TO USE ADDRESS
*>4E TO WRITE, >4F TO READ.

I2CDAT BYTE >4E ADDRESS. MUST IMMEDIATELY PRECEDE DATA.
BYTE >33,>32,>06,>0C,>28,>01
TEXT '* Texas *'
TEXT '* TI-99/4A *'
TEXT '* Instruments *'
TEXT '* I2C Interface *'

BFF BYTE >FF TERMINATOR CHARACTER.

END
======================

 

[mister35mm]

I did suggest a while back that the TI-99/4a joystick port could be used as a Rs232 port of some kind for us poor bastards who don't have PEB (as I don't).

 

My interest was that with a serial port, the TI-99/4 could be connected to a shortwave radio and used to decode Morse code, RTTY (Radio teletype) and other, more exotic data modes like JT65, PSK31 and other.

 

Unfortunately, I simply do not have the skills or resources to make this a reality.

 

I was also curios to see if the commodore 1541 family of disk drives could be interfaced to the TI-99/4a, as they are serial devices, and it has been done before:- http://www.sharpmz.org/mz-700/mz1571.htm

 

I am very impressed with your work

[Sinphaltimus]

Oh my. There's an under exploited port right there. This is why I need to learn assembly....

[+Ksarul]

@mister35mm, there is a side port cartridge that interfaces the TI to a radio. It is called HAMSOFT and connects the cartridge to a signalling interface between it and the radio. They sold a lot of these back in the day. . .

[+jedimatt42]

The Forths can play with CRU at a higher level as well. These 2 wire interfaces with a clock and data are really slick. The XT and PS/2 keyboard is similiar. I2C puts more structure on the simple concept so that you can have a 2 wire bus... many devices connected at once. It seemed to me that the I2C data protocol would fit nicely as a subset of our PAB, and you could have a DSR for I2C.<address>.<extras>

 

But direct access like Stuart's is pretty interesting... (instead of building a PEB card or something)

 

Stuart, is there a way to maybe software disable/enable the joystick i2c interface, so that a program can keep the keyboard working, and maybe even the joystick working?

 

There are microcontrollers with Wifi built in that could be configured as i2c slaves... Realtime clocks, flash memory, etc... The possibilities are very open...

[+Vorticon]

Very slick! You should cross-post in the TI hardware interfacing thread as well as a reference for future use. Well done!

[Tursi]

Very impressive! I had thought you could not control both joystick drives at the same time, though...? Or did you build the hardware such that it wouldn't be necessary to?

 

Awesome work!

[Omega-TI]

Bloody freaking wow! I didn't see this coming. Its nice to know there are still surprises in life. It'll be fun to see what develops over the next few years out of this.

[ElectricLab]

I did suggest a while back that the TI-99/4a joystick port could be used as a Rs232 port of some kind for us poor bastards who don't have PEB (as I don't).

 

My interest was that with a serial port, the TI-99/4 could be connected to a shortwave radio and used to decode Morse code, RTTY (Radio teletype) and other, more exotic data modes like JT65, PSK31 and other.

 

Unfortunately, I simply do not have the skills or resources to make this a reality.

 

I was also curios to see if the commodore 1541 family of disk drives could be interfaced to the TI-99/4a, as they are serial devices, and it has been done before:- http://www.sharpmz.org/mz-700/mz1571.htm

 

I am very impressed with your work

 

 

There is a project where a guy did create RS232 functionality using the joystick port: http://www.mainbyte.com/ti99/joytalk/joytalk.html

It wouldn't be a drop-in replacement for the standard RS232 port and software would have to be written to use it, but a really cool project.

 

I am an active ham and I've always loved digital modes. In about 1987, I used to decode morse by feeding in the audio from my HF transceiver into a simple circuit with an LM567 tone decoder chip. One of the LM567's pins would go low when a tone of ~1000 hz, as controlled by an RC circuit, was presented in its input. I fed the output of the tone decoder into a 2N2222 to simulate joystick button presses, if I remember correctly. I was able to write an XB program to listen for pulses and calibrate to the sender's speed and could decode the dots and dashes into text up to about 10 WPM. Any faster than that, and the poor TI running XB couldn't keep up. I new zero assembler back then, or I'd have made it work a lot better. It was cool nonetheless. For modes like PSK31, you'd need some more computational power to sample fast enough to be useful, even though the bit rate is just 31 baud. If you were able to feed Q and I into a TI, you might be able to do something in assembly. There are some interesting standalone projects like this one that I bought when they came out: http://www.nue-psk.com

 

I still tinker with packet radio and am in the process of putting a digipeater on a hilltop near where I live so I can do some experiments. I fully plan on using a TI console at home using an RS232 port connected to an old TNC, running at 1200 baud.

[ElectricLab]

 

 

There is a project where a guy did create RS232 functionality using the joystick port: http://www.mainbyte.com/ti99/joytalk/joytalk.html

It wouldn't be a drop-in replacement for the standard RS232 port and software would have to be written to use it, but a really cool project.

 

I am an active ham and I've always loved digital modes. In about 1987, I used to decode morse by feeding in the audio from my HF transceiver into a simple circuit with an LM567 tone decoder chip. One of the LM567's pins would go low when a tone of ~1000 hz, as controlled by an RC circuit, was presented in its input. I fed the output of the tone decoder into a 2N2222 to simulate joystick button presses, if I remember correctly. I was able to write an XB program to listen for pulses and calibrate to the sender's speed and could decode the dots and dashes into text up to about 10 WPM. Any faster than that, and the poor TI running XB couldn't keep up. I new zero assembler back then, or I'd have made it work a lot better. It was cool nonetheless. For modes like PSK31, you'd need some more computational power to sample fast enough to be useful, even though the bit rate is just 31 baud. If you were able to feed Q and I into a TI, you might be able to do something in assembly. There are some interesting standalone projects like this one that I bought when they came out: http://www.nue-psk.com

 

I still tinker with packet radio and am in the process of putting a digipeater on a hilltop near where I live so I can do some experiments. I fully plan on using a TI console at home using an RS232 port connected to an old TNC, running at 1200 baud.

I'm a sucker for old tech.

[Willsy]

Stuart this is great. Any chance of implementing reads? Also multi byte transfers would be great. Devices such as i2c eeproms often support multi-byte transfers to enable streaming data into/out of the chip.

 

Does the lcd module (PCF8574?) not send an ack bit after sending the slave address?

 

I'm struggling to remember the protocol. I think the slaves drive SDA low for one clock after being addressed (so needs pull ups on SDA). And there's something about not clocking the last bit to indicate end of transfer (might be multi byte mode that I'm thinking of).

 

Great job!

 

Mark

Edited September 19, 2016 by Willsy

[Stuart]

>> Stuart, is there a way to maybe software disable/enable the joystick i2c interface, so that a program can keep the keyboard working, and maybe even the joystick working? <<

 

I'm sure with a bit more tinkering this could be done. Might need a bit more on the hardware side as well.

 

 

>> I had thought you could not control both joystick drives at the same time, though...? Or did you build the hardware such that it wouldn't be necessary to? <<

 

I use one of the joystick drives for the clock, and for the data I use the joystick UP input which conveniently goes to one of the pins on the TMS9901 that you can use as either an input or an output. It's normally an input for scanning the keyboard and joysticks, but I use it as an output. Need to (software) reset the 9901 before it can be used as an input for scanning the keyboard again though.

 

 

>> Any chance of implementing reads? <<

 

They work already (but didn't need them for the LCD display). Just need to set SDA high so the slave can pull it low, then a CRU Test Bit command on the relevant pin on the 9901.

 

 

>> Also multi byte transfers would be great. <<

 

Yep, no problem with those. Just need the device-specific code to make multiple calls to the I2C write/read byte routine.

 

 

>> Does the lcd module (PCF8574?) not send an ack bit after sending the slave address? <<

 

It does. With the I2C protocol, the slave sends an Ack(nowledge) bit after the slave address and each 8-bit transfer. So the master needs to send 9 clock pulses for each byte, with the last clock pulse for the Ack bit from the slave. I can see the LCD slave doing that on the 'scope but I just don't bother testing for it.

[ti99iuc]

There is a project where a guy did create RS232 functionality using the joystick port:

http://www.mainbyte.com/ti99/joytalk/joytalk.html

 

 

 

it should be this:

 

Edited September 19, 2016 by ti99iuc

[+Ksarul]

I started out maintaining teletypes, though most of the truly mechanical ones I touched were from Kleinschmidt, Teletype Corp, and Siemens.

[Tursi]

 

 

and for the data I use the joystick UP input which conveniently goes to one of the pins on the TMS9901 that you can use as either an input or an output.

 

oooh, beauty! I always wondered if that would work.

[ElectricLab]

I started out maintaining teletypes, though most of the truly mechanical ones I touched were from Kleinschmidt, Teletype Corp, and Siemens.

 

I have a collection of the things and I've gotten them printing with AVR microcontrollers, and more recently, with Raspberry Pis. I only have two that speak ASCII, since most of my collection pre-dates 1963 which I think is when ASCII became a standard. When I was a kid, my Dad had a model 19 hooked up to a radio and was doing RTTY. I became enamored with the mechanical wonders.

[+Ksarul]

I did a lot of work on machines using the older BAUDOT standard, and even some on the earlier Morse tape machines (one center hole to feed, one data hole for a dot and another in the same row to turn it into a dash). Funny you should mention Model 19s--they were the first machine I ever got a close look at, well before I actually started working on teletypes in general.

[Omega-TI]

 

I still tinker with packet radio and am in the process of putting a digipeater on a hilltop near where I live so I can do some experiments. I fully plan on using a TI console at home using an RS232 port connected to an old TNC, running at 1200 baud.

 

Wow, I didn't know packet was still popular except for maybe APRS. Back before the Internet started mucking things up with the HF backbone links, I was usually logging in via WA7SJN in Goble. Most guys were using 300 baud back then, but with my KPC 9612 hooked to my a dual band Kenwood V7A I was able to get a few high speed nodes, even MIR and the ISS.

 

I still have my old TH79AD that gets infrequent use as a monitor, but it would be kind of cool if guys get their HT's or even a basic scanner radio with their TI's to decode some of the slower traffic.

[ElectricLab]

Packet is largely dead, and is no where near as popular as it once was. I talked to the ISS once too back in the height of packet. Mostly what I see when I camp out on a frequency are beacons for mail relays. Not much actual traffic though. I would like to set up a station for doing packed on HF and relaying email for people - maritime mobiles and what not, but I don't know when I'll get time to set that up.

APRS is popular, but not terribly exciting for me. The Emergency Communications guys are all about the APRS, and there are packet nodes at many hospitals in my area and they're set up to exchange data in the event of infrastructure failure. There's that D-STAR stuff, but being proprietary and therefore against the spirit of ham radio, not interesting to me.

[Omega-TI]

Yeah, I went through that ARES & RACES phase myself, but seriously I think its more for the retired OM's who have the time. I was unable to live and breathe it obsessively like some of them expected.

 

Half-duplex voice communications and the digital modes (with no traffic) gradually lost my interest, especially since many of the Ham's I once associated with became silent keys, so in the end my licence expired unused.

 

I wonder if there are any Part 15 components a guy could cobble together to make a small network just for TI's working off the joystick port?