Devices and interrupt mode 2

[arnoldemu]

@gerald and @Bryce:

I don't think there are many (perhaps only 1 or 2) devices on cpc that used Z80's interrupt mode 2. Or more specifically, an external device that signalled Z80's maskable interrupt.

I know that the firmware probably couldn't handle it but then the firmware can't handle NMIs either, but they are mentioned in the firmware manuals.

The firmware also mentions &f8ff to "reset" external devices.... that they should listen to it and perform a reset.

Is there any technical reason why devices didn't use external maskable interrupts on CPC?

If we look at asic, it can do them, so CPC could too in theory.

The device needs to continue to assert it's interrupt, or provide a way for the interrupt source to be detected through software to avoid conflict with raster interrupts. /BUSRESET can be used to reset them?

Just wondered after all this time....

[gerald]

@gerald and @Bryce:

I don't think there are many (perhaps only 1 or 2) devices on cpc that used Z80's interrupt mode 2. Or more specifically, an external device that signalled Z80's maskable interrupt.

I know that the firmware probably couldn't handle it but then the firmware can't handle NMIs either, but they are mentioned in the firmware manuals.

Can you name the peripheral using interrupt ?

IM2 interrupt mode has some constraint : if you have more than one device generating interrupt, you must give them a priority.
To give them a priority, the IM2 more use a set of input/ouput signal that you daisy-chain from the highest priority device to the lowest one. This is to ensure that only one device react to the IM2 acknowledge cycle where the interrupting device put the LSB that will form the address to the IM2 interrupt table.
The CPC extension port does not have the IO daisy chain signals, so you cannot make this work. If more than 1 peripheral is interrupting, they both will consider the interrupt acknowledged.

Note that IM2 is Z80 specific mode and merely only Zilog peripheral supported it.

The firmware also mentions &f8ff to "reset" external devices.... that they should listen to it and perform a reset.

This one is more to reset the peripherals in a knows state when performing a warm reset (CRTL/SHIFT/ESC).
But I don't think any available peripherals ever monitored this port.

If we look at asic, it can do them, so CPC could too in theory.

Yes, it is working because it's the only one.

The device needs to continue to assert it's interrupt, or provide a way for the interrupt source to be detected through software to avoid conflict with raster interrupts. /BUSRESET can be used to reset them?

When you only have one interrupt line and many peripheral can drive it, the usual way is that the handler scan all peripherals (in they priority order) for a flag indicating that interrupt.
The the software will clear the flag, which should release the interrupt. If an other peripheral is also interrupting, the CPU will just re-enter the interrupt handler.

[TotO]

@arnoldemu: IM2 work perfectly if a PlayCity is plugged to the CPC.
Last but noy least, the &F8FF port is used to reset the board ICs when the FW start.
But... You should know that, as you owned the prototype boards since 2 years now... 

[gerald]

@arnoldemu: IM2 work perfectly if a PlayCity is plugged to the CPC.

Put 2 CTC with different IO address (so you can access both) on 2 different card (so you cannot wire the IEI/IEO signal), and let me know if the IM2 interrupt is still working 

Last but noy least, the &F8FF port is used to reset the board ICs when the FW start.
But... You should know that, as you owned the prototype boards since 2 years now... 

Having a board does not mean knowing the details of the PLD implementation 

[TotO]

Put 2 CTC with different IO address (so you can access both) on 2 different card (so you cannot wire the IEI/IEO signal), and let me know if the IM2 interrupt is still working 

No, but that mean you can use IM2 while you plug a PlayCity on your CPC.

Having a board does not mean knowing the details of the PLD implementation 

The technical manual came with the developer prototype board and explain that. 

[TFM]

Is there any technical reason why devices didn't use external maskable interrupts on CPC?

Well, you didn't ask me, but I let you know the answer nevertheless: No! No technical reason.

And before you ask the subsequent question: Hardware design for polling external devices are cheaper in production (and cheaper to design) than devices using Daisy Chain Interrupt Mode 2. That's very sad, because every well programmer would enjoy a properly implemented Daisy Chain IM 2 system.

Zilog periphery chips for the Z80 all provide that, but hardware producers used cheap alternative chips instead.

Scene productions have another aim, and therefore they use IM2 and make it easy for the coder.

[TFM]

To give them a priority, the IM2 more use a set of input/ouput signal that you daisy-chain from the highest priority device to the lowest one. This is to ensure that only one device react to the IM2 acknowledge cycle where the interrupting device put the LSB that will form the address to the IM2 interrupt table.
The CPC extension port does not have the IO daisy chain signals, so you cannot make this work. If more than 1 peripheral is interrupting, they both will consider the interrupt acknowledged.

That's right. BUT.   But you can work around! Let's say Device A makes an interrupt. In this moment the CP C can sense that and ALSO Device B, which scans for that. Until the CPC does the Interrupt-Acknowledge the Device B will 'wait' to create it's own interrupt.
That's a system of no priority, first come first get's served. And if one device does ignore that, it's not a problem, it just will become dominant. 

[gerald]

That's right. BUT.   But you can work around! Let's say Device A makes an interrupt. In this moment the CP C can sense that and ALSO Device B, which scans for that. Until the CPC does the Interrupt-Acknowledge the Device B will 'wait' to create it's own interrupt.
That's a system of no priority, first come first get's served. And if one device does ignore that, it's not a problem, it just will become dominant. 

Yes, you can do that, but that defeat all the IM2 purpose : direct call to peripheral ISR to not bother about other IRQ source.
There are also side effect. The peripherals that support vectored interrupt (IM2) monitors the RETI instruction fetch to release their IRQ line and update the chain. They do not care about the interrupt mode of the CPU. So if you do not use the priority daisy chain and IM2 mode, your  ISR(s) MUST check all peripherals : a big waste of time.
The other problem with the CPC is that the GA does not support IM2 mode, which mean having a full vector table to handle it IRQ.
In a plus, the ASIC is providing a proper answer for IM2 mode, but there is no way to have the priority management, hence the need to check external peripherals if any in the dma/raster IRQ.

[TFM]

Well, you're clearly a hardware person and argue from that POV.    I decided to be a software person and so I take a look from that POV. So what's the purpose of IM2 for me?
- Getting the first 16 KB completely free
- Having an IM2 table, which sends the right interrupt to the right routine to serve it, means:
- to make software development more easy!


In reality I use IM 2 in all my bigger productions, and this works from CPC 464 to 6128 Plus.


The ISRs must not check all that, they right IM2 vector is provided IMHO.

[TotO]

With the PlayCity, the GA is seen as IM2 number 0.
You can program the CTC channels for handling multitasking and made programming more easy.