Skip to content

Nexus Saturn Hardware

Jump to bottom
Daniel Nylander edited this page Aug 26, 2026 · 3 revisions

Nexus Saturn Hardware

Preservation-grade analysis of the Sega Saturn hardware as it relates to Dungeon Master Nexus. This page documents the Saturn subsystems that Nexus uses and how Firestaff models them. Based on parity evidence pass 216.

Saturn System Overview

The Sega Saturn is a multi-processor console with dedicated hardware for 2D/3D graphics, sound, and I/O:

Component Chip Clock Role
Master CPU Hitachi SH-2 (SH7604) 28.6 MHz Main game logic
Slave CPU Hitachi SH-2 (SH7604) 28.6 MHz Secondary processing
VDP1 Sega 315-5688 28.6 MHz Sprite/polygon rendering
VDP2 Sega 315-5690 28.6 MHz Background/scroll planes
SCSP Yamaha YMF292 22.6 MHz Sound processor
SCU Sega 315-5689 14.3 MHz System control, DMA, DSP
SH-1 Hitachi SH-1 20 MHz CD-ROM controller
SMPC Sega 315-5744 4 MHz System manager, I/O

Controller-delivery receipt

Nexus uses the SMPC output-register protocol for the Saturn digital pad. A requested host-side input mask is not itself evidence that the game received it: the producer must apply it before Mednafen's original gamepad sampling and the resulting SMPC read must change in the same frame.

In the bounded Japanese retail-disc run, a START window at frames 1800--1803 changed the observed SMPC return stream at master-SH-2 PCs 0x0601456e, 0x06014584, 0x06014596, and 0x060145b2. Those PCs are inside the hash-verified DM.BIN load range. This is a narrow delivery receipt only; it does not identify a menu action, save selection, title composition, or a rendering route in Firestaff.

The reproducible development producer is version-locked to Mednafen 1.32.1: mednafen_1.32.1_nexus_smpc_read_trace.patch emits a bounded, operator-owned text trace through FIRESTAFF_NEXUS_TRACE_SMPC_READS, with the frame, output register, value, and both SH-2 PCs. It neither extracts media nor ships with or is required by the Firestaff runtime.

VDP1 -- Sprite and Polygon Processor

VDP1 handles all foreground rendering in Nexus: creatures, items, UI elements, and textured viewport objects.

Command Table Format

VDP1 processes drawing commands from a command table in VRAM. Each command is 32 bytes:

Offset Size Field
0x00 2 Control word (command type, link mode)
0x02 2 Link address
0x04 2 Draw mode (color mode, mesh, shadow, etc.)
0x06 2 Color / palette code
0x08 2 Source address (character pattern in VRAM)
0x0A 2 Character size (width/height)
0x0C 4 Vertex A (X, Y)
0x10 4 Vertex B (X, Y)
0x14 4 Vertex C (X, Y)
0x18 4 Vertex D (X, Y)
0x1C 2 Gouraud shading table address
0x1E 2 Reserved

Command types used by Nexus:

Type Code Description
Normal sprite 0x0 Axis-aligned sprite drawn from VRAM pattern
Scaled sprite 0x1 Sprite with hardware scaling
Distorted sprite 0x2 Four-vertex quad with arbitrary corners
Polygon 0x4 Flat-shaded or Gouraud-shaded quad
System clipping 0x9 Set clipping rectangle
Local coordinate 0xA Set coordinate origin

Color Modes

VDP1 supports multiple color depths per command:

Mode Bits/pixel Colors Palette
0 4 16 CRAM lookup
1 8 256 CRAM lookup
2 8 64 + special CRAM with priority/CC
3 15 32768 RGB direct
4 15 32768 RGB direct

Nexus primarily uses mode 0 (16-color paletted) and mode 1 (256-color paletted) for sprites, with CRAM palette references.

VDP1 VRAM Layout

VDP1 has 512 KB of dedicated VRAM:

  • Command table: starts at offset 0x000000.
  • Character patterns (sprite data): packed after the command table.
  • Gouraud shading tables: 8 bytes per table entry.
  • Framebuffers: two 512x256 or 352x240 framebuffers for double buffering.

VDP2 -- Background Processor

VDP2 handles background rendering in Nexus: dungeon walls, floors, ceilings, sky, and status bar backgrounds.

Scroll Planes

VDP2 provides up to 5 scroll planes:

Plane Name Capabilities
NBG0 Normal BG 0 Scroll, cell/bitmap, rotation
NBG1 Normal BG 1 Scroll, cell/bitmap, rotation
NBG2 Normal BG 2 Scroll, cell mode only
NBG3 Normal BG 3 Scroll, cell mode only
RBG0 Rotation BG 0 Full rotation/scaling

Nexus uses the scroll planes for:

  • Dungeon viewport background layers.
  • HUD and status bar overlays.
  • Title screen and menu backgrounds.

