6502.org

Just want to try and clarify something, on the WD65c02 data sheet it says :

"The OpCode fetch cycle of the microprocessor instruction is indicated with SYNC high. The SYNC output is provided to identify those cycles during which the microprocessor is fetching an OpCode. The SYNC line goes high during the clock cycle of an OpCode fetch and stays high for the entire cycle."

I'm assuming that this is only for the fetch of the opcode byte and not it's operands for example : Would only have sync active whilst fetching the LDA and not the $21 ?

Cheers.

Phill.

Hi, Phill. Yes, that's right -- you've got the idea. SYNC will be asserted while $A9 (the opcode for LDA#) is fetched. It will be deasserted on the following cycle when the $21 is fetched.

Are you planning some sort of circuit that would connect to SYNC? It might be important to remember that SYNC is always asserted during the fetch of an opcode byte, but if an interrupt occurs a dummy fetch will result. Ie: SYNC is asserted, and it "looks" like the instruction will proceed. But instead the opcode is discarded and the interrupt sequence commences. Details here.

cheers,
Jeff

ps- the 65816 has no SYNC pin, but the simultaneous assertion of VPA and VDA means the same thing: opcode fetch. The same warning applies. It's telling you an opcode is being fetched -- but in fact the opcode might not execute.

Right, good to have it confirmed to be good, that's what I though the data sheet meant, but thought I'd better confirm the assumption
Nope just trying to understand the exact function of a bit of the Master RAM board for the Acorn Electron, which uses !phi2 or !sync to clock a 74LS74, the D input is connected to a decode off the address lines, so this circuit looks like it's latching flag that is if the last instruction was fetched from this address range which makes sense considdering the circuit around it.

Cheers.

Phill.

Funky! Thanks for sharing that. Do we know what's driven by the flipflop -- where Q goes, what it does? A timing thing, perhaps, controlling wait states? Or altering the presence of IO devices in the memory map? In support of ...

Interesting!

What it seems the Master RAM board does is allow for read/write access to video RAM, but only by OS code which sits in a certain address range. So the new (fast) RAM overlays the original (slow) RAM and is used for all non-video access, whether code or data. The gain is up to 20k.

See http://www.acornelectron.co.uk/mags/aab ... r-mrb.html (I think you could do a similar thing, with less spectacular gain, to overlay RAM or ROM over the usual few pages of I/O addresses, provided you can produce a signal which distinguishes the OS code which is supposed to see the I/O pages from ordinary code which should see the overlay.)

I think it's to do with what's mapped where....

I have a traced schematic I can post if people want.

Cheers.

Phill.

I think Ed's post leads us to the answer; did you overlook that? I haven't yet fully digested the info myself. We need to carefully read what's at the link he posted.
That approach presents challenges. Even qualified by SYNC or by VPA and VDA, a low on an interrupt input doesn't equate to interrupt recognition. The interrupt signals pass through on-chip flipflops as a form of input conditioning, resulting in latency prior to recognition. More daunting to predict is the variable latency due to branches taken, as mentioned here. Also you'd need to accommodate the fact that IRQB is internally maskable, again affecting recognition. These problems are solvable perhaps but there's a tidy alternative solution: just look for the missing increment of the PC that occurs when the interrupt does get recognized. As shown below, flipflops and an XNOR gate can detect the increment (or lack of same). If the RDY input is in use (ie; wait states exist), use a '377 type flipflop with its data Enable input also driven by whatever drives RDY.

cheers,
Jeff

Edit: XNOR, not XOR