Confirmation of IRQ cycles?

[RR7]

sorry but i wasn't fully able to work this out, i'm a bit of a n00b. my understanding is that any irq consumes 44 cycles. since the ST MFP needs its own vector, i am using the interrupt acknowledge api function that returns this value for IRQ6, or the autovector (24+level) for any other. when i did some logging, only 12 cycles were consume between the interrupt request the the acknowledge function being called.

are the rest called later in the process, or am i expected to account for the cycles in the acknowledge function? (i think there is an extra 4 cycles to add on an ST anyway)

[dirkwhoffmann]

I've dug deeper into the IRQ handling of the Atari ST and just learned that the ST makes use of user-vectored interrupts. This is new terrain for me, too, as the Amiga solely utilizes auto-vectored interrupts.

If I understand your explanations correctly, you run Moira with interrupt type IRQ_USER and override function readIrqUserVector, which is called here:

u16
Moira::getIrqVector(u8 level) const {

    assert(level < 8);

    switch (irqMode) {

        case IRQ_AUTO:          return 24 + level;
        case IRQ_USER:          return readIrqUserVector(level) & 0xFF;
        case IRQ_SPURIOUS:      return 24;
        case IRQ_UNINITIALIZED: return 15;

        default:
            fatalError;
    }
}

Timing is likely imprecise in Moira for this kind of interrupt since I have tested Moira solely against Amiga hardware. However, you can always call sync(n) to manually generate any number of wait states.

BTW, to make interrupt timing 100% accurate in vAmiga, I had to implement additional delays on the Amiga side. This is done by managing a short pipeline that delays the IPL changes for a couple of cycles until they are fed into the CPU. In vAmiga, the code looks like this:

void
Paula::checkInterrupt()
{
    u8 level = interruptLevel();

    if ((iplPipe & 0xFF) != level) {

        iplPipe = (iplPipe & ~0xFF) | level;
        agnus.scheduleRel<SLOT_IPL>(0, IPL_CHANGE, 5);

        trace(CPU_DEBUG, "iplPipe: %016llx\n", iplPipe);
    }
}

void
Paula::serviceIplEvent()
{
    assert(agnus.id[SLOT_IPL] == IPL_CHANGE);

    // Update the value on the CPU's IPL pin
    cpu.setIPL((iplPipe >> 24) & 0xFF);
    
    // Shift the pipe
    iplPipe = (iplPipe & 0x00FF'FFFF'FFFF'FFFF) << 8 | (iplPipe & 0xFF);
    
    // Reschedule the event until the pipe has been shifted through entirely
    i64 repeat = agnus.data[SLOT_IPL];
    if (repeat) {
        agnus.scheduleRel<SLOT_IPL>(DMA_CYCLES(1), IPL_CHANGE, repeat - 1);
    } else {
        agnus.cancel<SLOT_IPL>();
    }
}

I am unsure if something similar is also needed for Atari ST emulation.

[RR7]

yes thats correct the mfp code works out the vector, all we need to do is return it instead of the auto vector for irq6, so theGetIrqVector is quite simple:

`
// Clear the CPU's interrupt request level
cpu.setIPL(0);

// Check if the interrupt is level 6 (for MFP)
if (level == 6)
{
// return the global MFPBaseVector that was generated by the MFP code prior to this.
return MFPBaseVector / SIZE_LONG;
}

// Return the default auto-vector for other interrupts
return 24 + level;
`

emulator timing is done via a cycle counter per loop, to which moira simply contributes right now, i may switch this around once i'm more settled in, so i can add any number of cycles in any operation needed, and would expect to have to do so, what i was curious to know was, if the cycle count is still 44 when an interrupt occurs through user_mode, or if the user_mode code is expected to handle it. the MFP has some overhead so i'll be adding to it anyway. but i did see when i put custom opcodes in, that it consumed 8 cycles per opcode, where an illegal operation should consume 34 apparently but they may be down to that change where is returns from the function, perhaps some cycles were already consumed at that point. (in reality right now my custom illegals are 0 cycles as they redirect to the correct opcode on the next instruction).

i am getting a few issues with moira and i think its down to timing of interrupts, but i cant be sure yet. what i can say is that they are the same as musashi, and they do not occur with the UAE core, which is whats pushing me to confirm these timings.

i think i'll just add some logging and do some acid tests.

[RR7]

i did some logging, and can confirm that in precise timing mode, moira correctly consumes 44 cycles from an interrupt acknowledgement call to the completion of the operation. (in non-precise, it doesnt consume any)