GARTHWILSON wrote:
BDD had me check for what would happen if ABORT\ hits during the SToP instruction, and the answer is that the processor stops without acting on the ABORT interrupt.
Garth's test on the actual hardware confirmed something that Bill Mensch had investigated via simulation following a query of mine a while back. The 65C816's behavior when hit with an /ABORT immediately after fetching an
STP instruction is something that I will have to consider when I eventually design my protected mode '816 system. The complex logic will have to do more than merely assert /ABORT if a program attempts to execute
STP. I envision that somehow the bit pattern on the data bus would have to be tinkered with to convert
STP to a "harmless" instruction before the fall of Ø2. With that done, /ABORT could be asserted to wrest control away from the misbehaving program.
The
STP instruction is opcode
$DB, or
%11011011. Very conveniently,
%11011011 XOR %11111111 results in
%00100100 or
$24, which is a
BIT <dp> instruction. So if I can get something in the system to invert the state of all data bus bits when logic detects that an
STP is being fetched I would then avert an MPU shutdown.
Timing with /ABORT is critical if the MPU is to be "aborted" at the right time. Converting the opcode to a
BIT <dp> gives the glue logic enough time to toggle /ABORT at a point in the instruction cycle where the MPU will correctly respond.
*My goal is to eventually design a 65C816 system whose hardware can be operated in "real mode" or "protected mode." In "real mode," there is no policing of instructions or memory access, and a program can unconditionally touch anything in the system and unconditionally execute any instruction, including
STP, which would normally cause "fatality" (the MPU's internal clock is halted in the high state and only a reset will get things going again). Direct page and stack accesses would occur in physical zero page and bank
$00, respectively.
In protected mode, "user" and "supervisor" sub-modes would exist, both of which would impose certain rules on memory and I/O access, and use of certain instructions that could potentially cause system fatality. In "user" sub-mode, read/write to on memory would be restricted to the bank in which the program is running, causing accesses to bank
$00 to be mapped back to the in-context bank. Hence there would never be conflicts over direct page or stack space.
In "supervisor" sub-mode, no restrictions will exist on instruction usage and the bank
$00 remapping could be turned off to allow the supervisor program (kernel) to write anywhere in RAM.
It's all out-loud thinking, of course.
————————————————————
*/ABORT must be asserted for no more than one Ø2 cycle, with the toggle sequence occurring as soon as the error condition is recognized but before the final Ø2 cycle of the instruction, which is when the computational results of the instruction are stored in registers or in memory.
Login
Register
FAQ
Search
Some of you may be wondering, given that the WDM instruction could hardly be simpler. (The CPU just fetches and ignores the $42 opcode and its operand byte.) The info Garth is collecting has to do with interrupt response. We're contemplating a scheme that uses the WDM as a prefix that works in combination with the following instruction. The two are are supposed to execute consecutively. But there's a risk of the WDM and the "target" instruction being separated by an ill-timed interrupt. We need to either do a fixup afterward, or prevent the problem in advance by briefly (2~) masking interrupts by means of external logic. It's the latter option that raises questions about behavior. Thanks for doing this, Garth!
