That's what I'm starting to think as well.
Respond to the autoconfig address locally until my device is configured, then act like the device has been told to shut up and let the motherboard respond instead.
You wouldn't even need to "act like shutup". You could have an accelerator with however many local Autoconfig devices on it, and use the usual CFGOUT/CFGIN chain between them, masking this from the motherboard until the accelerator is done. Once a device is Autoconfigured, it no longer responds to the Autoconfigure accesses. The first local device is done, and then it ignores Autoconfig accesses. The second local device is given CFGIN signal from the first, and it is the one to respond to Autoconfig, then third, forth, on to whatever N devices are local to the accelerator. All this time Autoconfig needs to be hidden from the motherboard, since the Zorro bus won't know that the accelerator has devices to autoconfig.
Only after all autoconfig devices known on the accelerator are done does the accelerator allow Autoconfig accesses to reach the motherboard, at which point the motherboard thinks it's the first Autoconfig to happen. Accelerator devices are done now, so they ignore all Autoconfig accesses happening with the motherboard.
Before a device is Autoconfigged, the base address of all devices is the Autoconfig base address. There are two of these Autoconfig base addresses, one for Zorro2 devices and one for Zorro3 devices.
As there are two Autoconfig runs, one for Zorro2 and another for Zorro3, choose which your accelerator will be part of. Or which one each of your local accelerator devices will be part of. Theoretically you could have some of each, but that'd probably be an odd thing to do. Choose the one that makes most sense. If you do have some of each, you'll have to trap Zorro2 Autoconfig local until done then pass that one on to the motherboard, and separately trap Zorro3 Autoconfig until done and then pass that on to the motherboard.
After a device has completed Autoconfig, it's base address to respond to changes to that assigned by the OS, so any Autoconfig access won't fit into the device's assigned address range. Nothing terribly special to do here in ignoring an access that doesn't belong to this device.
The CFGOUT/CFGIN chain tells the devices which one is currently up for Autoconfig. If a device is not yet done, and sees it's CFGIN valid, this device knows it's time for it to respond to Autoconfig. All other devices not yet done see their CFGIN as off, and continue waiting for their turn, ignoring Autoconfig accesses until it's their turn to go. At the end of an Autoconfig run for a device, the device turns on its CFGOUT so the next device knows to go on the next Autoconfig access.
The problem at hand is the chain is broken between the Accelerator and the motherboard. Perhaps Commodore didn't intend CPU cards to have local devices to Autoconfig. A strange notion as there had been A2000 Accelerators with Autoconfig memory, or at least hard-coded memory by then. You'd think they'd have seen that as a big hint that Autoconfig on the CPU board is important.
And thus we must trap and mask Autoconfig, keeping it away from the motherboard until the Accelerator knows that everything local is done. The last CFGOUT in the local Accelerator chain means you can now allow Autoconfig to go onto the motherboard.
