Nextgen — eZX improvements to the Spectrum Next compatibility image

The eZX's Next-compatible image runs every piece of ZX Spectrum Next software unchanged, with bit-exact ULA contention, Z80N timing, sprite/layer/audio behaviour, and NextReg semantics. Compatibility comes first and is non-negotiable. Within that constraint, the eZX's more capable substrate (larger FPGA, much more BSRAM, 72-bit DDR3, 16 MB HyperRAM, modern display outputs) makes possible a set of improvements that the real Next can't deliver. None of these change software-visible behaviour at the standard 28 MHz cycle-accurate operating mode — they remove failure modes, raise quality ceilings, and add development capability without altering what running software sees.

The headline CPU improvements (Z80NG architecture, unlocked turbo, hardware debug, performance counters, FPGA-native instruction extensions) are documented separately — see Z80NG. This document covers everything else: chipset bandwidth, display output, sprite engine, memory architecture, storage, audio, and peripherals.

Compatibility commitment

Before listing improvements, the explicit boundary:

• All software-visible NextReg behaviour is preserved. Reads return the same values, writes have the same effects, side effects fire on the same cycles. The single extension is bit 2 of $07 (CPU speed) which is used for Z80NG-only higher clocks; existing Z80N software never sets that bit and never notices.
• All cycle-accurate timing at 28 MHz mode is bit-exact. Including the Next's wait state behaviour (+1 wait state per M1 fetch, +1 per memory read/write), so any timing-critical Next software runs identically.
• All display modes, sprite behaviour, audio paths behave identically. Software that pushes the Next to its sprite/line limits still gets exactly the same sprite-drop pattern at the same column at the standard 28 MHz mode — see Sprites per line, contention-free for the opt-in toggle that removes this constraint
• All Next-side ROMs and ESXDOS / NextZXOS APIs are preserved. ROM-resident routines respond on the same vectors with the same timing
• All peripheral compatibility (Kempston joystick, Multiface, DivIDE/DivMMC, Microdrive emulation, etc.) is preserved
• NextNano upstream is the basis. The Next-compatible image is built from the upstream NextNano FPGA core for everything except the CPU (which is replaced with the Z80NG — see Z80NG § License and origin). The display, audio, sprite, layer, paging, copper, DMA, and peripheral subsystems are NextNano code, used as-is for the initial release, possibly with the BSRAM-allocation patches described below. Future Next-compat releases may introduce eZX-specific improvements to these subsystems (taking advantage of the better hardware substrate), but the initial commitment is to ship NextNano unchanged outside the CPU and BSRAM-replication patches — any modifications are explicit later work, not part of the v1 release

The improvements below are all either strictly invisible to existing software or opt-in via a feature register that defaults to the Next's original behaviour.

Sprites per line, contention-free

The real Spectrum Next's documented sprite budget is roughly 108 sprite-pixels per scanline. Past that, sprites drop at the right edge of the line. The failure mode is highly visible in busy scenes — shoot-em-up bullet hells, dense particle effects, multi-character battles — and Next demos and games work hard to stay under the limit.

The root cause is BSRAM read contention on the real Next's FPGA. Several display-side renderers (ULA pixel + attribute, ULAnext attribute, tilemap, sprites) and the CPU all need to read from a small number of BSRAM blocks during the scanline. The real Next's Xilinx-class FPGA has tight BSRAM budget and the upstream design shares blocks across consumers to fit; when multiple consumers want the same block in the same cycle, one of them has to wait, and at the per-line sprite-fetch deadline the wait shows up as missing sprites.

The eZX has dramatically more BSRAM available — approximately 280 BRAM blocks on the GW5AST-LV138 (the same FPGA the Ant64 uses for FireStorm), versus the upstream Next's tight Xilinx-class allocation. We use that budget to replicate the contended BSRAM blocks 4× and fan writes out to all replicas, so each reader gets a dedicated copy and never contends with another reader.

