Page 1 of 10

[Featured][Alpha] CLAP - TI Link - http://clap.timendus.com

Posted: Tue 18 Apr, 2006 9:04 pm
by Timendus
Update:

I remembered yesterday that I had already made a website for this project about a year ago. I just never opened it for the public :)

So here it is, I polished it a bit, added an updated Link test tool, and put it online:
http://clap.timendus.com

Please do leave a message in the little homebrewn forum :)

Old story:

Okay, here's a first release of the assembly libraries, but it isn't for the faint of heart :)

I have split the routines up in three layers or levels;
Low level - Controlling the link port in an easy and machine independant way (104 bytes)
Medium level - Sending over bytes and synchronizing two calcs, depends on the Low level (172 bytes)
High level - Sending over strings and blocks of data, depends on the Medium level (106 bytes)

On top of that I'm building the networking layer, but that's still got a nasty bug, and very little functionality, so that isn't included in the zip file. You have to put the three libraries in a directory named CLAP in your project directory (preferably in Latenite), and only include the highest level you want to use. So if you include MidLevel.inc, it will automatically also include LowLevel.inc. It was built under Latenite and Brass, so I'm not sure if it'll work with a normal TASM setup. In fact I guess it will not :)

Anyway, once you got it all properly included you can use these routines, per level:

LowLevel.inc:

= Writing
- setHighHigh
- setHighLow
- setLowHigh
- setLowLow
- setTipLow
- setTipHigh
- setRingLow
- setRingHigh
- toggleTip

= Reading
- readLines
- readTip
- readRing

MidLevel.inc:

= Writing
- sendByte

= Reading
- readByte

= Other
- sync

HighLevel.inc:

= Writing
- sendString
- sendBlock

= Reading
- readString
- readBlock

For documentation on these routines, please check the source. Everything is pretty well documented. One thing I haven't really documented is that it's usually a good idea to check if clear is pressed immediately after you use a read routine. All read routines will snap out of their endless loops immediately when you press clear, and you'll probably want to handle that gracefully. I do it like this for instance:

Code: Select all

	call readByte	; Get a byte
	ld b,a

	ld a,$FF		; Scan for Exit
	out (1),a
	ld a,$FD
	out (1),a
	in a,(1)
	cp 191
	ret z			; Exit the program if Clear pressed

	; Start working with the received byte b here
That way it should be almost impossible to get stuck in some loop waiting for input that never comes, and having to pull your batteries :)

I also put in a little tool that's at least three years old, but that has proven to be very useful. I updated it to use the libraries and added some hidden functionality. When you run it, you'll get a little menu asking if you want to be calc A or B. Choosing calc A will enable you to controll the link port lines manually, choosing calc B will show you the state of the link port. The hidden functions are accessed by pressing 3, 4 or 5 in the menu. 3 sends out a picture using the data block functionality of the highest level, 4 receives a block of data and displays it on the screen (intended to be used with 3 obviously, for transfer testing and demo purposes), and 5 prints out the bytes it receives on the screen. Unfortunately the Ti-OS output routines appear to be too slow to be able to keep up with some transfers... :P

A funny thing you should try is get four calcs running in PTI (either Ti-83 or Ti-83+, or mixed types, should all work), put the link test utility on all four and run them all. Link all calcs to the virtual hub. Then choose 4 in the menu on three calcs and 3 on one. You'll see the same image pop up on all four screens after about two seconds :P

I'd very much appreciate feedback, ideas, opinions that you might have.

-= Download =-


Even older story:

When CoBB released PindurTI with a virtual four way "networking hub" last week, I was excited to get back to playing with networking, but I was in the middle of exams, so it had to wait. Today I finally had enough time to start playing with it, but to get some networking going on I needed to rewrite my normal two calc linking routines once more, in a more modular and simpler way.

So I did, and thanks to Latenite and PindurTI I got them running perfectly, faster than I have ever managed before. I now have a set of routines that can send a byte, a zero terminated string or a block of data to an arbitraty number of listing calculators. I managed to send "Hello world!" from one calculator to three others simultaniously in PTI, somewhere this afternoon, and moved on to sending a full screen image using the data block transfer, which I then used to clock the transfer speed at around 2.6 kbps. Not very fast, but nothing's been optimized for speed, and it's already fast enough for most purposes. The routines are completely modular and work for sending data between TI-83's, TI-83+'s, and whatever else using the same hardware configuration as the TI-83+ (That is Ti-83+SE, Ti-84+, Ti-84+SE and Ti-73 if I'm not mistaken).

So, enough boasting, what exactely is the project I'm announcing here?

Quite a long time ago, when I was working on linking with that TI controlled sweeper robot with Belgian students, I had a secret project going on. I called it CLAP (the Calculator Link Alternative Protocol), and it was supposed to greatly simplify calculator linking for both assembly and basic programmers, work for and between all z80 calculators, and ultimately allow for 2+ calc linking. Unfortunately I had no way to test my calc to calc routines efficiently, other than sending them to my calculator and borrowing my brother's calc, and no way at all to test linking with more than two calculators. So I kinda gave up on the project after a while.

But thanks to CoBB, I finally have what I need to be able to work on that project again; true emulated linking. At least I hope that it's the same as on hardware... :) Anyway, I now have a pretty decent link library for linking between two calculators or broadcasting from one calculator to a multitide of others. So that part is already pretty much finished, I just have to figure out how I want you to interface with it. Perhaps I'll add it to the API, perhaps I'll make it a seperate include, perhaps I'll make it a Latenite project template, I don't know.

Writing a multi-calc chat program with these routines is no challenge, You'd just connect them to a few API routines and be done with it. Besides, that wasn't the original goal for CLAP. So I'm planning on a much cooler demo. A true network of calculators collaborating to get something done. It's gonna be cool, you'll see ;)

Anyway, I'll soon release those linking routines, which everyone should be able to use in their programs, because they are easy to use, modular in design and well documented. From there on I'll continue working on networking (at a slow pace though :)), in an attempt to make that work, and ultimately make it easy to use for everyone as well. I hope to get the first results tomorrow.

