6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Mon Sep 23, 2024 4:20 pm

All times are UTC




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Sync behavior
PostPosted: Tue Jun 11, 2013 11:08 pm 
Offline

Joined: Sun Nov 23, 2008 2:33 pm
Posts: 12
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:
   LDA   #$21


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

Cheers.

Phill.


Top
 Profile  
Reply with quote  
 Post subject: Re: Sync behavior
PostPosted: Tue Jun 11, 2013 11:25 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Quote:
Code:
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.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
 Post subject: Re: Sync behavior
PostPosted: Wed Jun 12, 2013 12:31 am 
Offline

Joined: Sun Nov 23, 2008 2:33 pm
Posts: 12
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Sync behavior
PostPosted: Wed Jun 12, 2013 12:46 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
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 ... :?:

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
 Post subject: Re: Sync behavior
PostPosted: Wed Jun 12, 2013 2:48 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
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.)


Top
 Profile  
Reply with quote  
 Post subject: Re: Sync behavior
PostPosted: Wed Jun 12, 2013 5:51 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8390
Location: Midwestern USA
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. :cry:

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


Last edited by BigDumbDinosaur on Wed Jun 12, 2013 6:06 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: Sync behavior
PostPosted: Wed Jun 12, 2013 5:52 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8390
Location: Midwestern USA
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...

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


Top
 Profile  
Reply with quote  
 Post subject: Re: Sync behavior
PostPosted: Wed Jun 12, 2013 8:28 am 
Offline

Joined: Sun Nov 23, 2008 2:33 pm
Posts: 12
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Sync behavior
PostPosted: Wed Jun 12, 2013 2:35 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
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
Attachment:
Interrupt-recognition detector.gif
Interrupt-recognition detector.gif [ 4.86 KiB | Viewed 1827 times ]

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 15 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: