83Plus:Interrupts - Revision history

Dr. D'nar at 04:05, 29 June 2013

2013-06-29T04:05:50Z

Dr. D'nar: More information!

2013-03-27T22:34:51Z

More information!

Dr. D'nar: I retract my claim.

2013-03-23T01:01:46Z

I retract my claim.

Dr. D'nar: The ld a, i/r bug does not apply to ASIC-based units because they have the CMOS Z80.

2013-03-08T20:47:58Z

The ld a, i/r bug does not apply to ASIC-based units because they have the CMOS Z80.

Dr. D'nar at 17:14, 8 March 2013

2013-03-08T17:14:21Z

Dr. D'nar: category fix

2013-03-08T17:12:01Z

category fix

Dr. D'nar: Page creation. It's kind of not very detailed, but whatever.

2013-03-08T17:10:55Z

Page creation. It's kind of not very detailed, but whatever.

New page

[[Category:83Plus:General Hardware Information|Memory Mapping]]
[[Category:84PCSE:General Hardware Information|Memory Mapping]]
The Z80 CPU supports three different modes of handling interrupts. They are called IM 0, IM 1, and IM 2. The IM 0 mode is identical to the Intel 8080's interrupt handling and is provided for compatibility. In IM 0, the interrupting hardware takes over the bus and sends an instruction to the CPU to execute. This instruction would usually be an RST instruction, which is what the RST instructions were designed for. In IM 1, the Z80 always executes RST 38h.

In IM 2, the Z80 uses an interrupt vector table. The interrupting hardware gives the Z80 an index into the table, such that up to 128 devices can automatically specify which interrupt service routine (ISR) needs to be run. The I register specifies where the IVT starts. Since I is 8 bits, it only specifies the high byte; the table always starts at an address in which the low byte is zero. The interrupting hardware is supposed to send an 8-bit number that's an index into the table. So the Z80 combines the index and the value of the I register to form a 16-bit address. The Z80 uses the 16-bit number at that address as the location of the ISR.

The TI-83+ family operating system always operates in IM 1, in which any interrupt signal causes the CPU to execute the RST 38h instruction. The OS provides no hooks for allowing software to catch and process interrupts. Fortunately, the Z80 also has the IM 2 mode, which allows us to move the interrupt vector table (IVT) to any of 256 different locations. Unfortunately, in the TI-83+ IM 2 is semibroken because it would actually be useful to us if it functioned properly. The ASIC doesn't bother to specify an index into the table for, so we have to poll different ports to figure out what generated the interrupt. Furthermore, you will note that the number the Z80 expects to be passed is an 8-bit number. Because the addresses in the table are 16-bits, each address takes 2 bytes. But the Z80 doesn't mask out the bottom bit. So you have to fill the table with 257 repeating bytes, and your ISR can only be at an address in which the high and lows bytes are the same.

The TA3 ASIC, used in older TI-84+s/SEs and the TI-83+CSE, has a useful quirk. It always sends the byte FF when an interrupt is generated. So IM 0 and IM 1 are the same. Even better, you only need to specify the final address in the IVT, and the high and low bytes don't have to be the same. Unfortunately, the TA1 ASIC doesn't do this, so TI-84+/SE software can't depend on this quirk. Also, if TI does anything to address the speed issues of the TI-84+CSE, they will probably break this useful feature just to spite us.

← Older revision		Revision as of 04:05, 29 June 2013
Line 9:		Line 9:
	The TI-83+ family operating system always operates in IM 1, in which any interrupt signal causes the CPU to execute the RST 38h instruction. The OS provides no hooks for allowing software to catch and process interrupts. Fortunately, the Z80 also has the IM 2 mode, which allows us to move the interrupt vector table (IVT) to any of 256 different locations. Unfortunately, in the TI-83+ IM 2 is semibroken because it would actually be useful to us if it functioned properly. The ASIC doesn't bother to specify an index into the table, so we have to poll different ports to figure out what generated the interrupt. Furthermore, you will note that the number the Z80 expects to be passed is an 8-bit number. Because the addresses in the table are 16-bits, each address takes 2 bytes. But the number the Z80 receives from the ASIC is effectively random. And the Z80 doesn't mask out the bottom bit. So you have to fill the table with 257 repeating bytes, and your ISR can only be at an address in which the high and lows bytes are the same.		The TI-83+ family operating system always operates in IM 1, in which any interrupt signal causes the CPU to execute the RST 38h instruction. The OS provides no hooks for allowing software to catch and process interrupts. Fortunately, the Z80 also has the IM 2 mode, which allows us to move the interrupt vector table (IVT) to any of 256 different locations. Unfortunately, in the TI-83+ IM 2 is semibroken because it would actually be useful to us if it functioned properly. The ASIC doesn't bother to specify an index into the table, so we have to poll different ports to figure out what generated the interrupt. Furthermore, you will note that the number the Z80 expects to be passed is an 8-bit number. Because the addresses in the table are 16-bits, each address takes 2 bytes. But the number the Z80 receives from the ASIC is effectively random. And the Z80 doesn't mask out the bottom bit. So you have to fill the table with 257 repeating bytes, and your ISR can only be at an address in which the high and lows bytes are the same.

