I didn't read all of the new posts yet, but let me set some concrete simple goals for "round 1" of this project:
Get a simple '816 board running at 14MHz.
Include an off-board bus to interface to an FPGA dev board (to develop the DMA controller).
Use a VIA and ACIA as basic I/O on the '816 board end... place the I/O, ROM, and RAM (if necessary- I can use the FPGA SRAM) in separate banks to test the bank circuit. I can worry about using the address space effectively later in round 2.
Garth pointed this out, but I'll reiterate. Scattering ROM and I/O into different banks is not efficient, particularly in the case of ROM.
When an interrupt hits the 65C816 will automatically load $00 into
PB after pushing it,
PC and
SR to the stack (which itself can only exist in bank $00 absent bank remapping logic). Therefore, you
must have code and data (vectors) in bank $00 for the '816 to access. Otherwise, the '816 will load garbage for an interrupt vector and your machine will likely crash.
Yes, it is possible to have a short ISR preamble in bank $00 and then JML from there to another bank for the rest of the ISR. However, that is not efficient, especially since an ISR should be as succinct and fast as possible. Yes, JML only uses six cycles and it would only happen once per interrupt, but it's six cycles repeated as many times per second as interrupts occur, which could be a lot during I/O.
Similarly, when the '816 is reset, it reverts to emulation mode and forces bank $00. Therefore, code must be available in bank $00.
There is no other way to initiate the reset procedure.
As for I/O hardware mapping, you have to consider that reads and writes with the '816 are always directed to the bank set in
DB, unless long or indirect long addressing is used. Therefore, you must be prepared to either change
DB on every interrupt and restore it before returning to the foreground process, or use 24 bit addressing on every I/O access. 24 bit addressing is slower than 16 bit addressing by one cycle, which really isn't something that you want in an ISR or an operating system kernel (a single I/O transaction could potentially involve several thousand device register accesses ). Also, a number of instructions are not available with 24 bit addressing, so you may find yourself using more code and clock cycles than really necessary.
For test purposes on a new design, having ROM and I/O in bank $00 assures access in emulation mode, which will simplify initial hardware debugging. You can always write a checkerboard routine that runs in bank $00 to test your bank logic after you have leaped the hurdle of getting the unit to work.
Don't make it complicated.
