_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Just checked the datasheet for the descriptions of ABORTB. Certainly not a model of clarity! See below.

It's not clear to me how memory writes are affected by abort, if at all.



My reading of the datasheet says that would be too late: ABORTB has to be stable before the rising edge of phi2.


Do we know this by experiment, or is it a suspicion?

The datasheet (Sep 2010) makes it clear that ABORTB has a setup time before the rising edge of phi2 and a hold time after the falling edge of phi2. It also says that ABORTB should only be asserted for a single cycle. It says that ABORTB is latched internally and that the current instruction completes but processor state is not updated. Table 5-7 ("Instruction Operation") contains annotations for a few instructions as to the last cycle in which ABORTB can be applied - there's no statement as to the earliest cycle and the implication that for all other instructions even the last cycle of the instruction is still a valid time to signal an abort.

The datasheet doesn't say what happens to memory writes - does the instruction still perform the expected memory writes or does it convert them to reads?

My feeling is that ABORTB is designed only to suppress the updating of internal state - suppressing memory writes is the responsibility of the memory subsystem. In the intended use, to signal an address fault, it is as you say: the address responsible for the abort becomes valid during phi2 low, and ABORTB should be asserted within that same phase, to meet the setup time constraint against the phi2 rising edge.

According to that, it would be fine to assert ABORTB in the second cycle of any instruction (other than an interrupt sequence.) With the possible exception of WAI, which isn't annotated. Has there been an experiment with aborting WAI?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

> Then before the fall of Φ2 in that second cycle of the WAI instruction, I pulled ABORT low

I think this is outside the spec: ABORTB is only allowed to change during phi2 low. It must be stable throughout phi2 high. Please could you redo this experiment (aborting WAI in the second cycle) with that in mind? It means pulling ABORTB low during phi1.

Hmm, it's not exactly the same, is it? There's still the opcode fetch at the start of the interrupt sequence, but neither of the dead bus cycles of the XBA mutates into a spurious operand fetch. It looks like that particular quirk is limited to two-cycle instructions.

I just noticed that the cycle breakdown of the hardware interrupt sequence in the 65816 datasheet contradicts itself. The "data bus" column describes the first cycle of the sequence as "I/O" (i.e. dead bus), but the VPA and VDA columns indicate that both are high (as in an opcode fetch). Evidently the VDA and VPA columns are correct and the data bus column is wrong.

Thanks again for your help!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks. WAI might be a difficult case then. For BDD's purposes, it might be necessary to detect and tweak the opcode during the fetch cycle, which will eat into the memory access time and potentially limit the clock speed of the system.

Could you test the following four cases, each time asserting /IRQ during the operand fetch of the BCS instruction?

1) An untaken branch (CLC; BCS)
2) A taken branch (SEC; BCS) in native mode
3) A taken branch in emulation mode that does not cross a 256-byte page
4) A taken branch in emulation mode that does cross a 256-byte page

I'd like to know in which cases the interrupt is taken immediately after the BCS and in which cases the 65816 executes another instruction first.

According to Visual6502, a 6502 will only take the interrupt immediately if the branch is taken and crosses a 256-byte page (making the branch instruction take 4 cycles); otherwise it executes one more instruction first. To guarantee the interrupt is taken before the next instruction, the interrupt line must go low during the opcode fetch of the branch instruction. I'd like to know whether the 65816 is the same, and whether it varies between native and emulation modes.

Actually, "I/O" in the operation table doesn't automatically mean a "dead bus" cycle. "I/O" means "internal operation," during which the buses may or may not be "valid." It's my opinion that "I/O" merely indicates that the state of the data bus is a "don't care" as far as the '816 is concerned. If memory and input/output hardware selection is being qualified by VDA and VPA, the state of the data bus during Ø2 high should never be an issue.

