Interrupt Wait ??

[demoniak]

Hello,
I downloaded from Richard Wilson's the website PlusTest utility, which allows among others to measure the execution time of all Z80 instructions (and thus verify that my emulator is ok on that side).

But there is a test, called Interrupt Wait Test, which also tests each Z80 instructions, but in a particular context, I guess related to interruptions.

And unfortunately, my emulator failed all instructions of this test...


If anyone knows what it is, and how implement it in a emulator, that will help me to improve further the emulation ofmy cpc emulator ...

[robcfg]

You can ask Richard directly in this forum, his nick is Executioner.


In this case you can go directly to the source 

[arnoldemu]

Hello,
I downloaded from Richard Wilson's the website PlusTest utility, which allows among others to measure the execution time of all Z80 instructions (and thus verify that my emulator is ok on that side).

But there is a test, called Interrupt Wait Test, which also tests each Z80 instructions, but in a particular context, I guess related to interruptions.

And unfortunately, my emulator failed all instructions of this test...


If anyone knows what it is, and how implement it in a emulator, that will help me to improve further the emulation ofmy cpc emulator ...

Normally the following happens:

1. a interrupt request comes
2. the z80 finishes the current instruction
3. if interrupts are "enabled" (e.g. by EI) there is a 1us delay for the z80 to acknowledge the interrupt and then the interrupt is executed (time for im0, im1 or im2 is then added on).
4. But for some instructions, and because of the way the timings are stretched by the cpc hardware, there is some "free" time at the end of them,  and the 1us interrupt acknowledge goes into the delay and the timing changes slightly.
This is something that this is testing for.

I did look at the exact way it did it and I also talked with Richard, but I forgot the details, sorry.

But my work in progress of Arnold passes all the timing tests here. (I'm finishing the new GUI on it at this time).

Here is a list of instructions that end up having a delay at the end:
INC IY
INC IX
EX (SP),IX
EX (SP),IY
LD SP,IY
LD SP,IX
LD I,A
LD R,A
LD A,I
LD A,R
LDI
LDD
LDIR
LDDR
CPI
CPD

I think that is all of them.

However, this will pass the tests, but to get really accurate timing you need to allow for the actual time I/O writes and reads occur within the instruction.
This is something I've not done yet, but I am getting close.

[Phi2x]

.

[arnoldemu]

I tried PlusTest with WinApe and noticed some strange behaviour with this Interrupt wait state timing test.
If the test is run with Amstrad Plus profile, all timings are OK in the test.

But, if I use a CPC classic profile in WinAPE, there are few timings that are not OK. Those are the following:
ED codes: 46, 4E, 66, 6E.

Is that supposed to behave that way? I don't have a CPC classic at hand to test it on the real thing.
But I don't understand the rationale behind such a difference in timings between CPC and Amstrad Plus.

Are those IM 0?

The CPC+ is different in that respect.

The standard CPC puts 0x0ff onto the databus (well this is the result of floating data, so really depends on peripherals etc attached), but CPC+ puts an actual known value.
So the results here *are* different.

Some source code on cpctech shows this for cpc+.

[Executioner]

The first part of any Z80 instruction is a memory read (instruction fetch). All memory reads are aligned in the CPC to a particular one of the 4MHz clock cycles by inserting a wait state or maybe up to 3. Writes appear to operate in a similar fashion, and I/O read and writes are also similar (although I think they're aligned to a different cycle).

The interrupt test occurs on the last T-State of the instruction, and if it's low, the Z80 will insert 2 wait states to acknowledge the interrupt. For instructions which end in the third or fourth T-State relative to the read alignment for the next instruction fetch will be delayed by an extra 4 T-States. The few instructions which end in the first or second T-State won't since the first instruction fetch/read in the interrupt won't be delayed an extra 4 T-States.

Most CPC emulators until now (including WinAPE) have been written to emulate the Z80 with special instruction timing, only taking whole microseconds into account, and these need to decrease the normal interrupt delay to cope with the early end of the instruction. (eg. INC BC is 6 so it ends 2 T-States before the next fetch).

The conditional return instructions will only delay the interrupt if the condition is met. Their internal operation is something like: fetch/execute (5 T-States). If condition is true: PC (low) = memory read from SP (delayed 3 T-States), INC SP, PC (high)= memory read from SP (delayed 3 T-States), INC SP.

[demoniak]

Thanks for the explanations, I will try to implement all of this in my emulator...