I am revising GR8NET code of identification of the maximal size of the mapper I/O register. I know that applications reading these registers are not following standard, and generally hardware must not respond to port fc-ff reads, but these "low-level" applications exist and sometimes very useful. Bad or good, I want them to be properly supported, but avoid electrical conflicts of the data line.
I will give two examples:
1. standard built-in YIS503-3 memory mapper has 128k onboard and responds with D2..D0 to the page number reads (Yamaha violating standard?). All other bits D7..D3 are floating, effectivelly making them 1s due to pull-ups (however there're exceptions of older machines not having pull-ups and reading shit for unused data lines, let's omit them for now). In this situation I can safely identify the size of mapper (3 bits) by writing 0 into the port, and happily use D7..D3 for GR8NET mapper register read response.
2. two GR8NETs in the system, one having 512K of mapped RAM, and another having 1024K of mapped RAM. Not sure why this may be needed, but it is fairly obtainable configuration. Or, there's some other memory mapper in the system. The issue here is that these memory mappers, like GR8NET, are not able to output selected bits only, but 8-bits at once. Thus if first GR8NET is initialized in 512K mode, it responds with 111xxxxx, and it will not be possible for second GR8NET, which is going to be configured with 11xxxxxx, to identify that bit D5 is actually being actively driven high, and is not floating. Thus if it will configure to output this way, there will be electrical conflict within D5 line when reading previously written values having 0 in D5.
I am interested hearing your thoughts on this matter, in particular:
1. how to deal with these configuration situations?
2. should we think to "standardize" the mapper port read further the statement that it is not allowed to read it as hardware and many application break this rule? Example could be if device is not able to keep data lines floating, it will report largest register - e.g. in case of GR8NET full 8-bit register will be reported, not just a part of it with higher bits forced to active 1. Surely programs will identify wrong, bigger size of the mapper, but there will be no conflicts and "smart" applications will actually scan for RAM and identify that it is smaller than the mapper (then question: what mapper RAM controller should put into RAM space for out-of-physical-RAM locations - same RAM mirrored, or 0ffh?).

Maybe same rule should apply here... -> If you can't do Hi-Z, do mirroring.