The address and data buses are driven on every cycle of every instruction, and as long as the expression VDA || VPA is true, the address bus will contain a valid address and the data bus will contain a valid bank address during Ø2 low. The data bus content during Ø2 high may be garbage or valid data, but that in itself is not defined by the VDA and VPA outputs (recall that those signals mean "valid data address" and "valid program address," respectively, so they only annunciate if the '816 is generating a valid address).


I essentially agree, although it may be that an "on the fly" opcode change as a consequence of thwarting the execution of a forbidden instruction would not necessarily affect overall performance. CPLDs and FPGAs are generally sub-10ns devices, so even at 20 MHz there could be enough time for the logic to intercede and convert a forbidden instruction into something harmless whilst toggling /ABORT. Needless to say, the timing analysis would be interesting to carry out.

I'm thinking that an errant WAI wouldn't be too much an issue as long as IRQs are enabled and a periodic interrupt is occurring, e.g., a timer IRQ, which most systems would have. All that would happen would be a little execution time would be squandered as the '816 was waiting for the next interrupt. Also, WAI can be indirectly detected in hardware, since the '816 (and the 65C02) pulls the RDY pin low while WAIting. To quote from the data sheet:

2.24 Ready (RDY)

The Ready is a bi-directional signal. When it is an output it indicates that a Wait for Interrupt instruction has been executed halting operation of the microprocessor. A low input logic level will halt the microprocessor in its current state. Returning RDY to the active high state releases the microprocessor to continue processing following the next PHI2 negative transition. The RDY signal is internally pulled low following the execution of a Wait for Interrupt instruction, and then returned to the high state when a RESB, ABORTB, NMIB, or IRQB external interrupt is active. This feature may be used to reduce interrupt latency by executing the WAI instruction and waiting for an interrupt to begin processing. If the IRQB Disable flag has been set, the next instruction will be executed when the IRQB occurs. The processor will not stop after a WAI instruction if RDY has been forced to a high state. The STP instruction has no effect on RDY. The RDY pin has an active pull-up and when outputting a low level, the pull-up is turned off to reduce power. The RDY pin can be wire ORed.

(Emphasis added.)

In my POC V2 design, RDY is attached to a CPLD pin so the CPLD can imposed a wait-state during ROM or I/O block accesses. Under normal operation, that CPLD pin is kept in the high-Z state so it doesn't interfere with the MPU's manipulation of RDY. However, since the data sheet says that the '816 won't halt on a WAI if RDY is continuously driven high (which implies, by the way, that there's no threat to the MPU's health if RDY is actively driven high when WAI is executed), continuously driving RDY high at all times when a wait-state isn't needed and the system is operating in user mode (as opposed to kernel mode, where WAI would be an acceptable instruction) would provide automatic protection, even in the case where IRQs have also been disabled.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks! So the 6502's quirky interrupt check timing during taken branches is not duplicated by the '816, even in emulation mode. I guess emulation mode is kind of a "best of both worlds" of the 6502 and 65C02--decimal mode adc/sbc don't take an extra cycle (like they do on the 'C02) and RMW instructions still write back the unmodified data during the cycle that's an I/O cycle in native mode (this quirk was removed in the 'C02, but there were apparently hardware and drivers that depended on it) but otherwise the '816 fixes the same quirks and bugs that the 'C02 does.

That had to change to accommodate the possibility of an abort interrupt. Abort is meant to force a restart of the same instruction if a memory access error, e.g., a page fault, occurs. If the '816 were allowed to take the branch before acknowledging /ABORT the entire purpose of being able to "abort" an instruction would be defeated.


Not exactly. None of the NMOS behavior is present in a way that will affect the rest of the system as long as the interface between the 65C816 and the buses is correct. This includes the proper use of VDA and VPA to qualify all bus cycles, which is something that is unambiguously stated in the Caveats section of the '816 data sheet.


Again, completely avoidable by proper use of VDA and VPA. The "false" data bus access during cycle 5 (8 bit accumulator) or 6 (16 bit accumulator) of any R-M-W operation is indicated by the expression VDA || VPA being false.

—————————————————
Edit: I incorrectly typed VDA && VPA instead of VDA || VPA.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, but in emulation mode it's a unique "false write cycle" rather than a "false read cycle". It's the only time ever that VDA is false but WR is true. So hardware that depends on the false write for some reason will work if WR overrides VDA, or if VDA isn't used at all (e.g. a 65802 dropped into a legacy 6502 board)