SpecNext Wiki - User contributions [en-gb]

Bibliography

2026-05-31T10:18:15Z

Johnnyo: /* ZX Spectrum Books and Documentation */ ZX Spectrum BASIC Programming

= ZX Spectrum Next Documentation =

The Next project is continuously improved, so it's a good practice to check for the most recent updates of the manuals, documents and Next-specific books.

== ZX Spectrum Next Manual ==

* Available online: [[FAQ#Where_can_I_download_a_copy_of_the_manual?]]

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder written and kept up to date by the author of NextZXOS and NextBASIC.

= Next-specific Books =

(The Next specific books are typically written under assumption that the reader is already familiar enough with the low-level hardware programming aspects relevant to the original ZX Spectrum, so the readers who aren't should also check the books about the "classic" ZX Spectrum too)

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or as a printed coil bound book.

== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
Many books were written since 1982, this is just a selection.

== ''Sinclair ZX Spectrum BASIC Programming'' by Steven Vickers (1982) ==

* https://worldofspectrum.net/ZXBasicManual/ The book included in the original package of ZX Spectrum 48K. Wealth of information in a single book.

== ''Step-by-Step Programming ZX Spectrum'' Series ==
* Book One, by Ian Graham (1984) https://worldofspectrum.net/item/2001330/
* Book Two, by Ian Graham (1984) https://worldofspectrum.net/item/2001331/
* Book Three, by Piers Letcher (1985) https://worldofspectrum.net/item/2000385/
* Book Four, by Piers Letcher (1985) https://worldofspectrum.net/item/2000460/

== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games (Since 2006, updated recently)
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm
== ''First Steps in Z80 Assembly Language'' (for ZX Spectrum) by Darryl Sloan (2020) ==
* The motivation for writing this book in 2020 was the release of the Sinclair ZX Spectrum Next, even if it (mostly?) covers the assembly which would work on the original ZX Spectrum: http://ped.7gods.org/z80.pdf
== ''Understanding Your Spectrum'' by Dr. Ian Logan (1982) ==
* https://spectrumcomputing.co.uk/entry/2000400/Book/Understanding_Your_Spectrum

Bibliography

2026-05-23T13:39:29Z

Johnnyo: /* Step-by-Step Programming ZX Spectrum Series */

= ZX Spectrum Next Documentation =

The Next project is continuously improved, so it's a good practice to check for the most recent updates of the manuals, documents and Next-specific books.

== ZX Spectrum Next Manual ==

* Available online: [[FAQ#Where_can_I_download_a_copy_of_the_manual?]]

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder written and kept up to date by the author of NextZXOS and NextBASIC.

= Next-specific Books =

(The Next specific books are typically written under assumption that the reader is already familiar enough with the low-level hardware programming aspects relevant to the original ZX Spectrum, so the readers who aren't should also check the books about the "classic" ZX Spectrum too)

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or as a printed coil bound book.

== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
Many books were written since 1982, this is just a selection.
== Step-by-Step Programming ZX Spectrum Series ==
* Book One, by Ian Graham (1984) https://worldofspectrum.net/item/2001330/
* Book Two, by Ian Graham (1984) https://worldofspectrum.net/item/2001331/
* Book Three, by Piers Letcher (1985) https://worldofspectrum.net/item/2000385/
* Book Four, by Piers Letcher (1985) https://worldofspectrum.net/item/2000460/

== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games (Since 2006, updated recently)
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm
== ''First Steps in Z80 Assembly Language'' (for ZX Spectrum) by Darryl Sloan (2020) ==
* The motivation for writing this book in 2020 was the release of the Sinclair ZX Spectrum Next, even if it (mostly?) covers the assembly which would work on the original ZX Spectrum: http://ped.7gods.org/z80.pdf
== ''Understanding Your Spectrum'' by Dr. Ian Logan (1982) ==
* https://spectrumcomputing.co.uk/entry/2000400/Book/Understanding_Your_Spectrum

Bibliography

2026-05-23T13:35:04Z

Johnnyo: /* Step-by-Step Programming ZX Spectrum Series */

= ZX Spectrum Next Documentation =

The Next project is continuously improved, so it's a good practice to check for the most recent updates of the manuals, documents and Next-specific books.

== ZX Spectrum Next Manual ==

* Available online: [[FAQ#Where_can_I_download_a_copy_of_the_manual?]]

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder written and kept up to date by the author of NextZXOS and NextBASIC.

= Next-specific Books =

(The Next specific books are typically written under assumption that the reader is already familiar enough with the low-level hardware programming aspects relevant to the original ZX Spectrum, so the readers who aren't should also check the books about the "classic" ZX Spectrum too)

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or as a printed coil bound book.

== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
Many books were written since 1982, this is just a selection.
== Step-by-Step Programming ZX Spectrum Series ==
* Book One, by Ian Graham https://worldofspectrum.net/item/2001330/
* Book Two, by Ian Graham https://worldofspectrum.net/item/2001331/
* Book Three, by Piers Letcher https://worldofspectrum.net/item/2000385/
* Book Four, by Piers Letcher https://worldofspectrum.net/item/2000460/

== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games (Since 2006, updated recently)
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm
== ''First Steps in Z80 Assembly Language'' (for ZX Spectrum) by Darryl Sloan (2020) ==
* The motivation for writing this book in 2020 was the release of the Sinclair ZX Spectrum Next, even if it (mostly?) covers the assembly which would work on the original ZX Spectrum: http://ped.7gods.org/z80.pdf
== ''Understanding Your Spectrum'' by Dr. Ian Logan (1982) ==
* https://spectrumcomputing.co.uk/entry/2000400/Book/Understanding_Your_Spectrum

Bibliography

2026-05-23T13:34:49Z

Johnnyo: /* ZX Spectrum Books and Documentation */ Step-by-Step Programming ZX Spectrum Series

= ZX Spectrum Next Documentation =

The Next project is continuously improved, so it's a good practice to check for the most recent updates of the manuals, documents and Next-specific books.

== ZX Spectrum Next Manual ==

* Available online: [[FAQ#Where_can_I_download_a_copy_of_the_manual?]]

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder written and kept up to date by the author of NextZXOS and NextBASIC.

= Next-specific Books =

(The Next specific books are typically written under assumption that the reader is already familiar enough with the low-level hardware programming aspects relevant to the original ZX Spectrum, so the readers who aren't should also check the books about the "classic" ZX Spectrum too)

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or as a printed coil bound book.

== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
Many books were written since 1982, this is just a selection.
== Step-by-Step Programming ZX Spectrum Series ==
* Book One, by Ian Graham https://worldofspectrum.net/item/2001330/
* Book Two, by Ian Graham https://worldofspectrum.net/item/2001331/
* Book Three, by Piers Letcher https://worldofspectrum.net/item/2000385/
* Book Four, by Piers Letcher https://worldofspectrum.net/item/2000460/

https://worldofspectrum.net/item/2001330/
== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games (Since 2006, updated recently)
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm
== ''First Steps in Z80 Assembly Language'' (for ZX Spectrum) by Darryl Sloan (2020) ==
* The motivation for writing this book in 2020 was the release of the Sinclair ZX Spectrum Next, even if it (mostly?) covers the assembly which would work on the original ZX Spectrum: http://ped.7gods.org/z80.pdf
== ''Understanding Your Spectrum'' by Dr. Ian Logan (1982) ==
* https://spectrumcomputing.co.uk/entry/2000400/Book/Understanding_Your_Spectrum

Layer 2

2026-05-20T00:39:10Z

Johnnyo: rewording

Layer 2 provides an additional screen layer at 256x192 256 colours, 320x256 256 colours or 640x256 16 colours in which every pixel is individually coloured. Layer 2 may appear in place of, behind, or above the ULA-generated/Tilemap layer.

The palette used to show the Layer 2 is selected by the bit 2 of the {{NextRegNo|$43}}.

The Layer 2 screen occupies 48kiB or 80kiB, spreading over 3, or 5, consecutive 16K [[Memory map|banks]]. By the NextZXOS/NextBASIC default, the same banks 9-11 are used for both the visible and the "shadow" Layer 2 screen (the core, after power-on but before the NextZXOS boots set its defaults to 8-10 for the displayed Layer 2 screen and 11-13 for the shadow screen, but these settings are modified during the boot of NextZXOS). The starting bank of the main Layer 2 screen can be changed using {{NextRegNo|$12}} and and the starting bank for the shadow Layer 2 screen can be changed using {{NextRegNo|$13}} (avoid using banks 5, 7 and 8 for the Layer 2 screen, unless you are familiar with SRAM and BRAM of the board and how the ULA screen memory has special treatment in Next's FPGA).

Each pixel of Layer 2 takes one byte of video memory in 8bpp modes or half a byte in 4bpp mode, so the Layer 2 needs 48kiB for 256x192 mode or 80kiB for 320x256-8bit or 640x256-4bit mode. The Layer 2 256x192 mode is divided '''horizontally''' into 3 16kiB banks of 64 '''lines''' each. The modes 320x256 and 640x256 are divided '''vertically''' into 5 16kiB banks of 64 '''columns''' each for 320x256 mode or 128 '''columns''' each for 640x256 mode.

Layer 2 is controlled via {{PortNo|$123B}} and {{NextRegNo|$70}}, the port is bit mapped as follows:

{| class="wikitable"
! Bit !! Description
|-
| 7-6 || Video RAM bank select (write/read paging)
|-
| 5-4 || Reserved, write 0
|-
| 3 || Use Shadow Layer 2 for paging - {{NextRegNo|$13}}
|-
| 2 || Enable Layer 2 read-only paging
|-
| 1 || Layer 2 visible - {{NextRegNo|$12}}
Since core 3.0 this bit has mirror in {{NextRegNo|$69}}
|-
| 0 || Enable Layer 2 write-only paging
|}

When bit 0 of $123B is set to 1, the appropriate area of Layer 2 video memory (as set by bits 6-7) is accessed by '''writes''' into slot 1, ie memory area $0000-$3fff (see [[Memory map]]). This prevents any conflict since this area would normally be ROM and thus useless to write to. However, you '''cannot READ the contents of Layer 2 via this mapping!''' Reading addresses in this range will read the values from the ROM page (or RAM bank if in AllRam mode) that would be mapped there normally if Layer 2 paging was disabled.

When bit 2 of $123B is set to 1 (new feature of core 3.0), the same area $0000-$3fff is remapped for read, allowing read access into Layer 2 bank selected by bits 3,6 and 7 (while write will still go into the regular ROM/RAM page).

With both bits 0 and 2 set you are creating alternative read+write mapping of RAM (technically identical to mapping done by MM0+MMU1 registers).

Bank 5 and first half of Bank 7, when being accessed by regular means (MMU paging, default memory mapping, DMA), are overshadowed by fast BRAM memory inside the FPGA chip, which is then used to generate ULA screen and [[Tilemap]] graphics (aka "Layer 3") - not using the SRAM memory chip in that particular area. This Layer 2 (mapping and visible data) is the only exception, circumventing this mechanism and accessing the Bank 5 and Bank 7 in the main memory SRAM chip (giving you extra 16+8kiB of "secret" memory and further headache to emulators' authors). If you are not sure what this means, just avoid using bank 5 and 7 for Layer 2, use values greater/equal to 8 (and avoid also Bank 8, unless you want to destroy NextBASIC warm-restart/soft-reset variables).

Bits 6 and 7 contain the number which third of Layer 2 should be mapped (0..2), or (new feature of core 3.0) when value 3 is set, whole 48kiB of Layer 2 is mapped into area $0000-$bfff (make sure your code, stack and interrupts will cope well with such new mapping).

There is one more new functionality in latest 3.x cores, allowing to set bank-offset variable from 0 to 7. This offset is further applied to the bank selected for write/read (by writing value 0..7 to the port with bit4 set (so it's value 16..23). If you did set for example 16kiB write mapping of first bank, the first bank is 9, and use value 21 for bank-offset setup (+5 offset), the bank mapped into $0000..$3FFF address area will be 14 (9+5). This way you can map full 80kiB of pixel data into the bottom 16kiB window (or bottom 48kiB window), using different offsets.

Use {{NextRegNo|$70}} to select particular Layer2 mode, and to modify palette offset (added to top four bits of each pixel). Don't forget to set up Layer 2 clip window correctly for each mode ({{NextRegNo|$18}}).

You can still use also the regular [[Memory map|banking]] ports to switch in one of the Layer 2 banks in slot for at $C000 (or use the ZX Next MMU registers to map that RAM in other regions). This will allow you to read and write the memory as usual. The ability to write to Layer 2 via writes into slot 1 is provided for convenience and to allow graphics data to be easily copied from extended RAM banks.

Pixels are drawn to Layer 2 by writing to the appropriate area of RAM. Layer 2 pixels in 256x192 mode are in English reading order with no ULA-style interlacing. Since there are 256 pixels per line, and when using access via slot 1 the memory port starts at $0000, the upper byte of the address exactly equals the Y coordinate (within the selected third of the screen) and the lower byte exactly equals the X coordinate.

In mode 320x256 (8bpp) the pixels are stored in memory going from top to bottom and left to right (second byte is first pixel on second line, 256th byte is second pixel on first line). Since there are 256 pixels per column, the upper byte of address could represent the X coordinate (only specific range of them, as whole 0..319 range does not fit into 8 bits), and the lower byte of address is Y coordinate. The total pixel memory is 80kiB (five 16kiB banks), and could be mapped into memory either by MMU or by bank-offset feature of {{PortNo|$123B}}.

In mode 640x256 (4bpp) the pixels are stored identically to 320x256 mode, but every byte contains two pixels. The top nibble (top four bits) form "left" pixel, and the bottom nibble form "right" pixel, so first 256 bytes will display as two columns on screen, not one.

Note that you will need to manually clear the Layer 2 screen before drawing on it, as it may contain random data when the machine starts up.

System registers {{NextRegNo|$16}}, {{NextRegNo|$71}} and {{NextRegNo|$17}} apply a pixel shift to all content in Layer
2, allowing scrolling effects to be created.

Since core 3.0 the visibility of Layer 2 is not affected by usage of ZX128 ULA-shadow (Bank 7) screen.

Obsolete info for core 2.x (limitation was lifted in core 3.0): <del>the visible Layer 2 will cause the slow down of CPU to 7MHz.</del>

To use double-buffered scheme for Layer 2, think about {{NextRegNo|$12}} being display related (i.e. has to be changed to display new Layer 2, when the new image is already prepared) (or it may be modified also during frame to compose final image from various memory areas), while {{NextRegNo|$13}} is related only to write-over-ROM paging functionality ({{PortNo|$123B}}).

Layer 2

2026-05-20T00:37:52Z

Johnnyo: rewording starting REG 12 / 13

Layer 2 provides an additional screen layer at 256x192 256 colours, 320x256 256 colours or 640x256 16 colours in which every pixel is individually coloured. Layer 2 may appear in place of, behind, or above the ULA-generated/Tilemap layer.

The palette used to show the Layer 2 is selected by the bit 2 of the {{NextRegNo|$43}}.

The Layer 2 screen occupies 48kiB or 80kiB, which is stored in 3 (or 5) consecutive 16K [[Memory map|banks]]. By NextZXOS/NextBASIC default, the same banks 9-11 are used for both the visible and "shadow" Layer 2 screen (the core, after power-on but before the NextZXOS boots set its defaults to 8-10 for the displayed Layer 2 screen and 11-13 for the shadow screen, but these settings are modified during the boot of NextZXOS). The starting bank of the main Layer 2 screen can be changed using {{NextRegNo|$12}} and and the starting bank for the shadow Layer 2 screen can be changed using {{NextRegNo|$13}} (avoid using banks 5, 7 and 8 for the Layer 2 screen, unless you are familiar with SRAM and BRAM of the board and how the ULA screen memory has special treatment in Next's FPGA).

Each pixel of Layer 2 takes one byte of video memory in 8bpp modes or half a byte in 4bpp mode, so the Layer 2 needs 48kiB for 256x192 mode or 80kiB for 320x256-8bit or 640x256-4bit mode. The Layer 2 256x192 mode is divided '''horizontally''' into 3 16kiB banks of 64 '''lines''' each. The modes 320x256 and 640x256 are divided '''vertically''' into 5 16kiB banks of 64 '''columns''' each for 320x256 mode or 128 '''columns''' each for 640x256 mode.

Layer 2 is controlled via {{PortNo|$123B}} and {{NextRegNo|$70}}, the port is bit mapped as follows:

{| class="wikitable"
! Bit !! Description
|-
| 7-6 || Video RAM bank select (write/read paging)
|-
| 5-4 || Reserved, write 0
|-
| 3 || Use Shadow Layer 2 for paging - {{NextRegNo|$13}}
|-
| 2 || Enable Layer 2 read-only paging
|-
| 1 || Layer 2 visible - {{NextRegNo|$12}}
Since core 3.0 this bit has mirror in {{NextRegNo|$69}}
|-
| 0 || Enable Layer 2 write-only paging
|}

When bit 0 of $123B is set to 1, the appropriate area of Layer 2 video memory (as set by bits 6-7) is accessed by '''writes''' into slot 1, ie memory area $0000-$3fff (see [[Memory map]]). This prevents any conflict since this area would normally be ROM and thus useless to write to. However, you '''cannot READ the contents of Layer 2 via this mapping!''' Reading addresses in this range will read the values from the ROM page (or RAM bank if in AllRam mode) that would be mapped there normally if Layer 2 paging was disabled.

When bit 2 of $123B is set to 1 (new feature of core 3.0), the same area $0000-$3fff is remapped for read, allowing read access into Layer 2 bank selected by bits 3,6 and 7 (while write will still go into the regular ROM/RAM page).

With both bits 0 and 2 set you are creating alternative read+write mapping of RAM (technically identical to mapping done by MM0+MMU1 registers).

Bank 5 and first half of Bank 7, when being accessed by regular means (MMU paging, default memory mapping, DMA), are overshadowed by fast BRAM memory inside the FPGA chip, which is then used to generate ULA screen and [[Tilemap]] graphics (aka "Layer 3") - not using the SRAM memory chip in that particular area. This Layer 2 (mapping and visible data) is the only exception, circumventing this mechanism and accessing the Bank 5 and Bank 7 in the main memory SRAM chip (giving you extra 16+8kiB of "secret" memory and further headache to emulators' authors). If you are not sure what this means, just avoid using bank 5 and 7 for Layer 2, use values greater/equal to 8 (and avoid also Bank 8, unless you want to destroy NextBASIC warm-restart/soft-reset variables).

Bits 6 and 7 contain the number which third of Layer 2 should be mapped (0..2), or (new feature of core 3.0) when value 3 is set, whole 48kiB of Layer 2 is mapped into area $0000-$bfff (make sure your code, stack and interrupts will cope well with such new mapping).

There is one more new functionality in latest 3.x cores, allowing to set bank-offset variable from 0 to 7. This offset is further applied to the bank selected for write/read (by writing value 0..7 to the port with bit4 set (so it's value 16..23). If you did set for example 16kiB write mapping of first bank, the first bank is 9, and use value 21 for bank-offset setup (+5 offset), the bank mapped into $0000..$3FFF address area will be 14 (9+5). This way you can map full 80kiB of pixel data into the bottom 16kiB window (or bottom 48kiB window), using different offsets.

Use {{NextRegNo|$70}} to select particular Layer2 mode, and to modify palette offset (added to top four bits of each pixel). Don't forget to set up Layer 2 clip window correctly for each mode ({{NextRegNo|$18}}).

You can still use also the regular [[Memory map|banking]] ports to switch in one of the Layer 2 banks in slot for at $C000 (or use the ZX Next MMU registers to map that RAM in other regions). This will allow you to read and write the memory as usual. The ability to write to Layer 2 via writes into slot 1 is provided for convenience and to allow graphics data to be easily copied from extended RAM banks.

Pixels are drawn to Layer 2 by writing to the appropriate area of RAM. Layer 2 pixels in 256x192 mode are in English reading order with no ULA-style interlacing. Since there are 256 pixels per line, and when using access via slot 1 the memory port starts at $0000, the upper byte of the address exactly equals the Y coordinate (within the selected third of the screen) and the lower byte exactly equals the X coordinate.

In mode 320x256 (8bpp) the pixels are stored in memory going from top to bottom and left to right (second byte is first pixel on second line, 256th byte is second pixel on first line). Since there are 256 pixels per column, the upper byte of address could represent the X coordinate (only specific range of them, as whole 0..319 range does not fit into 8 bits), and the lower byte of address is Y coordinate. The total pixel memory is 80kiB (five 16kiB banks), and could be mapped into memory either by MMU or by bank-offset feature of {{PortNo|$123B}}.

In mode 640x256 (4bpp) the pixels are stored identically to 320x256 mode, but every byte contains two pixels. The top nibble (top four bits) form "left" pixel, and the bottom nibble form "right" pixel, so first 256 bytes will display as two columns on screen, not one.

Note that you will need to manually clear the Layer 2 screen before drawing on it, as it may contain random data when the machine starts up.

System registers {{NextRegNo|$16}}, {{NextRegNo|$71}} and {{NextRegNo|$17}} apply a pixel shift to all content in Layer
2, allowing scrolling effects to be created.

Since core 3.0 the visibility of Layer 2 is not affected by usage of ZX128 ULA-shadow (Bank 7) screen.

Obsolete info for core 2.x (limitation was lifted in core 3.0): <del>the visible Layer 2 will cause the slow down of CPU to 7MHz.</del>

To use double-buffered scheme for Layer 2, think about {{NextRegNo|$12}} being display related (i.e. has to be changed to display new Layer 2, when the new image is already prepared) (or it may be modified also during frame to compose final image from various memory areas), while {{NextRegNo|$13}} is related only to write-over-ROM paging functionality ({{PortNo|$123B}}).

Layer 2

2026-05-20T00:32:54Z

Johnnyo: wording re starting banks

Layer 2 provides an additional screen layer at 256x192 256 colours, 320x256 256 colours or 640x256 16 colours in which every pixel is individually coloured. Layer 2 may appear in place of, behind, or above the ULA-generated/Tilemap layer.

The palette used to show the Layer 2 is selected by the bit 2 of the {{NextRegNo|$43}}.

The Layer 2 screen occupies 48kiB or 80kiB, which is stored in 3 (or 5) consecutive 16K [[Memory map|banks]]. By NextZXOS/NextBASIC default, banks 9-11 are used for the visible and "shadow" Layer 2 screen (the HW after power-on defaults to 8-10 for displayed and 11-13 for shadow screen, but that gets modified by NextZXOS booting up). The starting bank of the main Layer 2 screen can be changed using {{NextRegNo|$12}} and and the starting bank for the shadow Layer 2 screen can be changed using {{NextRegNo|$13}} (avoid using banks 5, 7 and 8 for the Layer 2 screen, unless you are familiar with SRAM and BRAM of the board and how the ULA screen memory has special treatment in Next's FPGA).

Each pixel of Layer 2 takes one byte of video memory in 8bpp modes or half a byte in 4bpp mode, so the Layer 2 needs 48kiB for 256x192 mode or 80kiB for 320x256-8bit or 640x256-4bit mode. The Layer 2 256x192 mode is divided '''horizontally''' into 3 16kiB banks of 64 '''lines''' each. The modes 320x256 and 640x256 are divided '''vertically''' into 5 16kiB banks of 64 '''columns''' each for 320x256 mode or 128 '''columns''' each for 640x256 mode.

Layer 2 is controlled via {{PortNo|$123B}} and {{NextRegNo|$70}}, the port is bit mapped as follows:

{| class="wikitable"
! Bit !! Description
|-
| 7-6 || Video RAM bank select (write/read paging)
|-
| 5-4 || Reserved, write 0
|-
| 3 || Use Shadow Layer 2 for paging - {{NextRegNo|$13}}
|-
| 2 || Enable Layer 2 read-only paging
|-
| 1 || Layer 2 visible - {{NextRegNo|$12}}
Since core 3.0 this bit has mirror in {{NextRegNo|$69}}
|-
| 0 || Enable Layer 2 write-only paging
|}

When bit 0 of $123B is set to 1, the appropriate area of Layer 2 video memory (as set by bits 6-7) is accessed by '''writes''' into slot 1, ie memory area $0000-$3fff (see [[Memory map]]). This prevents any conflict since this area would normally be ROM and thus useless to write to. However, you '''cannot READ the contents of Layer 2 via this mapping!''' Reading addresses in this range will read the values from the ROM page (or RAM bank if in AllRam mode) that would be mapped there normally if Layer 2 paging was disabled.

When bit 2 of $123B is set to 1 (new feature of core 3.0), the same area $0000-$3fff is remapped for read, allowing read access into Layer 2 bank selected by bits 3,6 and 7 (while write will still go into the regular ROM/RAM page).

With both bits 0 and 2 set you are creating alternative read+write mapping of RAM (technically identical to mapping done by MM0+MMU1 registers).

Bank 5 and first half of Bank 7, when being accessed by regular means (MMU paging, default memory mapping, DMA), are overshadowed by fast BRAM memory inside the FPGA chip, which is then used to generate ULA screen and [[Tilemap]] graphics (aka "Layer 3") - not using the SRAM memory chip in that particular area. This Layer 2 (mapping and visible data) is the only exception, circumventing this mechanism and accessing the Bank 5 and Bank 7 in the main memory SRAM chip (giving you extra 16+8kiB of "secret" memory and further headache to emulators' authors). If you are not sure what this means, just avoid using bank 5 and 7 for Layer 2, use values greater/equal to 8 (and avoid also Bank 8, unless you want to destroy NextBASIC warm-restart/soft-reset variables).

Bits 6 and 7 contain the number which third of Layer 2 should be mapped (0..2), or (new feature of core 3.0) when value 3 is set, whole 48kiB of Layer 2 is mapped into area $0000-$bfff (make sure your code, stack and interrupts will cope well with such new mapping).

There is one more new functionality in latest 3.x cores, allowing to set bank-offset variable from 0 to 7. This offset is further applied to the bank selected for write/read (by writing value 0..7 to the port with bit4 set (so it's value 16..23). If you did set for example 16kiB write mapping of first bank, the first bank is 9, and use value 21 for bank-offset setup (+5 offset), the bank mapped into $0000..$3FFF address area will be 14 (9+5). This way you can map full 80kiB of pixel data into the bottom 16kiB window (or bottom 48kiB window), using different offsets.

Use {{NextRegNo|$70}} to select particular Layer2 mode, and to modify palette offset (added to top four bits of each pixel). Don't forget to set up Layer 2 clip window correctly for each mode ({{NextRegNo|$18}}).

You can still use also the regular [[Memory map|banking]] ports to switch in one of the Layer 2 banks in slot for at $C000 (or use the ZX Next MMU registers to map that RAM in other regions). This will allow you to read and write the memory as usual. The ability to write to Layer 2 via writes into slot 1 is provided for convenience and to allow graphics data to be easily copied from extended RAM banks.

Pixels are drawn to Layer 2 by writing to the appropriate area of RAM. Layer 2 pixels in 256x192 mode are in English reading order with no ULA-style interlacing. Since there are 256 pixels per line, and when using access via slot 1 the memory port starts at $0000, the upper byte of the address exactly equals the Y coordinate (within the selected third of the screen) and the lower byte exactly equals the X coordinate.

In mode 320x256 (8bpp) the pixels are stored in memory going from top to bottom and left to right (second byte is first pixel on second line, 256th byte is second pixel on first line). Since there are 256 pixels per column, the upper byte of address could represent the X coordinate (only specific range of them, as whole 0..319 range does not fit into 8 bits), and the lower byte of address is Y coordinate. The total pixel memory is 80kiB (five 16kiB banks), and could be mapped into memory either by MMU or by bank-offset feature of {{PortNo|$123B}}.

In mode 640x256 (4bpp) the pixels are stored identically to 320x256 mode, but every byte contains two pixels. The top nibble (top four bits) form "left" pixel, and the bottom nibble form "right" pixel, so first 256 bytes will display as two columns on screen, not one.

Note that you will need to manually clear the Layer 2 screen before drawing on it, as it may contain random data when the machine starts up.

System registers {{NextRegNo|$16}}, {{NextRegNo|$71}} and {{NextRegNo|$17}} apply a pixel shift to all content in Layer
2, allowing scrolling effects to be created.

Since core 3.0 the visibility of Layer 2 is not affected by usage of ZX128 ULA-shadow (Bank 7) screen.

Obsolete info for core 2.x (limitation was lifted in core 3.0): <del>the visible Layer 2 will cause the slow down of CPU to 7MHz.</del>

To use double-buffered scheme for Layer 2, think about {{NextRegNo|$12}} being display related (i.e. has to be changed to display new Layer 2, when the new image is already prepared) (or it may be modified also during frame to compose final image from various memory areas), while {{NextRegNo|$13}} is related only to write-over-ROM paging functionality ({{PortNo|$123B}}).

Bibliography

2026-05-19T23:40:18Z

Johnnyo: /* ZX Spectrum Next Documentation */

= ZX Spectrum Next Documentation =

The Next project is continuously improved, so it's a good practice to check for the most recent updates of the manuals, documents and Next-specific books.

== ZX Spectrum Next Manual ==

* Available online: [[FAQ#Where_can_I_download_a_copy_of_the_manual?]]

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder written and kept up to date by the author of NextZXOS and NextBASIC.

= Next-specific Books =

(The Next specific books are typically written under assumption that the reader is already familiar enough with the low-level hardware programming aspects relevant to the original ZX Spectrum, so the readers who aren't should also check the books about the "classic" ZX Spectrum too)

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or as a printed coil bound book.

== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
Many books were written since 1982, this is just a selection.
== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games (Since 2006, updated recently)
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm
== ''First Steps in Z80 Assembly Language'' (for ZX Spectrum) by Darryl Sloan (2020) ==
* The motivation for writing this book in 2020 was the release of the Sinclair ZX Spectrum Next, even if it (mostly?) covers the assembly which would work on the original ZX Spectrum: http://ped.7gods.org/z80.pdf
== ''Understanding Your Spectrum'' by Dr. Ian Logan (1982) ==
* https://spectrumcomputing.co.uk/entry/2000400/Book/Understanding_Your_Spectrum

Bibliography

2026-05-19T23:38:20Z

Johnnyo: /* ZX Spectrum Books and Documentation */

= ZX Spectrum Next Documentation =

== ZX Spectrum Next Manual ==

* Available online: [[FAQ#Where_can_I_download_a_copy_of_the_manual?]]

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder written and kept up to date by the author of NextZXOS and NextBASIC.

= Next-specific Books =

(The Next specific books are typically written under assumption that the reader is already familiar enough with the low-level hardware programming aspects relevant to the original ZX Spectrum, so the readers who aren't should also check the books about the "classic" ZX Spectrum too)

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or as a printed coil bound book.

== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
Many books were written since 1982, this is just a selection.
== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games (Since 2006, updated recently)
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm
== ''First Steps in Z80 Assembly Language'' (for ZX Spectrum) by Darryl Sloan (2020) ==
* The motivation for writing this book in 2020 was the release of the Sinclair ZX Spectrum Next, even if it (mostly?) covers the assembly which would work on the original ZX Spectrum: http://ped.7gods.org/z80.pdf
== ''Understanding Your Spectrum'' by Dr. Ian Logan (1982) ==
* https://spectrumcomputing.co.uk/entry/2000400/Book/Understanding_Your_Spectrum

Bibliography

2026-05-19T23:31:13Z

Johnnyo: /* First Steps in Z80 Assembly Language (for ZX Spectrum) by Darryl Sloan */

= ZX Spectrum Next Documentation =

== ZX Spectrum Next Manual ==

* Available online: [[FAQ#Where_can_I_download_a_copy_of_the_manual?]]

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder written and kept up to date by the author of NextZXOS and NextBASIC.

= Next-specific Books =

(The Next specific books are typically written under assumption that the reader is already familiar enough with the low-level hardware programming aspects relevant to the original ZX Spectrum, so the readers who aren't should also check the books about the "classic" ZX Spectrum too)

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or as a printed coil bound book.

== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm
== ''First Steps in Z80 Assembly Language'' (for ZX Spectrum) by Darryl Sloan ==
* Listed here as the motivation for writing this book in 2020 was the release of the Sinclair ZX Spectrum Next, even if it (mostly?) covers the assembly which would work on the original ZX Spectrum: http://ped.7gods.org/z80.pdf

Bibliography

2026-05-19T23:29:15Z

Johnnyo: /* Next-specific Books */

= ZX Spectrum Next Documentation =

== ZX Spectrum Next Manual ==

* Available online: [[FAQ#Where_can_I_download_a_copy_of_the_manual?]]

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder written and kept up to date by the author of NextZXOS and NextBASIC.

= Next-specific Books =

(The Next specific books are typically written under assumption that the reader is already familiar enough with the low-level hardware programming aspects relevant to the original ZX Spectrum, so the readers who aren't should also check the books about the "classic" ZX Spectrum too)

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or as a printed coil bound book.

== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm
== ''First Steps in Z80 Assembly Language'' (for ZX Spectrum) by Darryl Sloan ==
* http://ped.7gods.org/z80.pdf

Bibliography

2026-05-19T23:24:23Z

Johnnyo: /* ZX Spectrum Books and Documentation */

Bibliography

2026-05-19T20:32:41Z

Johnnyo: /* ZX Spectrum Next Assembly Developer Guide by Tomaž Kragelj */ "or as a"

Bibliography

2026-05-18T09:06:07Z

Johnnyo: /* docs Directory of the Distribution */

Compilers

2026-05-14T11:13:20Z

Johnnyo: /* ZX Basic Studio */ link to a text

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ Boriel Basic (ZX Basic)]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/boriel-basic/ZXBasicStudio/releases ZX Basic Studio]'' ===
: A multiplatform IDE for Boriel BASIC, with itegration with emulators for ZX Spectrum Next (CSpect, ZEsarUX and MAME), GDU and font editor, Sprite editor with import from external images, Colour palette editor for ZX Spectrum Next. Its [https://boriel-basic.net/page/preparing-the-development-environment installer] allows an easy start on Windows, Linux and MacOS.

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]
: The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]
: The selection of the CRT is by startup=n number. The crts are in the range 0-31, some mentioned in the above Hello World text, and some in the sources like [https://github.com/z88dk/z88dk/tree/master/libsrc/newlib/target/zxn/startup newlib zxn startup]. (internally: The factors of 256 are added by subtype=? on the compile line: base 0 numbers have no assumptions about the output type, i.e. for binaries that will be tap/nex/.. Base 256 is for dot commands, base 512 is for dotx command (not appropriate for the Next), base 768 is dotn).

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

Compilers

2026-05-14T11:12:07Z

Johnnyo: /* BASIC */ zx basic studio

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ Boriel Basic (ZX Basic)]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/boriel-basic/ZXBasicStudio/releases ZX Basic Studio]'' ===
: A multiplatform IDE for Boriel BASIC, with itegration with emulators for ZX Spectrum Next (CSpect, ZEsarUX and MAME), GDU and font editor, Sprite editor with import from external images, Colour palette editor for ZX Spectrum Next

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]
: The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]
: The selection of the CRT is by startup=n number. The crts are in the range 0-31, some mentioned in the above Hello World text, and some in the sources like [https://github.com/z88dk/z88dk/tree/master/libsrc/newlib/target/zxn/startup newlib zxn startup]. (internally: The factors of 256 are added by subtype=? on the compile line: base 0 numbers have no assumptions about the output type, i.e. for binaries that will be tap/nex/.. Base 256 is for dot commands, base 512 is for dotx command (not appropriate for the Next), base 768 is dotn).

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

Compilers

2026-05-14T11:08:35Z

Johnnyo: /* ZX Basic */ Boriel

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ Boriel Basic (ZX Basic)]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]
: The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]
: The selection of the CRT is by startup=n number. The crts are in the range 0-31, some mentioned in the above Hello World text, and some in the sources like [https://github.com/z88dk/z88dk/tree/master/libsrc/newlib/target/zxn/startup newlib zxn startup]. (internally: The factors of 256 are added by subtype=? on the compile line: base 0 numbers have no assumptions about the output type, i.e. for binaries that will be tap/nex/.. Base 256 is for dot commands, base 512 is for dotx command (not appropriate for the Next), base 768 is dotn).

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

Hw im2 mode

2026-05-12T19:25:38Z

Johnnyo: bit 0

hw im2 mode is enabled by the bit 0 of {{NextRegNo|$C0}}.

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 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:

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, 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 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.

Hw im2 mode

2026-05-12T19:24:20Z

Johnnyo: nextreg CC

hw im2 mode is enabled by the bit 0 of {{NextRegNo|$C0}}.

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 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:

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, 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 (see e.g. {{NextRegNo|$CC}}) AFAIK (says AA) that's not been done anywhere else.

Hw im2 mode

2026-05-12T19:22:23Z

Johnnyo: The background

hw im2 mode is enabled by the bit 0 of {{NextRegNo|$C0}}.

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 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:

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, 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.

Hw im2 mode

2026-05-12T18:28:20Z

Johnnyo: wording

Layer 2

2026-05-07T15:46:33Z

Johnnyo: half a byte

Layer 2 provides an additional screen layer at 256x192 256 colours, 320x256 256 colours or 640x256 16 colours in which every pixel is individually coloured. Layer 2 may appear in place of, behind, or above the ULA-generated/Tilemap layer.

The palette used to show the Layer 2 is selected by the bit 2 of the {{NextRegNo|$43}}.

The Layer 2 screen occupies 48kiB or 80kiB, which is stored in 3 (or 5) consecutive [[Memory map|banks]]. By NextZXOS/NextBASIC default, banks 9-11 are used for the visible and "shadow" Layer 2 screen (the HW after power-on defaults to 8-10 for displayed and 11-13 for shadow screen, but that gets modified by NextZXOS booting up). These can be set using {{NextRegNo|$12}} and {{NextRegNo|$13}} (avoid banks 5, 7 and 8 to be used as Layer 2 screen, unless you are familiar with SRAM and BRAM of the board and how the ULA screen memory has special treatment in Next's FPGA).

Each pixel of Layer 2 takes one byte of video memory in 8bpp modes or half a byte in 4bpp mode, so the Layer 2 needs 48kiB for 256x192 mode or 80kiB for 320x256-8bit or 640x256-4bit mode. The Layer 2 256x192 mode is divided '''horizontally''' into 3 16kiB banks of 64 '''lines''' each. The modes 320x256 and 640x256 are divided '''vertically''' into 5 16kiB banks of 64 '''columns''' each for 320x256 mode or 128 '''columns''' each for 640x256 mode.

Layer 2 is controlled via {{PortNo|$123B}} and {{NextRegNo|$70}}, the port is bit mapped as follows:

{| class="wikitable"
! Bit !! Description
|-
| 7-6 || Video RAM bank select (write/read paging)
|-
| 5-4 || Reserved, write 0
|-
| 3 || Use Shadow Layer 2 for paging - {{NextRegNo|$13}}
|-
| 2 || Enable Layer 2 read-only paging
|-
| 1 || Layer 2 visible - {{NextRegNo|$12}}
Since core 3.0 this bit has mirror in {{NextRegNo|$69}}
|-
| 0 || Enable Layer 2 write-only paging
|}

When bit 0 of $123B is set to 1, the appropriate area of Layer 2 video memory (as set by bits 6-7) is accessed by '''writes''' into slot 1, ie memory area $0000-$3fff (see [[Memory map]]). This prevents any conflict since this area would normally be ROM and thus useless to write to. However, you '''cannot READ the contents of Layer 2 via this mapping!''' Reading addresses in this range will read the values from the ROM page (or RAM bank if in AllRam mode) that would be mapped there normally if Layer 2 paging was disabled.

When bit 2 of $123B is set to 1 (new feature of core 3.0), the same area $0000-$3fff is remapped for read, allowing read access into Layer 2 bank selected by bits 3,6 and 7 (while write will still go into the regular ROM/RAM page).

With both bits 0 and 2 set you are creating alternative read+write mapping of RAM (technically identical to mapping done by MM0+MMU1 registers).

Bank 5 and first half of Bank 7, when being accessed by regular means (MMU paging, default memory mapping, DMA), are overshadowed by fast BRAM memory inside the FPGA chip, which is then used to generate ULA screen and [[Tilemap]] graphics (aka "Layer 3") - not using the SRAM memory chip in that particular area. This Layer 2 (mapping and visible data) is the only exception, circumventing this mechanism and accessing the Bank 5 and Bank 7 in the main memory SRAM chip (giving you extra 16+8kiB of "secret" memory and further headache to emulators' authors). If you are not sure what this means, just avoid using bank 5 and 7 for Layer 2, use values greater/equal to 8 (and avoid also Bank 8, unless you want to destroy NextBASIC warm-restart/soft-reset variables).

Bits 6 and 7 contain the number which third of Layer 2 should be mapped (0..2), or (new feature of core 3.0) when value 3 is set, whole 48kiB of Layer 2 is mapped into area $0000-$bfff (make sure your code, stack and interrupts will cope well with such new mapping).

There is one more new functionality in latest 3.x cores, allowing to set bank-offset variable from 0 to 7. This offset is further applied to the bank selected for write/read (by writing value 0..7 to the port with bit4 set (so it's value 16..23). If you did set for example 16kiB write mapping of first bank, the first bank is 9, and use value 21 for bank-offset setup (+5 offset), the bank mapped into $0000..$3FFF address area will be 14 (9+5). This way you can map full 80kiB of pixel data into the bottom 16kiB window (or bottom 48kiB window), using different offsets.

Use {{NextRegNo|$70}} to select particular Layer2 mode, and to modify palette offset (added to top four bits of each pixel). Don't forget to set up Layer 2 clip window correctly for each mode ({{NextRegNo|$18}}).

You can still use also the regular [[Memory map|banking]] ports to switch in one of the Layer 2 banks in slot for at $C000 (or use the ZX Next MMU registers to map that RAM in other regions). This will allow you to read and write the memory as usual. The ability to write to Layer 2 via writes into slot 1 is provided for convenience and to allow graphics data to be easily copied from extended RAM banks.

Pixels are drawn to Layer 2 by writing to the appropriate area of RAM. Layer 2 pixels in 256x192 mode are in English reading order with no ULA-style interlacing. Since there are 256 pixels per line, and when using access via slot 1 the memory port starts at $0000, the upper byte of the address exactly equals the Y coordinate (within the selected third of the screen) and the lower byte exactly equals the X coordinate.

In mode 320x256 (8bpp) the pixels are stored in memory going from top to bottom and left to right (second byte is first pixel on second line, 256th byte is second pixel on first line). Since there are 256 pixels per column, the upper byte of address could represent the X coordinate (only specific range of them, as whole 0..319 range does not fit into 8 bits), and the lower byte of address is Y coordinate. The total pixel memory is 80kiB (five 16kiB banks), and could be mapped into memory either by MMU or by bank-offset feature of {{PortNo|$123B}}.

In mode 640x256 (4bpp) the pixels are stored identically to 320x256 mode, but every byte contains two pixels. The top nibble (top four bits) form "left" pixel, and the bottom nibble form "right" pixel, so first 256 bytes will display as two columns on screen, not one.

Note that you will need to manually clear the Layer 2 screen before drawing on it, as it may contain random data when the machine starts up.

System registers {{NextRegNo|$16}}, {{NextRegNo|$71}} and {{NextRegNo|$17}} apply a pixel shift to all content in Layer
2, allowing scrolling effects to be created.

Since core 3.0 the visibility of Layer 2 is not affected by usage of ZX128 ULA-shadow (Bank 7) screen.

Obsolete info for core 2.x (limitation was lifted in core 3.0): <del>the visible Layer 2 will cause the slow down of CPU to 7MHz.</del>

To use double-buffered scheme for Layer 2, think about {{NextRegNo|$12}} being display related (i.e. has to be changed to display new Layer 2, when the new image is already prepared) (or it may be modified also during frame to compose final image from various memory areas), while {{NextRegNo|$13}} is related only to write-over-ROM paging functionality ({{PortNo|$123B}}).

Layer 2

2026-05-06T13:38:24Z

Johnnyo: rewording

Layer 2 provides an additional screen layer at 256x192 256 colours, 320x256 256 colours or 640x256 16 colours in which every pixel is individually coloured. Layer 2 may appear in place of, behind, or above the ULA-generated/Tilemap layer.

The palette used to show the Layer 2 is selected by the bit 2 of the {{NextRegNo|$43}}.

The Layer 2 screen occupies 48kiB or 80kiB, which is stored in 3 (or 5) consecutive [[Memory map|banks]]. By NextZXOS/NextBASIC default, banks 9-11 are used for the visible and "shadow" Layer 2 screen (the HW after power-on defaults to 8-10 for displayed and 11-13 for shadow screen, but that gets modified by NextZXOS booting up). These can be set using {{NextRegNo|$12}} and {{NextRegNo|$13}} (avoid banks 5, 7 and 8 to be used as Layer 2 screen, unless you are familiar with SRAM and BRAM of the board and how the ULA screen memory has special treatment in Next's FPGA).

Each pixel of Layer 2 takes one byte of video memory in 8bpp modes or a half byte in 4bpp mode, so the Layer 2 needs 48kiB for 256x192 mode or 80kiB for 320x256-8bit or 640x256-4bit mode. The Layer 2 256x192 mode is divided '''horizontally''' into 3 16kiB banks of 64 '''lines''' each. The modes 320x256 and 640x256 are divided '''vertically''' into 5 16kiB banks of 64 '''columns''' each for 320x256 mode or 128 '''columns''' each for 640x256 mode.

Layer 2 is controlled via {{PortNo|$123B}} and {{NextRegNo|$70}}, the port is bit mapped as follows:

{| class="wikitable"
! Bit !! Description
|-
| 7-6 || Video RAM bank select (write/read paging)
|-
| 5-4 || Reserved, write 0
|-
| 3 || Use Shadow Layer 2 for paging - {{NextRegNo|$13}}
|-
| 2 || Enable Layer 2 read-only paging
|-
| 1 || Layer 2 visible - {{NextRegNo|$12}}
Since core 3.0 this bit has mirror in {{NextRegNo|$69}}
|-
| 0 || Enable Layer 2 write-only paging
|}

When bit 0 of $123B is set to 1, the appropriate area of Layer 2 video memory (as set by bits 6-7) is accessed by '''writes''' into slot 1, ie memory area $0000-$3fff (see [[Memory map]]). This prevents any conflict since this area would normally be ROM and thus useless to write to. However, you '''cannot READ the contents of Layer 2 via this mapping!''' Reading addresses in this range will read the values from the ROM page (or RAM bank if in AllRam mode) that would be mapped there normally if Layer 2 paging was disabled.

When bit 2 of $123B is set to 1 (new feature of core 3.0), the same area $0000-$3fff is remapped for read, allowing read access into Layer 2 bank selected by bits 3,6 and 7 (while write will still go into the regular ROM/RAM page).

With both bits 0 and 2 set you are creating alternative read+write mapping of RAM (technically identical to mapping done by MM0+MMU1 registers).

Bank 5 and first half of Bank 7, when being accessed by regular means (MMU paging, default memory mapping, DMA), are overshadowed by fast BRAM memory inside the FPGA chip, which is then used to generate ULA screen and [[Tilemap]] graphics (aka "Layer 3") - not using the SRAM memory chip in that particular area. This Layer 2 (mapping and visible data) is the only exception, circumventing this mechanism and accessing the Bank 5 and Bank 7 in the main memory SRAM chip (giving you extra 16+8kiB of "secret" memory and further headache to emulators' authors). If you are not sure what this means, just avoid using bank 5 and 7 for Layer 2, use values greater/equal to 8 (and avoid also Bank 8, unless you want to destroy NextBASIC warm-restart/soft-reset variables).

Bits 6 and 7 contain the number which third of Layer 2 should be mapped (0..2), or (new feature of core 3.0) when value 3 is set, whole 48kiB of Layer 2 is mapped into area $0000-$bfff (make sure your code, stack and interrupts will cope well with such new mapping).

There is one more new functionality in latest 3.x cores, allowing to set bank-offset variable from 0 to 7. This offset is further applied to the bank selected for write/read (by writing value 0..7 to the port with bit4 set (so it's value 16..23). If you did set for example 16kiB write mapping of first bank, the first bank is 9, and use value 21 for bank-offset setup (+5 offset), the bank mapped into $0000..$3FFF address area will be 14 (9+5). This way you can map full 80kiB of pixel data into the bottom 16kiB window (or bottom 48kiB window), using different offsets.

Use {{NextRegNo|$70}} to select particular Layer2 mode, and to modify palette offset (added to top four bits of each pixel). Don't forget to set up Layer 2 clip window correctly for each mode ({{NextRegNo|$18}}).

You can still use also the regular [[Memory map|banking]] ports to switch in one of the Layer 2 banks in slot for at $C000 (or use the ZX Next MMU registers to map that RAM in other regions). This will allow you to read and write the memory as usual. The ability to write to Layer 2 via writes into slot 1 is provided for convenience and to allow graphics data to be easily copied from extended RAM banks.

Pixels are drawn to Layer 2 by writing to the appropriate area of RAM. Layer 2 pixels in 256x192 mode are in English reading order with no ULA-style interlacing. Since there are 256 pixels per line, and when using access via slot 1 the memory port starts at $0000, the upper byte of the address exactly equals the Y coordinate (within the selected third of the screen) and the lower byte exactly equals the X coordinate.

In mode 320x256 (8bpp) the pixels are stored in memory going from top to bottom and left to right (second byte is first pixel on second line, 256th byte is second pixel on first line). Since there are 256 pixels per column, the upper byte of address could represent the X coordinate (only specific range of them, as whole 0..319 range does not fit into 8 bits), and the lower byte of address is Y coordinate. The total pixel memory is 80kiB (five 16kiB banks), and could be mapped into memory either by MMU or by bank-offset feature of {{PortNo|$123B}}.

In mode 640x256 (4bpp) the pixels are stored identically to 320x256 mode, but every byte contains two pixels. The top nibble (top four bits) form "left" pixel, and the bottom nibble form "right" pixel, so first 256 bytes will display as two columns on screen, not one.

Note that you will need to manually clear the Layer 2 screen before drawing on it, as it may contain random data when the machine starts up.

System registers {{NextRegNo|$16}}, {{NextRegNo|$71}} and {{NextRegNo|$17}} apply a pixel shift to all content in Layer
2, allowing scrolling effects to be created.

Since core 3.0 the visibility of Layer 2 is not affected by usage of ZX128 ULA-shadow (Bank 7) screen.

Obsolete info for core 2.x (limitation was lifted in core 3.0): <del>the visible Layer 2 will cause the slow down of CPU to 7MHz.</del>

To use double-buffered scheme for Layer 2, think about {{NextRegNo|$12}} being display related (i.e. has to be changed to display new Layer 2, when the new image is already prepared) (or it may be modified also during frame to compose final image from various memory areas), while {{NextRegNo|$13}} is related only to write-over-ROM paging functionality ({{PortNo|$123B}}).

Assemblers

2026-05-05T08:03:44Z

Johnnyo: /* Native tools (running on Next) */ specasm

Any Z80 assembler can produce code suitable for the Next. However the raw blocks of Z80 code may be not as convenient to use with Next or emulators, so a Next specific tools may be useful for creating one of the supported [[File Formats]].

== Cross-platform tools (running on PC) ==

=== ''[http://www.desdes.com/products/oldfiles/zeus.htm Zeus-ish]'' ===
: Provides a complete Z80 IDE and Macro assembler, scripted disassember plus an integrated Z80 emulator for a range of machines including partial Next support
: Supports the Next opcodes directly
: Supports remote debugging on the Next using ParaSys across a serial link
: Supports MMU paging in the integrated emulator
: Supports sprites (core versions prior to 2.00.26) in the integrated emulator

=== ''[http://pasmo.speccy.org/ Pasmo]'' ===
: A long established Z80 assembler, but has been mostly out of development for a long time (0.5.4-beta2 released in 2008, 0.5.5 in 2022)
: Supports all currently known Next extension opcodes in the 0.5.4-beta2-based 2018 version of [https://github.com/spec-chum/pasmo Pasmo modified by Russ McNulty and Tony Thompson] (also producing .sna files which were at that time used by CSpect).

=== ''SNasm'' ===
: Included with the [https://mdf200.itch.io/cspect #CSpect] emulator
: Full macro assembler
: Full bank control via Segment management
: Supports the Next extension opcodes directly
: Generates full 24bit map files for use in CSpect

=== ''z80asm'' ===
: Part of [https://github.com/z88dk/z88dk Z88dk]''
: Supports the Next extension opcodes directly, linking assembler with large z80 library, targets any memory configuration

=== ''[https://github.com/z00m128/sjasmplus z00m's fork of sjasmplus]'' ===
: Supports all (core2.00.28) Next extension opcodes, ZXN memory model (8 memory slots with 8ki pages and 1.75MiB virtual device memory), SAVENEX to build NEX files directly from ASM source (NEX version V1.2 (and experimental extension "V1.3")), MAP files for [https://mdf200.itch.io/cspect #CSpect] emulator, SLD tracing files for [https://github.com/maziac/DeZog DeZog] and [https://github.com/Ckirby101/NDS-NextDevSystem NDS-NextDevSystem] and it is under active development (feedback is welcome).
: Open source project ("BSD-3-Clause" license), '''windows executables available at [https://github.com/z00m128/sjasmplus/releases/latest releases]''', mac and linux users are expected to simply build from source (both make and CMake are supported).
: [http://z00m128.github.io/sjasmplus/documentation.html Documentation], latest stable release v1.23.0 2026-04-23

=== ''zmac'' ===

: [http://48k.ca/zmac.html zmac - Z-80 Macro Cross Assembler]

=== ''[https://github.com/CatpainBlack/FantASM FantASM]'' ===
: FantASM is a two pass non optimising assembler for the Z80 processor by [https://github.com/CatpainBlack Guy 'CatpainBlack' Black].

:It supports all undocumented op-codes and the extended instruction set of the ZX Next and additional pseudo opcodes used by the CSpect emulator to control debugging.

== Native tools (running on Next) ==

=== ''[https://gitlab.com/next-tools/odin Odin]'' ===

Work-in-progress Next-specific assembler written by Matt Davies, used also in video tutorials presented by Jim Bagley, the best way to acquire the binary is to join the official ZX Next discord server and check channel <code>#odin</code> - pinned messages, where you can also discuss any issues and get how-to hints.

: supports most of the undocumented opcodes, all official Z80 and Next-extended instructions
: supports nested includes and binary includes
: source is stored in tokenised form (smaller file), up to 48kiB of source in single file
: assembling can produce 32kiB of machine code (enough to produce simpler dot command)
: includes also editor and console modules (debugger is planned)

=== ''[https://www.solarisite.com/spectrumnext.html Sol]'' ===

Sol is an assembler and editor written by Solaris, that runs natively on the Next. Manual, assembler binary and assembler source can be downloaded [https://www.solarisite.com/spectrumnext.html here].

=== ''[https://gitlab.com/thesmog358/tbblue/-/tree/master/tools/dev/Zeus ZEUS]'' ===

Classic ZEUS native assembler by Simon Brattel, extended and included directly in the ZX Next distro.

=== ''[https://gitlab.com/thesmog358/tbblue/-/tree/master/tools/dev/SPED SPED]'' ===

Classic SPED assembler by César Hernández Bañó, included directly in the ZX Next distro, see [https://gitlab.com/thesmog358/tbblue/-/raw/master/docs/apps/dev/SPED53readme.txt README].

=== ''[https://github.com/markdryan/specasm specasm]'' ===

Mark Ryan's specasm assembler suite which includes an editor, an assembler, a linker and a tap file generator.
.specasm command launches an integrated editor/assembler.
Supports all the Z80n instructions. All mnemonics are entered in lower case. The edited files are .x files, which are annotated object files, with the instructions pre-assembled.

=== ''[https://taylorza.itch.io/nextbasic-inline-assembler NextBASIC Inline Assembler]''===
Enables you to write inline assembly code in your NextBASIC application. The assembler can be downloaded from [https://taylorza.itch.io/nextbasic-inline-assembler HERE] with documentation available [https://github.com/taylorza/zxn-inlineasm-doc/blob/main/README.md HERE]

Layer 2

2026-05-04T13:40:39Z

Johnnyo: palette detail

Layer 2 provides an additional screen layer at 256x192 256 colours, 320x256 256 colours or 640x256 16 colours in which every pixel is individually coloured. Layer 2 may appear in place of, behind, or above the ULA-generated/Tilemap layer.

The palette used to show the Layer 2 is selected by the bit 2 of the {{NextRegNo|$43}}.

The Layer 2 screen occupies 48kiB or 80kiB, which is stored in 3 (or 5) consecutive [[Memory map|banks]]. By NextZXOS/NextBASIC default, banks 9-11 are used for the visible and "shadow" Layer 2 screen (the HW after power-on defaults to 8-10 for displayed and 11-13 for shadow screen, but that gets modified by NextZXOS booting up). These can be set using {{NextRegNo|$12}} and {{NextRegNo|$13}} (avoid banks 5, 7 and 8 to be used as Layer 2 screen, unless you are familiar with SRAM and BRAM of the board and how the ULA screen memory has special treatment in Next's FPGA).

Each pixel of Layer 2 is assigned 1 byte of video memory (in 8bpp modes). This means Layer 2 consumes a total of 48kiB (256x192) or 80kiB (320x256). Since the Spectrum banks are 16kiB, Layer 2 256x192 mode is divided horizontally into 3 banks of 64 lines each, each of which is exactly 16kiB. The mode 320x256 (and 640x256) is divided vertically into 5 banks of 64 (128) columns each.

Layer 2 is controlled via {{PortNo|$123B}} and {{NextRegNo|$70}}, the port is bit mapped as follows:

{| class="wikitable"
! Bit !! Description
|-
| 7-6 || Video RAM bank select (write/read paging)
|-
| 5-4 || Reserved, write 0
|-
| 3 || Use Shadow Layer 2 for paging - {{NextRegNo|$13}}
|-
| 2 || Enable Layer 2 read-only paging
|-
| 1 || Layer 2 visible - {{NextRegNo|$12}}
Since core 3.0 this bit has mirror in {{NextRegNo|$69}}
|-
| 0 || Enable Layer 2 write-only paging
|}

When bit 0 of $123B is set to 1, the appropriate area of Layer 2 video memory (as set by bits 6-7) is accessed by '''writes''' into slot 1, ie memory area $0000-$3fff (see [[Memory map]]). This prevents any conflict since this area would normally be ROM and thus useless to write to. However, you '''cannot READ the contents of Layer 2 via this mapping!''' Reading addresses in this range will read the values from the ROM page (or RAM bank if in AllRam mode) that would be mapped there normally if Layer 2 paging was disabled.

When bit 2 of $123B is set to 1 (new feature of core 3.0), the same area $0000-$3fff is remapped for read, allowing read access into Layer 2 bank selected by bits 3,6 and 7 (while write will still go into the regular ROM/RAM page).

With both bits 0 and 2 set you are creating alternative read+write mapping of RAM (technically identical to mapping done by MM0+MMU1 registers).

Bank 5 and first half of Bank 7, when being accessed by regular means (MMU paging, default memory mapping, DMA), are overshadowed by fast BRAM memory inside the FPGA chip, which is then used to generate ULA screen and [[Tilemap]] graphics (aka "Layer 3") - not using the SRAM memory chip in that particular area. This Layer 2 (mapping and visible data) is the only exception, circumventing this mechanism and accessing the Bank 5 and Bank 7 in the main memory SRAM chip (giving you extra 16+8kiB of "secret" memory and further headache to emulators' authors). If you are not sure what this means, just avoid using bank 5 and 7 for Layer 2, use values greater/equal to 8 (and avoid also Bank 8, unless you want to destroy NextBASIC warm-restart/soft-reset variables).

Bits 6 and 7 contain the number which third of Layer 2 should be mapped (0..2), or (new feature of core 3.0) when value 3 is set, whole 48kiB of Layer 2 is mapped into area $0000-$bfff (make sure your code, stack and interrupts will cope well with such new mapping).

There is one more new functionality in latest 3.x cores, allowing to set bank-offset variable from 0 to 7. This offset is further applied to the bank selected for write/read (by writing value 0..7 to the port with bit4 set (so it's value 16..23). If you did set for example 16kiB write mapping of first bank, the first bank is 9, and use value 21 for bank-offset setup (+5 offset), the bank mapped into $0000..$3FFF address area will be 14 (9+5). This way you can map full 80kiB of pixel data into the bottom 16kiB window (or bottom 48kiB window), using different offsets.

Use {{NextRegNo|$70}} to select particular Layer2 mode, and to modify palette offset (added to top four bits of each pixel). Don't forget to set up Layer 2 clip window correctly for each mode ({{NextRegNo|$18}}).

You can still use also the regular [[Memory map|banking]] ports to switch in one of the Layer 2 banks in slot for at $C000 (or use the ZX Next MMU registers to map that RAM in other regions). This will allow you to read and write the memory as usual. The ability to write to Layer 2 via writes into slot 1 is provided for convenience and to allow graphics data to be easily copied from extended RAM banks.

Pixels are drawn to Layer 2 by writing to the appropriate area of RAM. Layer 2 pixels in 256x192 mode are in English reading order with no ULA-style interlacing. Since there are 256 pixels per line, and when using access via slot 1 the memory port starts at $0000, the upper byte of the address exactly equals the Y coordinate (within the selected third of the screen) and the lower byte exactly equals the X coordinate.

In mode 320x256 (8bpp) the pixels are stored in memory going from top to bottom and left to right (second byte is first pixel on second line, 256th byte is second pixel on first line). Since there are 256 pixels per column, the upper byte of address could represent the X coordinate (only specific range of them, as whole 0..319 range does not fit into 8 bits), and the lower byte of address is Y coordinate. The total pixel memory is 80kiB (five 16kiB banks), and could be mapped into memory either by MMU or by bank-offset feature of {{PortNo|$123B}}.

In mode 640x256 (4bpp) the pixels are stored identically to 320x256 mode, but every byte contains two pixels. The top nibble (top four bits) form "left" pixel, and the bottom nibble form "right" pixel, so first 256 bytes will display as two columns on screen, not one.

Note that you will need to manually clear the Layer 2 screen before drawing on it, as it may contain random data when the machine starts up.

System registers {{NextRegNo|$16}}, {{NextRegNo|$71}} and {{NextRegNo|$17}} apply a pixel shift to all content in Layer
2, allowing scrolling effects to be created.

Since core 3.0 the visibility of Layer 2 is not affected by usage of ZX128 ULA-shadow (Bank 7) screen.

Obsolete info for core 2.x (limitation was lifted in core 3.0): <del>the visible Layer 2 will cause the slow down of CPU to 7MHz.</del>

To use double-buffered scheme for Layer 2, think about {{NextRegNo|$12}} being display related (i.e. has to be changed to display new Layer 2, when the new image is already prepared) (or it may be modified also during frame to compose final image from various memory areas), while {{NextRegNo|$13}} is related only to write-over-ROM paging functionality ({{PortNo|$123B}}).

ZENext:Installing

2026-05-02T16:15:16Z

Johnnyo: /* Run */

= Installation =

The simplest procedure is building it for Linux:

<pre>
sudo apt install libsdl1.2-dev xorg-dev
./configure
make clean
make
</pre>

As of March 2026: it's possible to build it for other platforms, even a cross build on Linux for Windows 64, but additional work is then needed, among others, a modification of the configure script and a few source files and a suitable building of the SDL 1.

= Run =

To run, the following command line worked with the SD image containing NextZXOS 2.09.:

<pre>
./zesarux --noconfigfile --nosplash --quickexit --def-f-function f4 reset \
--disablerealjoystick --no-native-linux-realjoy \
--joystickemulated kempston \
--frameskip 1 \
--zoom 1 \
--enable-divmmc-ports --enable-mmc \
--mmc-file FULL_PATH_TO_SD_IMAGE
</pre>

Read how to download or create the SD card image on the: [[MAME:Installing#Creating_and_manipulating_NextZXOS_SD_card_image]] page

Notes: The upstream zesarux can't use big images because it loads them into RAM - but zenext doesn't do/suffer that. zenext does non-exclusive file locking, so you can mount from OS and emulator at same time (also note: using such mounting increases chances for accidental corruption of the image or inconsistent views).

ZENext:Installing

2026-05-02T16:15:04Z

Johnnyo: /* Run */

= Installation =

The simplest procedure is building it for Linux:

<pre>
sudo apt install libsdl1.2-dev xorg-dev
./configure
make clean
make
</pre>

As of March 2026: it's possible to build it for other platforms, even a cross build on Linux for Windows 64, but additional work is then needed, among others, a modification of the configure script and a few source files and a suitable building of the SDL 1.

= Run =

To run, the following command line worked with the SD image containing NextZXOS 2.09.:

<pre>
./zesarux --noconfigfile --nosplash --quickexit --def-f-function f4 reset \
--disablerealjoystick --no-native-linux-realjoy \
--joystickemulated kempston \
--frameskip 1 \
--zoom 1 \
--enable-divmmc-ports --enable-mmc \
--mmc-file FULL_PATH_TO_SD_IMAGE
</pre>

Read how to download or create the SD card image on the: [[MAME:Installing#Creating_and_manipulating_NextZXOS_SD_card_image]] page

Notes: The upstream zesarux can't use big images because it loads them into RAM - but zenext doesn't do/suffer that. zenext does non-exclusive file locking, so you can mount from OS and emulator at same time (alsonote: using such mounting increases chances for accidental corruption of the image or inconsistent views).

Bibliography

2026-04-29T15:43:05Z

Johnnyo: /* ZX Spectrum Next Manual */

Bibliography

2026-04-29T15:41:24Z

Johnnyo:

= ZX Spectrum Next Documentation =

== ZX Spectrum Next Manual ==

Online: [[FAQ#Where_can_I_download_a_copy_of_the_manual?]]

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder.

= Next-specific Books =

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or a printed coil bound book.
== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm

Bibliography

2026-04-28T11:27:25Z

Johnnyo:

= ZX Spectrum Next Documentation =

== ''docs'' Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder.

= Next-specific Books =

== ''ZX Spectrum Next Assembly Developer Guide'' by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or a printed coil bound book.
== ''ZX Spectrum Next Programming Notes'' by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
== ''How to Write Spectrum Games'' by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games
== ''comp.sys.sinclair FAQ'' ==
* https://worldofspectrum.org/faq/reference/reference.htm

Bibliography

2026-04-28T11:25:22Z

Johnnyo: added link to the repo docs

= ZX Spectrum Next Documentation =

== docs Directory of the Distribution ==
* https://gitlab.com/thesmog358/tbblue/-/tree/master/docs , especially note the [https://gitlab.com/thesmog358/tbblue/-/tree/master/docs/nextzxos nextzxos] folder.

= Next-specific Books =

== ZX Spectrum Next Assembly Developer Guide by Tomaž Kragelj ==
* Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or a printed coil bound book.
== ZX Spectrum Next Programming Notes by Theodore (Alex) Evans ==
* https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum Books and Documentation =
== How to Write Spectrum Games by Jonathan Cauldwell ==
* https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games
== comp.sys.sinclair FAQ ==
* https://worldofspectrum.org/faq/reference/reference.htm

Bibliography

2026-04-28T11:20:27Z

Johnnyo: creating page

= Next-specific =

== ZX Spectrum Next Assembly Developer Guide by Tomaž Kragelj ==
** Available as a free to download PDF https://github.com/tomaz/zx-next-dev-guide/ or a printed coil bound book.
== ZX Spectrum Next Programming Notes by Theodore (Alex) Evans ==
** https://github.com/varmfskii/zxnext_code/tree/master/zx_next_notes

= ZX Spectrum =
== How to Write Spectrum Games by Jonathan Cauldwell ==
** https://jonathan-cauldwell.itch.io/how-to-write-spectrum-games
== comp.sys.sinclair FAQ ==
** https://worldofspectrum.org/faq/reference/reference.htm

MAME:Installing

2026-04-23T09:36:46Z

Johnnyo: /* Continuous Integration MAME Builds */ an attempt for the better text "flow"

[https://www.mamedev.org/ MAME] (formerly an acronym of Multiple Arcade Machine Emulator) is a free and open-source emulator designed to emulate the hardware of arcade games, later expanded to include video game consoles, old computers and other systems in software on modern personal computers and other platforms.

MAME has supported the ZX Spectrum Next since version 0.267. The existing implementation is based on the v3.02.01 core and implements most of the features.

= Installation =

You will need to install MAME, provide it with the Next firmware ('ROM'), and get the NextZXOS image:

=== 1. Get MAME ===
Start with these official MAME releases. If you encounter crashes or other bugs, try replacing the MAME executable with holub's latest Continuous Integration (CI) builds as described at the end of this article.

* '''Windows:''' Download [https://www.mamedev.org/release.html MAME for Windows].
* '''macOS:''' Download [https://sdlmame.lngn.net/ MAME for macOS].
* '''Linux:''' Install MAME from the flatpak repositories by running:
<pre>sudo flatpak install org.mamedev.MAME</pre>

Note that Windows and macOS will likely prevent you from launching MAME directly for security reasons. See below on how to solve this.

Alternatively, for the MAME platform as a whole, you can also check your package manager, or [https://docs.mamedev.org/initialsetup/compilingmame.html build from sources].

Git of official MAME: [https://github.com/mamedev/mame/ https://github.com/mamedev/mame/] [https://github.com/mamedev/mame/blob/master/src/mame/sinclair/next/specnext.cpp specnext.cpp]

Git of holub's fork: [https://github.com/holub/mame https://github.com/holub/mame] [https://github.com/holub/mame/blob/master/src/mame/sinclair/next/specnext.cpp specnext.cpp] (may contain extra fixes and features before they are merged to official repository)

=== 2. Get TBBLUE (the Next 'boot ROM') ===
Put the file [https://github.com/Threetwosevensixseven/NexCreator/raw/master/bootroms/tbblue.zip tbblue.zip] into MAME's <code>roms</code> folder. Don't extract it; MAME will look for the zip file when the "tbblue" machine is selected.

Note: The ROMs in this zip are what is embedded inside the FPGA core on real Next hardware. They're different from any ZX Spectrum machine ROMs you may be used to using, that are on the distro, SD card or SD image file.

=== 3. Get the NextZXOS Image ===
Get an SD card image file of [https://www.specnext.com/latestdistro/ NextZXOS]. Note that '''some disk images published on the official SpecNext.com site do not work with some emulators currently''' (the <code>latestdistro</code> link points to the official location where the latest distribution can be found), but '''all images from <code>https://zxnext.uk/hosted/</code> work with both MAME and CSpect''', like [https://zxnext.uk/hosted/index_files/hdfimages/cspect-next-2gb.zip this SD card image in the zip archive]. Extract the image <code>cspect-next-2gb.img</code> from the archive to use it, then point MAME to this SD card image with the <code>-hard1</code> option (or select that file from the menu inside MAME).

= Usage =
MAME looks for its configuration and helper files in specific (configurable) folders. By default, these are relative to the current working directory (cwd), i.e., from where you launched the executable. The <code>mame.ini</code> file and folders like <code>roms, bgfx, plugins, language, ...</code> are expected there, unless the <code>mame.ini</code> file specifies other paths. When launching through a desktop icon or menu, depending on the OS, the working directory is often defined by the properties of that launch shortcut. When launching MAME from the command line, the current directory is "cwd" (doh). On Linux, MAME will look for <code>mame.ini</code> first in the <code>~/.mame</code> folder. You can use the option <code>-inipath</code> to point MAME to a different path for the <code>mame.ini</code> file.

However, the fastest way to run a machine with a desired configuration is from the command prompt, without requiring a <code>mame.ini</code> file. Most of the features are also available through MAME's UI, although that takes more time to configure.

As an example, this invocation enables the UI, uses "crisp pixels", starts in a window, doesn't display the starting gameinfo window (it can still be displayed interactively from the UI), disables the mouse, confirms before exiting MAME, and specifies the disk image (remember to adjust the path to it):

<pre>mame -ui_active -nounevenstretch -aspect 2:1 -video bgfx -bgfx_screen_chains unfiltered -window -skip_gameinfo -mouse_device none -confirm_quit tbblue -hard1 /path/to/cspect-next-2gb.img</pre>

Let's cover some useful options:

<ol start="1">

<li>
Run inside a window and with no mouse support, until you get familiar with the UI keys:
<pre>> mame tbblue -window -mouse_device none -hard1 /path/to/next-distribution.img</pre>
To launch the Linux flatpak version using the same options:
<pre>> flatpak run org.mamedev.MAME tbblue -window -mouse_device none -hard1 /path/to/next-distribution.img</pre>
</li>

<li>
Activate UI keys on startup:
<pre>> ... -ui_active</pre>
</li>

<li>
Don't show the info popup on startup:
<pre>> ... -skip_gameinfo</pre>
</li>

<li>Run with debugger. If you don't request this on startup, you won't have access to it:
<pre>> ... -debug</pre>
</li>

<li>Use "crisp" pixels:
<pre>> ... -nounevenstretch -aspect 2:1 -video bgfx -bgfx_screen_chains unfiltered</pre>
</li>

<li>No joystick connected to PC (having this may slightly speed up MAME's startup, but ''remember to remove this part from the command line and the corresponding setting in the ini file if you do want to use a joystick''):
<pre>> ... -joystickprovider none</pre>
</li>

<li>Ask for confirmation when exiting MAME (otherwise it's easy to exit MAME accidentally by hitting ESC, especially when playing games or navigating menus):
<pre>> ... -confirm_quit</pre>
</ol>

Check the [https://docs.mamedev.org/commandline/commandline-all.html#mame-commandline-universal official MAME documentation] for more advanced usage.

= Security: Allowing MAME to Run on Windows and macOS =

'''On Windows,''' you will need to confirm that you want to launch MAME by clicking "Run Anyway" on first launch. ''(More details needed here.)''

'''On macOS,''' MAME will not open at first. Instead, a dialog will appear saying:

''“mame” Not Opened. Apple could not verify “mame” is free of malware that may harm your Mac or compromise your privacy.''

Click “Done”. Then open '''System Settings -> Privacy & Security''', and scroll down to the message ''mame was blocked to protect your Mac.'' Click “Allow Anyway”.

Now launch MAME again. A dialog will ask once more if you want to open “mame”. Click “Open Anyway”, and enter your password or use Touch ID when prompted by macOS.

From now on, you can launch this version of MAME without warnings. However, you '''will''' need to repeat this each time you update MAME.

= Keys =

Keys are emulated in two modes: either to control the MAME emulator or completely dedicated to the emulated system (the Next). You can toggle between these two keyboard modes with ScrLk (on Win and Linux) or fn+delete (on Mac).

Some UI keys:
* F3 - soft reset
* Shift+F3 - hard reset
* F4 - sprites/tiles/font viewer (Enter, ], [)
* F5 - pause emulation
* F6 - save state
* F7 - load state
* Tab - emulator settings
* ~ - menu
* ` (backtick) - debugger (when enabled by starting MAME with <code>-debug</code> or <code>-d</code> on the command line)
* PgDwn (Linux/Mac), fn-Downarrow (MacBooks) or Insert (Win) - hold down to fast-forward emulation at maximum speed, e.g., to speed up booting the Next
* Esc - exit (exits menus but also the entire emulator - see <code>-confirm_quit</code> option above)
* F11 - DivMMC NMI
* F12 - Multiface NMI

Check [https://docs.mamedev.org/usingmame/defaultkeys.html default keys documentation] for more.

= Changing the UI toggle key =

Some laptops don't have a Scroll Lock key, so you may not be able to exit MAME if you run it in full-screen mode. In these cases, you can change the UI toggle key as follows:

* Run MAME without any command line arguments (except maybe -window) to open its GUI.
* Push TAB and enter the General Settings menu.
* Go to Input Assignments -> User Interface -> Toggle UI controls and select a new key. I use Right Alt / Alt GR.
* Return to the previous menu twice, then choose Save Settings

= Creating and manipulating NextZXOS SD card image =

Most users wanting to emulate the Next using MAME will be fine using a pre-built SD card image downloaded from the site hosting best pre-made images (currently, [https://zxnext.uk/hosted zxnext.uk/hosted] ) website. The following guide is provided for anyone wanting to create a NextZXOS SD card image from scratch.

Download the [https://www.specnext.com/latestdistro/ latest NextZXOS distribution zip file] (named something like sn-complete-WX.YZ.zip) and extract it into a new, empty directory.

== Creating and populating a SD card image using hdfmonkey jjjs build ==

The [https://www.specnext.com/forum/viewtopic.php?t=2604 hdfmonkey "jjjs build"] is a variant of hdfmonkey tool which includes some unique features and its main archive (at the previously given link) also contains pre-built binaries for Windows x64, MacOS x64, MacOS Apple Silicon and Linux x64. (Alternatively, the process to build a local Linux version of the executable is described [[Development_Tools:Linux_setup#hdfmonkey_tool | here]] )

If you extracted sn-complete-WX.YZ.zip into a subdirectory named <code>snWXYZ</code>, and you want to create a 1GB image called <code>NextZXOS.img</code> and you have a jjjs build" of hdfmonkey, then it's enough to do:

<pre>
hdfmonkey create NextZXOS.img 1G
hdfmonkey putdir NextZXOS.img snWXYZ /
</pre>

The first line creates an empty 1GB image and formats it with the best FAT parameters suited to the size of the image.

The second line recursively copies all the content of the directory <code>snWXYZ</code> to the image, preserving the directory structure inside, starting from the <code>/</code> in the image.

One of the advantages of this method is that even if the image has a capacity of 1GB, it will use much less space on your hard drive until you fill up the image. On Linux or MacOS, a command <code>du -h NextZXOS.img</code> shows the actual amount of disk space used by the image. On Windows the same information can be seen in the File Properties dialog.

The fastest way to transfer a file or a directory (including its content, recursively) into an image is by using a single <code>put</code> (or <code>putdir</code>, if it's to transfer the directory file content to an existing directory) command of hdfmonkey.

The most convenient tool to copy of all the content from the image to a folder outside of the image is 7-zip. On Windows, just use the 7-zip GUI. On MacOS and Linux, see: [[Development_Tools:Linux_setup#Extracting_all_files_from_the_sd-card_image]].

=MAME Plugins and Scripts=

Some MAME plugins and scripts that may be useful for Next developers and end users are listed [[MAME:Plugins_and_Scripts|here]]. They let you speed up the Next boot time, profile your NextBASIC or assembler code, and more.

=Continuous Integration MAME Builds=

MAME is updated on a release schedule, but due to the ongoing nature of development, including for the MAME Next machine, it can sometimes be useful to install a more recent build if it contains a new feature or bugfix you are interested in. Sometimes, this ongoing work is discussed on social media, such as the [https://discordapp.com/channels/556228195767156758/752197165891321886 Next Developer Discord].

Continuous Integration (CI) builds are available from both the [https://github.com/mamedev/mame/actions primary MAME repo] and [https://github.com/holub/mame/actions holub's GitHub repo]. Both are considered bleeding-edge, with the primary MAME repo slightly less so. MAME CI builds are available for Windows, Linux, and macOS and are updated automatically whenever code is committed by a maintainer or pushed to the primary repo.

'''You need to be logged in to github''' to download CI artifacts, so [https://github.com/login sign in] or [https://github.com/signup sign up].

To try out a CI build (more precisely, the resulting binary executable, which is a produced "artifact" of the build process) , first do a full MAME install from the [https://www.mamedev.org/release.html latest release] if you have not already done so. Then back up your main binary from its installation location - these are called something like <code>mame.exe</code> or <code>mame</code>. You're backing it up to be able to restore it if the CI build doesn't work, or if you don't like how the CI build behaves.

Then visit one of the links above and find a workflow run item for your platform. Workflow items are the things in the list. The tags are flagged as <code>CI (Windows)</code>, <code>CI (Linux)</code>, or <code>CI (macOS)</code> in the second row of each workflow item in the list (not the filter in the left hand nav menu). Click on a completed workfow item (only items with green checkmarks will have created downloadable binaries yet), find the Artifacts section at the bottom (note again: you need to be signed up to see that section and/or download the artifact), then click the Download button. Unzip the downloaded file and find the main binary (with the same name as above). Copy the main binary to the install location, overwriting the original one, and run MAME the same way you were running it before. On Windows and macOS, you need to repeat the security steps above to trust the new MAME executable.

= More MAME related links =

MAME [https://docs.mamedev.org/ documentation].

Report any issues with MAME on the [https://mametesters.org/ bugtracker].

For '''Linux''' users there are more tips (how to compile MAME from source, how to configure it to not use CWD as starting path for resource directories, how to mount or create image file) at [[Development_Tools:Linux_setup]] page.

[https://docs.mamedev.org/advanced/devicemap.html MAMEDEV.ORG MAME Stable Controller IDs].
By default, MAME does not assign stable numbers to input devices. For instance, a game pad controller may be assigned to “Joy 1” initially, but after restarting, the same game pad may be reassigned to “Joy 3”.
Here a some hints how to fixate MAME´s Joystick-Detection to specific Controllers: [https://www.youtube.com/watch?v=YmjfwLuZ_X0 Youtube - Mapping your controllers for stable IDs]
and: [https://forums.launchbox-app.com/topic/89296-stable-controller-ids-for-mame/ Stable Controller IDs for MAME]

Compilers

2026-04-21T16:17:20Z

Johnnyo: /* z88dk-scc80 and z88dk-zsdcc */ minor edit

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ ZX Basic]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]
: The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]
: The selection of the CRT is by startup=n number. The crts are in the range 0-31, some mentioned in the above Hello World text, and some in the sources like [https://github.com/z88dk/z88dk/tree/master/libsrc/newlib/target/zxn/startup newlib zxn startup]. (internally: The factors of 256 are added by subtype=? on the compile line: base 0 numbers have no assumptions about the output type, i.e. for binaries that will be tap/nex/.. Base 256 is for dot commands, base 512 is for dotx command (not appropriate for the Next), base 768 is dotn).

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

Compilers

2026-04-21T16:16:14Z

Johnnyo: /* z88dk-scc80 and z88dk-zsdcc */ minor edit

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ ZX Basic]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]
: The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]
: The selection of the CRT is by startup=n number. The crts are in the range 0-31, some mentioned in the above Hello World text, and some in the sources like [https://github.com/z88dk/z88dk/tree/master/libsrc/newlib/target/zxn/startup newlib zxn startup]. (internally: The factors of 256 are added by subtype=? on the compile line: base 0 numbers have no assumptions about the output type, ie they are destined for binaries which can be turned into tap/nex/.. Base 256 is for dot commands, base 512 is for dotx command (not appropriate for the Next), base 768 is dotn).

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

Compilers

2026-04-21T16:15:21Z

Johnnyo: /* z88dk-scc80 and z88dk-zsdcc */ better order

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ ZX Basic]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]
: The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]
: The selection of the CRT is by startup=n number. The crts are in the range 0-31, some mentioned in the above Hello World text, and some in the sources like [https://github.com/z88dk/z88dk/tree/master/libsrc/newlib/target/zxn/startup newlib zxn startup]. (internally: The factors of 256 are added by subtype=? on the compile line: base 0 numbers have no assumptions about the output type, ie they are destined for binaries which can be turned into tap/nex/.. Base 256 is for dot commands, base 512 is for dotx command (which is not appropriate for the Next), base 768 is dotn).

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

Compilers

2026-04-21T16:08:37Z

Johnnyo: /* z88dk-scc80 and z88dk-zsdcc */ numbers

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ ZX Basic]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]
: The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]
: The selection of the CRT is by startup=n number. The crts are in the range 0-31, some mentioned in the above Hello World text, and some in the sources like [https://github.com/z88dk/z88dk/tree/master/libsrc/newlib/target/zxn/startup newlib zxn startup]. (internally: base 0 numbers have no assumptions about the output type, ie they are destined for binaries which can be turned into tap/nex/.. Base 256 is for dot commands, base 512 is for dotx command (which is not appropriate for the Next), base 768 is dotn. The factors of 256 are added by subtype=? on the compile line).

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

Compilers

2026-04-21T16:05:26Z

Johnnyo: /* z88dk-scc80 and z88dk-zsdcc */ startup numbers

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ ZX Basic]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]
: The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]
: The selection of the CRT is by startup=n number. The crts are in the range 0-31, some mentioned in the above Hello World text, and some in the sources like [https://github.com/z88dk/z88dk/tree/master/libsrc/newlib/target/zxn/startup newlib zxn startup]. Base 256 is for dot commands, base 512 is for dotx command (which is not appropriate for the Next), base 768 is dotn. The factors of 256 are added by subtype=? on the compile line.

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

Compilers

2026-04-21T16:00:21Z

Johnnyo: /* z88dk-scc80 and z88dk-zsdcc */ nicer

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ ZX Basic]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]
: The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

Compilers

2026-04-21T15:59:56Z

Johnnyo: /* z88dk-scc80 and z88dk-zsdcc */ Hello World

== BASIC ==

=== ''[https://zxbasic.readthedocs.io/ ZX Basic]'' ===
: A Basic to Z80 compiler with extensions added to Sinclair Basic.

=== ''[https://github.com/em00k/NextBuild NextBuild v7]'' ===
: NextBuild is a suite of tools for Windows which uses Boriel's ZX Basic Compiler. It comes with a Next library of routines to take advantage of the Nexts hardware. Examples included.
: See [[NextBuild:Main Page| NextBuild dedicated Wiki section]].

== C ==

=== ''z88dk-scc80'' and ''z88dk-zsdcc'' ===
: Via the "zcc", the [https://github.com/z88dk/z88dk Z88dk] toolchain's front end, two compilers could be invoked <ref> [https://github.com/z88dk/z88dk/wiki z88dk wiki] </ref>:
: "z88dk-scc80", a small C derived C compiler that is nearly C90 compliant with a few notable exceptions. Emphasis is on small code.
: "z88dk-zsdcc", a fork of [[#SDCC]].
: A Next target is present and under development. Output file types include tap, sna, and esxdos dot commands.
: [[Calling convention notes]]

The tutorial for the "newlib" for ZX Spectrum mentions some important details about the possibilities of programs written for Next too: [https://github.com/z88dk/z88dk/blob/master/doc/target/zx/02_HelloWorld.md ZX Hello World]

=== ''SDCC'' ===

: [https://sdcc.sourceforge.net/ Small Device C Compiler, SDCC] is an open-source retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11, ISO C23) compiler suite that targets a lot of mostly 8-bit microprocessors <ref>[https://sdcc.sourceforge.net/ SDCC targets as of February 2026]: the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.), Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola) HC08 based (hc08, s08), Zilog Z80 based MCUs (Z80, Z80N, Z180, SM83, Rabbit 2000, 2000A, 3000A, SM83, TLCS-90, eZ80, R800), Padauk (pdk14, pdk15), STMicroelectronics STM8, MOS 6502 and WDC 65C02. Work is in progress on supporting the Rabbit 4000, 5000, 6000, Padauk pdk13 and the f8 and f8l targets; Microchip PIC16 and PIC18 targets are unmaintained. SDCC can be retargeted for other microprocessors.</ref> including a Z80N target.

: The compiler, assembler and linker are GNU GPL <ref>[https://www.gnu.org/licenses/old-licenses/gpl-2.0.html GNU GPL 2] , [https://www.gnu.org/licenses/gpl-3.0.html GNU GPL 3]</ref> licensed and the compiler's libraries are GNU GPL licensed with a special exception.

: Developed as separate projects there are: a development kit for SDCC for creating small NextZXOS DOT programs and a [https://github.com/retro-vault/libcpm3-z80 library for CP/M 3]

: Firmware and loader sources in the tbblue repository were made to be compiled with SDCC.

== C-like ==

=== ''[https://taylorza.itch.io/znc-compiler ZNC Native compiler]'' ===
: ZNC is a language and compiler for the ZX Spectrum Next. The language is closely modeled after the C programming language.
: The language suite includes the compiler, an optimizer, assembler and text editor to support native development on the Next. It also include a frontend that makes managing source files and building your projects easier.

== Forth ==

=== ''VForth Next'' ===

: [https://github.com/mattsteeldue/vforth-next VForth Next] is a Z80N Forth system suitable to run on the ZX Spectrum Next

== Pascal ==

=== ''Pasta80'' ===
: [https://github.com/pleumann/pasta80 Pasta80] is a Turbo Pascal 3.0-compatible compiler that generates machine code for classic and modern Z80 machines (currently ZX Spectrum 48K/128K/Next and CP/M).
: GNU GPL 3 license with a linking exception.

=== ''OmniPas'' ===
: [https://syntaxerrorsoftware.itch.io/omnipas OmniPas] is a Windows‑based Pascal cross‑compiler that targets multiple platforms, including the ZX Spectrum and ZX Spectrum Next.

== Utilities ==

=== ''[https://github.com/speccyorg/bas2tap bas2tap CLI]'' ===
: The utility to convert `BASIC in an ASCII file' to a TAP tape image file (can be loaded by emulator or Next as regular BASIC program).
: Comes complete with portable C source. With full BASIC syntax checking!
: (does not support NextBASIC extensions)
: (for NextBASIC you can use the NextZXOS dot commands .txt2bas and .bas2txt directly on the Next)

=== ''[https://github.com/remy/txt2bas txt2bas & bas2txt CLI]'' ===
: Cross platform command line tool to convert NextBASIC to +3dos .bas file and convert .bas files to plain text.
: The tool also includes verbose validation, tap and 3dos, BANK compatible and headerless export and import support

== References ==

DMA interrupt enable 0

2026-04-12T15:19:29Z

Johnnyo: added content from the AA's explanation

{{NextRegister
|Number=$CC
|Readable=Yes
|Writable=Yes
|ShortDesc=Interrupts that can override DMA
}}
bit 7 = NMI
bit 1 = Line
bit 0 = ULA
* Set bits indicate the corresponding interrupt will interrupt a dma operation when in [[hw im2 mode]]

Soft reset = 0x00

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.

A signal will force the dma to pause by giving up the bus and wait in a reacquire bus state while the cpu takes back control. There are some vagaries in the behaviour due to how the z80 works: the z80 does not check for an interrupt until the last T state of an instruction so it's possible the z80 executes one instruction before the isr is entered. This is mentioned here as a caution to programmers because normally you start the dma with an OUT and when the next instruction executes, the dma op has already finished. Not so with this arrangement as you could be executing one instruction following that OUT each time the dma is interrupted.

There is also a kind of priority inversion that can happen. If only a ctc channel can interrupt a dma operation, there could be higher priority interrupts pending. When the ctc channel interrupts the dma, the z80 services the higher priority interrupts first and then only returns control to the dma when the reti for the ctc channel isr executes. The dma is also prevented from reacquring the bus until after reti pops its return address to avoid stack overflow.

DMA interrupt enable 2

2026-04-11T19:57:30Z

Johnnyo:

{{NextRegister
|Number=$CE
|Readable=Yes
|Writable=Yes
|ShortDesc=UART Interrupts that can override DMA
}}
bit 7 = Reserved must be zero
bit 6 = UART1 Tx empty
bit 5 = UART1 Rx half full \ shared
bit 4 = UART1 Rx available / interrupt
bit 3 = Reserved must be zero
bit 2 = UART0 Tx empty
bit 1 = UART0 Rx half full \ shared
bit 0 = UART0 Rx available / interrupt
* Set bits indicate the corresponding interrupt will interrupt a dma operation when in [[hw im2 mode]]

soft reset = 0x00

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.

DMA interrupt enable 1

2026-04-11T19:57:15Z

Johnnyo: linking hw im2

{{NextRegister
|Number=$CD
|Readable=Yes
|Writable=Yes
|ShortDesc=CTC Interrupts that can override DMA
}}
bit 7 = ctc channel 7 zc/to
bit 6 = ctc channel 6 zc/to
bit 5 = ctc channel 5 zc/to
bit 4 = ctc channel 4 zc/to
bit 3 = ctc channel 3 zc/to
bit 2 = ctc channel 2 zc/to
bit 1 = ctc channel 1 zc/to
bit 0 = ctc channel 0 zc/to
* Set bits indicate the corresponding interrupt will interrupt a dma operation when in [[hw im2 mode]]

soft reset = 0x00

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.

DMA

2026-04-11T19:56:38Z

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

== Overview ==
The ZX Spectrum Next DMA (zxnDMA) is a single channel DMA device that implements a subset of the Z80 DMA functionality. The subset is large enough to be compatible with common uses of the similar Datagear interface available for standard ZX Spectrum computers and compatibles. It also adds a burst mode capability that can deliver audio at programmable sample rates to the DAC device.

== Accessing the zxnDMA ==
<del>The zxnDMA is mapped to a single Read/Write IO Port 0x6B which is the same one used by the Datagear but unlike the Datagear it doesn't also map itself to a second port 0x0B similar to the MB-02 interface.</del>

Since core 3.1.2 the zxnDMA is mapped to {{PortNo|$xx6B}}, and Zilog-DMA mode is mapped to {{PortNo|$xx0B}}.

== Description ==
The normal Z80 DMA (Z8410) chip is a pipelined device and because of that it has numerous off-by-one idiosyncrasies and requirements on the order that certain commands should be carried out. These issues are not duplicated in the zxnDMA. You can continue to program the zxnDMA as if it is were a Z8410 DMA device but it can also be programmed in a simpler manner.

The single channel of the zxnDMA chip consists of two ports named A and B. Transfers can occur in either direction between ports A and B, each port can describe a target in memory or IO, and each can be configured to autoincrement, autodecrement or stay fixed after a byte is transferred.

A special feature of the zxnDMA can force each byte transfer to take a fixed amount of time so that the zxnDMA can be used to deliver sampled audio.

== Modes of Operation ==
The zxnDMA can operate in a z80-DMA compatibility mode.

'''REMOVED in core 3.1.2:''' <del>The z80-DMA compatibility mode is selected by setting bit 6 of nextreg 0x06. In this mode, all transfers involve length+1 bytes which is the same behaviour as the z80-DMA chip. In zxn-DMA mode, the transfer length is exactly the number of bytes programmed. This mode is mainly present to accommodate existing spectrum software that uses the z80-DMA and for cp/m programs that may have a z80-DMA option.</del>

'''Since core 3.1.2:''' the DMA mode is selected by port number, the {{PortNo|$xx6B}} works in zxnDMA mode, {{PortNo|$xx0B}} works in Zilog mode. The bit 6 in {{NextRegNo|$06}} is not DMA related any more and will be reused for something different.

The zxnDMA can also operate in either burst or continuous modes.

Continuous mode means the DMA chip runs to completion without allowing the CPU to run. When the CPU starts the DMA, the DMA operation will complete before the CPU executes its next instruction.

Burst mode nominally means the DMA lets the CPU run if either port is not ready. This condition can't happen in the zxnDMA chip except when operated in the special fixed time transfer mode. In this mode, the zxnDMA will let the CPU run while it waits for the fixed time to expire between bytes transferred.

Note that there is no byte transfer mode as in the Z80 DMA.

== Programming the zxnDMA ==
Like the Z80 DMA chip, the zxnDMA has seven write registers named WR0-WR6 that control the device. Each register WR0-WR6 can have zero or more parameters associated with it.

In a first write to the zxnDMA port, the write value is compared against a bitmask to determine which of the WR0-WR6 is the target. Remaining bits in the written value can contain data as well as a list of associated parameter bits. The parameter bits determine if further writes are expected to deliver parameter values. If there are multiple parameter bits set, the expected order of parameter values written is determined by parameter bit position from right to left (bit 0 through bit 7). Once all parameters are written, the zxnDMA again expects a regular register write selecting WR0-WR6.

The table below describes the registers and the bitmask required to select them on the zxnDMA.

{|
! Register Group
! Register Function Description
! Bitmask
! Notes
|-
| WR0
| Direction, Operation and Port A configuration
| <pre>0XXXXXAA</pre>
| AA must NOT be 00
|-
| WR1
| Port A configuration
| <pre>0XXXX100</pre>
|
|-
| WR2
| Port B configuration
| <pre>0XXXX000</pre>
|
|-
| WR3
| Activation
| <pre>1XXXXX00</pre>
| It’s best to use WR6
|-
| WR4
| Port B, Timing and Interrupt configuration
| <pre>1XXXXX01</pre>
|
|-
| WR5
| Ready and Stop configuration
| <pre>10XXX010</pre>
|
|-
| WR6
| Command Register
| <pre>1XXXXX11</pre>
|
|}

== zxnDMA Registers ==
These are described below following the same convention used by Zilog for its DMA chip:

=== WR0 – Write Register Group 0 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
0 | | | | | | |
| | | | | 0 0 Do not use
| | | | | 0 1 Transfer (Prefer this for Z80 DMA compatibility)
| | | | | 1 0 Do not use (Behaves like Transfer, Search on Z80 DMA)
| | | | |
| | | | | 1 1 Do not use (Behaves like Transfer, Search/Transfer on Z80 DMA)
| | | | |
| | | | 0 = Port B -> Port A (Byte transfer direction)
| | | | 1 = Port A -> Port B
| | | V
D7 D6 D5 D4 D3 D2 D1 D0 PORT A STARTING ADDRESS (LOW BYTE)
| | V
D7 D6 D5 D4 D3 D2 D1 D0 PORT A STARTING ADDRESS (HIGH BYTE)
| V
D7 D6 D5 D4 D3 D2 D1 D0 BLOCK LENGTH (LOW BYTE)
V
D7 D6 D5 D4 D3 D2 D1 D0 BLOCK LENGTH (HIGH BYTE)</pre>

Several registers are accessible from WR0. The first write to WR0 is to the base register byte. Bits D6:D3 are optionally set to indicate that associated registers in this group will be written next. The order the writes come in are from D3 to D6 (right to left). For example, if bits D6 and D3 are set, the next two writes will be directed to PORT A STARTING ADDRESS LOW followed by BLOCK LENGTH HIGH.

=== WR1 – Write Register Group 1 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
0 | | | | 1 0 0
| | | |
| | | 0 = Port A is memory
| | | 1 = Port A is IO
| | |
| 0 0 = Port A address decrements
| 0 1 = Port A address increments
| 1 0 = Port A address is fixed
| 1 1 = Port A address is fixed
|
V
D7 D6 D5 D4 D3 D2 D1 D0 PORT A VARIABLE TIMING BYTE
0 0 0 0 0 0 | |
0 0 = Cycle Length = 4
0 1 = Cycle Length = 3
1 0 = Cycle Length = 2
1 1 = Do not use
</pre>

The cycle length is the number of cycles used in a read or write operation. The first cycle asserts signals and the last cycle releases them. There is no half cycle timing for the control signals.

=== WR2 – Write Register Group 2 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
0 | | | | 0 0 0
| | | |
| | | 0 = Port B is memory
| | | 1 = Port B is IO
| | |
| 0 0 = Port B address decrements
| 0 1 = Port B address increments
| 1 0 = Port B address is fixed
| 1 1 = Port B address is fixed
|
V
D7 D6 D5 D4 D3 D2 D1 D0 PORT B VARIABLE TIMING BYTE
0 0 | 0 0 0 | |
| 0 0 = Cycle Length = 4
| 0 1 = Cycle Length = 3
| 1 0 = Cycle Length = 2
| 1 1 = Do not use
|
V
D7 D6 D5 D4 D3 D2 D1 D0 ZXN PRESCALAR (FIXED TIME TRANSFER)
</pre>
The ZXN PRESCALAR is a feature of the zxnDMA implementation. If non-zero, a delay will be inserted after each byte is transferred such that the total time needed for each transfer is determined by the prescalar. This works in both the continuous mode and the burst mode. If the DMA is operated in burst mode, the DMA will give up any waiting time to the CPU so that the CPU can run while the DMA is idle.

The rate of transfer is given by the formula “Frate = 875kHz / prescalar” or, rearranged, “prescalar = 875kHz / Frate”. The formula is framed in terms of a sample rate (Frate) but Frate can be inverted to set a transfer time for each byte instead. The 875kHz constant is a nominal value assuming a 28MHz system clock; the system clock actually varies from this depending on the video timing selected by the user (HDMI, VGA0-6) so for complete accuracy the constant should be prorated according to documentation for nextreg 0x11.

In a DMA audio setting, selecting a sample rate of 16kHz would mean setting the prescalar value to 55. This sample period is constant across changes in CPU speed.

=== WR3 – Write Register Group 3 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
1 | 0 0 0 0 0 0
|
1 = DMA Enable
</pre>
The Z80 DMA defines more fields but they are ignored by the zxnDMA. The two other registers defined by the Z80 DMA in this group on D4 and D3 are implemented by the zxnDMA but they do nothing.

It is preferred to start the DMA by writing an 'Enable DMA' command to WR6.

=== WR4 – Write Register Group 4 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
1 | | 0 | | 0 1
| | | |
0 0 = Do not use (Behaves like Continuous mode, Byte mode on Z80 DMA)
0 1 = Continuous mode
1 0 = Burst mode
1 1 = Do not use
| |
| V
D7 D6 D5 D4 D3 D2 D1 D0 PORT B STARTING ADDRESS (LOW BYTE)
|
V
D7 D6 D5 D4 D3 D2 D1 D0 PORT B STARTING ADDRESS (HIGH BYTE)
</pre>
The Z80 DMA defines three more registers in this group through D4 that define interrupt behaviour. Interrups and pulse generation are not implemented in the zxnDMA nor are these registers available for writing.

=== WR5 – Write Register Group 5 ===
<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
1 0 | | 0 0 1 0
| |
| 0 = /ce only
| 1 = /ce & /wait multiplexed
|
0 = Stop on end of block
1 = Auto restart on end of block
</pre>
The /ce & /wait mode is implemented in the zxnDMA but is not currently used. This mode has an external device using the DMA's /ce pin to insert wait states during the DMA's transfer.

The auto restart feature causes the DMA to automatically reload its source and destination addresses and reset its byte counter to zero to repeat the last transfer when a previous one is finished.

=== WR6 – Command Register ===
<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
1 ? ? ? ? ? 1 1
| | | | |
1 0 0 0 0 = 0xC3 = Reset
1 0 0 0 1 = 0xC7 = Reset Port A 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 0 0 1 0 = 0x8B = Reinitialize Status Byte
0 1 0 0 1 = 0xA7 = Initialize Read Sequence
1 0 0 1 1 = 0xCF = Load
1 0 1 0 0 = 0xD3 = Continue
0 0 0 0 1 = 0x87 = Enable DMA
0 0 0 0 0 = 0x83 = Disable DMA
+-- 0 1 1 1 0 = 0xBB = Read Mask Follows
|
D7 D6 D5 D4 D3 D2 D1 D0 READ MASK
0 | | | | | | |
| | | | | | V
D7 D6 D5 D4 D3 D2 D1 D0 Status Byte
| | | | | |
| | | | | V
D7 D6 D5 D4 D3 D2 D1 D0 Byte Counter Low ("High" with core 3.0.5 = bug in core)
| | | | |
| | | | V
D7 D6 D5 D4 D3 D2 D1 D0 Byte Counter High ("Low" with core 3.0.5 = bug in core)
| | | |
| | | V
D7 D6 D5 D4 D3 D2 D1 D0 Port A Address Low
| | |
| | V
D7 D6 D5 D4 D3 D2 D1 D0 Port A Address High
| |
| V
D7 D6 D5 D4 D3 D2 D1 D0 Port B Address Low
|
V
D7 D6 D5 D4 D3 D2 D1 D0 Port B Address High
</pre>
Unimplemented Z80 DMA commands are ignored.

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.

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.

The format of the DMA status byte is as follows:

<pre>00E1101T</pre>

E is set to 0 if the total block length has been transferred at least once.

T is set to 1 if at least one byte has been transferred.

== 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]] (which only occurred in Next core's 1 and 2, the limitation was lifted in core 3.0).

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.

== The DMA and Interrupts ==
The zxnDMA cannot currently generate [[Interrupts|interrupts]].

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 ==
A simple way to program the DMA is to walk down the list of registers WR0-WR5, sending desired settings to each. Then start the DMA by sending a LOAD command followed by an ENABLE_DMA command to WR6. Once more familiar with the DMA, you will discover that the amount of information sent can be reduced to what changes between transfers.

=== Assembly ===
Short example program to DMA memory to the screen, then DMA a sprite image from memory to sprite RAM, and then showing said sprite scrolling across the screen.

<pre>;------------------------------------------------------------------------------
; sjasmplus extra options to enable Z80N, stricter syntax and Next device
opt --zxnext --syntax=abf : device zxspectrumnext
;------------------------------------------------------------------------------
; DEFINE testing ; uncomment to produce NEX file (instead of DOT)
;------------------------------------------------------------------------------
; DMA (Register 6)
;
;------------------------------------------------------------------------------
;zxnDMA programming example
;------------------------------------------------------------------------------
;(c) Jim Bagley
;------------------------------------------------------------------------------
DMA_RESET equ $c3
DMA_RESET_PORT_A_TIMING equ $c7
DMA_RESET_PORT_B_TIMING equ $cb
DMA_LOAD equ $cf ; %11001111
DMA_CONTINUE equ $d3
DMA_DISABLE_INTERUPTS equ $af
DMA_ENABLE_INTERUPTS equ $ab
DMA_RESET_DISABLE_INTERUPTS equ $a3
DMA_ENABLE_AFTER_RETI equ $b7
DMA_READ_STATUS_BYTE equ $bf
DMA_REINIT_STATUS_BYTE equ $8b
DMA_START_READ_SEQUENCE equ $a7
DMA_FORCE_READY equ $b3
DMA_DISABLE equ $83
DMA_ENABLE equ $87
DMA_WRITE_REGISTER_COMMAND equ $bb
DMA_BURST equ %11001101
DMA_CONTINUOUS equ %10101101
ZXN_DMA_PORT equ $6b
SPRITE_STATUS_SLOT_SELECT equ $303B
SPRITE_IMAGE_PORT equ $5b
SPRITE_INFO_PORT equ $57
;------------------------------------------------------------------------------

IFDEF testing
org $5800
block 32*24, $38 ; default ULA attributes
org $6000
ELSE
org $2000
ENDIF

start
ld hl,$0000
ld de,$4000
ld bc,$800
call TransferDMA ; copy some random data to the screen pointing
; to ROM for now, for the purpose of showing
; how to do a DMA copy.
ld a,0 ; sprite image number we want to update
ld bc,SPRITE_STATUS_SLOT_SELECT
out (c),a ; set the sprite image number
ld bc,1*256 ; number to transfer (1)
ld hl,testsprite ; from
call TransferDMASprite ; transfer to sprite ram

nextreg 21,1 ; turn sprite on. for more info on this check
; out https://www.specnext.com/tbblue-io-port-system/
ld de,0
ld (xpos),de ; set initial X position ( doesn't need it for
; this demo, but if you run the .loop again it
; will continue from where it was
ld a,$20
ld (ypos),a ; set initial Y position

.loop
ld a,0 ; sprite number we want to position
ld bc,SPRITE_STATUS_SLOT_SELECT
out (c),a
ld de,(xpos)
ld hl,(ypos) ; ignores H so doing this rather than
; ld a,(ypos):ld l,a
ld bc,(image) ; not flipped or palette shifted
call SetSprite

halt

ld de,(xpos)
inc de
ld (xpos),de
ld a,d
cp $01
jr nz,.loop ; if high byte of xpos is not 1 (right of
; screen )
ld a,e
cp $20+1
jr nz,.loop ; if low byte is not $21 just off the right of
; the screen, $20 is off screen but as the
; INC DE is just above and not updated sprite
; after it, it needs to be $21
xor a
ret ; return back to basic with OK

xpos dw 0 ; x position
ypos db 0 ; y position
; these next two BITS and IMAGE are swapped
; as bits needs to go into B register
image db 0+$80 ; use image 0 (for the image we transfered)
; +$80 to set the sprite to active
bits db 0 ; not flipped or palette shifted

c1 = %11100000
c2 = %11000000
c3 = %10100000
c4 = %10000000
c5 = %01100000
c6 = %01000000
c7 = %00100000
c8 = %00000000

testsprite
db c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1
db c1,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c1
db c1,c2,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c2,c1
db c1,c2,c3,c4,c4,c4,c4,c4,c4,c4,c4,c4,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c5,c5,c5,c5,c5,c5,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c6,c6,c6,c6,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c7,c7,c7,c7,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c7,c8,c8,c7,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c7,c8,c8,c7,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c7,c7,c7,c7,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c6,c6,c6,c6,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c5,c5,c5,c5,c5,c5,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c4,c4,c4,c4,c4,c4,c4,c4,c4,c3,c2,c1
db c1,c2,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c2,c1
db c1,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c1
db c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1

;-------------------------------------------------
; de = X
; l = Y
; b = bits
; c = sprite image
SetSprite
push bc
ld bc,SPRITE_INFO_PORT
out (c),e ; Xpos
out (c),l ; Ypos
pop hl
ld a,d
and 1
or h
out (c),a
ld a,l:or $80
out (c),a ; image
ret

;--------------------------------
; hl = source
; de = destination
; bc = length
;--------------------------------
TransferDMA
di
ld (DMASource),hl
ld (DMADest),de
ld (DMALength),bc
ld hl,DMACode
ld b,DMACode_Len
ld c,ZXN_DMA_PORT
otir
ei
ret

DMACode db DMA_DISABLE
db %01111101 ; R0-Transfer mode, A -> B, write adress
; + block length
DMASource dw 0 ; R0-Port A, Start address
; (source address)
DMALength dw 0 ; R0-Block length (length in bytes)
db %01010100 ; R1-write A time byte, increment, to
; memory, bitmask
db %00000010 ; 2t
db %01010000 ; R2-write B time byte, increment, to
; memory, bitmask
db %00000010 ; R2-Cycle length port B
db DMA_CONTINUOUS ; R4-Continuous mode (use this for block
; transfer), write dest adress
DMADest dw 0 ; R4-Dest address (destination address)
db %10000010 ; R5-Restart on end of block, RDY active
; LOW
db DMA_LOAD ; R6-Load
db DMA_ENABLE ; R6-Enable DMA

DMACode_Len equ $-DMACode

;------------------------------------------------------------------------------
; hl = source
; bc = length
; set port to write to with TBBLUE_REGISTER_SELECT
; prior to call
;------------------------------------------------------------------------------
TransferDMAPort
di
ld (DMASourceP),hl
ld (DMALengthP),bc
ld hl,DMACodeP
ld b,DMACode_LenP
ld c,ZXN_DMA_PORT
otir
ei
ret

DMACodeP db DMA_DISABLE
db %01111101 ; R0-Transfer mode, A -> B, write adress
; + block length
DMASourceP dw 0 ; R0-Port A, Start address (source address)
DMALengthP dw 0 ; R0-Block length (length in bytes)
db %01010100 ; R1-read A time byte, increment, to
; memory, bitmask
db %00000010 ; R1-Cycle length port A
db %01101000 ; R2-write B time byte, increment, to
; memory, bitmask
db %00000010 ; R2-Cycle length port B
db %10101101 ; R4-Continuous mode (use this for block
; transfer), write dest adress
dw $253b ; R4-Dest address (destination address)
db %10000010 ; R5-Restart on end of block, RDY active
; LOW
db DMA_LOAD ; R6-Load
db DMA_ENABLE ; R6-Enable DMA

DMACode_LenP equ $-DMACodeP
;------------------------------------------------------------------------------
; hl = source
; bc = length
;------------------------------------------------------------------------------
TransferDMASprite
di
ld (DMASourceS),hl
ld (DMALengthS),bc
ld hl,DMACodeS
ld b,DMACode_LenS
ld c,ZXN_DMA_PORT
otir
ei
ret

DMACodeS db DMA_DISABLE
db %01111101 ; R0-Transfer mode, A -> B, write adress
; + block length
DMASourceS dw 0 ; R0-Port A, Start address (source address)
DMALengthS dw 0 ; R0-Block length (length in bytes)
db %01010100 ; R1-read A time byte, increment, to
; memory, bitmask
db %00000010 ; R1-Cycle length port A
db %01101000 ; R2-write B time byte, increment, to
; memory, bitmask
db %00000010 ; R2-Cycle length port B
db %10101101 ; R4-Continuous mode (use this for block
; transfer), write dest adress
dw SPRITE_IMAGE_PORT ; R4-Dest address (destination address)
db %10000010 ; R5-Restart on end of block, RDY active
; LOW
db DMA_LOAD ; R6-Load
db DMA_ENABLE ; R6-Enable DMA
DMACode_LenS equ $-DMACodeS
;------------------------------------------------------------------------------
; de = dest, a = fill value, bc = lenth
;------------------------------------------------------------------------------
DMAFill
di
ld (FillValue),a
ld (DMACDest),de
ld (DMACLength),bc
ld hl,DMACCode
ld b,DMACCode_Len
ld c,ZXN_DMA_PORT
otir
ei
ret

FillValue db 22
DMACCode db DMA_DISABLE
db %01111101
DMACSource dw FillValue
DMACLength dw 0
db %00100100,%00010000,%10101101
DMACDest dw 0
db DMA_LOAD,DMA_ENABLE
DMACCode_Len equ $-DMACCode

;------------------------------------------------------------------------------
; End of file
;------------------------------------------------------------------------------

IFDEF testing
savenex open "DMAtest.nex", start, $FF00
savenex bank 5
ELSE
fin
savebin "DMATEST",start,fin-start
ENDIF
</pre>

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+) ==

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 "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.4 is near-perfect, all the remaining differences are very minor).

== Technical details (core 3.0.5) ==

=== Zilog DMA compatibility mode ===
In Zilog DMA compatibility mode (bit 6 of {{NextRegNo|$06}}) the zxnDMA will mostly work as expected, but there are few differences in behaviour which may eventually throw off some rare SW, here is the list of the known differences (most of them describe also how the zxnDMA mode works):

The LOAD command must be issued with correct transfer direction, loading addresses in opposite direction and flipping direction afterward will mismatch the source/destination address data (Zilog/UA858D DMA chips are also sensitive to direction flip after LOAD, but the resulting transfer quirks in different way, reading source data byte after write, offsetting whole transfer by one and damaging start/end of sequence).
(does apply also to zxnDMA mode)

The LOAD command will NOT destroy the already issued "Initialize Read Sequence" - this is how even the original Zilog documentation describes the DMA chip operation, but the real Zilog DMA and UA858D (clone chip) both destroy read sequence upon LOAD command (zxnDMA is better).
(does apply also to zxnDMA mode)

The content of registers read back after finished transfer differs: the counter has swapped LSB with MSB byte, and both addresses will be adjusted length+1 times (Zilog/UA858D will return destination address adjusted only length-many times).
(does apply also to zxnDMA mode, except addresses are adjusted only "length" times of course, counter has still swapped bytes)

<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><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).

<del>Status byte doesn't have bit 0 set (the "T" bit in description above).
(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

The command 0xBB setting read mask will cause implicit 0xA7 Initialize Read Sequence.
(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.
(does apply also to zxnDMA mode, the prescalar works only in zxnDMA mode)

The destination port address is LOAD-ed even when it is "fixed" type (Contrary to Zilog DMA, which requires you to load such port as "source", flip the direction after and re-LOAD again with correct direction. UA858D chip does also load destination port address in any case, just like zxnDMA).
(does apply also to zxnDMA mode)

=== zxnDMA mode vs Zilog mode ===

In zxnDMA mode length of transfer is equal to the length written to WR0 register, port addresses are adjusted also only length-times.

Prescalar value will affect speed of transfer (use zero to switch prescalar off) (in burst mode during the extra idle time the CPU receives control back and can execute further instructions, in continuous mode the transfer will keep blocking CPU even when "slow" transfer is being done).

Interrupt Status 1 Register

2026-04-11T19:18:44Z

Johnnyo: linking hw im2

{{NextRegister
|Number=$C9
|Readable=Yes
|Writable=Yes
|ShortDesc=has ctc interrupt occurred?
}}
bit 7 = ctc channel 7 zc/to
bit 6 = ctc channel 6 zc/to
bit 5 = ctc channel 5 zc/to
bit 4 = ctc channel 4 zc/to
bit 3 = ctc channel 3 zc/to
bit 2 = ctc channel 2 zc/to
bit 1 = ctc channel 1 zc/to
bit 0 = ctc channel 0 zc/to
* (R) Set bits indicate the device generated an interrupt in the past or an interrupt is pending
* (W) Set bits clear the status. In [[hw im2 mode]] the status will continue to read as set until the interrupt pending condition is cleared

Interrupt Status 2 Register

2026-04-11T19:18:16Z

Johnnyo: linking hw im2

{{NextRegister
|Number=$CA
|Readable=Yes
|Writable=Yes
|ShortDesc=Has UART interrupt happened?
}}
bit 7 = Reserved must be zero
bit 6 = UART1 Tx empty
bit 5 = UART1 Rx half full \ shared
bit 4 = UART1 Rx available / interrupt
bit 3 = Reserved must be zero
bit 2 = UART0 Tx empty
bit 1 = UART0 Rx half full \ shared
bit 0 = UART0 Rx available / interrupt
* (R) Set bits indicate the device generated an interrupt in the past or an interrupt is pending
* (W) Set bits clear the status. In [[hw im2 mode]] the status will continue to read as set until the interrupt pending condition is cleared

Hw im2 mode

2026-04-11T19:17:36Z

Johnnyo: how to enable

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 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

Interrupt Status 0 Register

2026-04-11T19:15:23Z

Johnnyo: linking hw im2

{{NextRegister
|Number=$C8
|Readable=Yes
|Writable=Yes
|ShortDesc=has interrupt occurred?
}}
bits 7:2 = Reserved must be 0
bit 1 = Line
bit 0 = ULA
* (R) Set bits indicate the device generated an interrupt in the past or an interrupt is pending
* (W) Set bits clear the status. In [[hw im2 mode]] the status will continue to read as set until the interrupt pending condition is cleared

DMA interrupt enable 0

2026-04-11T19:14:43Z

Johnnyo: linking hw im2

Hw im2 mode

2026-04-11T19:12:47Z

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

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