[Staff][Alpha] Emerson - TI-83+ Keyboard/Mouse

Here you can find side projects of the staff and great projects which we think should get extra support. (Note that featured projects are not projects by staff members of MaxCoderz)

Moderator: MaxCoderz Staff

Post Reply
User avatar
benryves
Maxcoderz Staff
Posts: 3074
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

[Staff][Alpha] Emerson - TI-83+ Keyboard/Mouse

Post by benryves »

This isn't a proper project, but couldn't really decide where to put it. Mods, move as you see fit. :)

It's posted in my GDNet journal;

http://www.gamedev.net/community/forums ... ?jn=273102

Image

EDIT: Changed name :)
Last edited by benryves on Tue 21 Feb, 2006 1:11 pm, edited 1 time in total.
User avatar
dysfunction
Calc Master
Posts: 1454
Joined: Wed 22 Dec, 2004 3:07 am
Location: Through the Aura

Post by dysfunction »

Heh, my mom actually bought me one of the TI keyboards (they're $40) so that I would take notes on it in class. I still use it all the time, though not much for taking notes I'm afraid- rather for writing my stories and such. Unfortunately, I wish there was a better word processor than NoteFolio that worked with it... :(
Image


"You're very clever, young man, but it's turtles all the way down!"
User avatar
tr1p1ea
Maxcoderz Staff
Posts: 4120
Joined: Thu 16 Dec, 2004 10:06 pm
Location: I cant seem to get out of this cryogenic chamber!
Contact:

Post by tr1p1ea »

This is pretty sweet Ben :). How funny would it be to turn up to class with your calc and a full sized keyboard, then start taking down notes :).
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."
Image
Image
Andy_J
Calc Master
Posts: 1110
Joined: Mon 20 Dec, 2004 10:01 pm
Location: In the state of Roo Fearing
Contact:

Post by Andy_J »

dysfunction -- any program that uses _getKey should work with it.
ImageImage
Image
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

That's really cool Ben :P
Especially considered how many people tried this before and failed to properly debug it - I will not point any fingers ;)

Will you release the include once it's finished?
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
benryves
Maxcoderz Staff
Posts: 3074
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Timendus wrote:Will you release the include once it's finished?
Yep - I'm sure a link port expert such as yourself could do a better job at this than me (ignore the at_get_byte routine in the journal - I've neatened it up a bit since) but I'm trying my best :)
User avatar
kalan_vod
Calc King
Posts: 2932
Joined: Sat 18 Dec, 2004 6:46 am
Contact:

Post by kalan_vod »

This sounds really cool, I want this to be finished don't fail!! :P .
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

benryves wrote:I'm sure a link port expert such as yourself could do a better job at this than me

Oh, cut that crap :) First, I think you're at least as good at this shit as I am, probably (much) better. Second; if it works, it works :P

Nonetheless, I am curious to see your final source ;)
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

Congrats Ben! I only was able to get halfway along where you did in this time, excellent work.
Image Image Image
User avatar
DigiTan
Calc Master
Posts: 1069
Joined: Fri 04 Mar, 2005 12:52 am
Location: NW Wisconsin
Contact:

Post by DigiTan »

Alright! 'Bout time the TI keyboard came along. Any possiblity of an XXR dancepad? 8)
My diet consists of nails, code-stealers, and HP fans.
Projects:

Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
CompWiz
Calc King
Posts: 1950
Joined: Thu 13 Oct, 2005 1:54 pm
Location: UB

Post by CompWiz »

Well, all we need is a USB dancepad, like this one for example, and a calc driver. That is, as long as you have an 84 series calc. :)
In Memory of the Maxcoderz Trophy Image
User avatar
benryves
Maxcoderz Staff
Posts: 3074
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

@Timendus; you've done considerably more with any sort of linking than I have, so I'm sure that you wouldn't be making some of the silly mistakes I am making :roll:

@Kerm; thanks! Did you ever get anywhere with connecting a mouse? It uses the AT protocol, I know that much, but I can't receive any bytes from my mouse. The only thing I can guess is that it's sending data at a significantly higher clock rate that the TI can't cope with (it's tight enough with a keyboard!)

@DigiTan; if you can find one that works as an AT or PS/2 keyboard (PS/2 keyboards use the same AT protocol, just a different sized/shaped connector) then yes. ;) Chances are, unfortunately, slim...

I've fixed the at_send_byte routine so that I can now successfully send bytes to the keyboard. Same link as before for the way I'm handling events!
Kozak
Maxcoderz Staff
Posts: 791
Joined: Fri 17 Dec, 2004 5:33 pm
Location: On the dark side of the moon.
Contact:

Post by Kozak »

