But what happens if an NMI occurs a bit after an IRQ?

If the NMI signal gets triggered before executing the third cycle of the IRQ sequence, the processor will forget the IRQ and finish the interrupt sequence as NMI.

Note that it always takes some time before the processor can start executing an interrupt sequence.  As the interrupt has to occur before the last but one cycle of the currently executed instruction in order to be served before the next instruction, the delay between the occurrence of an interrupt and the beginning of the interrupt sequence is at least two clock cycles.  For this reason, the NMI interrupt may occur four to eleven cycles after the IRQ, depending on the execution time of the current instruction, and still be served first.
  
The whole event will take the normal seven cycles.  Just like with BRK, you do not actually lose the IRQ interrupt: as the processor returns from the NMI handler, it will jump to your IRQ handler, unless you clear the interrupt condition in your NMI handler.  The jump will occur right after the RTI, as the RTI consumes the needed two cycles after restoring the Processor status register from the stack (and clearing the I flag).

After finishing the interrupt sequence, the processor will always start to execute the first instruction of the interrupt routine, even if there was another interrupt pending.  This proves that the processor uses a sort of pipelining: it finishes the current instruction (or interrupt sequence) while reading the opcode of the next instruction.

This is why the processor will always execute the instruction following a CLI before handling the interrupt, even though the IRQ signal is active.  But, on the other hand, a SEI following the CLI cannot prevent the processor from taking the interrupt, as the I flag won't actually be set until the first cycle of the interrupt handler sequence.

--

In article <330963e8.1602734@news.sprynet.com>,
Wolfgang Lorenz <100112.220@compuserve.com> wrote:
>Here is how the EDK (http://ourworld.compuserve.com/homepages/pc64)
>handles it now: 
>
>> IRQ - Interrupt Request
>>
>>  #  addres R/W description                                     proc
>> --- ------ --- ----------------------------------------------- ---------
>>  1    PC    R  dummy fetch                                     IRQ1
>>  2    PC    R  dummy fetch                                     IRQ2
...
>But these two dummy fetches are rather confusing me!

In the 1976 vintage Programming Manual from MOS Technology, those
cycles are described as

   Addr Data Bu  External Op    Internal Op
1  PC   OP CODE  Fetch Op Code  Hold Program Counter, Finish Previous 
                                Operation

2  PC   OP CODE  Fetch Op Code  Force a BRK Instruction, Hold Programming 
                                Counter

So the 6502 takes the quick and dirty method of jamming an op code into
the stream to implement the interrupt.  Simplifies the control logic at
the expense of setting up a special instruction (and making that
accessable to the programmer).

Mark Zenier  mzenier@eskimo.com  mzenier@netcom.com

--

Wolfgang, This is the sequence for the 65802/65816 which is the big brother of the 6502. Will this help?

	Interrupt Processing Sequence


The interrupt processing sequence is initiated as the direct result of hard-
vare Abort, Interrupt Request, Non-Maskable Interrupt, or Reset inputs.
The interrupt sequence can also be initiated as a result of the Break or
Co-Processor instructions within the software. The following listings
describe the function of each cycle in the interrupt processing sequence:


Hardware Interrupt /ABORT, /IRQ, /NMI, /RES Inputs

Cycle No.
 E = 0 E = 1 Address  Data   R/W  SYNC VDA VPA  VP Description

   1     1    PC        X     1    1    1   1   1  Internal Operation
   2     2    PC        X     1    0    0   0   1  Internal Operation
   3    [1]    S       PB     0    0    1   0   1  Write PB to Stack, S--
   4     3     S     PCH [2] 0[3]  0    1   0   1  Write PCH to Stack, S--
   5     4     S     PCL 12] 0[3]  0    1   0   1  Write PCL to Stack, S--
   6     5     S      P [4]  0[3]  0    1   0   1  Write P to Stack, S--
   7     6    VL      (VL)    1    0    1   0   0  Read Vector Low Byte,
                                                   0->PD, 1->P1, OO->PB
   8     7    VH      (VH)    1    0    1   0   0  Read Vector High 8yte


Software Interrupt - BRK, COP Instructions

Cycle No.
 E = 0 E = 1 Address  Data   R/W  SYNC VDA VPA  VP Description
   1     1   PC-2       X     1    1    1   1   1  Opcode
   2     2   PC-1       X     1    0    0   1   1  Signature
   3    [1]    S       PB     0    0    1   0   1  Write PB to Stack, S--
   4     3     S       PCH    0    0    1   0   1  Write PCH to Stack, S--
   5     4     S       PCL    0    0    1   0   1  Write PCL to Stack, S--
   6     5     S        P     0    0    1   0   1  Write P to Stack, S--
   7     6    VL      (VL)    1    0    1   0   0  Read Vector Low Byte,
                                                   0->PD, 1->P1, OO->PB
   8     7    VH      (VH)    1    0    1   0   0  Read Vector High Byte

