@KThunder
The MMU style approach can't work in this case, since an MMU can only reuse a (relatively) small amount of memory in a larger amount of address space such that an application believes to see more memory than is present. To do this, the MMU monitors the address generated by the CPU (in this case) and the memory manager is used to move (swap in and out) the physical memory to the logical location where it's needed. (Obviously the data has to be stored in an adequately sized but probably slower location, i.e. a hard disc.)
It's very important that logical address space is greater than physical memory. This whole idea with enlarging chipmem tries to operate an amount of physical memory inside a logical address space (=everything the unit in question can address, in the case of Agnus/Alice = 2 MB) that is actually smaller - this is just the opposite and is not possible. Furthermore, paging data in and out requires time, which very clearly violates the realtime requirements needed for producing graphics output, sound and floppy data transfer.
Try to envision the good ol' 6502 CPU of the C64, VIC20 et al. It's got a 16 bit address bus and can see 64K of memory. There's no way it could see more, its world has a size of 65536 bytes. The only way to access more is to use a scheme of bank switching (which the C64 actually does) where the same location in memory is used to window different sets of data. Now, this obviously requires clever programming to ensure that the application always sees the data it's expecting. The only one able to tell which data is needed is the app itself, so it must have provisions to switch the banked data.
Back to the Amiga, the chipset (representing the application) lacks any capability of telling any added (and arbitrarily clever) hardware which bank it wants to see right now. So banking is not a solution.
In theory, it's of course possible to build some hardware that simply knows which address location/bank the chipset wants to access because it knows Agnus' inner workings and foresees which memory locations are really needed. However, this hardware must be able to simulate the complete chipset to actually make this forecast, so its obviously more complex than the chipset itself - and harder to design.
The only solution to this problem is to completely redesign Agnus/Alice, enlarge the address registers and add the required address lines (towards the CPU bridge and towards RAM). Patching the OS to recognize/utilize the larger space is close to trivial.
Because the Agnus/Alice chip not only houses the registers, address generators but also blitter, copper, RAM controller, DMA arbitration engine, etc. a redesign from scratch for a pin compatible chip is a tall task, most of today's logic isn't even signal compatible to the old chips!