−	If you want to know whether interrupts are currently enabled or not (so you can disable them, and then enable interrupts again if and only if they were enabled before), the ld a, i and ld a, r instructions will copy the value of IFF2 into the P/V flag. In other words, if interrupts are enabled, the P/V flag will be set. The ~~original NMOS-based~~ Z80 ~~had~~ a bug ~~that would cause~~ ld a, i and ld a, r to reset the P/V flag if an interrupt occurred near the instruction. This bug was corrected in the CMOS version of the Z80, which is the version that is in the ASICs; therefore, you do not need to worry about the bug if you don't need your software to run on the older TI-83+s that were manufactured with a discrete Z80. The workaround ~~for the TI-83+~~ is ~~either to prohibit using older units, or~~ to perform the ld a, i/r operation twice, and compare the results.	+	If you want to know whether interrupts are currently enabled or not (so you can disable them, and then enable interrupts again if and only if they were enabled before), the ld a, i and ld a, r instructions will copy the value of IFF2 into the P/V flag. In other words, if interrupts are enabled, the P/V flag will be set. The Z80 has a bug causes ld a, i and ld a, r to reset the P/V flag if an interrupt occurred near the instruction. The workaround is to perform the ld a, i/r operation twice, and compare the results.

@@ Line 1: / Line 1: @@
 [[Category:83Plus:General Hardware Information|Interrupts]]
 [[Category:84PCSE:General Hardware Information|Interrupts]]
 The Z80 CPU supports three different modes of handling interrupts. They are called IM 0, IM 1, and IM 2. In all modes, after accepting an interrupt, the Z80 disables interrupts and you must manually enable them again at the end of your interrupt service routine. The IM 0 mode is identical to the Intel 8080's interrupt handling and is provided for compatibility. In IM 0, the interrupting hardware takes over the bus and sends an instruction to the CPU to execute. This instruction would usually be an RST instruction, which is what the RST instructions were designed for. In IM 1, the Z80 always executes RST 38h.
@@ Line 8: / Line 10: @@
 If you want to know whether interrupts are currently enabled or not (so you can disable them, and then enable interrupts again if and only if they were enabled before), the ld a, i and ld a, r instructions will copy the value of IFF2 into the P/V flag. In other words, if interrupts are enabled, the P/V flag will be set. The original NMOS-based Z80 had a bug that would cause ld a, i and ld a, r to reset the P/V flag if an interrupt occurred near the instruction. This bug was corrected in the CMOS version of the Z80, which is the version that is in the ASICs; therefore, you do not need to worry about the bug if you don't need your software to run on the older TI-83+s that were manufactured with a discrete Z80. The workaround for the TI-83+ is either to prohibit using older units, or to perform the ld a, i/r operation twice, and compare the results.

