As I said, I don't think loading this particular driver in ROM is a good plan. You could put it into a disk image and put the disk image into ROM, and boot the ROM image with my existing ROMDisk driver, and there might even be enough space to do that. The available space for a bootable ROM disk is machine specific. The II/IIx/SE30's system ROM maps in 1MB of ROM address space and uses 256KB of that for the ROM, leaving 768KB to play with. Once the system boots, the OS typically maps in more (dougg3's ROM SIMM holds 2MB). Other models, such as the IIci and Q700, map in more. I'm not sure about the IIfx or IIsi offhand. But when you're using it for booting, you're kind of limited to what the system ROM maps in for you (it is entirely possible to adjust the mappings yourself, but I'm not there yet). Anyway, this is something I intend to play with once I get my hands on one of dougg3's new programmers.

The problem with writes: The image shouldn't necessarily get corrupted. The writes that succeed will be correct. Remember the device driver is operating at a block level though, so if the filesystem required multiple separate block writes to succeed, and only one of them did, the filesystem might be unhappy. If you're concerned about the image getting corrupted in this way, I'd attach it to an emulator and run disk first aid on it. The problem is the system will occasionally hang on a write. Ultimately, this particular problem comes down to MacTCP (and the OT MacTCP compatibility shim, which has subtle differences from actual MacTCP) not really being intended to be called from a device driver, potentially at interrupt time. It also probably doesn't affect UDP, only TCP operations.