6510 Interrupt Handler for the 6502 Klaus Dormman Interrupt test

Question

So I have been testing my 6510 emulator using the 6502 Klaus Dormann tests. Everything seems to be right except the interrupt testing. I have looked around and did some research and found out that I need to create an interrupt handler. But for whatever reason NMI is being triggered every time. One fellow discord user mentioned this (while I was looking for a solution):

Message 1: "keep in mind that IRQ is level sensitive, not edge sensitive."

Message 2: "if I am following your code correctly it looks like you are triggering the IRQ when there is a low to high transition which would not be correct."

Here is the code for better reference:

static inline bool 
changed(int ov, int nv, int bit) {
  return ((ov & bit) == 0 && (nv & bit) != 0);
}

Interrupt handler:

void 
interrupt_handler(MOS_6510* const c)
{
  if(changed(c->old_status, c->irq_status, 0x2))
  {
    NMI(c);
    c->old_status |= 0x2;
  }
  else if(changed(c->old_status, c->irq_status, 0x1))
  {
    if(IRQ(c)) c->old_status |= 0x1;
  }
  else if(changed(c->irq_status, c->old_status, 0x2))
  {
    c->old_status &= ~0x2;
  }
  else if(changed(c->irq_status, c->old_status, 0x1))
  {
    c->old_status &= ~0x1;
  }
}

Execution loop:

  c->irq_status = rb(c, 0xBFFC);
  while(true) 
  {
    interrupt_handler(c);
    mnemonics(c);
    ...
}

Here are my IRQ and NMI implementations:

bool
IRQ(MOS_6510* const c)
{
  if((c->p >> IRQ_DISABLE_FLAG) & 1) return false;

  push_word(c, c->pc);
  push_byte(c, c->p);

  change_bit(c->p, IRQ_DISABLE_FLAG, 1);

  c->pc = rw(c, 0xFFFE);

  c->cyc += 7;

  return true;
}

void
NMI(MOS_6510* const c)
{
  change_bit(c->p, BREAK_COMMAND_FLAG, 1);
  push_word(c, c->pc);
  push_byte(c, c->p);

  change_bit(c->p, IRQ_DISABLE_FLAG, 1);

  c->pc = rw(c, 0xFFFA);

  c->cyc += 7;
}

I think I have posted all the necessary information, if I need to edit the post please let me know!

Thank you in advance!

`IRQ` is indeed level sensitive, which is why you need to clear its source before renabling or `RTI`. — Weather Vane, Aug 02 '23 at 12:55
@WeatherVane what do you mean by clearing its source? Do you have better references like links or sources for bettering understanding everything? — cdunku, Aug 02 '23 at 13:36
Suppose a UART is configured to give `IRQ` on received data. The program code has to tell the UART to remove its IRQ source, but this usually happens automatically when you read the RXD register. — Weather Vane, Aug 02 '23 at 13:45
Shouldn't `c->irq_status = rb(c, 0xBFFC);` be _inside_ the `while` loop (executes on each iteration) vs. above the loop (executes once)? — Craig Estey, Aug 02 '23 at 21:00
The function `changed` is a bit misnamed. It seems more like `on_rising_edge` (e.g.) Also, what [I think] WeatherVane means by "clearing the source" is that you have to tell the interrupt H/W to clear the "interrupt pending" bit (because it is _level_ triggered). So, for some pseudo code: `c->irq_status = rb(irq_status_port); clrbit = c->irq_status & ~0x01; wb(irq_status_port,clrbit);` This writes a zero into the "pending" bit. Some controllers are reversed. To clear the bit you must write a one to the pending bit -- YMMV — Craig Estey, Aug 02 '23 at 21:12
@CraigEstey so what will the irq_status_port exactly point to or what data will be stored there? And why do we need a clrbit in this case? And will clearing the interrupt pending bit be before or after the interrupt handling? — cdunku, Aug 03 '23 at 09:57

score 0 · Answer 1 · answered Aug 09 '23 at 10:45

if I am following your code correctly it looks like you are triggering the IRQ when there is a low to high transition which would not be correct.

Because an interrupt is triggered when the level of IRQ is high. You should be triggering an interrupt on (c->irq_status & 0x1) != 0 regardless of what its old value is. With the 6502, if the "not IRQ" pin remains low¹, when you reenable interrupts, the interrupt will immediately be triggered again. The interrupt routine has to clear the source, which means that it has to tell the chip that raised the interrupt that the interrupt has been serviced (this can often happen automatically as per Weather Vane's second comment on the question).

On the 6502, NMI is edge triggered, so the logic you have here is correct. However, you start with your NMI flag set to true (bit 2 of 0xBFFC is set) and I am assuming you have c->old_status initialised to 0, probably, but you don't show that code. That means NMI will always trigger the first time through.

¹To assert an interrupt on the 6502, you pull the relevant pin to ground. I'm assuming you have inverted that internally to make it less confusing.

yes my old_status is initialised to 0 and my that's what is causing for NMI to execute. Plus I have read irq_status at 0xBFFC and the value read is 255 so 0xFF. — cdunku, Aug 11 '23 at 12:13

6510 Interrupt Handler for the 6502 Klaus Dormman Interrupt test

1 Answers1