@@ -290,7 +353,7 @@ Each tilemap block is a 32x32 grid of 16-bit words:
* 32 x 32 = 1,024 entries
* 1,024 x 2 bytes = 2,048 bytes per block
-Each entry is a 16-bit little-endian word with this bitfield layout:
+Each entry is a 16-bit word with this bitfield layout:
Bits | Meaning
---|---
@@ -302,13 +365,48 @@ Bits | Meaning
If you are writing a parser:
-* read 16-bit `w` little-endian
+* read 16-bit `w` from the file
* `tile = w & 0x03FF`
* `pal = (w >> 10) & 0x07`
* `pri = (w >> 13) & 0x01`
* `hflip = (w >> 14) & 0x01`
* `vflip = (w >> 15) & 0x01`
+Endianness note:
+
+* In a ROM or 65c816 runtime context, SNES tilemap words are typically stored little-endian.
+* In the S-CG-CAD `save_scr` path, the tool explicitly byte-swaps each 16-bit word before writing it, and `load_scr` swaps it back after reading. That means S-CG-CAD-authored `.SCR` files are big-endian on disk for the 16-bit tilemap words.
+
+S-CG-CAD also writes a `0x100` metadata header (starting with ASCII `NAK1989 S-CG-CADVer...`) at `0x8000`, followed by a `0x200` trailer region. A few header bytes appear to mirror editor state:
+
+Offset (from 0x8000) | Size | Meaning | Notes
+---|---:|---|---
+`0x40` | `1` | `scbank` bit depth mode | Selects how the screen tool interprets tile graphics and pixel indices in its internal preview buffer. In the traced paths: `0` behaves like 2bpp (pixel indices `0-3` plus a per-tile 3-bit prefix), `1` behaves like 4bpp (pixel indices `0-15` plus a per-tile 3-bit prefix), and `2` behaves like 8bpp (raw `0-255` pixel indices).
+`0x41` | `1` | unknown SCR mode byte (2-bit) | A small per-screen mode field used by the CAD tool. The exact meaning has not been traced yet, but the value is preserved on load/save.
+`0x42` | `1` | screen tile size mode | Controls how the CAD tool composes tiles for preview and stamping. In the traced behavior, `0` acts like 8x8 and `2` acts like 16x16 (composed from 4 tiles: `tile`, `tile+1`, `tile+0x10`, `tile+0x11`).
+`0x43` | `1` | referenced CGX bank (2-bit) | Which of the CAD tool's CGX banks this screen uses when previewing tiles (0-3).
+`0x44` | `1` | screen colormap bank index | A small selector used by the CAD tool's preview colormap (0-3).
+`0x45` | `1` | screen color selector byte | Additional CAD preview color selector byte (interpretation depends on `scbank`).
+`0x46` | `1` | screen color selector byte | Additional CAD preview color selector byte (interpretation depends on `scbank`).
+`0x47..0x48` | `2` | stamp base tile index (16-bit) | Base tile index used by the CAD tool when stamping tiles into the screen, and displayed in the UI as a 3-nibble hex value like `ABC`.
+
+Trailer region note:
+
+* In `save_scr`, the trailing `0x200` bytes are written as `0xFF` fill.
+* In `load_scr`, the tool reads the `0x200` bytes (four `0x80` chunks) but does not appear to interpret them in the traced code paths.
+
+### Toolchain conversion
+Some pipelines include small conversion utilities that export a CAD-authored `.SCR` into a simpler table for PC-side tooling.
+
+One example is `stdscr.c` (header: "NEWS-CAD (SCR_File) -> STD_SCR (*.STD)", MS-DOS ver 1.11, 1992-04-13). It reads `base.SCR` as 4 blocks of `0x400` entries, but for each entry it takes one byte and discards the next byte, which effectively strips the upper byte of the 16-bit tilemap word (the byte that carries most attribute bits) and keeps the low byte.
+
+It then repacks the four 32x32 blocks into a single `0x1000` byte output called `base.STD`:
+
+* blocks 0 and 1 are placed side-by-side to form a 64x32 region (each 32-byte row becomes 64 bytes)
+* blocks 2 and 3 are placed side-by-side to form another 64x32 region below it
+
+In other words, this "MS-DOS screen" is not a DOS graphics format like a VGA framebuffer. It is a raw 4KB 64x64 grid of 8-bit tile indices, intended for quick viewing, printing, or importing into PC-side tools that do not need per-tile SNES attributes.
+
The CAD tool UI shows the same workflow split: screen, object, map, and SFX metadata as separate operations.
@@ -320,6 +418,161 @@ This viewer composes SCR using CGX and COL.
app="/public/js/sandpack/examples/SnesScrViewer.tsx">
+---
+## PNL Format
+PNL is the CAD-side "panel" format: a large tile selection surface used as the source for MAP stamping and MAP-to-SCR conversion.
+
+In the S-CG-CAD toolchain, PNL is stored as a fixed-size container.
+In the NEWS archives, `*.PNL` files are consistently `0x10100` bytes (65,792 bytes).
+
+Range | Size | Meaning
+---|---:|---
+`0x0000` to `0x00FF` | `0x100` | header (CAD provenance + editor state)
+`0x0100` to `0x80FF` | `0x8000` | tile table (16-bit words, big-endian)
+`0x8100` to `0x100FF` | `0x8000` | per-tile flag table (16-bit words, big-endian)
+
+This viewer can derive a screen tilemap directly from a `*.MAP` + `*.PNL` pair so you can validate flip, priority, and palette propagation without exporting a `*.SCR` from the original tool.
+
++ This view derives a 64x64 tilemap from a S-CG-CAD MAP (panel coordinates) and PNL (tile + attributes and optional tile id). Add the matching CGX and COL files to render the full + preview. You can load up to four PNL files (bank 0-3); the viewer will select the correct + one using the MAP header panelBank value (or a manual override). You can also optionally + load a SCR to auto-detect the default tile id used when the MAP disables tile-id copying. + This is useful for validating flip, priority, and palette propagation without first exporting + a SCR from the original tool. +
+