DMA - Revision history

Johnnyo: /* The DMA and Interrupts */ link to hw im2

2026-04-11T19:56:38Z

The DMA and Interrupts: link to hw im2

← Older revision		Revision as of 20:56, 11 April 2026
Line 271:		Line 271:
	The other side of this is that while the DMA controls the bus, the Z80 cannot respond to interrupts. On the Z80, the NMI interrupt is edge triggered so if an NMI occurs the fact that it occurred is stored internally in the Z80 so that it will respond when it is woken up. On the other hand, maskable interrupts are level triggered. That is, the Z80 must be active to regularly sample the /INT line to determine if a maskable interrupt is occurring. On the Spectrum and the ZX Next, the ULA (and line interrupt) are only asserted for a fixed amount of time ~30 cycles at 3.5MHz. If the DMA is executing a transfer while the interrupt is asserted, the CPU will not be able to see this and it will most likely miss the interrupt. In burst mode, with large-enough prescalar value, the CPU will never miss these interrupts, although this may change if multiple channels are implemented.		The other side of this is that while the DMA controls the bus, the Z80 cannot respond to interrupts. On the Z80, the NMI interrupt is edge triggered so if an NMI occurs the fact that it occurred is stored internally in the Z80 so that it will respond when it is woken up. On the other hand, maskable interrupts are level triggered. That is, the Z80 must be active to regularly sample the /INT line to determine if a maskable interrupt is occurring. On the Spectrum and the ZX Next, the ULA (and line interrupt) are only asserted for a fixed amount of time ~30 cycles at 3.5MHz. If the DMA is executing a transfer while the interrupt is asserted, the CPU will not be able to see this and it will most likely miss the interrupt. In burst mode, with large-enough prescalar value, the CPU will never miss these interrupts, although this may change if multiple channels are implemented.

	'''Since core 3.1.8:''' the ability to interrupt DMA transfers was added, this is opt-in mechanism and must be configured through {{NextRegNo\|$CC}}, {{NextRegNo\|$CD}} and {{NextRegNo\|$CE}} and requires "hw im2 mode" interrupts being set. Because interrupts are only sampled at the end of an instruction by the Z80, each time the dma is interrupted one instruction of progress is made in the main program (before the interrupt handler code is entered).		'''Since core 3.1.8:''' the ability to interrupt DMA transfers was added, this is opt-in mechanism and must be configured through {{NextRegNo\|$CC}}, {{NextRegNo\|$CD}} and {{NextRegNo\|$CE}} and requires [[hw im2 mode]] interrupts being set. Because interrupts are only sampled at the end of an instruction by the Z80, each time the dma is interrupted one instruction of progress is made in the main program (before the interrupt handler code is entered).

	This means after starting the DMA transfer with last `out` instruction you must follow it by N instructions which don't affect the transfer (don't remap source data memory, select different sprite/copper/... index if that's target of transfer, don't write anything to zxnDMA port), either doing different kind of work with CPU or adding block of `nop` instructions, to have non-interfering block of code available to fire N interrupts during transfer. Chose N to accommodate for worst case scenario of how many times you will interrupt the running DMA transfer. Or you can read state of zxnDMA to see if transfer did finish, but (IMHO by ped7g) in most cases it will be performance-cheaper to just add block of nop instructions or do other work on CPU not interfering with transfer.		This means after starting the DMA transfer with last `out` instruction you must follow it by N instructions which don't affect the transfer (don't remap source data memory, select different sprite/copper/... index if that's target of transfer, don't write anything to zxnDMA port), either doing different kind of work with CPU or adding block of `nop` instructions, to have non-interfering block of code available to fire N interrupts during transfer. Chose N to accommodate for worst case scenario of how many times you will interrupt the running DMA transfer. Or you can read state of zxnDMA to see if transfer did finish, but (IMHO by ped7g) in most cases it will be performance-cheaper to just add block of nop instructions or do other work on CPU not interfering with transfer.

Ped7g: Note about command A7 and Zilog docs vs Next FPGA implementation

2026-03-30T14:13:17Z

Note about command A7 and Zilog docs vs Next FPGA implementation