The replication technique

For any BSRAM block with multiple display-side readers:

                   ┌─────────────┐
                   │             │
CPU/DMA write ────►│  BSRAM-A    │──── Reader 1 (e.g., ULA scanout)
       │           │             │
       │           └─────────────┘
       │           ┌─────────────┐
       │           │             │
       ├──────────►│  BSRAM-B    │──── Reader 2 (e.g., tilemap)
       │           │             │
       │           └─────────────┘
       │           ┌─────────────┐
       │           │             │
       ├──────────►│  BSRAM-C    │──── Reader 3 (e.g., ULA+ palette lookup)
       │           │             │
       │           └─────────────┘
       │           ┌─────────────┐
       │           │             │
       └──────────►│  BSRAM-D    │──── Reader 4 (e.g., ULAnext attribute)
                   │             │
                   └─────────────┘

All four BSRAMs always contain identical data — writes from CPU or DMA are fanned out by the memory controller to write all four in lockstep. Reads from any replica return the same value. The four readers never block each other; 4× the read-port concurrency for the cost of 4× the BSRAM.

Blocks replicated 4× in the eZX Next-compat image

Total replication cost: ~115 KB of BSRAM, which is around 45 BRAM blocks on the GW5AST-LV138.

This was a substantial budget commitment when the eZX previously targeted the smaller GW5AT-60 (where ~45 blocks of replication consumed roughly 40% of the BSRAM budget). On the GW5AST-LV138 the same replication consumes around 13% of the budget, leaving the rest of the Next-compat image with comfortable headroom:

The 4× replication factor is the largest BSRAM line item in the image, but on the GW5AST-LV138 it's affordable with substantial headroom — about two-thirds of the BSRAM budget remains free for future enhancements, larger debug trace rings, more aggressive caching, or additional chipset features. The two scope-adjustment alternatives previously documented (selective replication factors per block, build-time disable flag) remain available if any future image evolution puts pressure on the budget, but they aren't needed for the initial release.

The detailed per-block decision is an implementation detail at chipset bring-up; the architectural commitment is "use BSRAM replication to eliminate contention failure modes" without committing to a specific factor at the spec level. The starting point is 4× on sprite pattern memory and 2× on the other shared blocks, refined upward where profiling shows benefit and the BSRAM budget permits.

Wider sprite fetch pipeline

With sprite pattern memory replicated 4×, the eZX runs four parallel sprite fetchers, each reading from its own BSRAM copy. Per cycle, the engine completes four sprite pattern fetches instead of one — the per-line sprite-pixel budget is roughly 4× the real Next's at the same FPGA fabric clock. The eZX's BSRAM-limited fabric clock (~380 MHz on the GW5AST-LV138) is in the same general range as the real Next's FPGA fabric clock (both are bounded by their respective BSRAM speeds, not by the Z80's 28 MHz user-visible clock — the Z80 clock is the rate at which Z80 cycles retire, not the rate at which the chipset's display and sprite logic actually runs). The real win here is the parallelism from replication, not raw clock speed: where the real Next has one sprite fetcher contending with everything else for shared BSRAM read ports, the eZX has four dedicated fetchers running in parallel against four independent copies of the pattern memory. Dozens of sprites per scanline become routine; the per-line budget is now bounded by the line-buffer write rate, not by BSRAM read contention.

Important: at the standard 28 MHz cycle-accurate operating mode the sprite drops still occur at exactly the column they would on a real Next — this is part of the compatibility commitment. Software that depends on sprite-drop behaviour (some clever demos use it as a horizontal-position indicator) gets the original behaviour.

The contention-free sprite engine is opt-in via a new chipset register (TBD-named, accessed through the NextReg mechanism in an unused register slot) that software can write to enable the enhanced engine. Software that doesn't write to this register gets exactly the Next's behaviour. Software that opts in gets:

