Join us on Discord!
You can help CodeWalrus stay online by donating here.

Some attempt at bringing Internet to Casio Prizm

Started by Yuki, June 30, 2016, 06:50:50 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

AmazoNKA

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

Dream of Omnimaga

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)?
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

gbl08ma

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.
  • Calculators owned: Prizm CG-20

Dream of Omnimaga

#18
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?
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Yuki

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.
  • Calculators owned: TI-83+ (dead?), Casio Prizm (also dead???)
  • Consoles, mobile devices and vintage computers owned: A lot
Read Zarmina!
YUKI-CHAAAANNNN
In the beginning there was walrii. In the end there will be walrii. All hail our supreme leader :walrii: --Snektron

if you wanna throw money at me and/or CodeWalrus monthly it's here

AmazoNKA

#20
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...

Yuki

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.
  • Calculators owned: TI-83+ (dead?), Casio Prizm (also dead???)
  • Consoles, mobile devices and vintage computers owned: A lot
Read Zarmina!
YUKI-CHAAAANNNN
In the beginning there was walrii. In the end there will be walrii. All hail our supreme leader :walrii: --Snektron

if you wanna throw money at me and/or CodeWalrus monthly it's here

gbl08ma

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.
  • Calculators owned: Prizm CG-20

Dream of Omnimaga

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.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Yuki

#24
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.
  • Calculators owned: TI-83+ (dead?), Casio Prizm (also dead???)
  • Consoles, mobile devices and vintage computers owned: A lot
Read Zarmina!
YUKI-CHAAAANNNN
In the beginning there was walrii. In the end there will be walrii. All hail our supreme leader :walrii: --Snektron

if you wanna throw money at me and/or CodeWalrus monthly it's here

Dream of Omnimaga

@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.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

gbl08ma

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.
  • Calculators owned: Prizm CG-20

Yuki

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.
  • Calculators owned: TI-83+ (dead?), Casio Prizm (also dead???)
  • Consoles, mobile devices and vintage computers owned: A lot
Read Zarmina!
YUKI-CHAAAANNNN
In the beginning there was walrii. In the end there will be walrii. All hail our supreme leader :walrii: --Snektron

if you wanna throw money at me and/or CodeWalrus monthly it's here

AmazoNKA

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

AmazoNKA

#29
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

Powered by EzPortal