I've had the nagging suspicion for a long time that the MMU could be enabled for 64mode via the unusued $d5xx pin 14 of U3 (74LS138).
This logic chip seems to be a nice spot for a planned ACIA 6551 expansion at $d7xx page, as "proven" by CP/M 128 source code .. and it may also have been the IC where MMU would have come alive in 64mode had not Bil Herd ( ? ) made the decision to void MMU from the C128 memory map.
Sadly, I am normal person forced to learn/script a little by necessity or curiousity. ... and you're fairly skilled at asking questions which I think you already know the answers to. =)
meanwhile, bjonte is correct, there is no known pure software escape from 64mode to 128mode.
The problem might come from one or two pins on the MMU 8722, courtesy of data from the net.
If we check the available flat C128 schematics, we see that Pin 47 (MS3) on the MMU is the 128/64 mode select. This goes to Pin 15 of PLA and two other other places, charrom select and a 74LS08 logic (i think). These pins seem to read HIGH in 128mode and LOW in 64mode. The other pins of interest on the MMU is Pin 13 (MS2). This goes to Pin 16 on the PLA (IO SELECT). These pins seem to read LOW in 128mode and HIGH in 64mode. ... and if HIGH, the PLA doesn't seem to hook up the $d5xx page (and perhaps ignores all other pages in I/O range as well).
I'm not certain how this song and dance goes. Does Pin 47 (LOW) on MMU force the PLA to flip Pin 16 (PLA) to HIGH, and thus disable MMU $d5xx on the 64mode map? ...... or Does the MMU drive its Pin 13 (MS2) HIGH on its own? .. Perhaps the solution to reacquiring $d5xx MMU in 64mode is simply to ground the trace between Pin 13 (MS2) and Pin 16 (IO SELECT)? .... but then, what happens to 64mode PLA behavior and do the MMU mirrors at $FFxx show up again ??
..... and what could the presumed $d5xx pin 14 of U3 (74LS138) do for us here, if needed .. ?
I honestly don’t understand the urge to find ways to use the MMU in C64 mode. I have difficulties coming up with something useful from C128 in C64 mode that won’t just make it depend on the C128 entirely and thus be better off in C128 mode in the first place. The placement of the $ff00 registers would make a lot of software incompatible unless those mirrors were removed as well. What do you want to use it for, mirkosoft?
Quick look at an early C128 Service Manual brings a little more clarity to the topic ...
The Configuration Register, CR, controls the ROM, RAM, and I/O configuration of the C128 system. It is located at $D500 in I/O space and at $FF00 in system space. Some of the bits in this register are at times reflected by hardware lines MS0 and MS1 in C128 mode, depending upon how RAM and ROM have been set. These MS lines are used to inform the PLA about the type of memory in a particular address range. In C64 mode, MS0 and MS1 are always high, and the selection of RAM and ROM is done by the PLA using standard C64 banking methods. The MS lines are alternately referred to as ROMBANK lines. They will be referred to as MS lines in this section in the interest of simplicity.
In C128 mode, bit 0 controls whether an I/O space, $0000-$0FFF, or a ROM/RAM access occurs. A low will select I/O, a high will enable some kind of ROM/RAM access, the nature of which is controlled by other bits in this register. The value of this bit is stored in a prelatch, until the fall of the clock, in order to prevent its changing in an unstable situation. Note that when not I/O space, the ROM/RAM access is controlled by the defined ROM Hi configuration bits, which are described later. This bit resets to 0. When the I/O bit is low, MMU registers $D500 to $D50B will assert themselves. When the bit is high, these registers disappear from the memory map. MMU registers $FF00 to $FF04 are always available in C128 mode. The hardware line I/O SELECT always reflects the polarity of this bit when in C128 mode. In C64 mode the I/O SELECT line, the hardware line driven by this bit, is completely ignored by the PLA, and the MMU is never asserted, even when C64I/O is enabled. The C64 method of selecting I/O via HIRaM and CHAREN takes over here. The I/O hardware line remains in its set state when in C128 mode, even though it has no effect in this mode.
Bit number 1 controls processor access to ROM low space, $4000-$7FFF, in C128 mode. If the bit is high, the area will appear as RAM, and a RAM access, CAS enable, will be generated to the appropriate RAM bank, which is determined by other bits in this register. If low, system ROM will be located in the space. This bit affects the memory status lines MS0 and MS1 which are decoded by the PLA to generate ROM chip selects. Selecting ROM here will drive both memory status lines low when the processor address falls within the specified low space range. This bit resets low to include the C128 Basic Low ROM. Of course in C64 mode, this bit is ignored.
The next two bits, bits 2 and 3, determine for C128 mode the type of memory that will be located in the mid space, $8000-$BFFF. If they are both low, system ROM will be located here. If bit 2 alone is high, internal function ROM is located here. External function ROM appears for bit 3 being alone high, and RAM appears, along with the proper CAS generation, for both bits set high. These bits also affect the hardware memory access lines. When in the aforementioned mid block address range, MS0 will reflect the status of bit 3, and MS1 will reflect the status of bit 2. These bits both reset low to start out with Basic Hi. C64 mode ignores these bits.
Bits 4 and 5 determine the contents of the Hi block, $C000-$FFFF, for C128 mode, and have no effect on C64 mode. As with the mid-space, both bits zero will set up system ROM, bit 4 high will set up internal function ROM, bit 5 high will set up external function ROM, and both bits high will set up RAM. Note that the I/O configuration bit, when set for I/O space, will leave the area from $0000 to $0FFF as I/O space, regardless of the values of these bits. If not set for I/O space, $0000 to $0FFF will contain the character ROM if the ROM chosen is System ROM. As with the other ROM selection bits, these bits are reflected by the memory status lines when this region of address is accessed. Bit 5 corresponds to MS0 and bit 4 to MS1. Both of these bits reset to low to permit Kernal and Character ROM to power up in this address space. Note that there is always a hole in high ROM during C128 mode for the MMU registers at $FF00 to $FF04. This hole is brought about by holding both MS lines high and both CAS enable lines high. These bits are ignored in C64 mode.
Finally, bit 6 controls the RAM bank selection. When low, it will select bank 0 by dropping CAS0. When high, it will select bank 1 by dropping CAS1. Bit 7 is unassigned at the present, left for future expansion. Note that a RAM share status that is non-zero will override the normal CAS enable generation to provide CAS0 for all shared memory. Also, note that when the proper CAS enable is generated, any area of memory, even if that area does not have its ROM bank bits set for RAM, is accessed. It is up to the PLA to block CAS for a read from ROM. This allows RAM bleed through on a write to ROM. For any access to the MMU registers from $FF00 to $FF04, in any C128 mode configuration, both CAS enable lines and both MS lines will be high. Note that in C64 mode, the bank used follows the same rules as in C128 mode, though of course banks cannot be changed once in C64 mode.
I hope the OCR'ing / editing didn't mess up anything important.
I was thinking about a case during development of a C64 game that the C128 would be responsible for the transmission of data from a cross compiler on another computer and then boot the game in C64 mode and after the test is done it can reboot itself into C128 mode again to transmit next test data. Since the C128 has the internal function ROM everything can be done automatically except the reset part. Even a bootable disk in the drive would suffice.