• No sprite-drop at line edges
• Effectively unlimited sprite count per line within total-active-sprites budget
• Same per-sprite latency from attribute table update to visible result

This is a meaningful new capability for the eZX as a platform: developers who want to write Next-style games without the sprite-per-line constraint can do so on the eZX, with the same software falling back gracefully to the documented Next limit when run on real hardware.

Display output: 1080p with integer scaling and optional CRT simulation

The real Spectrum Next outputs HDMI at lower resolutions (typically 1280×720@50/60Hz on most variants). The result is visually fine but the underlying scaling on modern 1080p / 4K displays often happens at the display end, with imperfect results. The eZX outputs native 1920×1080@50Hz or 60Hz and performs all scaling internally with integer-only filters, optionally with high-quality CRT simulation overlays.

Internal scaling pipeline

Spectrum content is rendered at its native resolution into a small framebuffer in BSRAM, then scaled to 1080p by the display engine:

The remaining 60 pixels of vertical space (the side bands above/below the 960-pixel content area at 5× ULA scaling) is filled with the current border colour — exactly the same border the Next would have shown around its scanline-by-scanline output, just stretched to fill the full 1080p frame.

Line replication and X-scaling

Anthony's described approach: each native scanline is rendered to the BSRAM line buffer once, then read 4–5 times by the HDMI output stage to produce 4–5 output lines, while horizontally each pixel is replicated 4–5 times across the 1920-pixel output line. The native-resolution data path stays minimal; the scaling cost is just multiple reads from the same line buffer at the output stage.

This is much cheaper than a true 1080p framebuffer (which would need a multi-MB buffer in BSRAM or DDR3) and gives genuinely sharp pixel-perfect output — no smoothing or filtering artefacts, just clean integer-scaled pixels at the native 1080p mode of the display.

Refresh rate fidelity

The eZX outputs at exactly the Spectrum's native refresh rate — 50.080 Hz for the PAL Spectrum (which most Next software targets), 60 Hz for the NTSC variants. 1920×1080@50Hz and 1920×1080@60Hz are both standard HDMI modes; modern displays accept them. Software that depends on exact 50.080 Hz timing (sound chips synced to frame rate, smooth-scrolling demos) sees the same per-frame timing as on a real Next.

Optional CRT simulation

For users who want the original aesthetic, the display engine offers configurable CRT simulation overlays applied during scaling:

• Scanline darkening — every other output scanline darkened by a configurable amount (0–50%), simulating the CRT's beam pattern. Pixel-perfect at integer scaling because the output is integer-aligned to native scanlines
• Soft horizontal blur — optional 1-pixel-wide low-pass filter on the X-scaled output, simulating CRT phosphor bleed
• Border colour treatment — option to render the 60-pixel side bands as a CRT-style fade-to-black rather than solid border colour
• Phosphor decay simulation — frame-blended low-intensity ghosting for high-frame-rate effects

All of these are toggleable per session via AntOS configuration; the default is no simulation (sharp 1080p pixel-perfect output).

Simultaneous RGB output

The eZX board provides both HDMI and analogue RGB outputs (see spec § Display outputs) — both can run simultaneously. The HDMI path serves the modern display; the RGB path drives a CRT in parallel for users who want both at once. The RGB path produces native Spectrum scanline timing without any scaling; the HDMI path produces the upscaled 1080p output. Both fed from the same internal frame data.

Memory architecture wins

The eZX's memory hierarchy is dramatically more capable than the Next's, and the Next-compat image inherits the benefits transparently. The eZX hardware has two configurations (see spec § The two configurations for the full picture):

