Re: [ticalc.org-general] 68k Link Protocol Problem

[Benjamin Moody]

[Wow, is this thing still on? I didn't remember I was subscribed!]

On Fri, 11 Jun 2021 14:04:41 -0700 (PDT)
Joseph Herning <joe.h...@gmail.com> wrote:
> Hello everyone!
>
> I'm new to this group. I am playing around with the link protocol for
> the 68k calculators.
>
> I have a TI-89 with AMS 2.09 and a V200 with 3.10. When I send a file
> request for a file that doesn't exist on the calculator the Link
> Guide seems to suggest the calculator should ACK then end the
> transmission
> (https://www.ticalc.org/archives/files/fileinfo/247/24750.html or
> http://merthsoft.com/linkguide/ti89/silent.html). This doesn't make
> much sense because the computer wouldn't know whether to receive data
> or move on. In testing the calculator actually responds with a
> SKIP/EXIT packet using error code 03h. The link guide calls this code
> "can't delete application."
>
> I cannot figure out the state of the calculator at this point. It
> does not immediately respond to a new variable request or a RDY even
> after an ACK, and is not trying to send data.
>
> I tried to verify this in TiLP. If I get a directory listing then
> change the name of a file on the calc, then try to get it with TiLP,
> sure enough the error message I usually get is "Msg: cannot delete
> application."
>
> What's going on here?
>
> - Joe
>

I don't know if my half-remembered knowledge of the Z80-series link
protocols will be any use, but just in case... :)

As far as I can recall, any time the PC or calculator sends a packet
with attached data and checksum, the other device is expected to
respond with an ACK (or an ERR if the checksum was wrong.) ACKs are
sometimes sent at other times too, but there should always be an ACK
in response to any packet with attached data.

So if you send a REQ, and the variable doesn't exist, the calculator
should send first an ACK (meaning the REQ was received correctly) and
then a SKP (meaning that variable doesn't exist). The SKP contains
data (an error code), so in response to that, the calculator expects
the PC to send an ACK. After that, as far as I know, the transaction
is over.

As for the actual contents of the SKP packet, I don't know. What TILP
calls the "error code", I guess, is the third of five data bytes? (In
the Z80 world, it's typically only one byte...) I'm sure those other
four bytes are there for a reason, and perhaps they would tell you
more about the cause of the error.

Romain Lievin did an absolutely fantastic job of reverse-engineering
the link protocols, but from what I remember, I think he did all of
that through trial and error, observing the data sent and received
over the wire - not by disassembling/decompiling the software, and not
from any official documentation. So, as excellent a document as it
is, it's unsurprising that the Link Guide is incomplete in some areas,
especially when it comes to error handling.

Best of luck in your protocol hacking adventures!

Benjamin

[Eric Shotwell]

It always gets a bit of activity when someone new pops in.

--
You received this message because you are subscribed to the Google Groups "ticalc.org-general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ticalcorg-general+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ticalcorg-general/20210622204652.1ed7cd04%40bigdeer.

[Joseph Herning]

Benjamin,

Thanks for the response! Yes, this tinkering would be very time-consuming without all the work that went into the Link Guide. The calculator does send an ACK before the SKP, but it then seemed to respond nonsensically to another VAR request.

Upon closer examination I saw an extra byte (FEh) being sent by the calculator before the normal ACK to my new request when using a gray cable. This, of course, mucks everything up because the parser is expecting a valid machine ID. It looks like the calculator is timing out (~2s) then sending this byte. Thus doing a blocking read for one byte after the SKP, then proceeding as normal to the next file works with the gray cable.

With the silver cable the byte does not seem to be sent (I will admit my "driver" for the silver cable is fairly hackish at the moment), so I have to wait ~2s then reset the cable to get things working. The cable is usually reset between transfers otherwise it eventually has trouble (again, this was based on a hint in a document by Romain Lievin).

It looks like a difference between how the gray and silver cables interpret a timeout on the calculator side. Perhaps only a partial byte is sent for some reason which is passed on by the graylink and not the silver one. I attempted to separate the cable-specific details from the byte-oriented protocol, but I guess that may not work as nicely as I had hoped.

 - Joe

[Joseph Herning]

Update:

I was finally able to try this with a black graphlink cable. With these I am sending/receiving bits individually. Oddly there is no additional transmission over this link. I do not receive a partial byte as I theorized above. Why the gray cable sends an extra byte is mysterious. Is it actually partially parsing the packets?

To make recovery work with all three cable types (black/gray/silver) I created a "soft reset" method which does nothing for the black cable, clears the input buffer for the gray, and resets the usb endpoints for the silver. After receiving an SKP because I requested a nonexisting file, it works for me to:

  1) Wait 2.1s.

  2) "Soft reset" the link.

  3) Send the next file request.

 - Joe

[Joseph Herning]

Update to the update:

My suspicion is that the Gray graphlink sends an extra byte to signal the computer about a link time out. Perhaps this could have aided early linking software if only blocking serial communication was available.

 - Joe

--
You received this message because you are subscribed to a topic in the Google Groups "ticalc.org-general" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ticalcorg-general/YW9dBQAmYdc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ticalcorg-gene...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ticalcorg-general/21f20f52-4766-463b-b5c9-1edb0ec51bfan%40googlegroups.com.