The Z80 will then read a 2-byte address which is the location of the interrupt handler.
Bit 0 of the vector will be 0. Bits 32..1 are generated by the ASIC based on the interrupt source (one of the DMA channels or raster interrupt). Bits 7..4 3 are defined by writing a value to the ASIC IVR register (at &6805 in the ASIC registers).
The raster interrupt interrupt comes from the CPC compatible 52-line interrupt OR the Plus programmable line interrupt (PRI at &6800 in the ASIC registers).
Following discussions on cpcwiki involving roudoudou, Longshot, gerald, arnoldemu and dragon the cause of the bug has been identified, through testing and from analysis by gerald with his logic analyzer and a workaround has been identified.
The This bug relates to has mostly been seen when using the raster interrupt. When a raster interrupt is acknowledged under some conditions (which are described below) the vector will be 6 (for raster interrupt) or 4 (for dma channel 0). it has been found that if the instruction which is being interrupted is located in a memory region where A13=1 (i.e. &2000-&3fff, &6000-&7fff, &a000-&cfff, &e000-&ffff) then the bug will not occur.
When the instruction For example, if DMA interrupts are not used and when a raster interrupt is in a memory region where A13=0 then acknowledged sometimes the vector will be seen to change between 6 and (for raster interrupt) or 4. This is related to if (for dma channel 0 - the CPU is performing a memory read/writelowest priority interrupt).
* If the instruction at the time of interrupt acknowledge is located in a memory region where A13=0 then the bug happens. The bug is independent of the value of not dependent on RAM or ROM or I register, the value. The location of the interrupt service routine, the handler code is also not important. The location of the vector table which has instruction is important. The bug also doesn't occur with opcodes that don't use memory read/write or don't contain a memory read/write when fetching the interrupt service routine addressesopcode. Single byte instructions are fine including HALT. However, it is difficult to code in a way to workaround the issue in this way.
The exact triggers are being investigated* If the instruction at the time of interrupt acknowledge is located in a memory region where A13=1 then the bug doesn't happen.
Advice* If auto-clear DMA interrupts are enabled (IVR bit 0=0), either point all interrupt vectors to then the same interrupt handler and manually acknowledge bug can also happen with the dma DMA interrupts OR locate your code where A13=1.
There are workarounds:
* Put your code between &2000-&3fff, &6000-&7fff, &a000-&bfff, &e000-&ffff. You can place your I value anywhere and the code for your interrupt handlers can be anywhere. You can make use of RAM and ROM and cart to make this easier
* Set all interrupt handlers to the same function, do not use auto-clear (DCSR bit 0 = 0) and handle it like IM 1. (For memory reasons IM 2 is often easier to use to control interrupts)
== Technical == The bug is related to logic around link LK106 and IC IC116 near the Z80 which relates to the Z80 signals /IORQ, /RESET, A13 and /WAIT, but the exact reason this logic is here is not known. See [[http://www.cpcwiki.eu/imgs/8/84/CPC_Plus_CPU_Schematic.jpg]] Logic analysis by the bug by gerald: See [[http://www.cpcwiki.eu/index.php/File:IM2_Plus_Ack_Bug.png]] When a raster interrupt is pending it has been found that the ASIC sees two interrupt acknowledge from the Z80. With the first, it will auto-clear the raster interrupt, record the information in the DCSR register and output the raster interrupt vector onto the bus. When it sees the second, because the raster interrupt has been seen and no DMA interrupts are pending, it defaults to the the vector for DMA channel 0. The logic around the Z80 shortens or lengthens the IORQ based on A13 and that is why the bug doesn't happen when A13=1. == Weblinks == *[https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/amstrad-plus-and-im2-bug/ Amstrad Plus and IM2 bug] [https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/asic-im-2-vector/ ASIC IM2 vector] Related topics on CPCWiki forum*[https://asmtradcpc.zilog.fr/docs/Interruptions_-_modes_et_fonctionnement.php Le bug des interruptions cpc+ (FR)]*[http://quasar.cpcscene.net/doku.php?id=assem:asic#les_interruptions_de_l_asic Le bug DMA0 vs PRI (FR)] [[Category:Hardware]]