← Older revision		Revision as of 15:13, 30 March 2026
Line 613:		Line 613:
	The command 0xBB setting read mask will cause implicit 0xA7 Initialize Read Sequence.		The command 0xBB setting read mask will cause implicit 0xA7 Initialize Read Sequence.
	(does apply also to zxnDMA mode)		(does apply also to zxnDMA mode)

			The command 0xA7 does initialize read sequence even when the previous sequence was only partially read (ZX Next FPGA implementation for both zxnDMA and Zilog-DMA) and there were more bytes pending. According to Zilog documentation the original Zilog DMA is claimed to ignore 0xA7 command in such case. Needs verification on HW to be fully confirmed, especially the original Zilog chip, this looks a bit unlikely, it would make lot more sense to abort current sequence and reset it.

	Be aware that both custom timing cycles count, and prescalar values are preserved in zxnDMA even when future write to WR1/WR2 does skip these particular bytes. To reset prescalar or cycles timing, write explicitly zero into prescalar register or use commands reset/reset-port-timing.		Be aware that both custom timing cycles count, and prescalar values are preserved in zxnDMA even when future write to WR1/WR2 does skip these particular bytes. To reset prescalar or cycles timing, write explicitly zero into prescalar register or use commands reset/reset-port-timing.

Ped7g: formatting + note

2026-03-30T12:16:56Z

formatting + note