← Older revision		Revision as of 01:01, 23 March 2013
Line 8:		Line 8:

	If you want to know whether interrupts are currently enabled or not (so you can disable them, and then enable interrupts again if and only if they were enabled before), the ld a, i and ld a, r instructions will copy the value of IFF2 into the P/V flag. In other words, if interrupts are enabled, the P/V flag will be set. The original NMOS-based Z80 had a bug that would cause ld a, i and ld a, r to reset the P/V flag if an interrupt occurred near the instruction. This bug was corrected in the CMOS version of the Z80, which is the version that is in the ASICs; therefore, you do not need to worry about the bug if you don't need your software to run on the older TI-83+s that were manufactured with a discrete Z80. The workaround for the TI-83+ is either to prohibit using older units, or to perform the ld a, i/r operation twice, and compare the results.		If you want to know whether interrupts are currently enabled or not (so you can disable them, and then enable interrupts again if and only if they were enabled before), the ld a, i and ld a, r instructions will copy the value of IFF2 into the P/V flag. In other words, if interrupts are enabled, the P/V flag will be set. The original NMOS-based Z80 had a bug that would cause ld a, i and ld a, r to reset the P/V flag if an interrupt occurred near the instruction. This bug was corrected in the CMOS version of the Z80, which is the version that is in the ASICs; therefore, you do not need to worry about the bug if you don't need your software to run on the older TI-83+s that were manufactured with a discrete Z80. The workaround for the TI-83+ is either to prohibit using older units, or to perform the ld a, i/r operation twice, and compare the results.
−
−	The TA3 ASIC, used in older TI-84+s/SEs and the TI-83+CSE, has a useful quirk. It always sends the byte FF when an interrupt is generated. So IM 0 and IM 1 are the same. Even better, you only need to specify the final address in the IVT, and the high and low bytes don't have to be the same. Unfortunately, the TA1 ASIC doesn't do this, so TI-84+/SE software can't depend on this quirk. Also, if TI does anything to address the speed issues of the TI-84+CSE, they will probably break this useful feature just to spite us.

@@ Line 1: / Line 1: @@
 [[Category:83Plus:General Hardware Information|Interrupts]]
 [[Category:84PCSE:General Hardware Information|Interrupts]]
-The Z80 CPU supports three different modes of handling interrupts. They are called IM 0, IM 1, and IM 2. The IM 0 mode is identical to the Intel 8080's interrupt handling and is provided for compatibility. In IM 0, the interrupting hardware takes over the bus and sends an instruction to the CPU to execute. This instruction would usually be an RST instruction, which is what the RST instructions were designed for. In IM 1, the Z80 always executes RST 38h.
+The Z80 CPU supports three different modes of handling interrupts. They are called IM 0, IM 1, and IM 2. In all modes, after accepting an interrupt, the Z80 disables interrupts and you must manually enable them again at the end of your interrupt service routine. The IM 0 mode is identical to the Intel 8080's interrupt handling and is provided for compatibility. In IM 0, the interrupting hardware takes over the bus and sends an instruction to the CPU to execute. This instruction would usually be an RST instruction, which is what the RST instructions were designed for. In IM 1, the Z80 always executes RST 38h.
 In IM 2, the Z80 uses an interrupt vector table. The interrupting hardware gives the Z80 an index into the table, such that up to 128 devices can automatically specify which interrupt service routine (ISR) needs to be run. The I register specifies where the IVT starts. Since I is 8 bits, it only specifies the high byte; the table always starts at an address in which the low byte is zero. The interrupting hardware is supposed to send an 8-bit number that's an index into the table. So the Z80 combines the index and the value of the I register to form a 16-bit address. The Z80 uses the 16-bit number at that address as the location of the ISR.
 The TI-83+ family operating system always operates in IM 1, in which any interrupt signal causes the CPU to execute the RST 38h instruction. The OS provides no hooks for allowing software to catch and process interrupts. Fortunately, the Z80 also has the IM 2 mode, which allows us to move the interrupt vector table (IVT) to any of 256 different locations. Unfortunately, in the TI-83+ IM 2 is semibroken because it would actually be useful to us if it functioned properly. The ASIC doesn't bother to specify an index into the table, so we have to poll different ports to figure out what generated the interrupt. Furthermore, you will note that the number the Z80 expects to be passed is an 8-bit number. Because the addresses in the table are 16-bits, each address takes 2 bytes. But the number the Z80 receives from the ASIC is effectively random. And the Z80 doesn't mask out the bottom bit. So you have to fill the table with 257 repeating bytes, and your ISR can only be at an address in which the high and lows bytes are the same.
 The TA3 ASIC, used in older TI-84+s/SEs and the TI-83+CSE, has a useful quirk. It always sends the byte FF when an interrupt is generated. So IM 0 and IM 1 are the same. Even better, you only need to specify the final address in the IVT, and the high and low bytes don't have to be the same. Unfortunately, the TA1 ASIC doesn't do this, so TI-84+/SE software can't depend on this quirk. Also, if TI does anything to address the speed issues of the TI-84+CSE, they will probably break this useful feature just to spite us.