You could also use the calculator as a external MIDI control device. Then you can link output from a calculator to functions in music programs (like Ableton Live). You would have to give it midi output then though. But usefull to mix music, control volume, effects, etc.
"They say that sea was created by a man named Maarten Zwartbol, a long time ago...." - Duck, an old Corbin version
User avatar
Timendus
Calc King
Posts: 1729
Joined: Sun 23 Jan, 2005 12:37 am
Location: Netherlands
Contact:

Post by Timendus »

benryves wrote:Same link as before

It keeps loading indefinitely... :?
http://clap.timendus.com/ - The Calculator Link Alternative Protocol
http://api.timendus.com/ - Make your life easier, leave the coding to the API
http://vera.timendus.com/ - The calc lover's OS
User avatar
benryves
Maxcoderz Staff
Posts: 3074
Joined: Thu 16 Dec, 2004 10:06 pm
Location: Croydon, England
Contact:

Post by benryves »

Timendus wrote:
benryves wrote:Same link as before

It keeps loading indefinitely... :?
GDNet is down, by the looks of things.

Reliability

I'm sure you wouldn't want to use a keyboard that was inaccurate. Unfortunately, (as you might have seen me moaning in the past) the keyboard generates the clock signal. This basically means you need to be constantly checking the clock line to see if it goes low - that or use a hardware interrupt the jumps in and receives the scancode packet when the keyboard decides you want to stop sending something.

Well, I don't have the luxury of an extra keyboard chip or a hardware interrupt, so I needed to don my thinking cap. I had thought that one possible way around this would be to send a "disable" command to the keyboard after receiving bytes, running my handler code, then sending an "enable" command - these commands clear the keyboard's buffer, unfortunately, which is not good.

I downloaded another document on the AT protocol to see if they mentioned anything useful, and lo and behold:

The host may inhibit communication at any time by pulling the Clock line low for at least 100 microseconds.

I think I can spare 100us - I added the line ld a,1 \ out (bport),a to the end of my buffer-filling code from earlier (it fills a scancode key buffer) - and the code doesn't drop a single scancode. Result!

Providing useful functionality

All these keyboard routines do at the moment is to display the data coming in on the screen - not exactly a great use of them. What is really needed is a simple two-way handler - it calls two different user-defined routines based on what a key is doing, whether it is being pushed down or released.

For this, I should translate the scancodes into a new format - there are less than 256 keys, so there's no reason why I can't fit every single key into a byte.

As well as user-defined keyboard events, I'll have to add my own to handle toggling the status of the keyboard - the num/caps/scroll lock as well as the shift/alt/ctrl.

It's really quite simple to do. Basically, I just run through all the received bytes. I check for $E0 (if so, switch to the alternate scancode conversion table for the extended codes) then $F0 (if so, load the alternate handler for a key up event rather than a key down event) then look up the scancode on the selected code table.

I created a couple of very basic event handlers - the key down event displays ↓ followed by the adjusted key code, the key up event displays ↑ followed by the adjusted key code.

Image

What would be ideal would be to provide internal event handlers that could be called on keyup/keydown which would then jump over to the user's custom handler. These event handlers could look for special keys and adjust the keyboard LEDs and set internal flags that could be used to detect the status of certain keys. I'd need:

Num Lock
Caps Lock
Scroll Lock
Shift
Ctrl
Alt

Unfortunately, I think that there is a problem with my byte-sending code. Setting the keyboard LEDs starts to do strange things - I now have two options;

1 - After switching status, ignore the LEDs. The status flag is set correctly internally, but you can't see it on the keyboard (which is a bit pants).
2 - Update the status flags every single time we run through the loop to check for any new bytes (which makes the keyboard lag like crazy - there's up to half a second of buffering going on!)

Mixing-and-matching the two - rewriting the branch before we bring the clock high again (for maximum speed) confuses the keyboard - the status LEDs never change and it decides to disable itself in a strop until I send $FF (the reset command) again. I think it's time to revisit the at_send_byte> routine again to see what it's doing wrong!

Well, comparing it to my new notes - it's actually completely wrong at the end, when it comes to sending the parity/stop/ACK bits! A quick rewrite to how I think it should go isn't too hopeful - the keyboard LEDs flash like mad. Tweaking the timing by throwing in a few calls to _wait_bit_low and _wait_bit_high to synchronise my data to the clock stop this completely - and now the code is as it was before, at 100% accuracy - but about twice as fast.

Replacing my branch code still doesn't work all the time - sometimes the LEDs change, sometimes they do not. Not believing it would work, I threw in a check for the ACK bytes returned - if they were $FE, the 'repeat last command' byte, I'd send again.

My routines were clearly not as broken as I thought - the keyboard LEDs now change status perfectly, and as much as I hammer the Num Lock, Caps Lock and Scroll Lock keys, I cannot lock up the program or get the keyboard LEDs to display the wrong value. Not to mention that keying in other keys is back to the lightning fast response they used to be...
Post Reply