If I have a floppy disk in the physical internal drive, it contains an AUTOBOOT.C65, and the drive is MOUNTed, if I then etherload a PRG from my PC to the MEGA65, the reboot after the file transfer boots the disk, and overwrites the etherloaded program.
Without the disk, etherload does a warm boot after the loading, causing the loaded PRG to be in memory ready to RUN. What I would want in this situation is for everything to be the same, with disk booting suppressed. Ideally, it'd also leave the drive mounted, but I'd accept stopping just short of that: etherload could unmount drives before the file transfer.
I noticed this when using etherload to test KERNAL disk routines, but I imagine it would apply to any developer situation involving a physical disk.
fwiw I'd be amenable to some KERNAL collaboration if necessary to make this work, maybe a parameterized warm boot or something.
IMHO this is nothing really critical. If this is not easily solved, we should not invest to much workaround into this, but just use the obvious workaround at hand: remove the autoboot disk from the drive.
If I have a floppy disk in the physical internal drive, it contains an AUTOBOOT.C65, and the drive is MOUNTed, if I then etherload a PRG from my PC to the MEGA65, the reboot after the file transfer boots the disk, and overwrites the etherloaded program.
Without the disk, etherload does a warm boot after the loading, causing the loaded PRG to be in memory ready to RUN. What I would want in this situation is for everything to be the same, with disk booting suppressed. Ideally, it'd also leave the drive mounted, but I'd accept stopping just short of that: etherload could unmount drives before the file transfer.
I noticed this when using etherload to test KERNAL disk routines, but I imagine it would apply to any developer situation involving a physical disk.
fwiw I'd be amenable to some KERNAL collaboration if necessary to make this work, maybe a parameterized warm boot or something.
(/cc @ki-bo )