Suppose I have an Amiga computer without any working boot disks. Is it possible to trigger the built-in ROM monitor (RomWack or SAD, see https://theamigamuseum.com/amiga-kickstart-workbench-os/guru-meditation/) and then somehow send a program over the serial port to, say, write a disk image to disk? Would it require any hardware modifications to do this?
It is possible, but not simple. The ordinary boot process which brings a working machine up from cold to the prompt for a Workbench disk doesn't offer an opportunity to drop into the debugger.
A dodgy and potentially hardware-damaging approach is to cause an unexpected CPU exception by e.g. wiggling the trapdoor memory in an A500 -- execbase disappearing is sure to cause a crash -- or shorting the interrupt lines to cause an NMI. It'll crash, and while the power LED is blinking, you can take control over the serial port.
An arguably somewhat more "correct" approach is to add an expansion card of some sort which will hook the system and call Debug() on command. Building one from scratch would be more effort than it's worth, but existing cards could be presssed into service with similar effect.
Assuming an A500 or A1000, you can use an Action Replay cartridge. The one I had allowed me to format disks and install a custom bootblock, which gives enough of an edge to to bootstrap a working system from a machine that didn't come with Workbench disks. Earlier Action Replays might not be so featureful, but should at least let you break the running OS in such a way that it'll crash and drop into the debugger.
Another kind of expansion card is a hard disk controller. You can use an Amiga emulator to partition and install Workbench onto a hard disk which can then be transplanted into the real Amiga, which should then just boot off it. This is easier on a machine with built-in IDE since USB-IDE controllers are still easy to find, but SCSI is uncommon on modern machines. From here you can then just call Debug() directly, but since your bootstrap problem has already been solved, it's unnecessary.
You could also just get one of those GoTek USB-to-floppy adaptors, which also nicely sidesteps the problem of having no boot floppies.
Another idea could be to dump some Kickstart ROM to a file, then either add a new
Resident module if there is space available in the image, or overwrite a non-essential one (
audio.device comes to mind, see below), with a custom module that calls
Debug() on Exec (You could use the module's Init function to do this). Then you burn your new ROM to an EPROM and use that as the Kickstart.
At this point you will have a system with working multitasking, and RomWack or SAD should function normally (of course multitasking won't actually run while you're in SAD or RomWack).
Your custom resident module should be a
RTF_COLDSTARTone, with a reasonable priority. Depending on the priority, you will get a system that is less and more initialised and similar to a standard environment.
You cannot use
RTF_AFTERDOSbecause those modules are initialised by
dos.libraryis initialised not by Exec but by either the boot blook on floppy disks or by a hard disk firmware when it registers its MountLists for the partitions on disk.
You may indeed try to do what HD firmwares do, and
dos.libraryitself, but I have no idea if the system at that point would be in a state consistent enough to do anything meaningful with DOS.
SAD in Kickstart 3.0 is broken; you may want to base this on Kickstart 3.1 instead. Alternatively, if you want RomWack, Kickstart 2.04/2.1 should be a safe bet; in this case you can certainly overwrite
audio.devicesince it is guaranteed not to be used by the bootstrap process.