********************************************************************************* From: "Bryan Christopher Turner" -------- Alright! I got it, I figgured out how to control the red and white lines explicitly! I havn't looked at reading the line states yet (just got the writing down this morning before classes). I'm sure if you can write to the lines you can also read from them. What's the next step? I'd really love to get an expander for my 92, and I'd be happy to write the driver for it too. (I noticed you were about to raffle off the expanders). In the environment of openness and freedom, here's how you control the 92's port wires: Set the Write Mode Active bit (arbitrary label): BSET #6,$60000C (TI-ROM often writes the value $E0 to this location, which includes setting bit six as above, but I don't know the purpose of the other bits at present) Then the individual Red/White lines are controled by: BSET/BCLR #0,$60000E - Red? BSET/BCLR #1,$60000E - White? As I said, I did this just this morning on a hunch before class, so I havn't even checked which wire was plugged into which LED.. But suffice to say I can control the wires independently and precicely. Where can I get the protocol information for conversing with the expander? --Bryan bcturner@eos.ncsu.edu ********************************************************************************* From: "Bryan Christopher Turner" -------- > > I think I'm gonna try to setup my TI-92 and test what you have done. > I only have limited fargo experience so this will be my first fargo > assembly program, but I've got lots of people on IRC to help me if I > get stuck. :) > Ok, here's full confirmation. I reset the calc, installed Fargo and Raven (my 68K debugger/hexeditor), attached the link cable to my tester and set the memory as such: :RW [60000C] <.6......|........> = set: Link port override Then, I could toggle either line (and maintain a stable signal indefinitly) by changing: :RW [60000E] <.......0|........> = Red control <......1.|........> = White control Also, I could read the signal sent from an outside source in: :RO [60000E] <.....2..|........> = Red status <....3...|........> = White status The bits above also mirror the signals of bits 0 and 1 if we write to them. ie: setting bit 0 automaticly sets bit 2, however if bit 0 is not set, and an external signal pulls Red high, bit 2 is set. The work you examined (pulling one to ground sets 60000E to C etc..) is a byproduct of the link port interrupts. If you set the link port override bit, and clear the other bits (or possibly just setting the override bit) will cause the lines to be individually distinguishable. Also, no bits of 60000F change at all during this operation. I never actually tested those asm commands, and I checked ROM for similar stuff, it uses bit 8 and bit 9 of $60000E.w (that is, using a full 16 bits starting at $60000E with highest bits first). This corrisponds to bits 0 and 1 of the first byte. I have a project due friday and I won't be able to assemble anything till this weekend. Try the commands: move.b #40,$60000C ; revised: byte sizing (.b) bset.b #0,$60000E ; set Red wire high bset.b #1,$60000E ; set White high delay: move.l #7ffff,d0 ; Hopefully a long enough delay to be visible dbra d0,delay bclr.b #0,$60000E ; clear Red bclr.b #1,$60000E ; clear White move.b #$8D,$60000C ; Clear link override Of course, substitute bset and bclr at will but be sure to include the (.b) extention. Also, pick up a copy of Raven from the Fargo Archive, I wrote it with this type of thing in mind. Let me know if you confirm it, or need more info. I think we got it. --Bryan bcturner@eos.ncsu.edu ********************************************************************************* From: "Bryan Christopher Turner" -------- > > I just want to congradulate you on your fine work. You will get FULL > credit for this. Do you want me to post the news on the webpage? > > His program seemed to lock my calculator every once in a while Yay! Hopefully I'll get a shot at an expander now, I have and 85 but I don't use it much since purchasing the 92, and since the expander wasn't available for the 92 yet, I didn't put in an order. My guess about the crashing: either normal programmer error, OR, if the override bit is not set when you set BOTH control bits, the calc will hang. I knew I had found the right port control bit when I could set both red and white control bits at the same time without hanging. > > One clarification/question: Do we know what the other bits in $60000C > do? Should they all be cleared and just have bit #6 set, or what? > What happens if we exit a fargo program with the bit still set to this > position? And finally, do we need to disable/enable interrupts and > what effects does this have on operation? You said that setting bit > #6 overrides this but are you sure? > I did not test what happened if the other bits were left. I cleared them, and set the override bit. I do know that if you don't set the byte at $60000C back to $8D when you leave, the link port is inoperable. I tested each of the bits for individual function in the byte $8D, but none did anything special independently. Setting two of the bits often got a timeout error from my computer instead of a link cable not connected error. Resetting it to $8D enables all link port operation - ie: the normal state. > Would you like for me to publicly post this information now? Or just > post that we have figured it out and not give details? I don't have any burning need to let it out if it will help you for some reason. But if you don't gain any advantage for keeping it secret, then by all means, let the Fargo community know. If left to my own ends, I'd send a blurb to David Ellsworth to update his Ports.txt file. > I am attaching the sourcecode to my Beta expander driver software, so > you can see what is involved with the actual sending and receiving. > I'm not sure how much you know about Z80 or zshell, but here you go. > Really though I should be the one to write the driver, unless you have > a burning desire to do so. I would have written it a while ago had > this information been known. What do you think? I think you know best about the driver aspects.. I've programmed 68K asm professionally so if you need help converting, etc.. just let me know. Also, if I don't catch an expander off the raffle, I'd really like a chip next time you find a batch. --Bryan bcturner@eos.ncsu.edu