Why, part 1: more data 'lanes'

Drives are normally connected to a C64 or C128 using the IEC serial bus. In its normal mode of operation, this is a bus with separate data, clock and 'attention' lines which can address multiple devices. Data and clock are used for the actual data, and for timing signals, where as a very rough and general rule, data is used by the sender to send data and clock by the receiver to indicate it is ready to receive the next data. ATN (attention) is used for bus management, ie for setting up which device is going to send or receive data.
If we could somehow use 2 instead of one of those lines for sending data, we could send data twice as fast.

Why, part 2: multiple devices on one wire

An interesting property of the IEC bus is that every wire acts like a logical or, that means that whenever any device on the bus makes a line 'true', it will be seen as 'true', no matter what the other devices do. That means that a line will only be seen as 'false' when all devices have made it false. Or put differently, as long as any device on the bus holds a line true, it will be seen as true.

Why, part 3: ATN handling

When the bus master (the computer in pretty much every normal configuration) signals ATN, every device on the IEC bus is expected to respond inmediately by making data true. After a short while, the computer will start waiting for data to become false again, which will happen once every device is ready to actually handle a new command and has changed its internal ATNA line to match the state of ATN. The computer will wait for all devices having released the data line before proceeding with a bus management command. This is the normal, multi device mode of operation of the IEC bus. In order to ensure devices respond to ATN inmediately, every known Commodore drive uses a simple 'hardware assisted ATN ack'. This is implemented as a simple XOR port, which takes 2 inputs and controls the data line based on those 2 inputs. One input is the ATN line, the other input is called ATNA, which is controlled by the CPU of the drive (or actually, by a pin on a VIA or CIA chip in the drive, which in turn is controlled by the cpu).
Whenever ATN and ATNA have the same state (true/false), this will result in data being 'false', but whenever both lines differ, data will be set to true. Additionally, when ATN changes state, an IRQ will be triggered on the drive CPU to ensure it is aware and can deal with the request.
In a classic IEC bus setup, only the computer can act as 'bus master', and hence, only the computer can control the ATN line, drives can only 'listen' to that line. The computer itself cannot listen for the state of the ATN line, it can only control it.

Why, part 4: abusing ATN

So what if we would use ATN instead of the clock line to tell the drive we want to receive data, and have the drive use both clock and data to send that data? First of all, as mentioned above, we can transfer data twice as fast. We could also use the IRQ resulting from ATN if we want. We cannot use a different configuration of the 3 lines for this because the computer cannot sense the state of the ATN line, but this configuration also lets you take advantage of the hardware ATN handling to create a 2 way handshaking protocol (computer changes ATN state to indicate it is ready and waits for data to become false again, drive changes ATNA to match once it has the next 2 bits ready, waits a few cycles so the computer can pick this up, and puts the next 2 bits on the data and clock lines, computer changes ATN state again when its done storing the bits, rinse and repeat. This allows both computer and drive to indicate when they are ready for the next transfer, which in turn allows for very flexible timing, and supporting things like background loading of code/data.

The problem that arrises here when having multiple devices is the hardware ATN ack functionality. Every time the computer makes ATN true, all devices on the bus will make data true by hardware. A drive that is aware of the alternative protocol will know to change ATNA asap to clear the data line before using data and clock to send data to the computer, but drives talking the default protocol do not know about this, and hence will keep data true for too long, and hence will corrupt data on the IEC bus.

Drive mute, how it works

The above explanation should already hint at what drive mute code does, it watches the ATN line, and will make the ATNA line match the state of ATN asap, hence making the data line false fast enough to not interfer.

This is some example drive mute code for 1541 and 1571 drives. This will not work for a 1581.

        sei                       ; stop interupts
        lda #$20
        sta $1801                 ; turn on 2mhz if this happens to be a 1571, does nothing on a 1541 unless.. 
                                  ; it happens to have a parallel cable, in which case we turn on bit 5 on 
                                  ; the parallel connection.
        lda #$00
        sta $1c00                 ; motor and activity led off
        ldx #$10
--      bit $1800                 ; loop until ATN set
        bpl --
        stx $1800                 ; set ATNA
-       bit $1800                 ; loop until ATN cleared
        bmi -
        sta $1800                 ; clear ATNA
        bpl --                    ; back to waiting for ATN
      

A version for the 1581, note this drive uses a CIA instead of a VIA and its registers are at a different location in memory. Additionally, instead of an XOR between ATN and ATNA, the 1581 uses an AND, so simply turning off ATNA is enough.

        sei                       ; stop interupts
        lda #$40
        sta $4000
        lda #$00
        sta $4001                 ; clear ATNA
-       beq -                     ; loop forever
      

This code has to be uploaded to the drive and executed there. It is based on the original by Krill but also forces the drive motor and activity led off (we disable interupts, so there is nothing that will turn them off if they happened to be on when the mute code is started).

tools

S.T.F.U. by Cascade, a standalone tool for muting 154x and 157x drives
C128 Device Manager function rom capable of muting 154x, 157x and 158x drives

---