You opinions about the concept are very much appreciated :)

Posted: Tue 18 Apr, 2006 11:26 pm
by tr1p1ea
Wow, thats great. I was hoping that one day you would release some linking routines.

Im sure that these will benefit anyone who wishes to make a program/game with linking.

Posted: Tue 18 Apr, 2006 11:30 pm
by Liazon
Linking is so important for multiplayer action games. Go for it!!

Posted: Wed 19 Apr, 2006 12:27 am
by kalan_vod
Sounds great, I guess I could say "I hope to get the CLAP soon!" >.> This will be a program and not an app for us basic programmers right?

Posted: Wed 19 Apr, 2006 12:54 am
by DigiTan
This is really good to hear. I think the limited link emulation in the community was stifling multiplayer development.

Posted: Wed 19 Apr, 2006 2:43 am
by Treefrog
Sounds pretty cool. Best of luck to you.

Posted: Wed 19 Apr, 2006 3:58 am
by katmaster
This really sounds awesome! I always wished there were more link games then just bomberman and falldown. (and a few others that dont work very well)

Posted: Wed 19 Apr, 2006 7:36 am
by Timendus
Thanks y'all. I too hope that this will finally get more people writing cool link games :)

@kalan_vod: The Basic interface is something I haven't really thought about yet. It'll probably be a program that you use to send a value on one side and receive it on the other. It would be a lot more work to make it work with the TI-OS variables, and for silent transfer you'd need to use the Ti link protocol, not mine...

Edit: Perhaps it would be better if Tr1p could put them in xLib?

Posted: Wed 19 Apr, 2006 9:14 am
by L4E_WakaMol-King
Forgive my ignorance, but how does one link 2+ calculators together? I didn't know that kind of hardware existed.

A chat program would be a cool program to test this out, but if people will have to be hard-wired together (?), it might not find a lot of use. Perhaps once the library is done, someone could look into a game like Chineese Checkers or even a multi-player shooter?

Posted: Wed 19 Apr, 2006 11:43 am
by Timendus
No, such hardware doesn't really exist, not in an electronics shop anyway, but it's very simple to make a hub yourself. To create a hub like the one PTI currently emulates, all you have to do is get four female stereo 2.5mm plugs and a bit of wire to connect them all. Tips to tips, rings to rings, bases to bases. Put that in a nice square box, and you've got a hub that you can plug calculators into with normal link cables.

I've never tested this, unfortunately, I guess I should do that (unlike some people who've been working on this) before I release a network version and get people's hopes up.

Chatting is pretty useless indeed, and I've already made a chat program with a friend of mine years ago. But it's a library, so anyone can use it for any purpose.

Posted: Wed 19 Apr, 2006 3:08 pm
by kalan_vod
Would you be including a schematic of the hub? I think more would give it a try if there were some plans for it. Also I think adding it to xLIB would be great, he did say he had a little room left :P.

Posted: Wed 19 Apr, 2006 4:28 pm
by DigiTan
Well, basically the hub is all the links diasy-chained together. Calc software takes care of everything else.

Posted: Wed 19 Apr, 2006 9:55 pm
by Timendus
Exactely. But I'll draw up some "scematics" anyway :)

So far the networking part doesn't want to do much. It's handing out addresses perfectly, logging in on the network runs like a charm, but something seems to be going wrong when I send a "packet" from one calc to another... :( Like it isn't receiving anything... *sigh*

Edit: See first post in this thread for a first release

Posted: Thu 20 Apr, 2006 4:48 pm
by KermMartian
Congratulations, Timendius! Once again, you amaze me and beat me to it. ;)

Posted: Thu 20 Apr, 2006 8:54 pm
by Timendus
Ah, yes, your global calc net... I had forgotten all about it. I still think it's neither technically achieveable without making it your life's work, nor practical in any way to link small networks of calculators together over the Internet, and still expect performance. But on the other hand I've already brought you one step closer I guess :)

Well, you still have a chance to beat me to writing actual networking software. Mine still refuses to receive packets once the network is operational, and I have to focus my attention on my other (PC) projects again, so that's back in the freezer. I am this close however... :)

To answer the question you PMed me, of course you can use the routines and the protocol in DCS, like everyone else. These routines, as well as the network library once I finish it, are free software, with an open protocol, like it should be. A little credit for the work and research would be appreciated though of course.

Which reminds me, I should document the protocol... It's all pretty simple now, but the networking part could get interesting...