VDP2 Registers

Key VDP2 registers relevant to Nexus rendering:

Register Address Description
TVMD 0x25F80000 TV mode (resolution, interlace)
BGON 0x25F80020 Background enable flags
CHCTLA/B 0x25F80028/2A Character control (tile size, color depth)
PLSZ 0x25F8003E Plane size (1x1, 2x1, 2x2 pages)
MPOFN/R 0x25F80040+ Map offset registers
SCXIN/SCYIN 0x25F80070+ Scroll position registers
ZMXN/ZMYN 0x25F80078+ Zoom registers
PRISA-D 0x25F800F0+ Priority registers per plane
CCRSA-D 0x25F800F8+ Color calculation ratio per plane

CRAM -- Color RAM

The Saturn's CRAM holds all palette data shared between VDP1 and VDP2:

  • Size: 4 KB (2048 colors in 15-bit RGB mode).
  • Organization: 256 palettes of 16 colors each (mode 0), or 8 palettes of 256 colors (mode 1), or 2048 direct entries (mode 2).
  • Address range: 0x25F00000 to 0x25F00FFF.
  • Color format: 15-bit RGB (5 bits per channel, MSB ignored or used as priority/transparency).

Nexus uses CRAM mode 0 (16-color palettes) for most sprites and backgrounds, with palette swaps used to vary creature and item colors.

SCSP -- Sound Processor

The SCSP (Saturn Custom Sound Processor) is a Yamaha YMF292 that handles all Nexus audio:

Capabilities

  • 32 channels of PCM or FM synthesis.
  • 16-bit PCM playback at up to 44.1 kHz.
  • 8-bit or 16-bit sample data.
  • ADPCM (4-bit compressed) sample support.
  • Hardware DSP with 16 effect slots (reverb, chorus, delay).
  • 512 KB dedicated sound RAM.
  • Independent from the main SH-2 CPUs (runs on its own 68000 or DSP).

SCSP Register Map

Register Offset Description
SA 0x00 Sample start address
LSA 0x04 Loop start address
LEA 0x06 Loop end address
D2R/D1R/AR 0x08 Envelope rates
KRS/DL/RR 0x0A Key rate scaling, decay level, release rate
STWINH 0x0C Stack write inhibit
TL 0x0E Total level (volume)
OCT/FNS 0x10 Octave and frequency number
LFOF/PLFOWS 0x12 LFO frequency and waveform
ISEL/IMXL 0x14 Input select and mix level
DISDL/DIPAN 0x16 Direct send level and pan
EFSDL/EFPAN 0x18 Effect send level and pan

Sound Driver (SDDRVS.TSK)

Nexus uses a sound driver task (SDDRVS.TSK) that runs on the SCSP's embedded 68EC000 processor:

  • The driver receives commands from the SH-2 via shared sound RAM.
  • It manages channel allocation, sample playback, and envelope control.
  • The SAL (Sound Abstraction Layer) provides the software interface between game logic and the SCSP hardware.
  • MAP files define instrument and sample mappings.

IWA Source Modules

Analysis of the Nexus binary reveals IWA-prefixed source module identifiers. These represent the original source code organization:

  • IWA modules contain game logic, rendering code, and data management.
  • Module boundaries are visible in the binary's symbol table and string references.
  • Firestaff uses these module boundaries to organize its Nexus implementation.

ITEM.IBS Field Analysis

The ITEM.IBS (Item Binary Store) file contains the complete item database for Nexus:

Field Size Description
Item type 2 bytes Type identifier (weapon, armor, scroll, etc.)
Properties 2 bytes Bitfield of item properties
Weight 2 bytes Item weight in game units
Sprite index 2 bytes Reference to VDP1 sprite data
Attack/Defense 2 bytes Combat statistics
Special 2 bytes Special properties (magic, quest flags)
Name offset 2 bytes Offset into string table

Item types follow a classification system similar to DM1 "things" but with Saturn-specific extensions for 3D rendering attributes and palette references.

SMAP and FACE Textures

  • SMAP: Surface map textures used for dungeon walls, floors, and ceilings. Stored as paletted pixel data with CRAM palette references.
  • FACE: Face/portrait textures for creatures and champions. Similar format to SMAP but sized for the portrait display area.

Both formats use Saturn-native pixel layouts compatible with VDP1 character patterns or VDP2 cell data.

Firestaff Modeling Approach

Firestaff models the Saturn hardware at the data and behavioral level, not at the cycle-accurate hardware level:

  • VDP1 command tables are parsed to understand draw order and sprite placement.
  • VDP2 scroll plane configurations are decoded to reproduce background layouts.
  • CRAM palettes are converted to SDL3-compatible RGBA values.
  • SCSP audio data is decoded and played through the SDL3 audio backend.
  • The goal is faithful visual and behavioral reproduction, not hardware emulation.

See Also

Clone this wiki locally