Bell release v0.2!
Posted: Thu 09 Nov, 2006 9:11 pm
Bell release v0.2
(Binary data Exchange Link Library)
http://bell.timendus.com/
Download latest version - Thursday 16th of november 2006
(Library and manual only, no demo software included)
Things it can do
(Binary data Exchange Link Library)
http://bell.timendus.com/
So, it's hereTimendus wrote:My point of view here is that I want things to work, be simple and preferably be fast. Or at least fast enough to be useful.
I think I'm going to have to make two versions of the library (and the protocol); one that is optimized for simple data transfer between two(!) calculators, mainly aimed at game programmers who need speed and don't care about the theoretical possibilities of networking [...]
I want to make a simple, small and fast library using some implementation of TI's protocol that can exchange bytes, data blocks or strings fast from one calculator to another to accomodate game programmers [...] it uses known technology in a welltried manner and only the wrapping is more shiny than TI's version (it should be more easy to use, better documented, and perhaps a tad faster, but that's about it). I hope to be able to release that rather soon.
Download latest version - Thursday 16th of november 2006
(Library and manual only, no demo software included)
Things it can do
- Set up a connection between two calculators, uniquely identifying the two and checking if they are running the same program
- Swap data without the user having to worry about who goes first
- Send data from one calculator to another in the form of a byte, a block of data (max 255 bytes), a large block of data (max 65535 bytes) or a zero terminated string
- Autodetect the calculator model you're compiling for (currently Ti-82, Ti-83 and Ti-83+ series are supported and tested for, Ti-84 "should work" but I don't have a rom image for it) and configure it's hardware control routines to match at compile time
- Alert the coder about errors by always returning a status flag in z (nz is always an indication that an error has occured)
- Be compiled with your requirements only (by commenting what you don't need)
- Use a user-definable timeout duration (you can even turn the feature off)
- Output the selected hardware type (or an error if it wasn't able to detect it) and the number of bytes that the library takes up in your program to the compiler output
- Compile for Ti-85/Ti-86 or other calculator models
- Detect a connection "on the fly" (without having to wait at the "waiting for opponent" screen) - though I'm not sure if anyone would want/use this
- Detect data transfer corruption (I plan to implement a simple parity bit check, but I doubt it's neccessary..)
- Detect if the other calculator wants to send anything before going to receive mode (I'm not sure how to implement this yet)
- Connect more than two calculators; that's what the CLAP project is for, this project didn't get it's own name for no reason
- Alexander Graham Bell may not have been the inventor of the first telephone, but it was Bell who made it popular and who, through his company, made it possible for ordinary people to make phonecalls. That's pretty much what this library should do; it's not really anything new, nothing that hasn't been done before, but it should make a different kind of electronic communication more popular and much easier to use.
Apart from that, the word "Bell" nicely fits with the word "Clap"
- The source code is heavily documented, and you can find the manual here or in the download zip file.
- The speed of a transfer routine is always difficult to determine, so I'm not even going to try to be accurate, but the routines take approximately 7 and a half seconds to transfer 10000 bytes from one calculator to another in PTI. Seeing that PTI nicely reports the calculators to be running at 100%, I guess I could base my calculations on that. 7.5 seconds for 10KB makes 1.33 kB/s or 10.66 kbps. According to this website that pretty much rivals the Ti-OS routines, or it may even be a slight bit faster. Anyway, I think the demo speaks for itself.
The connect routine is a bit slow though; as you may be able to see in the second screenshot it takes almost a third of a second to conclude that the programs aren't compatible. It's slowness is probably also the main reason why I can't reduce the timeout any further in the demo in the first screenshot (which is why it takes a while before the "connection lost" message appears). It's not really a problem as you only have to go through that routine once, but it would be nice if I could improve it.