Notes:
  [1] Delete this cycle in Emulation mode.
  [2] Abort writes address of aborted opcode.
  [3] R/W remains in the high state during Reset.
  [4] In Emulation mode, bit 4 written to stack is changed to 0.



Peter Jakacki
email:	cybert@aai.com.au
        cyb@ozemail.com.au
www:    www.ozemail.com.au/~cyb

--

mzenier@netcom.com (Mark Zenier) wrote:

>   Addr Data Bu  External Op    Internal Op
>1  PC   OP CODE  Fetch Op Code  Hold Program Counter, Finish Previous 
>                                Operation
>
>2  PC   OP CODE  Fetch Op Code  Force a BRK Instruction, Hold Programming 
>                                Counter

Thank you for enlighting this. Seems that I've implemented it right :)

>In the 1976 vintage Programming Manual from MOS Technology, those
>cycles are described as

Is this manual available online? I couldn't find "MOS Technology" at http://www.scruznet.com/~gcreager/brief.htm

>MOSAID http://www.mosaid.com 
>MoSys http://www.mosysinc.com 
>S-MOS Systems http://www.smos.com 
>Inmos' products are now sold by SGS-Thomson

Is MOS Technology one of them? I'll search AltaVista with today's online pass.

Does the manual contain descriptions of the CIA6526/VIA6522 as well? The timer part of the 6526 is driving me crazy. There seems to be some sort of internal pipelining which is hard to emulate.

Cycle exact emulation of the C64 seems to be a matter of 20 years at least. I'm working on it since 1992.

--

Peter Jakacki <cyb@ozemail.com.au> wrote:

>Wolfgang, This is the sequence for the 65802/65816 which is the
>big brother of the 6502. Will this help?

Yes, thank you. Your source also says that IRQ and NMI will perform two dummy reads from the same location. And it shows that RESET is using the same sequence. This is not implemented correctly in the current version of the EDK.

If only I had that information a few years ago. Is this excerpt from a book, or from a Web page?

--

In article <330ed905.8678754@news.sprynet.com>,
Wolfgang Lorenz <100112.220@compuserve.com> wrote:
>mzenier@netcom.com (Mark Zenier) wrote: 
>>In the 1976 vintage Programming Manual from MOS Technology, those
>>cycles are described as
>
>Is this manual available online? I couldn't find "MOS Technology" at
>http://www.scruznet.com/~gcreager/brief.htm

Sorry to tease you with a bit of ancient history off of my bookshelf.
MOS Technology was the company that designed the 6502 and later became
the Commodore Semiconductor division.  (I think for a time they went
back to the MOS Technology name).  

They gained a foothold (circa 1975) by a introductory sales campaign 
where they sold their CPU chips for around $25 when the 6800 and 8080 
where in the $100 - $300 range.  (Remember this was before the Oil
Shock price inflation and that was a lot of money).  

They were founded by the people who did the 6800 at Motorola and then 
split off to build their own company.  Then some of the people there
went to Commodore and did the PET computer.  And later to Victor and
did an 8086 based system.

>Does the manual contain descriptions of the CIA6526/VIA6522 as well?

No, the book is too old.

>The timer part of the 6526 is driving me crazy. There seems to be some
>sort of internal pipelining which is hard to emulate.
>
>Cycle exact emulation of the C64 seems to be a matter of 20 years at
>least. I'm working on it since 1992.

I remember talking to a guy doing the software for a 6809 hardware
emulator (back when the 6809 was hot stuff).  He said they couldn't 
even trust the manufacturers documentation and had to hire a 
consultant to spend a couple of months with a logic analyzer to see
what the chip was really doing.  

>If only I had that information a few years ago. Is this excerpt from a
>book, or from a Web page?

Don't expect anything old to be on the web.  Most of this stuff is too
old for desktop publishing, (where the .pdf files are a low cost spinoff).
At best, you'll find some enthusiast may have scanned in something, but
for obselete chips or dead manufacturers part's, it's more likely to be 
on a bookshelf at an electronics surplus store or used bookstore than 
in any online site.

Mark Zenier  mzenier@eskimo.com  mzenier@netcom.com
