Sync behavior

[phillhs]

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 :

Code: Select all

   LDA   #$21

Would only have sync active whilst fetching the LDA and not the $21 ?

Cheers.

Phill.

[Dr Jefyll]

Quote:

Code: Select all

LDA   #$21

Would only have sync active whilst fetching the LDA and not the $21 ?

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.

[phillhs]

Dr Jefyll wrote:

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.

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

Quote:

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.

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.

[Dr Jefyll]

Quote:

flag that is if the last instruction was fetched from this address range

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 ...

[BigEd]

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

Quote:

In order to provide Shadow RAM for the Electron, slogger has had to rewrite the Operating System. The new Slogger MOS (Machine Operating System) is automatically paged in when shadow mode is selected. The new bank of 32K becomes main memory as far as software is concerned. When an instruction is encountered which should result in a value being written to a location in the screen memory, e.g. BASIC's PLOT or VDU, screen memory is engaged and the value sent on its way again; the instruction is channelled to the correct piece of hardware.

(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.)

[BigDumbDinosaur]

Dr Jefyll wrote:

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.

Absolutely correct.

I've spent some time observing VDA and VPA on my dual-channel 'scope (using Ø2 to trigger the sweep) and have noted that both outputs are asserted (VDA & VPA) during the first cycle when the '816 starts on a hardware interrupt, just as the data sheet says (page 43, step 22a). That would be a dummy opcode fetch of the next instruction, whose address will be pushed during cycles 3, 4 and 5 of the interrupt sequence. VDA & VPA will be true again on the 9th cycle of the interrupt sequence, which is when the first instruction of the interrupt service routine will be fetched. Therefore, to indicate to the machine that a fetch is the start of an instruction and not an interrupt, you'd need hardware logic that would say OPCODE_FETCH = VDA & VPA & ABORTB & IRQB & NMIB. Similar logic would work with the 'C02: OPCODE_FETCH = SYNC & IRQB & NMIB.

Incidentally, VPA alone is asserted during cycle two of a software interrupt, indicating that a dummy read of the signature byte is occurring. Of course, the byte doesn't actually show up in a register, which would be a very useful feature to have with an operating system that implements API calls via software interrupts.

[BigDumbDinosaur]

Dr Jefyll wrote:

Quote:

flag that is if the last instruction was fetched from this address range

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 ...

I wonder if it's some sort of clock-stretching thing...

[phillhs]

Dr Jefyll wrote:

Quote:

flag that is if the last instruction was fetched from this address range

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 ...

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

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

Cheers.

Phill.

[Dr Jefyll]

BigDumbDinosaur wrote:

I wonder if it's some sort of clock-stretching thing...

phillhs wrote:

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

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.

BigDumbDinosaur wrote:

to indicate to the machine that a fetch is the start of an instruction and not an interrupt, you'd need hardware logic that would say OPCODE_FETCH = VDA & VPA & ABORTB & IRQB & NMIB.

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

Interrupt-recognition detector.gif (4.86 KiB) Viewed 2391 times