It include a console interface, which allow to chat with 9 networked calculators, and an animation in which calculators sharing their screens and display bouncing balls.
It's not a serious project, juste a little demo of networking program for others developers.
Is it actually using a networking protocol, or just the calculators' point-to-point protocol? I wish I had had more than nine calculators that were running when I made that video, so I could have demonstrated more. According to my calculations, at least one hundred or so TI calculators could be on the same local branch of a CALCnet network before you start seeing major signal degradation, and of course since the protocol has a 256^6-device address space, you could link all the calculators in the world together through some bridges and not run into problems. Regardless, this looks superb, and I hope to learn more about how it works.
It use network identifier on one byte. Value 255 is used as recipient for broadcast messages. 254 is a control character for end of message. So the protocole can be used for 253 calculators (id '0' mean "not logged").
The low-level protocol is simply : <recipient><sender><data><EOM>
EOM=End Of Message=254.
data is an array of 61 bytes max (64 bytes max for the whole message).
In high-level, there is different kinds of data, with a header system.
But electrically, do the calculators allow themselves to be connected together that way? I assume it uses the built-in RS232/serial capabilities, correct? I didn't think that supported a multipoint network.
Hm, I don't know exactly what happens electrically. The program just send and receive data. But I imagine that if you connect the sender wire of a calc to the reveiver wire of 2 others calcs, they will both receive the message.
Am I wrong?
Hm, I don't know exactly what happens electrically. The program just send and receive data. But I imagine that if you connect the sender wire of a calc to the reveiver wire of 2 others calcs, they will both receive the message.
Am I wrong?
Well, among the things that you need to consider (which is why there were eight years between me first designing CALCnet and publishing CALCnet 2.2 in Doors CS! ):
:: How to arbitrate so that multiple calculators don't try to talk at once
:: How to assign addresses on-the-fly without a "server" calculator (CALCnet solves it by using each calculator's unique ID). Earlier versions of CALCnet actually used a client-server protocol
:: A unidirectional send protocol with no cooperative timing or global wallclock, so that calculators don't need to sync with each other
:: Error detection/correction: the more devices on a network, the more noise, and the more probability of bit flips.
:: Delivery acknowledgement for directed packets so that delivery guarantees can be made
:: Other things that I'm too tired to remember
I'd actually be very curious to learn more about the serial protocol the calculators use and how you leveraged it for your protocol. I was very sad when I discovered I couldn't literally implement CALCnet on Casio calcs since both data lines are unidirectional.
Oh, there's another problem - you need to swap tip and ring going from calculator A to calculator B, so what happens when calculator C joins? Either way, it will only be able to speak to one calculator.
what can flourish for the Prizm do and what are the controls?
It's a unit-to-unit transfer using the serial protocol rather than a neworking protocol. Like my own Flourish, it has no controls, but simply showcases the balls traveling between the two screens to show that the calculators are communicating.
what can flourish for the Prizm do and what are the controls?
Start by giving a number to calcs (e.g. "1" for the left one and "2" for the right one), then press [0] to start the balls animation, or press [EXE] to send a message to another calc.
And naturally [EXIT] to stop animation or disconnect.
Looks nice; good music as well. How much modification would be needed to test this out on a prizm? (So I can link my 9860 and CG10)
I'd figure it'd probably just involve changing the frontend graphics for the Prizm version of it. That is, of course, if the prizm and 9860 share the same linking protocol/hardware.
Oh, there's another problem - you need to swap tip and ring going from calculator A to calculator B, so what happens when calculator C joins? Either way, it will only be able to speak to one calculator.
Just a theoretic idea:
We can create simple 2 wire bus ( open collector bus with 1 wire data and GND).
Each calculator will connect it's RX do the data wire (and of course GND to GND wire). The TX pin will go to the data wire through diode so logical 1 will not affect the data wire, logical 0 will write it to the data wire.
Data packet should be short (and may have fixed length). Each calculator will receive everything - it's own output included.
So the collision can be solved - calculator may transmit if there is idle on the bus (no data receive for a while). Calculator is transmitting byte after byte and it compares each byte with the received one. Mismatch means collision - so calculator will probably need to wait some random time and then (if bus seems to be free) retry.
The bus may need external pull up (or each calculator will have weak pullup - parallel resistor to the diode) Particular values of the resistor are based on values - how many calculator will be connected in the network, how strong is logical 0 on TX.
I do not have enough programmable calculators to try this but I can help anybody if interested.
MPoupe, the protocol you describe would work, but it would be relatively slow and unreliable compared with something like CALCnet, because you have no out-of-band information to help synchronize, coordinate, or indicate bus status. With a one-wire protocol such as what you describe, you need to add a lot of extra guarding to make sure each calculator is properly seeing the start of each packet and byte, and that no collisions or noise have caused random bit-flipping errors. It would of course work, but I worry that compared with a two-wire protocol, it would be much slower to achieve reliability.
...It would of course work, but I worry that compared with a two-wire protocol, it would be much slower to achieve reliability.
Yes, but you do not have 2 wires for the Casio calculator. So it is better than nothing I think.
Agreed, unless we can figure out how to use each line bidirectionally, which I would prefer. Especially since it would let us generate stereo audio as well.
Do we know what is between CPU and the 2.5 mm stereo socket ?
There may be some amplifier on TX and some CPU protection/ voltage reduction on RX. For that case bidirectional pin access would solve nothing.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum