Table of Content  Branch Up  

ISSUES

I staked with a simple data-transfer philosophy in which there is always a SOURCE register and a DESTINATION register. If transfer occurs from or to memory then the SOURCE or DESTINATION register (respectively) provides the address; this is the case of the PC, the SP or any register used as a pointer in an Indirect Addressing instruction.

Following this simple philosophy, I am negated to latch the Address Bus content to a so called "Memory Address Register" (MAR). Instead, I am planning to provide the Address directly from SOURCE or DESTINATION registers.

This seems to work pretty well (on paper, at least) except for the particular case in which the SOURCE and the DESTINATION registers coincide. That is the case of restoring the SP content directly from the Stack or loading any register by using itself as a pointer (Ex: LDX B, B).


To understand the issue, lets see what happen during a normal Indirect Address instruction such as LDX A, B (see CPU Block Diagram above).

This instruction tells the CPU to load A from the memory location which address is the content of B. Here, A is the DESTINATION register and B is the SOURCE providing the memory address.

For executing this instruction, the CPU will open the B register to the Address Bus, then it will activate the BUS RD signal and finally it will signal A to latch whatever is in the Data Bus.

Now lets "run" the problematic instruction: LDX B, B.

This instruction will execute the same way: Register B will open its buffer to the Address Bus to provide the address; then the BUS RD signal will be activated and finally the same B register will be signaled to latch the Data Bus content.

Problem here is that, as soon the content of B changes, so the address, which will cause the data bus to change unexpectedly causing data corruption.

There is a number of ways to solve this problem. The simplest one is to forbid Indirect Addressing over the same register. This may be convincing specially because pointing a register with itself does not seems very useful in the first place.

Another solution is to always latch the Address Bus content using a MAR register as most computers do. But I don't want to because it will defeat my data-transfer philosophy all together. A more convincing argument for not to use a MAR register is the delay penalty it would impose to every bus cycle.

There are still more solutions. For instance, I can use the OR register only for those problematic cases. During indirect addressing instructions register OR is not used.

The definite solution is still pending but we can see that the simple data-transfer philosophy I staked on have not been defeated yet.

I will simply forbit indirect addressing over the same register used as a pointer. For instance, the follow instruction is illegal:

LDX B, B  ; Load register B from memory location which address is the content of B.

Illegal statements of this kind have two consequences: (1) The Assambler will generate an error. (2) The CPU will generate an exception.

I have established that "vectors" in Heritage/1 interrupts are nothing but the actual ISR address. The reason for this dangerous scheme comes from the count of 64K interrupt "vectors" which in turn comes form the Data Bus size. 64K is too big for a real interrupt vector so I opted to make it a memory address.

But there is a problem with the Memory Bank register (MB): If a program that had switched the MB is interrupted, then the address supplied from the interrupter device will apply to the new bank and not to the intended previous one, so the need for saving the MB register before branching to the new ISR. However, this is not possible in the current architecture because MB is not connected to the D-BUS.

One solution is to simply build a path from MB to the D-BUS so we can save/restore the MB register to/from the Stack as we do with the PC. Additionally we can establish that ISRs always reside in Bank 0 so the Interrupt Controller always reset MB before passing control to the ISR.

Another solution is to re-architecture Interrupts. We can opt, for instance, to a "real" 8-bits interrupt vector leaving the remaining 8 bits for setting the MB content.

A path between MB and the D-BUS was added. Since MB is 8-bits and the Flags Register (F) is also 8 bits, I resolved to save both at the same time in a single memory (16-bits) before serving an interrupt request.