SpecNext Wiki - User contributions [en-gb]

Memory map

2026-07-29T21:03:39Z

Johnnyo: added NextRegNo|$8E note

The Next supports two memory management models which operate in tandem. One is a unique memory management system for the Next. The other is an expanded version of the memory manager from the original Spectrum 128 and +2/+3 series.

== Global Memory Map ==

The total available RAM space of the Next is 768k on an unexpanded Next, or 1792k on a Next expanded to 2Mb. (The base Next has 1mb of memory but 256k of it is reserved for the ROMs and firmware.)

The Z80 processor in the Next can access only 64k of memory at a time, and so the memory is divided into ''banks'' which are used in determining which memory it sees. Spectrum 128k memory management, and [[NextBASIC]], use 16k banks. Next memory management via machine code uses 8k banks.

{|class="wikitable"
! 16k-bank !! 8k-bank !! True Address !! Size !! Description || FPGA Core Selector
|-
| - || - || $000000-$00ffff || 64K || ZX Spectrum ROM || A20:A16 = 00000
|-
| - || - || $010000-$011fff || 8K || divMMC ROM || A20:A16 = 00001,000
|-
| - || - || $012000-$013fff || 8K || Reserved for future Alt ROM2 +3 || A20:A16 = 00001,001
|-
| - || - || $014000-$017fff || 16K || Multiface ROM,RAM || A20:A16 = 00001,01
|-
| - || - || $018000-$01bfff || 16K || Alt ROM0 128k || A20:A16 = 00001,10
|-
| - || - || $01c000-$01ffff || 16K || Alt ROM1 48k || A20:A16 = 00001,11
|-
| - || - || $020000-$03ffff || 128K || divMMC RAM || A20:A16 = 00010
|-
| 0-7 || 0-15 || $040000-$05ffff || 128K || ZX Spectrum RAM || A20:A16 = 00100
|-
| 8-15 || 16-31 || $060000-$07ffff || 128K || Extra RAM ||
|-
| 16-47 || 32-95 || $080000-$0fffff || 512K || 1st extra IC RAM (available on unexpanded Next) ||
|-
| 48-79 || 96-159 || $100000-$17ffff || 512K || 2nd extra IC RAM (only available on expanded Next) ||
|-
| 80-111 || 160-223 || $180000-$1fffff || 512K || 3rd extra IC RAM (only available on expanded Next) ||
|}

Additionally, the first few pages have certain uses and traits summarised below:

{|class="wikitable"
! 16k-banks !! 8k-banks !! Description
|-
| 0 || 0-1 || Standard RAM, maybe used by esxDOS. Initially mapped to $c000-$ffff.
|-
| 1 || 2-3 || Standard RAM, contended on 128, may be used by esxDOS, RAMdisk on NextZXOS.
|-
| 2 || 4-5 || Standard RAM. Initially mapped to $8000-$bfff.
|-
| 3 || 6-7 || Standard RAM, contended on 128, may be used by esxDOS, RAMdisk on NextZXOS.
|-
| 4 || 8-9 || Standard RAM, contended on +2/+3, RAMdisk on NextZXOS.
|-
| 5 || 10-11 || ULA Screen, contended except on Pentagon, cannot be used by [[NextBASIC]] commands. Initially mapped to $4000-$7fff.
|-
| 6 || 12-13 || Standard RAM, contended on +2/+3, RAMdisk on NextZXOS.
|-
| 7 || 14-15 || ULA Shadow Screen, contended except on Pentagon, NextZXOS Workspace, cannot be used by [[NextBASIC]] commands
|-
| 8 || 16-17 || Next RAM, Default Layer 2, NextZXOS screen and extra data, cannot be used by [[NextBASIC]] commands
|-
| 9-10 || 18-21 || Next RAM, Rest of default Layer 2
|-
| 11-13 || 22-27 || Next RAM, Default Layer 2 Shadow Screen
|}

Please note that NextZXOS moves the Layer 2 bank assignments. Therefore, Layer 2, after NextZXOS boots, is mapped to 16k-banks 9-11 (8k-banks 18-23). The Layer 2 shadow memory is also assigned to 16k-banks 9-11 (8k-banks 18-23).

== Z80 Visible Memory map ==

At start up, the 16-bit address space of the Z80 is mapped to memory as follows:

