Well, I'm very curious to know how this was done. My bankswitching logic is very traditional. Top level memory map:

A15 = 0 A14 = 0 : Fixed mapping to bank 0
A15 = 0 A14 = 1 : Bank N of 32 banks
A15 = 1 A14 = 0 : IO
A15 = 1 A14 = 1 : ROM

Clearly doing mappings between the full memory space and an MPU address + bank register write is awkward, but I was never planning to use banking in this way. More likely each bank would serve a specific purpose and operations would be closer to a RAM-disk of sorts then general purpose memory. This is still, IMO, useful.

So, care to explain how all 16bits of addressing can be used for RAM? How is ROM paged in, would be my first question.....

_________________
8 bit fun and games: https://www.aslak.net/

My web site has a one-page summary of the KimKlone here and a longer description here.

What sets the KK's mapping scheme apart from others is that the "peek" into the wider address space lasts only one bus cycle (or three cycles for a read-modify write). IOW the peek occurs in the midst of a single instruction, and it's "over and done with" before the next opcode needs to be fetched. KK logic operates on a cycle-by-cycle basis, and "knows" when the MPU will do its data access.

That may sound daunting to design, but the predecessor to the KK was actually quite simple. That machine was a modified KIM-1 microcomputer, and you would code for a far data access by manually determining which bus cycle of the target instruction does the data access. (This will vary according to address mode etc). Having determined the timing, you'd select one of several prefix instructions and place the prefix before the target instruction. At runtime the prefix caused a shift register to be loaded, essentially arming a little time bomb that goes off a few cycles later while the target instruction is executing!

The KimKlone is a reiteration of the mapping idea (not of the KIM-1 microcomputer). It uses external microcode to keep in step with what the MPU is doing, and is much more powerful (and nicer to code for) than the modified KIM-1. Still, for 6809 a simple approach might suffice -- and assembler macros could ease coding by encapsulating your prefix/target combinations. I'd have to drag out my Motorola doc and look at the opcode map to see what can be done. But really you should be using Rob Finch's core instead!

Normally the ROM appears at the top of the 16MB space, but the machine wakes up with only 64K accessible, and -- you guessed it! -- the ROM initially appears in the top of that space. After firmware has initialized the bank registers it's safe to go into 16MB mode. There are four bank registers. One lets code execute from anywhere in the 16MB space, and the other three are available for whatever purpose the programmer chooses.

cheers,
Jeff

[Edit: mention assembler macros]

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html