Maybe you shouldn't think of the register banks of 8 registers each as being what they're called. They are, after all, just 8 of the 128 iRAM locations, more specifically, 8 of the 32 locations in iRAM that can be addressed as such, aren't they? The access to them as registers is really just an alternate logic path to the physical iRAM, right? Unlike "real" registers (A, B, SP, DPH, DPL) they're physical ram locations and aren't accessible through SFR space. Consequently, they don't have directly accessible flipflops, as a piece of I/O hardware might.

What those instructions that access those specific pieces of iRAM really can be viewed as doing, is to provide an address to the content of whatever is pointed to by those (register-bank-select bits plus the register select bit) bits to address, into the mechanism that's use for addressing. Why would that be? Well, when you generate an address, you have to derive the topmost bits from the instruction, i.e. the part that defines whether it's iRAM, xDATA, xCODE, iCODE, SFR, or whatever, that's being accessed, and then combine that with the actual address, whether that's from the SP, PC, DPTR, or code bytes, and then send it to the physical address bus, some of which may reach pins on the MCU, but all of which certainly goes somewhere to determine what is being addressed. In the case of the use of registers R0 and R1, for indirect access, those are loaded in to the ABL with the internal RAM selected. ABH is not used for internal RAM, so it doesn't matter, hence, isn't affected, or even relevant.

I hesitate to go further, because my vision of an 805x core and yours probably differ considerably. I don't want to hamper your development of your idea with my "vastly better" notion.

It's easy to become entangled in details of the construct being implemented and allow that to hamper one's vision of how it can be implemented. There's no reason you cannot shadow R0 and R1 in RAM if it benefits you in some way. It's just a problem for me because it's really already in RAM, specifically, in iRAM, and I see it offering absolutely no benefit. Since arguments such as address bytes have to come from somewhere, I'd guess it won't take any longer to fetch R0 or R1 from iRAM, or, for that matter, from dedicated hardware, than from a shadowed location.

Again, having a dedicated hardware location for R0 and R1 (and there are four of them) means having them implmented in incrementable/decrementable/loadable, form. You know I like to "squeeze every nickel until the buffalo sh*ts" where hardware resources are concerned, so you can conclude how that strikes me. You can also conclude from that, why I like the notion of using the same ALU to do the simple arithmetic on address objects as is used to operate on data objects.

RE