IEC processor can continue listening after EOI

[rgc2000]

On very rare occasions, the IEC program allows the IEC processor to continue listening after EOI. This may acknowledge a byte that is not intended for the software IEC.

To reproduce this :

• First talk to an existing software IEC device. You can use C64 BASIC, eg: LOAD "$",10 (default devices ID on software IEC are 10 for IEC drive or 4 for printer). The data transmission must be followed by a EOI (should be the case).
• Then use C64 BASIC to talk to another device ID that is not on the IEC bus (eg 12).
• We expect the error "? DEVICE NOT PRESENT ERROR" but if you fall In the IEC bug you will get no error and BASIC will hang thinking that the device ID exists.

Depending which part of the code is executed, the LISTENER flag may not able cleared since last CHECK_ATN_BYTE sequence. To prevent this you can add "SET LISTENER=0" when receiving EOI. No one should be listening anymore after EOI, a new ATN sequence should select the next listener.

Here is a suggested patch or maybe we could add SET LISTENER=0 and SET TALKER=0 at _dont_print label in code (because this is where I suspect LISTENER to keep set to 1 after receiving a new ATN not intended for software IEC.

iec_code.patch

[radius75]

You can use C64 BASIC, eg: LOAD "$",10 (default devices ID on software IEC are 10 for IEC drive or 4 for printer). The data

Off topic:
In FW3.10f the default ID is 11.
In FW3.10a I think it was 10.
Interesting. Maybe it doesn't matter.
I'm reporting it anyway.

[rgc2000]

You are right, default IEC drive ID is 11 now but in the IEC code it is still 10. It should not be a problem as the value in IEC code is replaced by the configured ID at initialization. Search/replace is still looking for ID 10 for replacement.