Commander X16

6 minutes ago, TomXP411 said:

I don't know where you got that idea. Once the direction is set, it stays that way until the end of a message - which consists of all the data in the buffer. That's expected to be more than one byte at a time, especially when using this for File I/O. 

From where it said it:

Sender switches Data and CLK pins to write mode. 

Sender sets data on D0-D7, Sender sets CLK high. 

Receiver reads D0-D7 and sets ACK high. 

Sender lowers CLK

Receiver lowers ACK

Sender switches all pins to read mode. 

I didn't follow why the CX16 floating the pins during a write was part of the handshake, but it's listed as the last step in the handshake, and once the sender has floated the pins, it's got to start from the first line for the next byte.

Did it mean to say:

1. 
   Sender switches Data and CLK pins to write mode. 
   


2. 
   Sender sets data on D0-D7, Sender sets CLK high. 
   


3. 
   Receiver reads D0-D7 and sets ACK high. 
   


4. 
   Sender lowers CLK
   


5. 
   Receiver lowers ACK
   


6. 
   Goto 2 on multiple byte transfers
   


7. 
   Sender switches all pins to read mode. 
   

 

6 minutes ago, BruceMcF said:

From where it said it:



Sender switches Data and CLK pins to write mode. 

Sender sets data on D0-D7, Sender sets CLK high. 

Receiver reads D0-D7 and sets ACK high. 

Sender lowers CLK

Receiver lowers ACK

Sender switches all pins to read mode. 



I didn't follow why the CX16 floating the pins during a write was part of the handshake, but it's listed as the last step in the handshake, and once the sender has floated the pins, it's got to start from the first line for the next byte.



Did it mean to say:

1. 
   Sender switches Data and CLK pins to write mode. 
   


2. 
   Sender sets data on D0-D7, Sender sets CLK high. 
   


3. 
   Receiver reads D0-D7 and sets ACK high. 
   


4. 
   Sender lowers CLK
   


5. 
   Receiver lowers ACK
   


6. 
   Goto 2 on multiple byte transfers
   


7. 
   Sender switches all pins to read mode. 
   

 

I wrote that on my cell phone while I was walking back from lunch. I think you can assume that when I get around to implementing that on a test platform, I'll use some common sense optimizations. 

2 minutes ago, TomXP411 said:

I wrote that on my cell phone while I was walking back from lunch. I think you can assume that when I get around to implementing that on a test platform, I'll use some common sense optimizations. 

Knowing the first I can assume that ...

... before hearing that and not knowing whether floating the pins was part of handling the possible deadlocks in that protocol, I didn't assume I knew what change would be optimizing and what change would be breaking.

I still prefer the handshake lines being unidirectional, especially if there might be +5v and +3.3V level translation. A +5v tolerant 3.3v line hex driver tied on for the three output lines, a +3.3v to +5v hex level shifter for the two input lines, also tied on, and the data bus transceiver(s) can be controlled by READ high or low.

So this is interesting. I just watched a video about TI calculators, and they have an interesting way of negotiating data transfer between two devices. The cool thing is that the system automatically adjusts for clock speeds by requiring an acknowledgement for each baud unit. 

With this information in mind, I may try to tackle my communication interface again and see if I can work out something a little more reliable. 

 

Oh, I really like the automatic speed adjustment.  That would be super-useful for our relatively higher-tech world, where an extra ACK is a worthwhile tradeoff for high speeds.

I also like "elegant".   And symmetric.  And cheap.  And easy.

So two signal lines, like ATN and DAT kinda.  When one wants to send to the other, it pulls the ATN low.  The other calculator acknowledges by pulling DAT low.  That's the handshake?!

Packets... one byte for the protocol ID (calculator version), one byte for packet type, two bytes for message length, the message, and then a checksum.  Elegant.

I even like the connector... I mean you could use an RCA jack for the I/O port for goodness' sake.

***

So let's see... how does that work...

I suppose I have to assume that delays are not in DETECTING SIGNALS, but rather in marshaling the data.  That removes one variable: the time needed to present a bit to the receiver. 

(If I'm wrong, then I don't know what to do.)

I'll go look up two-line protocols now...

 

 

On 2/23/2022 at 12:22 AM, TomXP411 said:

The cool thing is that the system automatically adjusts for clock speeds by requiring an acknowledgement for each baud unit. 

Bah. My HP48G lets you choose a baud rate for Kermit or Xmodem transmission -- over infrared! My college friends and I would zap stuff to each other, mostly games and demos.

On 2/23/2022 at 6:50 AM, SlithyMatt said:

Bah. My HP48G lets you choose a baud rate for Kermit or Xmodem transmission -- over infrared! My college friends and I would zap stuff to each other, mostly games and demos.

I don't know where my HP48G ended up. I liked that calculator, but I think I liked my TI 92 Plus a bit better. The QWERTY keyboard was faster, and the UI was definitely easier to use. 

Anyway, back to the topic... The design is interesting, and when I think about it, it's not really that different than what I was originally thinking: 

Sender asserts the data lines with 1 byte of data + CLK line.

Receiver asserts the ACK line. 

Sender lowers CLK line.

Receiver lowers ACK line. 

That's 4 steps, with no extra waiting between each step. While I think this could peak at nearly 80KB/s, I would be happy to get 32KB/s. At this point, filling main memory in 1 second seems like a good benchmark.

 

On 2/23/2022 at 3:50 PM, SlithyMatt said:

Bah. My HP48G lets you choose a baud rate for Kermit or Xmodem transmission -- over infrared! My college friends and I would zap stuff to each other, mostly games and demos.

Love RPL, RPN and all HP calclulators! Fantastically great devices, 10x ahead of TI and Casio! 

Hey, folks. Late-comer here. I'm wondering how far you got with this external communication board development. Is it nailed down? Is it working? What were the final transfer rates? Thanks.

pastblast wrote: ↑Wed Feb 22, 2023 8:01 am Hey, folks. Late-comer here. I'm wondering how far you got with this external communication board development. Is it nailed down? Is it working? What were the final transfer rates? Thanks.

It completely stalled out. A hardware change on the Commander eliminated the User port, so a parallel interface is not possible.

There is a network card in development, but it seems that's probably a ways off. For the meantime, we'll have to make do with bit-banged serial via the IEC port or a couple of pins on the remaining VIA.