@leirbag28
What everyone has said at this point is that the limitation is in the hardware.
14-bit audio is a trick with our hearing, similar to speech synthesis on the C64's SID. To anologize, it appears that a project of this sort would be akin to forcing more than 16 colors out of the C64's VIC-II -- it just ain't gonna happen since the VIC only processes one nybble (four bits) of color data, period.
The MegAChip was nothing more than the fulfillment of the expected expansion of ChipRAM using compatible and available custom chip, Agnus. The systems already had the provisions for 2MB. Whereas the 1200 and 3000 do not have provisions for 8MB addressing and while the 4000 has the data lines for it, it appears that the chipset as a whole neither supports nor recognizes the extra lines required.
Software emulation of ChipRAM is not possible. The custom chips cannot access FastRAM directly due to hardware architecture. Software cannot overcome this limitation. Virtual ChipRAM would not work as there is no way for the custom chips to throw an exception on memory accesses out-of-boundaries. Even if it could, imagine how the system would come to a crawl if you had objects on the screen from different pages -- the CPU would now be tied up moving memory in to and out of ChipRAM via the custom chip interfaces.
In IBM/PC perspectives, you cannot increase the memory on some video cards because the video chip (Cirrus Logic, Trident, etc.) does not know how to address the extra space. This is the same reason why on some motherboards a 32MB SIMM shows up as 8MB.
Comparing UAE's multi-MB ChipRAM feature to the Amiga hardware is comparing trees to acorns. UAE is a software implementation of classic hardware -- in short, it *is* redesigned hardware. The OS doesn't care about or understand hardware limitations, so it is happy to accept whatever information the software-emulated hardware tells it.
So, the bottom line is more ChipRAM requires a completely new hardware architecture.
