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:
Please do leave a message in the little homebrewn forum
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:
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
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...
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
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