Hw im2 mode - Revision history

Johnnyo: bit 0

2026-05-12T19:25:38Z

bit 0

← Older revision		Revision as of 20:25, 12 May 2026
Line 23:		Line 23:
	For backwards compatibility, the Next's devices normally work in the spectrum mode where they know nothing about interrupts other than pulling into low for about 30 cycles.		For backwards compatibility, the Next's devices normally work in the spectrum mode where they know nothing about interrupts other than pulling into low for about 30 cycles.

	You can choose to operate in hw im2 mode where the hw switches to implementing Zilog's im2 scheme via the bit in ~~nextreg 0xc0~~. That's when you have prioritized interrupts and unique vectors/ISRs for each interrupting device. What's new in the Next is that these interrupts can also be set to interrupt a dma operation via nextreg in the CC range (see e.g. {{NextRegNo\|$CC}}) AFAIK (says AA) that's not been done anywhere else.		You can choose to operate in hw im2 mode where the hw switches to implementing Zilog's im2 scheme via the bit 0 in {{NextRegNo\|$C0}}. That's when you have prioritized interrupts and unique vectors/ISRs for each interrupting device. What's new in the Next is that these interrupts can also be set to interrupt a dma operation via nextreg in the CC range (see e.g. {{NextRegNo\|$CC}}) AFAIK (says AA) that's not been done anywhere else.

Johnnyo: nextreg CC

2026-05-12T19:24:20Z

nextreg CC

← Older revision		Revision as of 20:24, 12 May 2026
Line 23:		Line 23:
	For backwards compatibility, the Next's devices normally work in the spectrum mode where they know nothing about interrupts other than pulling into low for about 30 cycles.		For backwards compatibility, the Next's devices normally work in the spectrum mode where they know nothing about interrupts other than pulling into low for about 30 cycles.

	You can choose to operate in hw im2 mode where the hw switches to implementing Zilog's im2 scheme via the bit in nextreg 0xc0. That's when you have prioritized interrupts and unique vectors/ISRs for each interrupting device. What's new in the Next is that these interrupts can also be set to interrupt a dma operation via nextreg in the CC range. AFAIK (says AA) that's not been done anywhere else.		You can choose to operate in hw im2 mode where the hw switches to implementing Zilog's im2 scheme via the bit in nextreg 0xc0. That's when you have prioritized interrupts and unique vectors/ISRs for each interrupting device. What's new in the Next is that these interrupts can also be set to interrupt a dma operation via nextreg in the CC range (see e.g. {{NextRegNo\|$CC}}) AFAIK (says AA) that's not been done anywhere else.

Johnnyo: The background

2026-05-12T19:22:23Z

The background

← Older revision		Revision as of 20:22, 12 May 2026
Line 12:		Line 12:

	That does mean, e.g., that if multiple events occur while the isr still hasn't executed RETI then you're not going to see more than the one current interrupt. If the DMA is taking a long time, multiple CTC interrupts on a channel only generate one channel interrupt when the dma ultimately gives up the bus. If you have the CTC interrupting DMA op, then you'll see them all most likely.		That does mean, e.g., that if multiple events occur while the isr still hasn't executed RETI then you're not going to see more than the one current interrupt. If the DMA is taking a long time, multiple CTC interrupts on a channel only generate one channel interrupt when the dma ultimately gives up the bus. If you have the CTC interrupting DMA op, then you'll see them all most likely.

			= The background =

			Zilog defines what IM2 mode is.. the hardware is in a physically ordered daisy chain with each interrupting device using that chain to know which has highest priority. The devices put vectors on the bus during int ack so that the z80 can jump directly to a specific device's ISR.

			Sinclair does not support that and instead the ula is a like a traditional 8080 device with one int signal going to one ISR in im1 mode. There is no intelligence in the ula for interrupts, just a notion of asserting the int line low for about 30 cycles.

			Even when you put the z80 in im2 mode, the devices don't obey Zilog's im2 scheme. That's why you need 257 bytes in the vector table that are all the same. The ula does not provide a vector.

			For backwards compatibility, the Next's devices normally work in the spectrum mode where they know nothing about interrupts other than pulling into low for about 30 cycles.

			You can choose to operate in hw im2 mode where the hw switches to implementing Zilog's im2 scheme via the bit in nextreg 0xc0. That's when you have prioritized interrupts and unique vectors/ISRs for each interrupting device. What's new in the Next is that these interrupts can also be set to interrupt a dma operation via nextreg in the CC range. AFAIK (says AA) that's not been done anywhere else.