• Base configuration — 16 MB HyperRAM as system RAM + ROM tier, BSRAM holds the entire video subsystem as master copies, no DDR3 SODIMM. The Next-compat image runs at every clock from cycle-accurate 28 MHz through unlocked turbo (up to 380 MHz) in the base configuration — HyperRAM's 70 ns effective first-byte latency combined with the Z80NG's prefetch buffer + μop cache absorbs the access cost at every speed
• DDR3-equipped configuration — adds a DDR3 SODIMM (72-bit ECC module, 1 / 2 / 4 GB user-addressable data plus 8 metadata bits per word for debugger watch bits and wide-mode extension nibbles, at DDR3-800 / 6.4 GB/s peak user-data bandwidth — the GW5AST-LV138's maximum supported DDR3 data rate). Not needed by the Next-compat image at any speed; on the eZX primary image it's required only for "expanded" titles that use genuine wide-mode CPU features, while "compatibility-mode" titles run without it and automatically speed up when it's fitted — see spec § Compatibility-mode and expanded software

The key win on the eZX vs the real Next: video memory is in BSRAM, system RAM is in HyperRAM (or DDR3 if equipped), and they don't share a pool. On the real Next, video memory and system RAM come from the same 2 MB SRAM pool — software using Layer 2 hi-res (80 KB) loses 80 KB from its system RAM budget. On the eZX, software has its full system RAM budget regardless of which Layer 2 mode is active, and all Layer 2 modes (standard, hi-res, hi-color) can be simultaneously resident in BSRAM since the BSRAM tier is large enough to hold the entire video subsystem at once.

More benefits, briefly (full detail in spec):

• 16 MB HyperRAM vs the real Next's 1–2 MB SRAM — system RAM is plentiful for asset-heavy games, multi-MB save states, large compiled-content workloads in the base configuration; DDR3 SODIMM brings GB-class capacity for the eZX primary image
• HyperRAM as ROM tier — entire ROM library + tape/disk image cache + cartridge library all simultaneously resident
• Bus parallelism — three independent buses (BSRAM, HyperRAM, and optionally DDR3) operate concurrently. ROM fetch, system RAM access, display scanout, and audio DMA never contend
• Instruction prefetch buffer + μop cache make tight Z80 loops free of memory access overhead at the FPGA core clock — see Z80NG § Instruction prefetch buffer and Z80NG § μop cache. Combined with HyperRAM's 70 ns effective first-byte latency, even unlocked-turbo loops execute mostly from BSRAM with negligible HyperRAM stalls

Why HyperRAM is sufficient at every turbo mode

The Z80NG's μop cache and prefetch buffer mean most fetches are window-hits with zero memory access. HyperRAM's 70 ns effective first-byte latency (35 ns intrinsic × 2× from the dual-die fixed-latency mode) fits inside the Z80N's 3-T-state memory cycle at 28 MHz cycle-accurate (107 ns budget) with comfortable margin. At turbo modes the per-miss penalty grows: ~1 T-state at 56 MHz, ~5 T-states at 112 MHz, ~13 T-states at 224 MHz, ~24 T-states at 380 MHz unlocked turbo — but these are paid only on branches outside the prefetch window, and the μop cache filters hot loops entirely off HyperRAM. The Tang Nano 20K empirically runs the upstream NextNano core at full 28 MHz from 32-bit SDRAM at 166 MHz SDR with neither cache nor prefetch buffer — confirmation that this workload class is fundamentally tolerant of DRAM-class memory at the Next's design clock; HyperRAM with the Z80NG's prefetch and μop cache is comfortably more capable.

Software running at any clock on the Next-compatible image is bit-identical and timing-identical between the base and DDR3-equipped configurations — the DDR3 SODIMM is needed only for the eZX primary showcase image, not for any Next-compatible mode.

Storage: instant-access HyperRAM-resident image library

The real Next loads games and assets from SD card; the eZX caches them in 16 MB of HyperRAM at session start, presenting them to NextZXOS as virtual disk / tape / cartridge devices that run at HyperRAM speed (400 MB/s) instead of SD speed (5–20 MB/s).

Concrete improvements

• Instant tape loading — .tap / .tzx / .pzx tape images loaded into HyperRAM at session start. Multi-load games and demos have zero load-time hitching mid-game
• Instant disk side flipping — .dsk images for +3 / +D / DivIDE / DivMMC entirely in HyperRAM. Multi-disk games flip sides in milliseconds
• Instant Interface 2 cartridge swaps — the entire historical Interface 2 cartridge library can sit in HyperRAM. Selecting a different cartridge is a memory-controller remap, not a load
• Game asset preload cache — NextZXOS file I/O still works exactly as before, but cached files in HyperRAM mean assets-heavy games load near-instantly. Demos and multi-level games that took seconds to start now appear in fractions of a second
• DivMMC sector cache — frequently-accessed sectors of mounted SD images are cached in HyperRAM, accelerating mass-storage workloads without changing the cycle-accurate memory model

All of these are invisible to Next software — the SD-loaded files appear at the same addresses with the same APIs; they're just faster. Software that polls real SD speeds (none that we know of, since the speeds vary by SD card anyway) would see no change.

Snapshot / quick-save ring

The eZX's hardware snapshot subsystem freezes the entire simulated-system state (RAM banks + sprite tables + Layer 2 + palette + ULA mode + Z80NG register file + AY state + Copper state) into a HyperRAM slot, and resumes from any slot on demand. At 400 MB/s, even a 1 MB snapshot completes in under 4 ms.

Snapshots are stored in standard Spectrum interchange formats — .sna, .z80, and .szx — so saves taken on the eZX can be loaded into software emulators (Fuse, ZEsarUX, CSpect) and vice versa. The eZX's snapshot ring is preserved across power cycles by staging slots through SD; users can browse, name, tag, and manage their snapshot collection via AntOS.

The slot ring is configurable (default 32 slots). Software running on the Next image is completely unaware of the snapshot system — it's a host-side feature of the eZX, accessible via AntOS hotkeys.

Audio: higher-quality output

The Spectrum Next has multiple AY-3-8912 chips, the SpecDrum 4-channel DAC, the Pi accelerator-routed audio, and stereo output via the analogue jack. Audio quality on the real Next is good but the underlying DAC chain limits it.

The eZX's audio path goes through Pulse (the ESP32-P4 secondary processor with 32 MB PSRAM), which provides:

• Higher sample rate output — Pulse's audio path can run at 48 kHz / 96 kHz / 192 kHz, where the real Next's path is limited by its PWM stages
• Higher bit depth — proper 24-bit DAC output instead of the Next's lower bit depth
• Lower output noise — modern DAC hardware with proper output filtering
• Optional digital effects — Pulse can apply real-time reverb, EQ, and other DSP in software, configurable per session
• HDMI audio embedding — audio mixed into the HDMI stream alongside video, so connecting only an HDMI cable gives full audio without separate jack

The Next-compatible image continues to drive the AY chip emulations and SpecDrum at the exact AY/SpecDrum sample rates Next software expects (1.7 MHz AY clock, etc.). Pulse takes the digital audio and outputs it at higher quality than the Next's analogue chain can. Software-visible behaviour (AY register reads/writes, SpecDrum behaviour) is identical to the real Next.

Debug and development

The eZX Next-compat image's debug subsystem is comprehensively better than anything the real Spectrum Next offers. Full detail in Z80NG § Debug support. The headline capabilities:

• Hardware breakpoints, watchpoints, single-step, register inspection over the DeMon JTAG path
• Full-instruction trace to HyperRAM debug ring — every retired Z80 instruction recorded with PC, opcode, register state, and timestamp. The trace ring covers seconds of execution at full speed; on breakpoint hit the host debugger reads back the trace for full post-mortem reconstruction
• Z80-equivalent T-state counter — measured-not-projected effective frequency reading via memory-mapped or JTAG-accessible counters
• DZRP-compatible debug protocol for integration with DeZog and other existing Z80 / Z80N debugger toolchains

This makes the eZX a more capable Spectrum Next development target than a real Spectrum Next. Some developers will use the eZX as their primary development target even for software intended to ship on real Next hardware.

Performance: turbo mode beyond 28 MHz

The Z80NG's unlocked turbo mode (spectrum-mode next with NextReg $07 = %111) runs at the full 380 MHz FPGA core clock — see Z80NG § Operating modes. The intermediate Z80NG-only speeds (56, 112, 224 MHz) provide a graceful ladder for software that wants more than 28 MHz but with predictable timing.

The Z80NG's cycle count tables and Z80N instruction analysis show concretely how many internal Z80NG cycles each Z80 or Z80N instruction takes (μop cache hit, turbo mode). The empirical effective Z80-equivalent frequency for any workload is measurable via the Z80-equivalent T-state counter — no projections, no marketing claims, just a runtime number that depends on the actual workload.

Peripheral extensions (mostly invisible to Next software)

The eZX board's peripheral set is broader than the Next's — four DE-9 joystick ports via Sticky (the Spectrum Next has two), USB host via DeMon, WiFi 2.4/5 GHz and Bluetooth via DeMon's ESP32-C5, and DeMon's own network stack (SD card, USB mass storage, telnet/FTP). The Next-compatible image presents to Next software exactly the peripheral set the Next has (Kempston, Sinclair joystick protocol, etc.); the additional eZX peripherals are accessible via AntOS APIs and don't intrude on Next-side software.

Notable: physical joystick adapter compatibility — the eZX's full 4-port Sticky chipset adapts modern USB controllers, Bluetooth gamepads, etc. into Kempston-protocol signals that the Next-compat image presents to software. Modern controllers work with Next software without any software-side awareness, and the extra two physical ports beyond the Next's complement give multiplayer-friendly Next software (Next Sabreman Generations and similar) genuinely-wired multiplayer rather than depending on USB hub aggregation.

What stays the same — the compatibility ledger

To summarise the boundary clearly, here's what the eZX Next-compatible image does not change from a real Spectrum Next:

Everything that any Next software examines reads the same as on a real Next. Everything that any Next software measures by timing reads the same as on a real Next at 28 MHz mode. Improvements appear only as faster boot, faster load, better visible output quality, more debug capability, and access to higher CPU clocks (which Z80N software never asks for and so doesn't get).

Document references

• Z80NG — the clean-room Z80N-compatible CPU, the source of the CPU-side improvements
• spec — eZX hardware spec; the memory hierarchy, FPGA, displays, and peripheral set that the Next-compat image builds on
• eZX — the eZX primary image's chipset (some of the Next-compat image's chipset enhancements share design patterns)

Future ideas

Possibilities not yet committed but worth recording:

• 4K output mode — 3840×2160 at 8× integer ULA scale (2048×1536 with bars). The FPGA's display path can do this if HDMI 2.0 transmission is wired; the rest is just timing
• Variable refresh rate — output to VRR-capable displays at the Spectrum's native ~50.080 Hz with no frame interpolation
• Per-pixel post-processing — bloom, glow, custom shader-style effects on the upscaled output
• Network play — modern multiplayer over WiFi for Spectrum games written with networking in mind (probably nothing existing, but the capability is there for new software)
• Hardware sprite collision detection extension — adds collision-detection register to the chipset that Next-software can opt into; not a feature on real Next hardware
• Multi-image cross-execution — switch from Next-compat to eZX primary mid-game with HyperRAM-resident state, for software that uses both paradigms
• MIDI output / input for music-software workflows
• Higher-resolution Layer 2 — Layer 2 at 1280×1024 native (not upscaled) for new software written for the eZX. Existing Layer 2 software gets the upscaled 320×256 / 640×256 modes unchanged

These are out of scope for the initial Next-compatible image release. The first release targets the BSRAM replication, 1080p output, HyperRAM ROM tier, debug subsystem, and turbo mode — substantial improvements but with a tractable implementation path.