So that means the USB lines can't be controlled directly? Of course, the idea never was to implement "the missing parts" of USB (i.e. anything other than the Mass Storage emulation), but to send custom data through the USB port (in ways that do not conform to the USB standards).



There are? Can you please tell me where? I'm looking for some technical reading for this evening

So, if you can find the port that can toggle the D- and D+ lines, you are golden. You need to make sure that you some how disable the USB controller and stop the Prizm OS's interrupts from firing and checking the USB. This is only theoretical.

What do you exactly want to do? And what will be toggling the lines?

Well I was only wondering if the USB could be an alternative to the 3pin port for bidirectional data communication (two lines that could act as both Tx and Rx, vs. one Rx line and one Tx line). I was thinking on communicating with other calculators using the existing CALCnet protocol, or even something simpler like a file-transfer-only protocal for faster transfer than what is possible through the serial 3pin port using the OS methods.

You could always just use the controller as it is and use the OS functionality to communicate over USB. You might get away with using a different protocol and a different gcn client to translate the Prizm's protocol to the correct Cn format.

Are you looking at unit to unit linking, or unit to PC linking for gcn?

@Someone who knows, how specific to the ti8x is the direct USB connection protocol for CALCnet?

Actually, it's even worse than that: the particular model of SH3/4 CPU that that part of the IP is from doesn't allow either line to be bidirectional, so we're completely stuck on that point. Stereo audio over the I/O port will never be possible, and native CALCnet without an adapter will never be possible. Of course, with something like an MSP430 or an AtMega 328, an RS232 to CALCnet adapter would be trivial, but translation hardware is always a pain.

Not a problem on the audio: with just 16MB of memory, it's not like you would store many minutes of music on there, and add-ins can never get big enough to include many stereo sounds.
If we ever get the ability to read SD cards on the CG10/20, and it is great enough for storing many minutes of music, it will likely be through developing some Arduino-ish thing for reading an SD card and transmitting its data over the 3 pin port. But if the 3 pin port is used, how would you play audio?
My conclusion:other than the purpose of "we can do it", there isn't really an use for stereo audio on the Prizm.



In that case, my opinion is that it will be easier to develop a Prizm-specific network protocol in case we ever want to do something like CALCnet for it, instead of forcibly using an adapter even for network communication between two Prizm (that would be translating from CasioNet to Cn, and then from Cn to CasioNet, when a direct CasioNet connection would be faster and simpler.
A computer or some dedicated translation hardware could provide a compatibility layer between the two protocols for talking with TI calcs. (and if we use a computer already, that means it will also be easier to connect Prizms to the gCn; in fact, I think it's easier to start by connecting Prizms to the gCn than raw device-to-device Cn connections).

And luckily, that's not even necessary, as there are well-defined multi-device protocols for ports electrically-compatible with RS232. Therefore, we just need to port over one of the existing protocols, if I am remembering my history of networked communication correctly. Something is nagging at my mind about RS-484 or something along those lines. After looking it up, it seems that RS-485, the successor to RS-484, is not in fact electrically-compatible with a two-wire RS-232 port. Like CALCnet, I2C requires two bidirectional lines, rather than two unidirectional lines, so that's not really an option either. SPI is essentially a four-wire bus, making it totally useless. It looks like this protocol or something close might be a good option.

There is so much to learn about this calculator and I am still confused about many things on it...

What I am wondering is if it is possible to develop a chat addin to work between just two calculators using the 3pin calculator to calculator cable? Or no chance for that?

Reading this threat I am getting confused about the 3pin cable itself - aren't 3 pins: 1 for TX, 1 RX and 1 GND... so why would the 1-wire etc alternatives be needed or suggested?

Sorry for the questions and many thanks for your explanations in advance

Very easily. I doubt you'd even need to use C for this; Casio's BASIC variant might expose the necessary serial commands.

I'm not sure I understand this question. It's an RS232 serial port: GND, TX, and RX, as you said.

It doesn't; you really need C for this. (Casio BASIC does expose some serial functions but which, IIRC, are for communicating with E-Con2 devices, and thus are not appropriate for calculator-to-calculator communication.) With that said, the syscalls controlling the serial port at a lower level (and thus uncoupled from any Casio-specific protocol) have been discovered and are documented. See http://prizm.cemetech.net/index.php/Category:Syscalls:Serial .

Ahhh, that makes a lot of sense, just as the Send() and Get() commands in TI-BASIC are primarily intended for communicating with a CBL/CBL2 device, not with another calculator. Thanks for that clarification.

Many thanks for all you help, c is what i am more familiar with, let me absorb those things- i have to admit it is a bit overwhelming for me still.

Would you have any examples of how chat would work, I'm confused which system call does what... I have looked at the flourish addin for casio but struggle compiling it on my windows machine so haven't learned much from it yet. Would this have all the ingredients needed to create calc to calc chat add in?

Another question just out of curiosity regarding ti-basic - I don't know this language and understand that it is for other non calculator devices but wouldn't you be able to make a receiving calculator to believe it is communicating with such a device ( ie sending calculator could pretend to be something else) and this way utilise os built in interface at least for receiving popups or so. Probably not a viable solution but just curious if you know...

I would love a chat program which gives a popup for receiving messages even if you are in another app basically - do you think it is possible

By 3pin cable i meant the cable which came with the calculator - was i wrong to assume it is a three wire cable or is it still that but there are some problems how rx, tx and gdn are implemented, ie you need bidirectional not unidirectional setup for wifi etc?