Johnnyo: wording

2026-05-12T18:28:20Z

wording

← Older revision		Revision as of 19:28, 12 May 2026
Line 1:		Line 1:
	hw im2 mode is enabled by the bit 0 of {{NextRegNo\|$C0}}.		hw im2 mode is enabled by the bit 0 of {{NextRegNo\|$C0}}.

	If not in hw im2 mode, ie normal ~~spectrum~~ behaviour, then all devices that generate an interrupt do it by asserting /int low for around 30 cycles and that's it.		If not in hw im2 mode, i.e. normal Spectrum behaviour, then all devices that generate an interrupt do it by asserting /int low for around 30 cycles and that's it.

	If you are in hw im2 mode, then all interrupting devices including the ~~ula has~~ an im2 state machine attached. If an interrupt is generated, the state machine remembers this as it moves to an assert /int state. Recognition of RETI for the specific device moves the state machine to a place where another /int from the device can be accepted.		If you are in hw im2 mode, then all interrupting devices including the ULA have an im2 state machine attached. If an interrupt is generated, the state machine remembers this as it moves to an assert /int state. Recognition of RETI for the specific device moves the state machine to a place where another /int from the device can be accepted.

	For recognition of RETI:		For recognition of RETI:

	reti instruction has been detected active in T3 for rising edge of T4		reti instruction has been detected active in T3 for rising edge of T4
Line 11:		Line 11:
	so on rising edge of T4, the hw will move to a state where it will see a new int event from the device. /int events are edge detected so you can't hold /int low forever and keep generating interrupts.		so on rising edge of T4, the hw will move to a state where it will see a new int event from the device. /int events are edge detected so you can't hold /int low forever and keep generating interrupts.

	That does mean, eg, that if multiple events occur while the isr still hasn't executed RETI then you're not going to see more than the one current ~~int~~. If the ~~dma~~ is taking a long time, multiple ~~ctc ints~~ on a channel only ~~generates~~ one channel interrupt when the dma ultimately gives up the bus. If you have the ~~ctc~~ interrupting ~~dma~~ op, then you'll see them all most likely		That does mean, e.g., that if multiple events occur while the isr still hasn't executed RETI then you're not going to see more than the one current interrupt. If the DMA is taking a long time, multiple CTC interrupts on a channel only generate one channel interrupt when the dma ultimately gives up the bus. If you have the CTC interrupting DMA op, then you'll see them all most likely.

Johnnyo: how to enable

2026-04-11T19:17:36Z

how to enable

← Older revision		Revision as of 20:17, 11 April 2026
Line 1:		Line 1:
			hw im2 mode is enabled by the bit 0 of {{NextRegNo\|$C0}}.

	If not in hw im2 mode, ie normal spectrum behaviour, then all devices that generate an interrupt do it by asserting /int low for around 30 cycles and that's it.		If not in hw im2 mode, ie normal spectrum behaviour, then all devices that generate an interrupt do it by asserting /int low for around 30 cycles and that's it.

Johnnyo: added page, content from the AA's explanation

2026-04-11T19:12:47Z

added page, content from the AA's explanation

New page

If not in hw im2 mode, ie normal spectrum behaviour, then all devices that generate an interrupt do it by asserting /int low for around 30 cycles and that's it.

If you are in hw im2 mode, then all interrupting devices including the ula has an im2 state machine attached. If an interrupt is generated, the state machine remembers this as it moves to an assert /int state. Recognition of RETI for the specific device moves the state machine to a place where another /int from the device can be accepted.

For recognition of RETI:

reti instruction has been detected active in T3 for rising edge of T4

so on rising edge of T4, the hw will move to a state where it will see a new int event from the device. /int events are edge detected so you can't hold /int low forever and keep generating interrupts.

That does mean, eg, that if multiple events occur while the isr still hasn't executed RETI then you're not going to see more than the one current int. If the dma is taking a long time, multiple ctc ints on a channel only generates one channel interrupt when the dma ultimately gives up the bus. If you have the ctc interrupting dma op, then you'll see them all most likely