I was working on this project before
@gbl08ma diagnosed my calculator as having passed away (read, mysteriously bricked) after only 2 days... Figured I'd post what I have right now before marking the project as inactive. (Until I get a new one, DJ lends me his while taking extra care to not brick it and/or someone somehow figures out how to unbrick it, that is. I never really heard of those calcs being bricked this easily, having known... Oh well. That's a real bummer.)
I had this idea the other day, why not porting a TCP/IP stack to the Prizm? With a protocol like SLIP or PPPoS, that would definitely work over the serial port. That would kinda be like CalcNet, on the TI-83+ series, but you won't need an Arduino or something. (Well, I use one, but you don't even need the Atmega chip on it. Only its TTL converter so you'd have a serial device on the computer.) Who knows all the applications you could do with that? That would be quite nice.
Right now, there's some sort of scrolling UI that basically works (should be useful for an IRC client) and the start of a port of the TCP/IP stack.
Anyway, here's the code: https://github.com/juju2143/PrizmIRC
I don't know if it's possible to unbrick the calculators. You would need to ask glb08ma or on Cemetech, where many people had bricked calcs. But I could lend you mine if you make sure it stays in good condition (granted, it could brick itself at any moment since it's old and stuff but I would rather see it bricked through development than a rainstorm or something :P), so you can develop again (I don't do much PRIZM dev right now).
As for a TCP/IP stack for the PRIZM or Internet, my main concern is that I recall hearing a few years ago that unlike the TI-84+ I/O port, the Casio PRIZM link port can only send data in one direction at a time rather than two, or something like that that apparently would have prevented a Calcnet port. I wonder if there would be a way around that, though. Have you gotten any online connectivity success so far in the code above?
The TX and RX lines are separate, so theorically you'd have a duplex connection, but I don't know how it's handled by the OS syscalls or inside the calc. Anyway, I didn't had time to test the online code yet, but I've been able to have a Linux (and Mac!) shell over the serial port.
Ah I see. And nice! I didn't realize you had such progress done. Hopefully you can showcase a proof of concept in the near future :)
You can't have duplex because of hardware limitations. IIRC, people found out that only one of the lines could communicate in both directions, or perhaps not even that, I can't quite remember.
Well, TX and RX means you have 2 lines, one going one way and the other going to the other way? No need of them going both ways. Shouldn't be any problem with that, unless the lines are somehow joined inside the calc.
The library I wanted to use should deal with it.
Can't you just send only, then receive only, back and forth? That would be laggy, but shouldn't it work?
What he means is that the serial port is just, well, a normal serial port, which has a RX line and a TX line and as such both devices can send at the same time. Hence, the connection as a whole is bidirectional, and both devices can send without waiting for the other (more or less). So, it's full-duplex. But you can't e.g. send on both lines at the same time or receive on both lines at the same time - each line by itself is unidirectional. This blocks the use of more sophisticated protocols that could deliver higher speeds or facilitate connections (this last one being, I think, the main reason why CalcNet requires each of the two lines to be bidirectional).
Yeah, pretty much. With two unidirectional lines, you still can achieve speeds up to 115200 bauds, which is not bad if you're not downloading big files. For comparaison, it's twice the speed of a 56K modem.
Quote from: PrizmIRC README https://github.com/juju2143/PrizmIRC/blob/a4600cf136ae42d2ac9aeb9c18e7fdcb9fc2373a/README.md
With a TCP/IP stack on the Casio Prizm, the sky will be the limit. Many applications could be created using it, maybe even an add-in download manager or even a web browser if possible.
Sorry to ruin your party, but downloading add-ins will not be possible, unless you come up with wacky workarounds (which I wouldn't recommend given all the bricking cases...). The execution of the running add-in tends to break when g3a files are manipulated from it. See http://www.casiopeia.net/forum/viewtopic.php?p=13830#p13830 .
Later I found out the problem occurs with most file manipulations involving g3a, and not just file creation: the OS will perform an add-in re-registration when g3a files are manipulated, and this causes changes to the TLB, breaking the execution of the current add-in (making execution jump to places where it's not meant to be: a great way to damage the OS, or the bootloader). This is the reason why the Add-In Manager in Utilities causes system errors often, and that's why the Add-In Manager only appears when the "show advanced tools" setting is enabled (before removing it altogether, the CPU overclocking tool in Utilities belonged in this category too).
Using Bfile syscalls while timers are installed also causes problems; see http://prizm.cemetech.net/index.php/Incompatibility_between_Bfile_Syscalls_and_Timers
Also note that 2016 is a great year to be developing for the Prizm: a few years ago we didn't know about these quirks and you'd be left scratching your head for days without understanding why your "perfect" code wouldn't work. Now we have a clearer idea of how terrible the Casio OS is.
Regarding creation of g3a addins - should creating a file with not g3a extention work without any problems? And subsequently renaming it to g3a would normally work too provided the newly created g3a would not try to be placed on the main menu anywhere before the addin doing that renaming... So theoretically it should be possible to achieve all of the above.
But i may be missing crucial issues i'm not familiar with like will creating a file itself endanger parts of the calculator memory with the bootloader or anything important like that... Will receiving or serial communication going on before or after that endanger anything?
So it's just my thoughts/theories above and I would love to know how if any of those things actually work this way or not please - so please confirm or correct anything you agree or disagree with. Thanks in advance
It's pretty much like running a program on your computer. They're usually harmless, except otherwise specified, like those addins that do overclocks and things like that you should take care. Serial communication is definitely harmless, unless there's a yet undiscovered bug in one of the syscalls that makes your calc halt and catch fire.
Do you remember how or what exactly bricked your prizm? Was serial communication or something else running on it?
If I remember from IRC conversations, he did some USB transfers prior the bricking, but the calculator was also powered via USB rather than batteries for an extended period of time. I seriously hope that the calculator cannot fail just from USB or I/O transfers alone.
Yeah, the culprit is not serial communication, but more something akin to USB transfer and overusage. I didn't even began the serial part in my program anyway.
Thanks for your replies.
By the way on the subject of serial communication - known system calls can only do receiving or transmitting not both at the same time - correct me if you disagree - but it's something to take this into account for example by making corresponding loops in loops for those things respectively to wait to receive or send when necessary
Please share your thoughts or workarounds on this
Yeah, that was the concern arisen back then by Kerm or someone else when someone suggested a Prizm port of gCn. For a multiplayer game, each calculator would need to put themselves in receive then send mode back and forth, with the mode changing as soon as the other calculator received the new data. This would be much slower but probably the only way to do it.
Does receiving data from an IRC chat requires any uploading to be done at the same time (other than when sending messages)?
Quote from: DJ Omnimaga on July 03, 2016, 09:35:16 PM
each calculator would need to put themselves in receive then send mode back and forth, with the mode changing as soon as the other calculator received the new data
Sigh, no, there is no such thing as putting in "receive mode" and "transmit mode", both devices in a UART link are always sending and receiving as each "direction" happens on a different wire and there are buffers on each end to store the received data. This was explained in this thread before.
Mandatory Recommended reading:
https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter
https://en.wikipedia.org/wiki/Synchronous_serial_communication (
not what we have)
https://en.wikipedia.org/wiki/1-Wire (one example of another thing that is
not what we have)
Related Prizm syscalls: http://prizm.cemetech.net/index.php/Category:Syscalls:Serial
The single requirement of CALCnet which the Prizm fails to meet is the following (emphasis mine):
Quote from: CALCnet paper(...) Every z80 graphing calculator has a two-wire link port, that is, two signal lines and a ground. (...) Each line floats at 5v and can be pulled low by any calculator. If one calculator pulls a line low, it is pulled low for all calculators, and only when all calculators have released that line does it float high on every calculator. (...)
As far as I remember the Prizm can only pull its TX line low, and thus doesn't meet the hardware requirements for CALCnet (even if did, some level shifting would be required to meet the 5V of the TI calculators, but that is very easily workable). CALCnet is not a protocol compatible with generic UARTs for this reason.
I don't care about what comments Kerm made as they most likely were made with CALCnet in mind; back when the Prizm was more actively discussed at Cemetech, he would often make comments and assumptions based on what he knew about the Z80 calcs that didn't make much sense on the Prizm; let's just say knowledge about TI's Z80 systems doesn't translate directly to Casio calculators or the Nspire, in the first case because Casio tends to do stuff in a
much more sloppy different way, and in both cases because these are completely different systems running completely different operating systems, much more complex than the Z80 ones, on CPU architectures much more complex than Z80, and so on.
However, this doesn't stop the Prizm serial port from being used for other protocols, like SLIP ( https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol ) or its much more complex replacement PPP ( https://en.wikipedia.org/wiki/Point-to-Point_Protocol ), which I assume are similar to what Juju was trying to get working.
Sorry, I am not tech-savy, so obviously I went with what I read on the forums, and since I don't go to Cemetech as often as CW (or Omnimaga before the split), I usually didn't have the time to read through some of the massive walls of text in the Prizm topics just to see what info in there was accurate or not (something I wouldn't have been able to figure out even after reading them anyway since I am not tech-savy about that stuff).
From what Kerm or someone else said back then it seemed like the Casio I/O only had 1 wire. Anyway thanks for clarifying some of this very unclear stuff.
However isn't that "Sighs" remark kind of uncalled for? Just because it's easy for you to understand something this technical doesn't mean it's as easy for other people, you know?
Quote from: gbl08ma on July 03, 2016, 11:06:52 PM
However, this doesn't stop the Prizm serial port from being used for other protocols, like SLIP ( https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol ) or its much more complex replacement PPP ( https://en.wikipedia.org/wiki/Point-to-Point_Protocol ), which I assume are similar to what Juju was trying to get working.
That is indeed what I was shooting for. Those protocols are pretty much made with serial ports in mind, and the Prizm, as far as I know, tested and the syscalls seems to say, has a standard one, down to standard speeds and everything, similar to RS-232, so it would definitely work. TI calcs, as far as I know, goes with some custom stuff, so CalcNet had to go with custom stuff as well. They probably don't have the CPU for that anyway.
I understand that it is quite standard UART but the point I'm making is that standard system calls we know for prizm will absolutely require to do send then receive or vice versa and in turn that's when this calculator is de facto in sending only or receiving only modes I assume... Still it is not such a big issue normally, but perhaps there is still some even better way of intercepting the tx and rx lines simultaneously not in turns as the so far known system calls currently force us to. Maybe reading some registers directly is possible - so this is something i was hoping for.
Many thanks for all the other explanations...
I guess we'll probably be stuck with a receiving only and a sending only line, and I think it's pretty much what we need so far to begin with. If someone finds a hack so both lines are bidirectional or exceed 115Kbps in speed, well go for it, but let's begin with implementing something like SLIP first, that's the simplest thing to do, and more than enough to do some stuff like IRC or downloading files that are only kilobytes in size. The calc only have 16 MB of storage and 64 KB of RAM anyway.
Quote from: DJ Omnimaga on July 04, 2016, 12:27:55 AMHowever isn't that "Sighs" remark kind of uncalled for? Just because it's easy for you to understand something this technical doesn't mean it's as easy for other people, you know?
It's because it's almost as if nobody read my previous reply on this thread, https://codewalr.us/index.php?topic=1424.msg41030#msg41030 , where I clearly say the Prizm communication uses two wires, being just a "normal" serial port, and so both parties can send and receive at the same time - in one wire, the communication goes one way, in the other, it goes the other way. It annoys me a little when the discussion goes in circles because people can't be bothered to read what was posted, and instead of asking questions about it just go and assume otherwise. I understand that people may be attached to posts made at Cemetech four years ago, and sometimes all the parallel discussions about CALCnet there can lead to these confusions, and that not everyone has the motivation to research a little before posting, but please try to ask questions about what was posted if there are any doubts. I'm sorry that what I write isn't always well understood, or is too technical, but I prefer you call me out on it than just ignore it.
The serial port is really better suited for communication between two parties. I believe there are (probably less reliable or more complex) protocols that allow for communication between 3+ devices with UART hardware, but for now what Juju wants to do is to connect the calculator to a single computer, so the basic capabilities are more than enough.
@AmazoNKA, the serial port syscalls do not have any notion of "receiving" and "sending" modes. You can send and receive at any time (with different syscalls). You can look at registers directly, but there's not much point in doing so. As I said, the serial port has buffers for the received data so you don't lose the data that is received while you are "not looking" (of course, once the buffer is full older data gets discarded - this is why the buffer is called a FIFO - First In, First Out. But reading the buffer often enough isn't difficult). For all definitions, this is bidirectional, full-duplex communication.
You may be mixing up with Casio's own communication
protocol ("protocol 7.00"), which indeed involves putting one calculator in "Receive" mode and another in "Transmit" mode (some syscalls are here: http://prizm.cemetech.net/index.php/Category:Syscalls:Communication ). Note that this is a protocol that works over the serial port and has no relation to any other protocols that we may want to use with the serial port (like SLIP, ...).
It's important to distinguish between the capabilities of the hardware and the capabilities of the protocols that are used with that hardware. For example, in the case of TI calculators, CALCnet is a different, much more powerful protocol over the same hardware that is used by TI's limited protocol.
@Juju, if you see the follwing thread and archive at Cemetech:
https://www.cemetech.net/forum/viewtopic.php?t=7497&postdays=0&postorder=asc&start=0
https://www.cemetech.net/programs/index.php?mode=file&id=703
you'll see that it's possible to operate the serial port at at least 460800 baud. I'm not sure if data transfer is still reliable at those speeds, that was not the goal of that project :)
If you look at this post from that thread: https://www.cemetech.net/forum/viewtopic.php?p=223750#223750 you'll also see that the hardware supports synchronous mode. This means the serial port on the Prizm is actually a USART (Universal Synchronous Asynchronous Receiver Transmitter). Of course, each USART is also a UART. Before people get all confused, this only means the serial port has additional capabilities. Most interestingly, this also means that one of the wires can be bidirectional, when operating in synchronous mode. This is still not enough for CALCnet, as far as I remember reading on Cemetech when this was discovered (both wires would need to be bidirectional). Synchronous mode would be overkill for what Juju is trying to do, IMO. Also, there's no point in receiving data very fast when the bottleneck is in the CPU or the program running on it.
If there are any questions about the Prizm serial port, please ask them. I realize that sometimes it's hard to understand what I'm saying. It's important to clear up misconceptions, otherwise people would end up thinking the Prizm hardware is more limited than it really is, and throw away good application ideas because they think the hardware is not up to par.
For some reasons, I completely missed https://codewalr.us/index.php?topic=1424.msg41030#msg41030 and juju's post right after that when I read the topic. I usually read those posts twice to make sure I might understand, but I guess it didn't help that I miss that post completely. >.<
Regarding using the serial port for PC-calculator or online communications, one important issue is that very few people are willing to spend extra money and deal with online stores to buy the required equipment to connect their calculator via the serial port to an USB port on the PC. So your audience would be much smaller than if you only required a standard USB cable that comes with every digital camera or calculator.
Quote from: DJ Omnimaga on July 04, 2016, 11:00:10 PM
Regarding using the serial port for PC-calculator or online communications, one important issue is that very few people are willing to spend extra money and deal with online stores to buy the required equipment to connect their calculator via the serial port to an USB port on the PC. So your audience would be much smaller than if you only required a standard USB cable that comes with every digital camera or calculator.
Eh, you'd be surprised. The Arduino is something a lot of people a minimum interested in electronics and programming would own, some schools even buy it to their students (personally, that's why I have one), and if not it's rather inexpensive, like $25. And even then, the setup required is very simple (3 wires, 3 staples and the transfer cable on a breadboard, in my case, YMMV), unlike CalcNet, if I remember correctly. It's not just one cable directly, but eh, it's pretty much next to this. You might even find a cable not unlike the TI Silverlink who does this in one cable. Or else your local electronics store may help you buying a serial to TTL converter for cheap.
Even then, I'd call it a proof of concept because my goal was to show it works.
@Juju I was more refering to the issue about how in some cities no store sells such device or hardware and that not everyone trust online shopping.
Using an Arduino just for the USB<->serial converter is overkill. If you already have a serial port on your computer or a USB to serial adapter, you can build your own cable:
http://www.casiopeia.net/forum/viewtopic.php?t=1473
Personally I own one based on a MAX232, but it wasn't made by me, nor for Casio calculators. It was made for old Casio electronic diaries which have a link port with the same layout and use the same tension levels as the calculators. That cable is probably older than me.
Eh, making your own cable is kinda harder, and as DJ said, not everyone would want to do it, if you know electronics, then go for it, if not, the one I shared is simple enough.
Thanks, gbl08ma, i looked at my code and it works without a problem with serial_read system call in a loop to constantly check if anything was received and from memory it didn't work if i were not reading with this system call very closely to the moment the other calculator was doing serial send... Maybe i had something else causing this problem but constant reading if something was received resolved it for me. It is possible I'm confused but it still appears to me that the calculator has to constantly go into some type of receiving state when doing serial read just in order not to miss something, i.e. it's like the buffer gets wiped or not gets populated otherwise... Or is my experience different because it was for communication of one calculator with another and not with a pc etc.
In other words, do you see a way I could have an addin doing some serial unrelated stuff and then let's say every 5 or 15 sec read the buffer and capture anything what was sent to it in that period of time up to its limit for example... I struggled to achieve that... Sorry for trying to clarify and being confused between all the things i read and tried
Also has anyone been able to use the emulator to test serial communication somehow? I test calculator to calculator code on real hardware but if someone knows how to tap into serial port on the emulator too i would be very greatful. Conversely if someone needs anything tested for them using multiple prizms let me know please
I asked
@gbl08ma for that, apparently we can't.
Feel free to retry it, though. It might work on different operating systems and emulator versions.
Oh? I'll see on my Mac if it works.
Something I wonder is if the current emulator core could be re-used in a different wrapper, like Adriweb did with TI-Smartview CE and his Javascript wrapper? It's a bit off-topic, though, but maybe it would allow us to make a new emulator with more features, including linking? It would require the user to install a copy of the Prizm manager, though.
thanks again, gbl08ma, for your previous posts - i retested my code and increasing the interval between serial reads did not cause any data to be lost - good to learn new things from you as always
Quote from: DJ Omnimaga on July 11, 2016, 11:41:15 PM
Something I wonder is if the current emulator core could be re-used in a different wrapper, like Adriweb did with TI-Smartview CE and his Javascript wrapper? It's a bit off-topic, though, but maybe it would allow us to make a new emulator with more features, including linking? It would require the user to install a copy of the Prizm manager, though.
Eh, good question. I know QEMU has a SH4 port, would it be useful for a future community-made emulator?
That's more or less the idea behind https://www.cemetech.net/forum/viewtopic.php?p=250623 , but the project seems to have been abandoned.
Yeah, the big drawback in Casio development is the lack of a proper community-made emulator, that would be really awesome if this project comes to term and would definitely get more developers in the community to program add-ins.
Quote from: gbl08ma on July 12, 2016, 08:18:42 PM
That's more or less the idea behind https://www.cemetech.net/forum/viewtopic.php?p=250623 , but the project seems to have been abandoned.
Yeah it's a shame :/