Powered off IEC drive stalls autoboot in edge cases

[dansanderson]

Test Environment (required)

• Platform: MEGA65 (tested on R6)
• ROM Release: 920408
• Core Commit: 3c10488 (v0.96)

Describe the bug
When:

1. An IEC disk drive is connected to the IEC port.
2. The disk drive is powered off.
3. The MEGA65 is configured to boot from a virtual disk image.
4. The virtual disk image exists on the SD card.
5. The virtual disk image does not contain a file named AUTOBOOT.C65.

Then powering on the MEGA65 hangs after printing the BASIC banner and before returning to the READY prompt, and the MEGA65's disk error light blinks.

In this state, Run/Stop-Restore successfully resets to the READY prompt. The last disk error is File Not Found.

All of these conditions must be true to reproduce this. If the IEC drive is disconnected or powered on, if the MEGA65 is configured to boot from a disk image that doesn't exist on the SD card, or if the disk image exists and contains AUTOBOOT.C65, the boot occurs normally.

Note that this state is potentially common because MEGA65.D81 is the default boot disk image, and users are encouraged to disable its autoboot menu in a way that renames AUTOBOOT.C65 to something else. Anyone who does this and also connects an external IEC drive and leaves it powered off will encounter the autoboot stall.

Details
The autoboot process is described in b65.src, the autoboot routine. It is only supposed to check the internal drive for a bootable disk (a disk present with AUTOBOOT.C65) and fail quietly if not found. Normally, the boot process allows FNF to happen then clears it, opting to do nothing if AUTOBOOT.C65 is not present on the mounted disk. The autoboot process is not expected to check other units for AUTOBOOT.C65.

It is not clear how a connected but powered-off IEC drive would confuse this process. Execution appears to be stuck near CB08, which for ROM 920408 is the debounce loop in debpia, a low level I/O routine in system.src that waits for the end of input.

The IEC drive I tested with allows for setting the unit number by DIP switches. The DIP setting does not affect the outcome—which makes sense, because it should only impact IEC communications when powered on.

Some time ago, someone reported that an external IEC drive added delay to this autoboot process, and there may have been an attempt to fix this. I don't remember the details.