← Older revision		Revision as of 13:16, 30 March 2026
Line 604:		Line 604:

	<del>Any read of zxnDMA port without pending read request (commands "Read Status Byte" or "Initialize Read Sequence") will return status byte (Zilog will return random value vaguely similar to status byte, but incorrect, UA858D will return zero).		<del>Any read of zxnDMA port without pending read request (commands "Read Status Byte" or "Initialize Read Sequence") will return status byte (Zilog will return random value vaguely similar to status byte, but incorrect, UA858D will return zero).
	(does apply also to zxnDMA mode)</del>		(does apply also to zxnDMA mode)</del><br>
	2026-03-30: any read of zxnDMA port without pending read request will return next byte in read sequence, the default read mask is 0x7F after power on (based on reading the VHDL, needs to verify with HW).		2026-03-30: any read of zxnDMA port without pending read request will return next byte in read sequence, the default read mask is 0x7F after power on (based on reading the VHDL, needs to verify with HW).

	<del>Status byte doesn't have bit 0 set (the "T" bit in description above).		<del>Status byte doesn't have bit 0 set (the "T" bit in description above).
	(does apply also to zxnDMA mode)</del>		(does apply also to zxnDMA mode)</del><br>
	2026-03-30: going by [https://gitlab.com/SpectrumNext/ZX%20Spectrum%20Next%20FPGA/-/blob/master/cores/zxnext/src/device/dma.vhd?ref%20type=heads VHDL source] this seems to be now fixed, needs to verify with HW and guess in which version of core this was fixed		2026-03-30: going by [https://gitlab.com/SpectrumNext/ZX%20Spectrum%20Next%20FPGA/-/blob/master/cores/zxnext/src/device/dma.vhd?ref%20type=heads VHDL source] this seems to be now fixed, needs to verify with HW and guess in which version of core this was fixed

	The command 0xBB setting read mask will cause implicit 0xA7 Initialize Read Sequence.		The command 0xBB setting read mask will cause implicit 0xA7 Initialize Read Sequence.
			(does apply also to zxnDMA mode)

	Be aware that both custom timing cycles count, and prescalar values are preserved in zxnDMA even when future write to WR1/WR2 does skip these particular bytes. To reset prescalar or cycles timing, write explicitly zero into prescalar register or use commands reset/reset-port-timing.		Be aware that both custom timing cycles count, and prescalar values are preserved in zxnDMA even when future write to WR1/WR2 does skip these particular bytes. To reset prescalar or cycles timing, write explicitly zero into prescalar register or use commands reset/reset-port-timing.

Ped7g: adding more notes about reading-status of zxnDMA, figured out while reading VHDL and debugging Mike's mod player init.

2026-03-30T12:14:20Z

adding more notes about reading-status of zxnDMA, figured out while reading VHDL and debugging Mike's mod player init.

← Older revision		Revision as of 13:14, 30 March 2026
Line 603:		Line 603:
	(does apply also to zxnDMA mode, except addresses are adjusted only "length" times of course, counter has still swapped bytes)		(does apply also to zxnDMA mode, except addresses are adjusted only "length" times of course, counter has still swapped bytes)

	Any read of zxnDMA port without pending read request (commands "Read Status Byte" or "Initialize Read Sequence") will return status byte (Zilog will return random value vaguely similar to status byte, but incorrect, UA858D will return zero).		<del>Any read of zxnDMA port without pending read request (commands "Read Status Byte" or "Initialize Read Sequence") will return status byte (Zilog will return random value vaguely similar to status byte, but incorrect, UA858D will return zero).
	(does apply also to zxnDMA mode)		(does apply also to zxnDMA mode)</del>
			2026-03-30: any read of zxnDMA port without pending read request will return next byte in read sequence, the default read mask is 0x7F after power on (based on reading the VHDL, needs to verify with HW).

	Status byte doesn't have bit 0 set (the "T" bit in description above).		<del>Status byte doesn't have bit 0 set (the "T" bit in description above).
	(does apply also to zxnDMA mode)		(does apply also to zxnDMA mode)</del>
			2026-03-30: going by [https://gitlab.com/SpectrumNext/ZX%20Spectrum%20Next%20FPGA/-/blob/master/cores/zxnext/src/device/dma.vhd?ref%20type=heads VHDL source] this seems to be now fixed, needs to verify with HW and guess in which version of core this was fixed

			The command 0xBB setting read mask will cause implicit 0xA7 Initialize Read Sequence.

	Be aware that both custom timing cycles count, and prescalar values are preserved in zxnDMA even when future write to WR1/WR2 does skip these particular bytes. To reset prescalar or cycles timing, write explicitly zero into prescalar register or use commands reset/reset-port-timing.		Be aware that both custom timing cycles count, and prescalar values are preserved in zxnDMA even when future write to WR1/WR2 does skip these particular bytes. To reset prescalar or cycles timing, write explicitly zero into prescalar register or use commands reset/reset-port-timing.

Ped7g: adding info about hw im2 mode interrupts executing extra instructions on "main thread"

2025-12-06T22:25:50Z

adding info about hw im2 mode interrupts executing extra instructions on "main thread"

← Older revision		Revision as of 23:25, 6 December 2025
Line 270:		Line 270:

	The other side of this is that while the DMA controls the bus, the Z80 cannot respond to interrupts. On the Z80, the NMI interrupt is edge triggered so if an NMI occurs the fact that it occurred is stored internally in the Z80 so that it will respond when it is woken up. On the other hand, maskable interrupts are level triggered. That is, the Z80 must be active to regularly sample the /INT line to determine if a maskable interrupt is occurring. On the Spectrum and the ZX Next, the ULA (and line interrupt) are only asserted for a fixed amount of time ~30 cycles at 3.5MHz. If the DMA is executing a transfer while the interrupt is asserted, the CPU will not be able to see this and it will most likely miss the interrupt. In burst mode, with large-enough prescalar value, the CPU will never miss these interrupts, although this may change if multiple channels are implemented.		The other side of this is that while the DMA controls the bus, the Z80 cannot respond to interrupts. On the Z80, the NMI interrupt is edge triggered so if an NMI occurs the fact that it occurred is stored internally in the Z80 so that it will respond when it is woken up. On the other hand, maskable interrupts are level triggered. That is, the Z80 must be active to regularly sample the /INT line to determine if a maskable interrupt is occurring. On the Spectrum and the ZX Next, the ULA (and line interrupt) are only asserted for a fixed amount of time ~30 cycles at 3.5MHz. If the DMA is executing a transfer while the interrupt is asserted, the CPU will not be able to see this and it will most likely miss the interrupt. In burst mode, with large-enough prescalar value, the CPU will never miss these interrupts, although this may change if multiple channels are implemented.

			'''Since core 3.1.8:''' the ability to interrupt DMA transfers was added, this is opt-in mechanism and must be configured through {{NextRegNo\|$CC}}, {{NextRegNo\|$CD}} and {{NextRegNo\|$CE}} and requires "hw im2 mode" interrupts being set. Because interrupts are only sampled at the end of an instruction by the Z80, each time the dma is interrupted one instruction of progress is made in the main program (before the interrupt handler code is entered).

			This means after starting the DMA transfer with last `out` instruction you must follow it by N instructions which don't affect the transfer (don't remap source data memory, select different sprite/copper/... index if that's target of transfer, don't write anything to zxnDMA port), either doing different kind of work with CPU or adding block of `nop` instructions, to have non-interfering block of code available to fire N interrupts during transfer. Chose N to accommodate for worst case scenario of how many times you will interrupt the running DMA transfer. Or you can read state of zxnDMA to see if transfer did finish, but (IMHO by ped7g) in most cases it will be performance-cheaper to just add block of nop instructions or do other work on CPU not interfering with transfer.

	== Programming examples ==		== Programming examples ==

Ped7g: Adding one more note about prescalar being reset by reset commands to make it easier to find.

2025-12-02T09:36:40Z

Adding one more note about prescalar being reset by reset commands to make it easier to find.

← Older revision		Revision as of 10:36, 2 December 2025
Line 243:		Line 243:
	Unimplemented Z80 DMA commands are ignored.		Unimplemented Z80 DMA commands are ignored.

	Prior to starting the DMA, a LOAD command must be issued to copy the Port A and Port B addresses into the DMA's internal pointers. Then an 'Enable DMA' command is issued to start the DMA.		Prior to starting the DMA transfer, a LOAD command must be issued to copy the Port A and Port B addresses into the DMA's internal pointers. Then an 'Enable DMA' command is issued to start the DMA. The last LOAD command before ENABLE must be done with correct transfer direction set.

	The 'Continue' command resets the DMA's byte counter so that a following 'Enable DMA' allows the DMA to repeat the last transfer but using the current internal address pointers. I.e. it continues from where the last copy operation left off.		The 'Continue' command resets the DMA's byte counter so that a following 'Enable DMA' allows the DMA to repeat the last transfer but using the current internal address pointers. I.e. it continues from where the last copy operation left off.

			Reset and Reset Port A/B Timing commands on zxnDMA do reset also prescalar value.

	Registers can be read via an IO read from the DMA port after setting the read mask. (At power up the read mask is set to 0x7f). Register values are the current internal DMA counter values. So 'Port Address A Low' is the lower 8-bits of Port A’s next transfer address. Once the end of the read mask is reached, further reads loop around to the first one.		Registers can be read via an IO read from the DMA port after setting the read mask. (At power up the read mask is set to 0x7f). Register values are the current internal DMA counter values. So 'Port Address A Low' is the lower 8-bits of Port A’s next transfer address. Once the end of the read mask is reached, further reads loop around to the first one.

Intrepidis: Layer2 auto-slowdown was lifted in Core 3.0

2024-01-06T15:56:25Z

Layer2 auto-slowdown was lifted in Core 3.0

← Older revision		Revision as of 16:56, 6 January 2024
Line 258:		Line 258:

	== Operating speed ==		== Operating speed ==
	The zxnDMA operates at the same speed as the CPU, that is 3.5MHz, 7MHz, 14MHz or 28Mhz. This is a contended clock that is modified by the ULA and the auto-slowdown by [[Layer 2\|Layer2]].		The zxnDMA operates at the same speed as the CPU, that is 3.5MHz, 7MHz, 14MHz or 28Mhz. This is a contended clock that is modified by the ULA and the auto-slowdown by [[Layer 2\|Layer2]] (which only occurred in Next core's 1 and 2, the limitation was lifted in core 3.0).

	~~Auto~~-slowdown occurs without user intervention if speed exceeds 7Mhz and the active Layer2 display is being generated (higher speed operation resumes when the active Layer2 display is not generated). Programmers do NOT need to account for speed differences regarding DMA transfers as this happens automatically.		The (pre-core 3.0) auto-slowdown occurs without user intervention if speed exceeds 7Mhz and the active Layer2 display is being generated (higher speed operation resumes when the active Layer2 display is not generated). Programmers do NOT need to account for speed differences regarding DMA transfers as this happens automatically.

	Because of this, the cycle lengths for Ports A and B can be set to their minimum values without ill effects. The cycle lengths specified for Ports A and B are intended to selectively slow down read or write cycles for hardware that cannot operate at the DMA's full speed.		Because of this, the cycle lengths for Ports A and B can be set to their minimum values without ill effects. The cycle lengths specified for Ports A and B are intended to selectively slow down read or write cycles for hardware that cannot operate at the DMA's full speed.

SaNchez at 00:22, 19 October 2023

2023-10-19T00:22:48Z

← Older revision		Revision as of 01:22, 19 October 2023
Line 258:		Line 258:

	== Operating speed ==		== Operating speed ==
	The zxnDMA operates at the same speed as the CPU, that is 3.5MHz, 7MHz or ~~14MHz~~. This is a contended clock that is modified by the ULA and the auto-slowdown by [[Layer 2\|Layer2]].		The zxnDMA operates at the same speed as the CPU, that is 3.5MHz, 7MHz, 14MHz or 28Mhz. This is a contended clock that is modified by the ULA and the auto-slowdown by [[Layer 2\|Layer2]].

	Auto-slowdown occurs without user intervention if speed exceeds 7Mhz and the active Layer2 display is being generated (higher speed operation resumes when the active Layer2 display is not generated). Programmers do NOT need to account for speed differences regarding DMA transfers as this happens automatically.		Auto-slowdown occurs without user intervention if speed exceeds 7Mhz and the active Layer2 display is being generated (higher speed operation resumes when the active Layer2 display is not generated). Programmers do NOT need to account for speed differences regarding DMA transfers as this happens automatically.

Ped7g: adding mention of B3 command to not confuse me every time I see it in old code, and looking what it is...

2021-09-28T17:47:58Z

adding mention of B3 command to not confuse me every time I see it in old code, and looking what it is...

← Older revision		Revision as of 18:47, 28 September 2021
Line 208:		Line 208:
	1 0 0 0 1 = 0xC7 = Reset Port A Timing		1 0 0 0 1 = 0xC7 = Reset Port A Timing
	1 0 0 1 0 = 0xCB = Reset Port B Timing		1 0 0 1 0 = 0xCB = Reset Port B Timing
			0 1 1 0 0 = 0xB3 = Force Ready (irrelevant for zxnDMA)
	0 1 1 1 1 = 0xBF = Read Status Byte		0 1 1 1 1 = 0xBF = Read Status Byte
	0 0 0 1 0 = 0x8B = Reinitialize Status Byte		0 0 0 1 0 = 0x8B = Reinitialize Status Byte

Ped7g: core 3.1.4 changes/refresh

2020-04-16T01:08:02Z

core 3.1.4 changes/refresh

← Older revision		Revision as of 02:08, 16 April 2020
Line 574:		Line 574:
	Based on original text by: Allen Albright & Mike Dailly with input by Jim Bagley, Lyndon J Sharp and Phoebus R. Dokos		Based on original text by: Allen Albright & Mike Dailly with input by Jim Bagley, Lyndon J Sharp and Phoebus R. Dokos

	== Technical details (core 3.1.3) ==		== Technical details (core 3.1.3+) ==

	The Zilog/zxnDMA mode is now selected by using the particular I/O port number ({{PortNo\|$xx6B}} for zxnDMA mode, {{PortNo\|$xx0B}} for Zilog mode). The bit 6 in {{NextRegNo\|$06}} is not DMA related any more and will be reused for something different.		The Zilog/zxnDMA mode is now selected by using the particular I/O port number ({{PortNo\|$xx6B}} for zxnDMA mode, {{PortNo\|$xx0B}} for Zilog mode). The bit 6 in {{NextRegNo\|$06}} is not DMA related any more and will be reused for something different.

	~~<del>~~The "counter" RR1-RR2 read back after transfer has ~~now~~ correct byte order.~~</del> - and not yet, the WIP build was faulty and the fix was reverted for this moment, so still waiting for this fix~~.		The "counter" RR1-RR2 read back after transfer has correct byte order since core 3.1.4.

	Other differences described below in "3.0.5" remains (but from practical point of view the Zilog DMA emulation in 3.1.3 is near-perfect, all the remaining differences are very minor).		Other differences described below in "3.0.5" remains (but from practical point of view the Zilog DMA emulation in 3.1.4 is near-perfect, all the remaining differences are very minor).

	== Technical details (core 3.0.5) ==		== Technical details (core 3.0.5) ==