Changes

Jump to: navigation, search

Plus Vectored Interrupt Bug

786 bytes added, 10:13, 30 July 2017
/* The Vectored Interrupt Bug */
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 bug relates to the raster interrupt. When a raster interrupt is acknowledged under some conditions (which are described below) sometimes 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-&fffflowest priority interrupt) then the bug will not occur.
When * If the instruction at the time of interrupt acknowledge is located in a memory region where A13=0 then the vector will be seen to change between 6 and 4bug happens. This The bug is related not dependent on RAM or ROM or I register value. The location of the instruction is important. The bug also doesn't seem to if happen when the CPU instruction is performing a memory purely based on opcode read operation (e.g. single byte opcodes that don't read/writememory).
The bug is independent of * If the value of I register, instruction at the location time of the interrupt service routine, acknowledge is located in a memory region where A13=1 then the location of bug doesn't happen. Therefore to workaround the vector table which has issue 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 service routine addresseshandlers can be anywhere.
The exact triggers are being investigated.== Technical ==
Advice, either point all interrupt vectors The bug is related to the same interrupt handler logic around link LK106 and manually acknowledge IC IC116 near the dma interrupts OR locate your code where Z80 which relates to the Z80 signals /IORQ, /RESET, A13=1and /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:
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.
Arnoldemu
2,562
edits
Retrieved from "https://gryzor.info/index.php/Special:MobileDiff/98370"