I saw in an older thread that you worked with Gamba on the IIfx also.
All I recall is discussing the IIfx ROM with him. It's possible I've forgotten, but as I recall most of Gamba's and my interaction was either regarding the Micron Exceed video card for the SE/30 or the ROM modules for the Mac II family.
IIRC the IIfx RAM is multiplexed and there are, for the vast majority of these machines, unused parity checking lines.
There are unused parity lines but other than meaning there are pins in the socket which aren't used, I don't think they provide anything. I guess there are probably traces to them from somewhere, since parity was an option on the IIfx. That might make some kind of hacking easier. But compared to the rest of the task, it wouldn't be much of an easing.
I'm not sure what you mean by multiplexed. The writes to the IIfx RAM are buffered. In practice this means that the data bus has a set of latches between the data bus and IIfx RAM Write pins. And yes, the Data-Read and Data-Write pins are separate on the IIfx RAM. That's what makes the stuff a pain, but it also improves performance.
In practice, on other computers, the CPU would put the write data out on the data bus, along with an address on the address bus and Write Enable active, and the memory controller would translate the address lines into something that the RAM understand and eventually the RAM copies the data from teh data bus. Meanwhile, no other activity takes place on the data bus.
On a IIfx, the CPU puts the write data on the data bus, along with an address on the address bus and Write Enable active and the memory controller signals the Write Latches to latch the data bus. The address is copied into registers in the memory controller and the memory controller tells the CPU that the operation is finished and the CPU goes on its way and the data bus is available for use for other things. Meanwhile the memory controller translates the address and write request into commands for the RAM (Row address followed by column address, etc) and the RAM copies the write data from the latches, which form their own little data cul 'de sac, invisible to the rest of the machine.
This scheme means that IIfx memory absolutely must have separate pins for data read and data write or data out and data in. If you just tie them together, the data being held in the write latches will trample on the entire data bus while the rest of the machine may be trying to use it. And data on the data bus will trample on the RAM data-in while it's still completing the buffered write operation.
So there's no converting conventional 30 pin or 72 pin SIMMs into IIfx memory. Not saying that was your plan, but pointing out it won't work.
My notion was that these lines could be rework jumpered/hijacked at the memory controller or CPU, becoming additional lines for addressing much more memory on an entirely new RAM card design.
The memory controller only understands how to translate addresses intended for RAM into, at most, 12 row address and 12 column addresses. The memory controller chip just doesn't have any way to translate more addresses than that.
Now, I guess you could build some SIMMs with additional upper address bits. Then the memory controlller would do the normal row and column translation of the lower bits and your extra logic would supply the upper address bit as a bank select, chip select, or just an additional address bit. But to do that you'd need access to the higher address bus lines (probably available around the memory controller) and you'd need to modify the ROM code so that the machine knows how to detect and report larger RAM capacities. I think that there's 1 GB of address space allocated to RAM in the IIfx memory map, but the ROM code (probably) doesn't know to look for more than 128 MB when it does its start up memory test.
You'd also need some scheme to provide refresh support to those upper tiers of memory and that would probably require a PLD all its own.
I know Gamba had a IIfx RAM SIMM layout for the maximum "normally" addressable memory ceiling. However, I was thinking it might be possible to add a few more bits of addressing through a parity line rework/hijack hack. I don't recall much offhand about the IIfx memory mapping, but the additional memory should, at the very least, be addressable as a RAMdisk, configured as Virtual Memory, and accessed at the same speed as normal system memory.
I don't remember Gamba having such a design, but that doesn't mean much given my leaky memory and it's irrelevant. Yes, if you could add some higher memory address bits to the SIMMs and memory to go with them, and change the ROM code so it will be detected, and solve the refresh problem, then it could probably either be added to addressable RAM or used as a RAM disk.
Any of those options is going to require non-trivial hacking of the code that controls the low level hardware. I'm sure it's doable. I just think you should realize that there's a substantial learning/mystery/probably-undocumented-code-modifying to be done to make it work.
