Dissecting a 2-bit transfer protocol over the IEC bus

We know that Commodore defined their transfer protocol over the IEC bus. We also know that such protocol is quite slow but that it allows multiple slaves on the bus. Some of us have also read a description of the protocol by Jim Butterfield and seen various diagrams and traces, including those showing the electric signals over the DATA, CLOCK and ATN lines.

What I am sharing today is the trace for a fast 2-bit transfer protocol, which on one side allows way faster transfers but on the other side limits the communication to just one slave on the bus:

2-bit protocol over Commodore's IEC bus by Luigi Di Fraia

2-bit protocol over Commodore’s IEC bus

Due to the electrical nature of the IEC bus it is difficult to understand which device is pulling low which line, so here’s some description of what is going on.

In the initial phase, at around 1061+0.65 ms, the slave (a 1541 disk drive) pulls DATA low. The master (IECHost, impersonating a Commodore 64) monitors the DATA line and as soon as it detects the line being pulled low it acknowledges the event by pulling CLOCK low. At this point the slave, upon seeing CLOCK going low, releases the DATA line (which is pulled to +5V by pull-up resistors). Finally the master releases the CLOCK line. At this point, around 1061+0.7 ms, the slave pulls low both DATA and CLOCK lines, as it is obvious from the fact they go down at the same time, and then releases both, again they go up at the same time: this is the last chance for the master to synchronize with the incoming signal without requiring the use of an extra pacing signal. In fact, both the DATA and CLOCK line from now on are controlled exclusively by the slave in order to send over data bits: the master passively reads voltage values on both lines at a given pace.

Each bit couple within the same byte is sent by the slave 8 CPU clock cycles apart, about 8 us. After the fourth couple is read in by the master, the latter has to store it, which means the slave has to delay sending the bits that form the subsequent byte for as long as it takes the master to store the bits previously received and prepare for the following receipt. Fortunately no clock cycle is wasted as the the slave has its own job to follow-up with: fetch the next byte. So the complete sequence of events is:

  • master is idle WHILE slave fetches the very first byte
  • master receives bits WHILE slave transmits them
  • master stores byte WHILE slave fetches the second byte
  • master receives bits WHILE slave transmits them
  • and so on…

The total time spent between bytes is 22 CPU clock cycles on both sides of the transfer: again the master stores a byte during that time and the slave fetches the next byte.

Here’s some code on the slave side (transmit):

        LDX #$00      
B0329   LDA BUFF,X    ; Fetch a byte to send
        TAY           
        AND #$0F      
        STA $1800     ; Send bits 1 and 3
        ASL           
        AND #$0F      
        STA $1800     ; Send bits 0 and 2

        LDA MLKUP,Y   ; Perform 4 x LSR with this
                      ; lookup (fast) to get the 
                      ; high nybble
        STA $1800     ; Send bits 5 and 7
        ASL           
        AND #$0F      
        STA $1800     ; Send bits 4 and 6

And here’s the coupled code at the master (receive), which is also the fastest implementation possible (at least with documented/legal OPCodes) at 8 CPU cycles between each received bit couple:

        LDA $DD00     ; Shift DATA and CLOCK in A
        LSR           ; and retrieve the next pair
        LSR           ; from bit 6 and 7
        ORA $DD00     
        LSR           
        LSR           
        ORA $DD00     
        LSR           
        LSR           
        ORA $DD00     ; Whole byte received

        STA WBUFF,X   

There’s plenty more code around these snippets in order to achieve the initial synchronization and keep both sides synchronized in absence of a pacing signal.

That’s something for another post though. What I wanted to show here is how critical timing is when implementing the master side of the connection on a hardware “emulator” of some sort, e.g. IECHost, when a fast 2-bit transfer is in place.

This entry was posted in Retrocomputing, Technical and tagged , , , , , , . Bookmark the permalink.

One Response to Dissecting a 2-bit transfer protocol over the IEC bus

  1. Pingback: IECHost: more progress on the warp disk image write feature | Luigi Di Fraia's e-Footsteps

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s