{|class="wikitable"
! Area !! 16k-slot !! 8k-slot !! Default 16k-bank !! Default 8k-bank !! Description
|-
| $0000-$1fff || rowspan=2 | 1 || 0 || rowspan=2 | ROM || ROM (255) || Normally ROM. R/W redirect by [[Layer 2]]. IRQ and NMI routines here.
|-
| $2000-$3fff || 1 || ROM (255) || Normally ROM. R/W redirect by [[Layer 2]].
|-
| $4000-$5fff || rowspan=2 | 2 || 2 || rowspan=2 | 5 || 10 || Normally used for normal/shadow ULA screen.
|-
| $6000-$7fff || 3 || 11 || Timex ULA extended attribute/graphics area.
|-
| $8000-$9fff || rowspan=2 | 3 || 4 || rowspan=2 | 2 || 4 || Free RAM.
|-
| $a000-$bfff || 5 || 5 || Free RAM.
|-
| $c000-$dfff || rowspan=2 | 4 || 6 || rowspan=2 | 0 || 0 || Free RAM. Only this area is remappable by 128 memory management.
|-
| $e000-$ffff || 7 || 1 || Free RAM. Only this area is remappable by 128 memory management.
|}

=== Memory decoding order ===

(check also current [https://gitlab.com/SpectrumNext/ZX_Spectrum_Next_FPGA/-/blob/master/cores/zxnext/src/zxnext.vhd#L2918 VHDL source])

The 0-16k area could be remapped by several different mechanics, the priority order of these (from highest priority to lowest):
# bootrom
# multiface
# divmmc
# layer 2 mapping
# mmu
# config mode
# romcs expansion bus
# rom

The 16k-48k area is either mapped by MMU or overshadowed by Layer2 mapping:
# layer 2 mapping
# mmu

Finally the remaining top 16k, the 48k-64k area is mapped only by MMU.

Additionally, there's 16KB + 8KB KB which exist in two instances: as an "internal bram" and as an "external sram":

Accesses to (the RAM of 16KB) "bank 5" or (the first 8KB RAM of the RAM of 16KB) "bank 7" always go to internal bram with the following three exceptions:

1 ''Layer 2 itself has a direct connection to external sram'' so while (the core is) reading bytes to generate video, all bytes read (for Layer 2) come from external sram. It (Layer 2) has no connection to internal bram so its "bank 5" or "bank 7" accesses are from external sram and not internal bram.

2 ''Layer 2 mapping is a mapping to external sram only.'' So (in the context of Layer 2 mapping) "bank 5" or "bank 7" will not come from internal bram but from external sram which is how the cpu can uncover that otherwise hidden memory in external sram.

3 The config mapping is also an external sram mapping.

== Paging techniques ==

=== 128-style memory management ===

128-style memory management can only alter the bank addressed at $c000 (16k-slot 4, or 8k-slot 7-8). The active 16k-bank at $c000 is selected by writing the 3 LSBs of the 16k-bank number to the bottom 3 bits of [[Memory_Paging_Control | Port $7FFD]], and the 3 MSBs to the bottom 3 bits of [[Next_Memory_Bank_Select | Port $DFFD]]. (The reason for the division is that the original Spectrum 128, having only 128k of memory, only needed 3 bits.)

On an unexpanded Next, this allows any 16k-bank to be paged in at $c000. On an expanded Next, there are not enough bits available to access the banks at the bottom of the expanded memory, so Next memory management must be used to access these.

If you are using the standard interrupt handler or OS routines, then any time you write to [[Memory_Paging_Control | Port $7FFD]] you should also store the value at $5B5C. Any time you write to [[Plus_3_Memory_Paging_Control | Port $1FFD]] you should also store the value at $5B67. There is no corresponding system variable for the Next-only [[Next_Memory_Bank_Select | Port $DFFD]] and standard OS routines may not support the extended banks properly.

=== 128 Special Paging Mode ===
"Special paging mode" (also called "AllRam mode" or "CP/M mode") is enabled by writing a value with the LSB set to [[Plus_3_Memory_Paging_Control | Port $1FFD]]. Depending on the 3 low bits of this value a memory configuration is selected as follows:
{| class="wikitable"
! Bits !! Slot 1 !! Slot 2 !! Slot 3 || Slot 4
|-
| %001 || 0 || 1 || 2 || 3
|-
| %011 || 4 || 5 || 6 || 7
|-
| %101 || 4 || 5 || 6 || 3
|-
| %111 || 4 || 7 || 6 || 3
|}

=== Layer 2 Switching ===
Layer 2 switching can allow one of the 16k-banks to be ''written to'' or ''read from'' in 16k-slot 1, by writing the 16k-bank number to {{NextRegNo|$12}} and then enabling Layer 2 paging by setting the paging bits in [[Layer_2_Access_Port | Port $123B]]. You can use also the {{NextRegNo|$13}} for the same purpose (change of register $12 is immediately visible at display, while register $13 is not related to display in any way, it works only as bank selector for writing into slot 1). Since core 3.0 you can page not only first 16kiB, but whole 48kiB of Layer 2 to address region $0000..$BFFF).

Writing to/reading from this paging area will then write/read the appropriate area of memory, whereas the other operation may remain unaffected and use the area mapped by other memory management.

Layer 2 is actually 3 banks big, so using Layer 2 controls to access different "sections" of Layer 2 can access the two following banks after the one selected in register $12/$13.

=== Next Memory Management ===
The 8k-bank accessed in an 8k-slot is selected by writing the 8k-bank number to bits 7-0 of the 8 Next registers from {{NextRegNo|$50}} upwards. $50 addresses 8k-slot 0, $51 addresses 8k-slot 1, and so on.

In addition, in 8k-slots 0 and 1 only, the ROM can be paged in by selecting the otherwise nonexistent 8k-page $FF. Whether the high or the low 8k of the ROM is mapped is determined by which 8k-slot is used.

Also note that since core 3.1.1 there's {{NextRegNo|$8E}}, and it affects the same memory mapping aspects as explained in 128-style memory management and all the related ports .

=== Interactions between paging methods ===
In normal mode, changes made in 128 style and Next style memory management are synchronized. The most recent change always has priority. This means that using 128-style memory management to select a new 16k-bank in 16k-slot 4 will update the MMU registers for the two 8k-slots with the corresponding 8k-bank numbers.

However, enabling 128 special paging mode (AllRam mode) mode will '''override the Next MMU'''. The bank selections from the AllRam mode table will override the set pages in the Next registers. The MMU registers can still be changed, but they will have no effect until special paging mode is disabled.

Since the 128-style memory management ports are not readable, there is no synchronization applicable in the other direction.

== ROM paging and selection ==
$0000-$3fff is usually mapped to ROM. This area can only be fully remapped using Next memory management. ROM is not considered one of the numbered banks; it is mapped to the two 8k-banks by default, or by setting their 8k-bank numbers to 255.

The 128k Spectrum has 2 ROM pages. Which of these is mapped is selected by altering Bit 4 of [[Memory_Paging_Control | Port $7FFD]]. The +2a/+3 has 4 ROM pages; the extra bit needed to select between these is bit 2 of [[Plus_3_Memory_Paging_Control | Port $1FFD]]. This maintains compatibility with the original machines' ROM paging as long as the ROM is not paged out.

=== Paging out ROM ===
ROM can be paged out by enabling AllRam mode, or by using Next memory management. Beware that some programs may assume that they can find ROM service routines at fixed addresses between $0000-$3fff. More importantly, if the default interrupt mode (IM 1) is set, the Z80 '''will''' jump the program counter to $0038 every frame expecting to find an interrupt handler there. If it does not, pain and suffering will likely result. [[Extended Z80 instruction set#DI|DI]] is your friend. On the plus side, this does allow you to write your own interrupt handler without the nuisance of using IM 2.

Activating [[Layer 2]]'s paging will not affect ROM operation, because it only remaps ''writes'', not reads. With core 3.0 you can now enable this paging also for ''read'' operation, that will hide ROM data and for example IM 1 interrupt request will execute the data from the Layer 2 bank.

== Screen ==
16k-Bank 5 is the bank read by the ULA to determine what to show on screen. The ULA connects directly to the larger memory space ignoring mapping; the screen is always 16k-Bank 5, no matter where in memory it is (or if it is switched in at all). Setting bit 3 of [[Memory_Paging_Control | Port $7FFD]] will have the ULA read from 16k-bank 7 (the "shadow screen") instead, which can be used as an alternate screen. Beware that '''this does not map 16k-bank 7 into RAM'''; to alter 16k-bank 7 it must be mapped by other means.

Memory Mapping Register

2026-07-29T20:59:12Z

Johnnyo: slight reformatting

{{NextRegister
|Number=$8E
|Readable=Yes
|Writable=Yes
|ShortDesc=Control classic 128K Spectrum memory mapping
}}

bit 7 = port 0xdffd bit 0 \ RAM
bits 6:4 = port 0x7ffd bits 2:0 / bank 0-15
R bit 3 = 1
W bit 3 = 1 to change RAM bank,
= 0 no change to mmu6 / mmu7 / RAM bank in ports 0x7ffd, 0xdffd
bit 2 = port 0x1ffd bit 0 paging mode
If bit 2 = paging mode = 0 (normal)
bit 1 = port 0x1ffd bit 2 \ ROM
bit 0 = port 0x7ffd bit 4 / select
If bit 2 = paging mode = 1 (special allRAM)
bit 1 = port 0x1ffd bit 2 \ all
bit 0 = port 0x1ffd bit 1 / RAM

: Writes can affect all ports {{PortNo|$7FFD}}, {{PortNo|$DFFD}}, {{PortNo|$1FFD}}
: Writes always change the ROM / allRAM mapping
: Writes immediately change the current mmu mapping as if by port write

(new register since core 3.1.1)

(note: Next registers with number higher than $7F are inaccessible from Copper code)

Emulators

2026-07-24T09:58:47Z

Johnnyo: emulation of non-next targets out of scope of here

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

(The following table is ordered alphabetically)

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://github.com/jorgegv/jnext JNext]||[https://github.com/jorgegv Jorge González]|| ||An emulator with debugger and automated control for CI/CD. Currently in beta.||Any||[https://github.com/jorgegv/jnext Yes]||Yes
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go. Early in development but improves. Its documentation still claims more than it actually does: many games don't run or run wrong, even the simple ones. (Note: The status of emulation of non-Next Spectrums irrelevant for this wiki -- hundreds of emulators are intentionally not listed). ||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|}

Emulators

2026-07-21T08:20:00Z

Johnnyo: keeping the table in alphabetical order

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

(The following table is ordered alphabetically)

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://github.com/jorgegv/jnext JNext]||[https://github.com/jorgegv Jorge González]|| ||An emulator with debugger and automated control for CI/CD. Currently in beta.||Any||[https://github.com/jorgegv/jnext Yes]||Yes
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go. Early in development but improves. Its documentation still claims more than it actually does: many games don't run or run wrong, even the simple ones. (Note: The status of emulation of non-Next Spectrums irrelevant for this wiki -- hundreds of emulators are intentionally not listed). ||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|}

Emulators

2026-07-21T08:17:33Z

Johnnyo: removing what's obvious from the "Any" entry in the table

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

(The following table is ordered alphabetically)

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go. Early in development but improves. Its documentation still claims more than it actually does: many games don't run or run wrong, even the simple ones. (Note: The status of emulation of non-Next Spectrums irrelevant for this wiki -- hundreds of emulators are intentionally not listed). ||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|-
|[https://github.com/jorgegv/jnext JNext]||[https://github.com/jorgegv Jorge González]|| ||An emulator with debugger and automated control for CI/CD. Currently in beta.||Any||[https://github.com/jorgegv/jnext Yes]||Yes
|}

Emulators

2026-07-10T05:45:26Z

Johnnyo: zx_go clarify

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

(The following table is ordered alphabetically)

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go. Early in development but improves. Its documentation still claims more than it actually does: many games don't run or run wrong, even the simple ones. (Note: The status of emulation of non-Next Spectrums irrelevant for this wiki -- hundreds of emulators are intentionally not listed). ||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|}

Emulators

2026-07-10T05:43:46Z

Johnnyo: clarify the note

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

(The following table is ordered alphabetically)

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go. Its documentation still claims more than it actually does: many games don't run or run wrong, even the simple ones. (Note: The status of emulation of non-Next Spectrums irrelevant for this wiki -- hundreds of emulators are intentionally not listed). ||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|}

Emulators

2026-07-10T05:40:57Z

Johnnyo: more true zx_go description

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

(The following table is ordered alphabetically)

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go. Its documentation still claims more than it actually does: many games don't run or run wrong, even the simple ones. Emulation of non-Next Spectrums irrelevant here. ||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|}

Emulators

2026-07-10T05:40:26Z

Johnnyo: /* WARNING: */

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

(The following table is ordered alphabetically)

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go. Comprehensive debugger. Its documentation still claims more than it actually does: many games don't run or run wrong, even the simple ones. Emulation of non-Next Spectrums irrelevant here. ||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|}

Emulators

2026-06-18T23:27:06Z

Johnnyo: keeping the table in alphabetical order

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

(The following table is ordered alphabetically)

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go, seemingly still in its early development phase. Boots into the NextZXOS. Fails to open the tap file. NextBASIC Invaders game (from the distro) doesn't work, and many other games.||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|}

Emulators

2026-06-18T23:23:38Z

Johnnyo: wording

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go, seemingly still in its early development phase. Boots into the NextZXOS. Fails to open the tap file. NextBASIC Invaders game (from the distro) doesn't work, and many other games.||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|}

Emulators

2026-06-18T19:58:48Z

Johnnyo: /* WARNING: */ MAME has at least "good" Next support now.

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with good Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go, seemingly still in its early development phase. Boots into the NextZXOS. Fails to open the tap file. NextBASIC Invaders don't work, and many other games.||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|}

Emulators

2026-06-18T19:56:39Z

Johnnyo: minimizing more

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with relatively recent Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go, seemingly still in its early development phase. Boots into the NextZXOS. Fails to open the tap file. NextBASIC Invaders don't work, and many other games.||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|}

Emulators

2026-06-18T17:47:15Z

Johnnyo: more honest zx_go state

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with relatively recent Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go, seemingly still in its early development phase. Boots into the NextZXOS, but doesn't show all directories. Fails to open the tap file. Fails to start .ls dot command. Writes to the disk go missing (e.g. welcome is not renamed).||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|}

Emulators

2026-06-18T17:38:29Z

Johnnyo: /* WARNING: */ removing non-Next relevant feature list from zx_go, honest state

===== WARNING: =====

The current Next emulators are work-in-progress, missing several features of real HW Next, and emulating other features in less than cycle-accurate way (which become a "norm" for classic ZX Spectrum after two decades of emulators development). The differences in results between real Next and CSpect or ZEsarUX are to be expected - as a developer test your SW also with real HW to find any problems early. It may also help to read the known-bugs pages to have some rough idea what works and how accurately. There're also multiple test-suites and free games and demos which you can try to go through and compare the emulator output with real machine, to get familiar with the differences and adjust your workflow and expectations.
 

Also make sure to explore the command line options and configuration of each emulator, as there are multiple ways how to run them with different fidelity of emulation. When in doubt, you are welcome to join the official ZX Spectrum Next discord chat and ask for help at #emulator-help channel.
 

Currently the most UI and performance friendly emulator seems to be #CSpect, the most accurate and performant emulator is MAME.

{| class="wikitable"
!Name||Author||Known bugs||Description||OS||Source||Maintained
|-
|[https://mdf200.itch.io/cspect CSpect]||[https://lemmings.info/about/ Mike Dailly]||[[CSpect:known bugs|List]]||Emulates many features of the Next and includes a fully featured debugger, complete with 24bit breakpoints and an assembler||Windows ([https://lemmings.info/installing-cspect-on-a-mac/ mac]/[[Development_Tools:Linux_setup##CSpect_emulator|linux]] with mono - mostly works)||No||[https://www.patreon.com/posts/crash-and-cspect-143597332 Statement of maintenance and support]
|-
|[https://www.mamedev.org/ MAME]||[https://github.com/holub holub] (Next), many contributors (MAME)||[[MAME:known bugs|List]]‎||Mature multi-system emulator with relatively recent Next support. See [[MAME:Installing|installation notes]].||Any||[https://github.com/mamedev/mame Yes]||Yes
|-
|[https://gitlab.com/garrylancaster/zenext ZENext]||[https://github.com/chernandezba César Hernández Bañó], [https://gitlab.com/garrylancaster Garry Lancaster]|| |||ZX Next-only fork of ZEsarUX emulating most of the core 3.1.10 features to make it run NextZXOS 2.07 or 2.09 (missing some features like CTC timers). See [[ZENext:Installing|installation notes]]||Any (more easily: only Linux)||[https://gitlab.com/garrylancaster/zenext Yes]||Occasionally
|-
|[https://github.com/chernandezba/zesarux/releases ZEsarUX]||César Hernández Bañó|||[[ZEsarUX:known bugs|List]]||A full feature emulator including a debugger - sometimes updated to support Next (TBBlue)||Any||[https://github.com/chernandezba/zesarux Yes]||Yes
|-
|[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 ZESERUse]||César Hernández Bañó, [https://github.com/ped7g Peter Helcmanovsky]||[[ZESERUse:known bugs|List]]||Fork of older ZEsarUX 8.2 with improved emulation accuracy of (rather old) core 3.1.5||Any||[https://github.com/ped7g/zesarux/tree/tbblue_small_fixes2 Yes]||Rarely
|-
|[https://github.com/conorarmstrong/zx_go zx_go]||Conor Armstrong|| ||An emulator written in Go, seemingly still in its early development phase. Boots into the NextZXOS, but doesn't show all directories. Fails to open the tap file. Fails to start .ls dot command.||Any||[https://github.com/conorarmstrong/zx_go Yes]||Yes
|-
|[http://www.desdes.com/products/oldfiles/zeus.htm Zeus]||[https://www.desdes.com/ Simon Brattel]|| || A PC cross-assembler which includes an IDE and Spectrum 48/128/+2/+3 emulator. Includes support for Next MMU banking, sprites and UART only, with remote debugging on Next hardware.||Windows||No||No
|}

CTC

2026-06-09T15:36:16Z

Johnnyo:

CTC

The CTC has been temporarily reduced to four channels from eight.

Eight independent CTC channels are available on ports 0x183B through 0x1F3B. These perform counter / timer functions that can be used to generate timer interrupts or to generate interrupts on behalf of physical signals.

The CTC is a standard Zilog part. Its datasheet can be found at http://www.zilog.com/docs/z80/ps0181.pdf and the user manual at "Z80 CPU Peripherals User Manual UM0081" http://www.zilog.com/docs/z80/um0081.pdf The Zilog documentation is ambiguous around how soft resets are treated so the following clarifies some points in the Next's implementation.

: 1. Hard reset requires a control word to be written with D2 = 1 (time constant follows) otherwise the channel effectively ignores the control word and will remain in the hard reset state.

: 2. Soft reset is generated when the control word's D1 = 1. if D2 = 0, the channel will enter the hard reset state. If D2 = 1 the channel expects a time constant to be written next and after that the counter/timer will run as expected.

: 3. Changing the trigger edge selection in bit 4 counts as a clock edge. A timer waiting for a clock edge to start will start and in counter mode, the count will be decremented.

: 4. ZC/TO is asserted for one clock cycle and not for the entire duration that the count is at zero.

To soft reset a particular channel that is in an unknown state, a soft reset control word should be written twice with D2 = 0 (no time constant follows).

At the moment, the ZC/TO output of each channel is fed into the CLK/TRG input of the succeeding channel so that time and count periods can be cascaded. Channel 3's ZC/TO output is divided by two and drives the joystick's clock in io mode.

The rate of clock input to the CTC's timer is not affected by the value in the NextReg 7.

CTC

2026-06-09T15:35:38Z

Johnnyo: user manual

CTC

The CTC has been temporarily reduced to four channels from eight.

Eight independent CTC channels are available on ports 0x183B through 0x1F3B. These perform counter / timer functions that can be used to generate timer interrupts or to generate interrupts on behalf of physical signals.

The CTC is a standard Zilog part. Its datasheet can be found at http://www.zilog.com/docs/z80/ps0181.pdf and the user manual at http://www.zilog.com/docs/z80/um0081.pdf The Zilog documentation is ambiguous around how soft resets are treated so the following clarifies some points in the Next's implementation.

: 1. Hard reset requires a control word to be written with D2 = 1 (time constant follows) otherwise the channel effectively ignores the control word and will remain in the hard reset state.

: 2. Soft reset is generated when the control word's D1 = 1. if D2 = 0, the channel will enter the hard reset state. If D2 = 1 the channel expects a time constant to be written next and after that the counter/timer will run as expected.

: 3. Changing the trigger edge selection in bit 4 counts as a clock edge. A timer waiting for a clock edge to start will start and in counter mode, the count will be decremented.

: 4. ZC/TO is asserted for one clock cycle and not for the entire duration that the count is at zero.

To soft reset a particular channel that is in an unknown state, a soft reset control word should be written twice with D2 = 0 (no time constant follows).

At the moment, the ZC/TO output of each channel is fed into the CLK/TRG input of the succeeding channel so that time and count periods can be cascaded. Channel 3's ZC/TO output is divided by two and drives the joystick's clock in io mode.

The rate of clock input to the CTC's timer is not affected by the value in the NextReg 7.

MAME:Installing

2026-06-02T20:55:08Z

Johnnyo: /* 1. Get MAME */ make the items as the lists

[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.04 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.

MAME for macOS now requires the SDL3 library.

* '''Windows:''' Download [https://www.mamedev.org/release.html MAME for Windows].
* '''macOS:''' Download the [https://github.com/libsdl-org/SDL/releases/latest SDL3 library], and copy its '''SDL3.xcframework''' and '''share''' folders to ~/Library/Frameworks, as instructed in the included INSTALL.md file. Then 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 (and the SDL3 framework) 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/]

* Git of Holub's fork: [https://github.com/holub/mame https://github.com/holub/mame] (may contain extra fixes and features before they are merged to official repository, from the Actions page, if you're logged in, the most recent executables could be downloaded).

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

You will then need to '''repeat this process for the SDL3 framework.'''

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

= 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 the GitHub Action pages of both:

* the [https://github.com/mamedev/mame/actions https://github.com/mamedev/mame/actions -- primary MAME repo Actions pagee] and

* [https://github.com/holub/mame/actions https://github.com/holub/mame/actions -- Holub's GitHub repo Actions page].

Both are newer builds than the latest official release, and Holub's repo still tends to contain the fixes still waiting to be accepted to the primary repo. 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 your preferred "Actions page" 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]

MAME:Installing

2026-06-02T20:54:29Z

Johnnyo: /* Installation */ removed links to the single cpp source, not needed in the intro

[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.04 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.

MAME for macOS now requires the SDL3 library.

* '''Windows:''' Download [https://www.mamedev.org/release.html MAME for Windows].
* '''macOS:''' Download the [https://github.com/libsdl-org/SDL/releases/latest SDL3 library], and copy its '''SDL3.xcframework''' and '''share''' folders to ~/Library/Frameworks, as instructed in the included INSTALL.md file. Then 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 (and the SDL3 framework) 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/]

Git of Holub's fork: [https://github.com/holub/mame https://github.com/holub/mame] (may contain extra fixes and features before they are merged to official repository, from the Actions page, if you're logged in, the most recent executables could be downloaded).

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

You will then need to '''repeat this process for the SDL3 framework.'''

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

= 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 the GitHub Action pages of both:

* the [https://github.com/mamedev/mame/actions https://github.com/mamedev/mame/actions -- primary MAME repo Actions pagee] and

* [https://github.com/holub/mame/actions https://github.com/holub/mame/actions -- Holub's GitHub repo Actions page].

Both are newer builds than the latest official release, and Holub's repo still tends to contain the fixes still waiting to be accepted to the primary repo. 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 your preferred "Actions page" 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]

MAME:Installing

2026-06-02T20:52:17Z

Johnnyo: /* Installation */ the Actions page in the first mention

[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.04 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.

MAME for macOS now requires the SDL3 library.

* '''Windows:''' Download [https://www.mamedev.org/release.html MAME for Windows].
* '''macOS:''' Download the [https://github.com/libsdl-org/SDL/releases/latest SDL3 library], and copy its '''SDL3.xcframework''' and '''share''' folders to ~/Library/Frameworks, as instructed in the included INSTALL.md file. Then 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 (and the SDL3 framework) 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, from the Actions page, if you're logged in, the most recent executables could be downloaded).

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

You will then need to '''repeat this process for the SDL3 framework.'''

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

= 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 the GitHub Action pages of both:

* the [https://github.com/mamedev/mame/actions https://github.com/mamedev/mame/actions -- primary MAME repo Actions pagee] and

* [https://github.com/holub/mame/actions https://github.com/holub/mame/actions -- Holub's GitHub repo Actions page].

Both are newer builds than the latest official release, and Holub's repo still tends to contain the fixes still waiting to be accepted to the primary repo. 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 your preferred "Actions page" 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]

MAME:Installing

2026-06-02T20:43:54Z

Johnnyo: /* Continuous Integration MAME Builds */ Actions

[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.04 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.

MAME for macOS now requires the SDL3 library.

* '''Windows:''' Download [https://www.mamedev.org/release.html MAME for Windows].
* '''macOS:''' Download the [https://github.com/libsdl-org/SDL/releases/latest SDL3 library], and copy its '''SDL3.xcframework''' and '''share''' folders to ~/Library/Frameworks, as instructed in the included INSTALL.md file. Then 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 (and the SDL3 framework) 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.

You will then need to '''repeat this process for the SDL3 framework.'''

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

= 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 the GitHub Action pages of both:

* the [https://github.com/mamedev/mame/actions https://github.com/mamedev/mame/actions -- primary MAME repo Actions pagee] and

* [https://github.com/holub/mame/actions https://github.com/holub/mame/actions -- Holub's GitHub repo Actions page].

Both are newer builds than the latest official release, and Holub's repo still tends to contain the fixes still waiting to be accepted to the primary repo. 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 your preferred "Actions page" 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]

MAME:Installing

2026-06-02T20:30:58Z

Johnnyo: /* Continuous Integration MAME Builds */ improving? links

[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.04 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.

MAME for macOS now requires the SDL3 library.

* '''Windows:''' Download [https://www.mamedev.org/release.html MAME for Windows].
* '''macOS:''' Download the [https://github.com/libsdl-org/SDL/releases/latest SDL3 library], and copy its '''SDL3.xcframework''' and '''share''' folders to ~/Library/Frameworks, as instructed in the included INSTALL.md file. Then 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 (and the SDL3 framework) 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.

You will then need to '''repeat this process for the SDL3 framework.'''

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

= 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 https://github.com/mamedev/mame/actions -- primary MAME repo Actions pagee] and

* [https://github.com/holub/mame/actions https://github.com/holub/mame/actions -- Holub's GitHub repo Actions page].

Both are newer builds than the latest official release, and Holub's repo still tends to contain the fixes still waiting to be accepted to the primary repo. 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]

MAME:Installing

2026-06-02T20:16:35Z

Johnnyo: /* Continuous Integration MAME Builds */ official

[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.04 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.

MAME for macOS now requires the SDL3 library.

* '''Windows:''' Download [https://www.mamedev.org/release.html MAME for Windows].
* '''macOS:''' Download the [https://github.com/libsdl-org/SDL/releases/latest SDL3 library], and copy its '''SDL3.xcframework''' and '''share''' folders to ~/Library/Frameworks, as instructed in the included INSTALL.md file. Then 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 (and the SDL3 framework) 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.

You will then need to '''repeat this process for the SDL3 framework.'''

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

= 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 https://github.com/mamedev/mame/actions primary MAME repo Actions pagee] and

* [https://github.com/holub/mame/actions https://github.com/holub/mame/actions Holub's GitHub repo Actions page].

Both are newer builds than the latest official release, and Holub's repo still tends to contain the fixes still waiting to be accepted to the primary repo. 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]

MAME:Installing

2026-06-02T20:14:58Z

Johnnyo: /* Continuous Integration MAME Builds */ actions pages more prominent

[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.04 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.

MAME for macOS now requires the SDL3 library.

* '''Windows:''' Download [https://www.mamedev.org/release.html MAME for Windows].
* '''macOS:''' Download the [https://github.com/libsdl-org/SDL/releases/latest SDL3 library], and copy its '''SDL3.xcframework''' and '''share''' folders to ~/Library/Frameworks, as instructed in the included INSTALL.md file. Then 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 (and the SDL3 framework) 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.

You will then need to '''repeat this process for the SDL3 framework.'''

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

= 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 https://github.com/mamedev/mame/actions primary MAME repo Actions pagee] and

* [https://github.com/holub/mame/actions https://github.com/holub/mame/actions Holub's GitHub repo Actions page].

Both are newer builds than the latest release, and Holub's repo still tends to contain the fixes still waiting to be accepted to the primary repo. 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]

MAME:Installing

2026-06-01T23:13:53Z

Johnnyo: core 3.02.04

[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.04 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.

MAME for macOS now requires the SDL3 library.

* '''Windows:''' Download [https://www.mamedev.org/release.html MAME for Windows].
* '''macOS:''' Download the [https://github.com/libsdl-org/SDL/releases/latest SDL3 library], and copy its '''SDL3.xcframework''' and '''share''' folders to ~/Library/Frameworks, as instructed in the included INSTALL.md file. Then 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 (and the SDL3 framework) 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.

You will then need to '''repeat this process for the SDL3 framework.'''

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

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

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