MSX Art Examples and Visual Constraints

 # MSX Art Examples and Visual Constraints

## Executive summary

MSX “typicality” in graphics is less about any single palette and more about **a specific set of hardware-era constraints that shape composition**: the **TMS9918A “Graphics II / MSX SCREEN 2”** character-pattern system (256×192 active pixels, 32×24 tiles) with **two colours per 8×1 pixel line**, hardware sprites with strict per-scanline limits (notably **4 sprites per horizontal line**), and an output chain that often ends in **analogue video softness** (blur/bleed) rather than perfect pixels. citeturn39view2turn41view0turn42view0

Across commercial games, demoscene productions, and modern “retro-native” works (MSXdev/homebrew and fan pixel art), recurring visual strategies emerge: **bold silhouettes and outlining**, **dithering and patterning to imply extra colours/materials**, **carefully managed colour boundaries aligned to the 8×1 attribute granularity**, and **sprite layering that either embraces or works around the 4-sprites-per-line rule** (often via selective flicker or design for readability). citeturn41view0turn39view2turn34view0

For reproduction in modern engines, the most convincing results come from treating “MSX look” as a **pipeline**: (a) enforce **layout constraints** (SCREEN 2 attribute rules, sprite limits), (b) adopt a **VDP-appropriate palette model** (including the fact that TMS9918A colour is specified in luminance/chrominance terms), and (c) reintroduce **display characteristics** (gamma, scanlines, controlled blur/bleed, mild glow) with a shader chain. citeturn41view1turn44view1turn53search0turn53search9turn53search2

Notable uncertainties remain: **palettes vary across emulators and real machines**, some behaviours differ by VDP vendor/revision (e.g., Toshiba MSX1 VDP edge cases), and many online screenshots are emulator-captured (lossy scaling, post-filters, or compression), complicating “ground truth” comparison. citeturn46view1turn44view1turn41view1

## What makes art MSX-typical

This report uses “MSX-typical” to mean **art that is recognisably shaped by MSX display semantics**, particularly:

- **MSX1 / SCREEN 2 (TMS9918A Graphics II)**: the screen is a mosaic of 8×8 character patterns; **each 8×8 is controlled line-by-line**, where the colour table sets **foreground/background for each 1×8 line** (the core “two colours per 8×1 strip” rule). citeturn39view2turn42view0  

- **Sprite-centric composition**: multiple display “planes” and strict sprite rules affect animation and layering; critically, the VDP limit of **4 active sprites per horizontal line**, with excess sprites becoming transparent, becomes an artistic constraint designers must accommodate. citeturn41view0turn40view2  

- **Composite-era colour thinking**: the TMS9918A colour assignments are specified via luminance (DC) and chrominance (AC) values, which contributes to variation when mapped to modern RGB and when viewed through different video connections. citeturn41view1turn41view0  

Primary/official technical foundations referenced include original VDP documentation from entity["company","Texas Instruments","semiconductor company"] and entity["company","Yamaha","japanese electronics company"], MSX specification texts produced under entity["company","ASCII Corporation","japan publisher"] / entity["company","Microsoft","software company"], and the MSX2 VDP handbook materials. citeturn41view0turn43view0turn46view0turn51search11turn51search5

For screenshots/metadata and modern community examples, the corpus leans on entity["organization","MobyGames","video game database"], entity["organization","PixelJoint","pixel art community site"], entity["organization","Pouët.net","demoscene database"], entity["organization","Demozoo","demoscene database"], entity["organization","MSXdev Contest","homebrew msx contest"], entity["organization","itch.io","indie game distribution site"] and comparative commentary from entity["organization","Retronauts","retro gaming publication"]. citeturn51search0turn34view0turn28view0turn32view0turn25view0turn37view0turn48view0

Key commercial-era studios in the representative set include entity["company","Konami","video game company japan"], entity["company","Compile","japanese game developer"], entity["company","HAL Laboratory","video game company japan"] and entity["company","Game Arts","video game company japan"], with a broader “Japanese microcomputer” context touched via entity["company","Bothtec","software company japan"]. citeturn49search2turn49search3turn18search5turn52search12turn7search16

Fan and modern-tradition items were chosen from PixelJoint artists entity["people","Mermaid","pixeljoint artist"] and entity["people","Shiru","pixeljoint artist"], plus MSXdev/indie creators including entity["people","Jacco Bikker","msxdev developer"], entity["people","Casper Croes","msxdev developer"], entity["people","bosh77","msxdev developer"], and entity["people","theNestruo","indie msx developer"]. citeturn34view0turn34view2turn25view0turn25view2turn22view0turn37view0

```mermaid

timeline

  title MSX art evolution (constraints → aesthetics → revival)

  1983 : MSX standard introduced; MSX1 baseline (TMS9918A / SCREEN 2 culture)

  1985 : MSX2 developed; V9938 enables higher resolutions + programmable palette

  1992 : MSX2 demoscene consolidates showcase aesthetics (e.g., megademos)

  2003 : Anniversary-era demos revive and document MSX2 capabilities

  2009 : “Oldschool platform” demos push MSX1/MSX2 presentation and sync

  2020 : Modern MSX-native releases + palette-switching “authenticity” options

  2023 : MSXdev and size-coded intros demonstrate ongoing technical play

  2025 : Continued MSXdev production with MSX2 visuals and tooling maturity

```

This sequence is anchored in the V9938 programmer manuals’ historical framing (MSX introduced in 1983; MSX2 developed in 1985) and in dated demoscene/homebrew release records. citeturn51search11turn28view0turn28view2turn30view0turn32view0turn37view0turn22view0turn25view0

## Representative MSX art corpus

image_group{"layout":"carousel","aspect_ratio":"16:9","query":["MSX Knightmare screenshot","MSX Metal Gear 1987 screenshot","MSX2 Snatcher screenshot","MSX demo Megademo 1 screenshot"],"num_per_query":1}

### Comparative table of games and artworks with attributes

The table below is a **curated reference set** (not exhaustive) intended to span: commercial MSX1/MSX2, demoscene, and modern/fan “MSX-style” work. Where “MSX-typical” is interpretive, it is grounded in the SCREEN 2 / VDP constraints described in the technical sections and supported by the linked visual evidence. citeturn41view0turn39view2turn43view0

| Item | Year | Creator | Short description | Why it’s MSX-typical | Source link | Image / screenshot URL |

|---|---:|---|---|---|---|---|

| entity["video_game","Antarctic Adventure","MSX 1983"] | 1983 | Konami | Early iconic MSX-era action/arcade presentation. citeturn8search23 | SCREEN 2-era tile/sprite grammar; bold colour blocks suit 8×1 attribute constraints. citeturn41view0turn39view2turn8search5 | `https://www.mobygames.com/game/11543/antarctic-adventure/` citeturn8search23 | `https://www.mobygames.com/game/11543/antarctic-adventure/screenshots/msx/132921/` citeturn8search5 |

| entity["video_game","Road Fighter","MSX 1984"] | 1984 | Konami | Racer/score-attack visuals with strong lane/road patterning. citeturn13search4 | Straight edges and repeating tiles read cleanly under character-pattern rendering. citeturn13search8turn39view2 | `https://www.mobygames.com/game/5570/road-fighter/` citeturn13search4 | `https://www.mobygames.com/game/5570/road-fighter/screenshots/msx/148882/` citeturn13search8 |

| entity["video_game","Eggerland Mystery","MSX 1985"] | 1985 | HAL Laboratory | Puzzle-room graphics emphasising legibility and iconography. citeturn49search3 | Clean sprite silhouettes and two-colour-per-strip-friendly tile design. citeturn15search3turn41view0turn39view2 | `https://www.mobygames.com/game/19596/eggerland-mystery/` citeturn49search3 | `https://www.mobygames.com/game/19596/eggerland-mystery/screenshots/msx/131468/` citeturn15search3 |

| entity["video_game","King's Valley","MSX 1985"] | 1985 | Konami | Puzzle-platformer with readable tile motifs and controlled colour regions. citeturn12search5 | Typical MSX “tile mosaic” look; designs often align colour boundaries to attribute rows. citeturn12search1turn39view2 | `https://www.mobygames.com/game/7057/kings-valley/` citeturn12search5 | `https://www.mobygames.com/game/7057/kings-valley/screenshots/msx/141331/` citeturn12search1 |

| entity["video_game","Yie Ar Kung-Fu","MSX 1985"] | 1985 | Konami | Fighting silhouettes with backgrounds built from strong blocks/stripes. citeturn12search18 | Character readability prioritised; background colour strips fit SCREEN 2’s line-wise attributes. citeturn12search2turn39view2 | `https://www.mobygames.com/game/10112/yie-ar-kung-fu/` citeturn12search18 | `https://www.mobygames.com/game/10112/yie-ar-kung-fu/screenshots/msx/718168/` citeturn12search2 |

| entity["video_game","Gradius","MSX 1985"] | 1985 | Konami | Signature scrolling shooter composition and HUD. citeturn52search9 | MSX port aesthetics: tile-derived backgrounds + sprite enemies; colour handling shaped by SCREEN 2 granularity. citeturn52search1turn41view0turn39view2 | `https://www.mobygames.com/game/4512/gradius/` citeturn52search9 | `https://www.mobygames.com/game/msx/gradius/screenshots/gameShotId,129789/` citeturn52search1 |

| entity["video_game","Thexder","MSX 1986"] | 1986 (MSX) | Game Arts | Maze/action-shooter imagery with dense mechanical tiling. citeturn7search16 | Shows “character-oriented” pattern plane look and 256×192 framing typical of MSX1 art. citeturn52search6turn41view0 | `https://www.mobygames.com/game/49/thexder/` citeturn7search16 | `https://www.mobygames.com/game/49/thexder/screenshots/msx/123575/` citeturn52search6 |

| entity["video_game","Knightmare","MSX 1986"] | 1986 | Konami | Vertical action-shooter with mythic motifs and rich sprite layering. citeturn52search12 | MSX-familiar mix of sprite planes + background patterns; boss readability under sprite-per-line constraints. citeturn52search0turn41view0turn39view2 | `https://www.mobygames.com/game/6543/knightmare/` citeturn52search12 | `https://www.mobygames.com/game/6543/knightmare/screenshots/msx/138945/` citeturn52search0 |

| entity["video_game","Penguin Adventure","MSX 1986"] | 1986 | Konami | Fast platforming with colourful, high-contrast scenery. citeturn12search16 | “Konami MSX” style: patterned backdrops + strong sprite silhouettes to survive blur/bleed and colour limits. citeturn12search0turn41view0turn39view2 | `https://www.mobygames.com/game/10272/penguin-adventure/` citeturn12search16 | `https://www.mobygames.com/game/10272/penguin-adventure/screenshots/msx/129844/` citeturn12search0 |

| entity["video_game","Relics","MSX 1986"] | 1986 | Bothtec | Moodier action visuals in the Japanese microcomputer style. citeturn49search2 | An example of how SCREEN 2 constraints can support densely patterned atmospherics via dithering/texture blocks. citeturn15search2turn41view0turn39view2 | `https://www.mobygames.com/game/114075/relics/` citeturn49search2 | `https://www.mobygames.com/game/114075/relics/screenshots/msx/950256/` citeturn15search2 |

| entity["video_game","Zanac EX","MSX 1987"] | 1987 | Compile | Vertical shooter with “Compile” density and clear bullet/enemy separation. citeturn18search5 | Strong example of using tiles + sprites efficiently; boss forms composed to remain legible with sprite limits. citeturn18search2turn41view0 | `https://www.mobygames.com/game/19518/zanac-ex/` citeturn18search5 | `https://www.mobygames.com/game/19518/zanac-ex/screenshots/msx/130626/` citeturn18search2 |

| entity["video_game","Nemesis 2","MSX 1987"] | 1987 | Konami | Advanced shooter art direction and enemy variety. citeturn14search9 | Demonstrates typical MSX “busy but readable” look: repeated patterns + sprite enemies atop. citeturn14search2turn41view0turn39view2 | `https://www.mobygames.com/game/19553/nemesis-2/` citeturn14search9 | `https://www.mobygames.com/game/19553/nemesis-2/screenshots/msx/130933/` citeturn14search2 |

| entity["video_game","The Maze of Galious","MSX 1987"] | 1987 | Konami | Adventure/platform hybrid with strong iconography and tile motifs. citeturn3search6 | Uses bold outlines and readable objects consistent with colour-attribute constraints and sprite layering. citeturn3search5turn41view0turn39view2 | `https://www.mobygames.com/game/19122/the-maze-of-galious/` citeturn3search6 | `https://www.mobygames.com/game/19122/the-maze-of-galious/screenshots/msx/130402/` citeturn3search5 |

| entity["video_game","Metal Gear","MSX 1987"] | 1987 | Konami | Stealth/action with crisp UI and contrast-led scene readability. citeturn0search7 | Uses high-contrast tile fields and sprite silhouettes; works within “character-oriented” graphics constraints. citeturn0search8turn41view0turn39view2 | `https://www.mobygames.com/game/10431/metal-gear/` citeturn0search7 | `https://www.mobygames.com/game/10431/metal-gear/screenshots/msx/115481/` citeturn0search8 |

| entity["video_game","Nemesis 3","MSX 1988"] | 1988 | Konami | Late-era MSX shooter polish and effects. citeturn13search9 | Exemplifies MSX1 “maximal” art within SCREEN 2; some effects differ on MSX2 hardware (compatibility quirks noted by the community). citeturn13search0turn16search1turn41view0 | `https://www.mobygames.com/game/19554/nemesis-3-the-eve-of-destruction/` citeturn13search9 | `https://www.mobygames.com/game/19554/nemesis-3-the-eve-of-destruction/screenshots/msx/150889/` citeturn13search0 |

| entity["video_game","Snatcher","MSX 1988"] | 1988 | Konami | MSX2 adventure visuals with richer presentation and resolution on other platforms. citeturn17search1 | Useful for cross-platform comparison: MSX vs PC-88 screenshots show different “computer-native” aesthetics. citeturn17search5turn17search9turn48view0turn43view0 | `https://www.mobygames.com/game/7524/snatcher/` citeturn17search1 | `https://www.mobygames.com/game/7524/snatcher/screenshots/msx/120159/` citeturn17search5 |

| entity["video_game","Aleste 2","MSX 1989"] | 1989 | Compile | Dense shooter visual language including large bosses and power-up readability. citeturn18search14 | Demonstrates how MSX-era shooters balance clutter vs readability under sprite limits and palette constraints. citeturn17search16turn41view0 | `https://www.mobygames.com/game/19701/aleste-2/` citeturn18search14 | `https://www.mobygames.com/game/19701/aleste-2/screenshots/msx/132717/` citeturn17search16 |

| entity["video_game","Space Manbow","MSX2 1990"] | 1990 (MobyGames) | Konami | MSX2 shooter often cited for high technical finish. citeturn17search11 | Strong case for MSX2-era colour/presentation; note year ambiguity across secondary sources. citeturn17search11turn17search15turn43view0 | `https://www.mobygames.com/game/19512/space-manbow/` citeturn17search11 | `https://www.mobygames.com/game/19512/space-manbow/screenshots/msx/130170/` citeturn17search7 |

| entity["video_game","SD Snatcher","MSX 1990"] | 1990 | Konami | Late MSX2 title with illustrated UI/portraits and battle scenes. citeturn14search10 | Represents MSX2 palette/control improvements while still living in tile/sprite + CRT display culture. citeturn14search0turn43view0 | `https://www.mobygames.com/game/18597/sd-snatcher/` citeturn14search3 | `https://www.mobygames.com/game/18597/sd-snatcher/screenshots/msx/480884/` citeturn14search0 |

| entity["video_game","Metal Gear 2: Solid Snake","MSX2 1990"] | 1990 | Konami | High-composition stealth scenes and UI. citeturn13search11 | MSX2-era visual density + readability; good reference for “how far tile/sprite thinking can go”. citeturn13search2turn43view0 | `https://www.mobygames.com/game/10432/metal-gear-2-solid-snake/` citeturn13search11 | `https://www.mobygames.com/game/10432/metal-gear-2-solid-snake/screenshots/msx/115503/` citeturn13search2 |

| Megademo 1 (demo) | 1992 | Royal MSX Force | Multi-part demoscene showcase with multiple effects on MSX2. citeturn28view0 | Shows raster/colour effects and presentation that depend on VDP timing and MSX2 features. citeturn28view0turn43view0 | `https://www.pouet.net/prod.php?which=50381` citeturn28view0 | `https://content.pouet.net/files/screenshots/00050/00050381.png` citeturn29view0 |

| MSX 20th Anniversary (demo) | 2003 | Abyss Productions | Anniversary-era effects compilation for MSX2. citeturn28view2 | Demonstrates the “scene” aesthetic: bold typography, effect blocks, and timing-led composition. citeturn28view2turn43view0 | `https://www.pouet.net/prod.php?which=50377` citeturn28view2 | `https://content.pouet.net/files/screenshots/00050/00050377.png` citeturn29view1 |

| Bold (demo) | 2009 | Dvik & Joyrex | Highly regarded MSX demo with strong art direction. citeturn30view0 | Visually cohesive design built around MSX limitations and display expectations (glow/blur implied). citeturn30view0turn41view0 | `https://www.pouet.net/prod.php?which=54051` citeturn30view0 | `https://content.pouet.net/files/screenshots/00054/00054051.jpg` citeturn31view0 |

| MSX (256b intro) | 2023 | ESP Soft | Size-coding style production; screenful is part of the “proof of craft.” citeturn32view0 | Shows contemporary engagement with MSX constraints and raster timing, even in minimalist forms. citeturn32view0turn41view0 | `https://demozoo.org/productions/327887/` citeturn32view0 | `https://media.demozoo.org/screens/o/b4/a7/908f.331242.jpg` citeturn33view0 |

| MSX forest (fan pixel art) | 2014 (drawn) / 2016 (posted) | Mermaid | Landscape piece explicitly designed for MSX1 restrictions. citeturn34view0 | Artist states fixed palette + 256×192 + 2 colours per 8×1 block; textures are achieved via patterning. citeturn34view0turn39view2turn41view0 | `https://pixeljoint.com/pixelart/102067.htm` citeturn34view0 | `https://pixeljoint.com/files/icons/full/msx1g.png` citeturn35view0 |

| MSX Tetris mockup (fan pixel art) | 2008 (posted) | Shiru | Mock UI exploring SCREEN 2 limitations and sprite “third colour” hacks. citeturn34view2 | The piece explicitly discusses two colours per 8×1 strip and using sprites for extra colour. citeturn34view2turn41view0turn39view2 | `https://pixeljoint.com/pixelart/37468.htm` citeturn34view2 | `https://pixeljoint.com/files/icons/full/hzzz.png` citeturn35view2 |

| Eggy’s Maze (MSXdev) | 2023 | MSXdev Team / Jacco Bikker | Modern MSX2 puzzle title; strong tile readability and scrolling playfield. citeturn25view0 | MSX2-native but deliberately “MSX-feeling” tilework and palette; MSX2-specific features noted. citeturn25view0turn27view2turn43view0 | `https://www.msxdev.org/2023/08/30/msxdev23-15-eggys-maze/` citeturn25view0 | `https://www.msxdev.org/wp-content/uploads/2023/08/MSXdev23_EggysMaze_v1.0.0002.png` citeturn27view2 |

| Phenix Corrupta (MSXdev) | 2023 | MSXdev Team / Casper Croes | Modern MSX2 action-adventure with striking title artwork. citeturn25view2 | Shows modern mastery of MSX2 palette/sprite presentation while keeping retro readability. citeturn25view2turn27view3turn43view0 | `https://www.msxdev.org/2023/10/16/msxdev23-27-phenix-corrupta/` citeturn25view2 | `https://www.msxdev.org/wp-content/uploads/2023/10/MSXdev23_PhenixCorrupta_v1.0_000.png` citeturn27view3 |

| Racing (MSXdev) | 2025 | MSXdev Team / bosh77 | Modern MSX2 racing visuals with clean colour fields and UI. citeturn22view0 | Contemporary demonstration of MSX2 constraints and strengths; screenshots are provided as direct captures. citeturn22view0turn23view2turn43view0 | `https://www.msxdev.org/2025/01/21/msxdev24-24-racing/` citeturn22view0 | `https://www.msxdev.org/wp-content/uploads/2025/01/MSXdev24_Racing_v1.0_0008.png` citeturn23view2 |

| Stevedore (modern MSX release) | 2020 | theNestruo | Modern MSX game with explicit palette selection modes for authenticity. citeturn37view0 | Notably exposes “Default MSX palette (TMS9918 approximate)” vs “Default MSX2 palette (V9938)” selection—an explicit modern framing of MSX look. citeturn37view0turn41view1turn43view0 | `https://thenestruo.itch.io/stevedore` citeturn37view0 | `https://img.itch.zone/aW1nLzQ5OTY1ODgucG5n/original/L9Hu56.png` citeturn38view2 |

## Technical foundations of MSX visuals

### SCREEN 2 and the TMS9918A “Graphics II” attribute model

MSX SCREEN 2 is fundamentally a **character-oriented** graphics system: an on-screen grid of **32×24 pattern positions (8×8 pixels each)** yields the familiar **256×192** active image area. citeturn41view0turn39view2

The crucial artistic constraint is the **colour table granularity**:

- In MSX SCREEN 2, the colour table provides **foreground/background colour for each 1×8 (8 pixels wide, 1 pixel tall) line** of an 8×8 character, i.e., two colours per 8×1 strip. citeturn39view2turn42view0  

- The TMS9918A technical description aligns: “Graphics II” uses a 6144-byte colour table segmented in blocks, with each pattern’s colour information specified per byte/row. citeturn42view0  

This is the mechanical basis for why “MSX-looking” imagery often features: horizontally stable colour regions, dithering placed to respect strip boundaries, and careful avoidance of multi-colour vertical edges that cross many attribute rows unaligned. citeturn39view2turn41view0

### Sprite rules as composition rules

The TMS9918A plane model explicitly treats sprites as separate planes over the pattern plane. citeturn40view2  

A defining constraint is the per-scanline sprite limit:

- “Only four sprites can be active on any horizontal line; additional sprites … will be automatically made transparent for that line.” citeturn41view0  

This limitation shapes typical MSX art decisions: enemy formations are designed not to stack too many sprites at the same Y coordinate; projectiles may be patterned into the background instead of sprites; and flicker, when used, becomes part of the style rather than a pure flaw. citeturn41view0

### Colour as luminance/chrominance

A subtle but important authenticity trap is that TMS9918A colours are not originally defined as modern RGB triples. The TI documentation provides colour assignments in terms of **luminance (DC) and chrominance (AC)**, making exact RGB reproduction dependent on assumptions and measurement. citeturn41view1turn41view0  

This is a major reason why “MSX palettes” differ across emulators, shaders, and scanned screenshots. citeturn41view1turn44view1

### MSX2: V9938 expands the design space

MSX2 adopts the **Yamaha V9938 (MSX-VIDEO)**, developed for MSX2, with the MSX2 standard described as being developed in 1985 to strengthen the original MSX. citeturn51search11turn43view0  

Key MSX2 VDP features for art include:

- **512 colours with a 9-bit palette**, up to **256 colours at once**, higher resolutions, and more sprite capabilities (e.g., more sprites on a horizontal line). citeturn43view0turn51search5  

This changes what “MSX-typical” can mean: MSX2 art can be genuinely more painterly, but *stylistic* MSX-ness often persists through conservative palette choices, tile-like organisation, and readability-first sprite design (a legacy of MSX1 and CRT viewing expectations). citeturn43view0turn37view0

### Core technical sources table

| Technical source | What it covers | Why it matters for art analysis | Source link |

|---|---|---|---|

| TI TMS9918A/TMS9928A/TMS9929A VDP data manual | Display planes, sprite rules, Graphics I/II mapping, colour assignments | Primary basis for SCREEN 2 constraints (8×8 patterns; per-line colour bytes; 4 sprites/line; luma/chroma colour model). citeturn41view0turn42view0turn41view1 | `https://www.cs.columbia.edu/~sedwards/papers/TMS9918.pdf` citeturn40view0 |

| MarMSX “Screen 2 Layout” (English) | Practical SCREEN 2 mapping and “front/back colour per 1×8 line” | Clear, implementation-level explanation of why MSX pixel art has “stripe” constraints. citeturn39view2 | `https://marmsx.msxall.com/artigos/arquitetura_sc2_en.pdf` citeturn39view2 |

| MSX Technical Data Book (scan) | MSX hardware/software specifications | Canonical-era reference context; useful for how MSX was specified and standardised. citeturn46view0 | `https://download.file-hunter.com/Manuals/msx_technical_data_book.pdf` citeturn46view0 |

| V9938 programmer manual framing | MSX introduced 1983; MSX2 developed 1985 | Anchors historical timeline and why MSX2 exists. citeturn51search11 | `https://ia801709.us.archive.org/3/items/tms9918_guide/V9938-programmers-guide%20insecure.pdf` citeturn51search11 |

| V9938 Technical Data Book (Aug 1985) | MSX-VIDEO technical capabilities | Primary MSX2 VDP reference and feature set. citeturn51search5 | `https://www.bitsavers.org/pdf/yamaha/Yamaha_V9938_MSX-Video_Technical_Data_Book_Aug85.pdf` citeturn51search5 |

| MSX2 Technical Handbook (Chapter 4) | V9938 features, palette registers, sprites, scanline interrupts | Practical MSX2 programming model; distinguishes MSX1 vs MSX2 art affordances. citeturn43view0 | `https://konamiman.github.io/MSX2-Technical-Handbook/md/Chapter4a.html` citeturn43view0 |

| openMSX manual (video settings) | Blur, scanlines, gamma, “accuracy” timing | Concrete documentation of what emulators change vs CRT reality and how to approximate. citeturn44view1 | `https://openmsx.org/manual/user.html` citeturn44view1 |

| openMSX issue on Toshiba VDP quirks | VDP-vendor behavioural differences | Evidence that “real hardware” is not uniform, affecting authenticity claims. citeturn46view1 | `https://github.com/openMSX/openMSX/issues/607` citeturn46view1 |

```mermaid

flowchart LR

  VDP[TMS9918A / V9938 VDP] --> ATTR[Attribute granularity<br/>2 colors per 8×1 (SCREEN 2)]

  VDP --> SPR[Sprite system<br/>per-line limits]

  VDP --> PAL[Palette model<br/>luma/chroma (TMS9918A)<br/>9-bit RGB (V9938)]

  VDP --> OUT[Video output chain<br/>RGB/composite → CRT/LCD]

  ATTR --> EFFECT1[Visual effect:<br/>structured banding & tile thinking]

  SPR --> EFFECT2[Visual effect:<br/>flicker / careful vertical spacing]

  PAL --> EFFECT3[Visual effect:<br/>dithered shading & selective saturation]

  OUT --> EFFECT4[Visual effect:<br/>blur/bleed, scanlines, glow]

  EFFECT1 --> ART1[Art outcome:<br/>bold silhouettes, patterns, outlines]

  EFFECT2 --> ART2[Art outcome:<br/>enemy/bullet choreography & readable UI]

  EFFECT3 --> ART3[Art outcome:<br/>texture illusion via dithering]

  EFFECT4 --> ART4[Art outcome:<br/>softened edges; “CRT-authentic” colour feel]

```

The causal links above are supported by the SCREEN 2 colour table model and sprite rules (constraints), plus emulator documentation describing blur/scanlines and timing fidelity (“accuracy”). citeturn41view0turn42view0turn41view1turn44view1turn46view1turn43view0

## Emulator versus real-hardware rendering

### Pixel-perfect output vs analogue display reality

Emulators typically start from an internal “perfect pixel” framebuffer, but real MSX viewing historically involved CRT monitors/TVs and often composite/RGB connections. The TMS9918A itself defines colours in a way tied to luminance/chrominance signals, implicitly pointing to a pre-RGB, pre-LCD era. citeturn41view1turn41view0

In practical emulator terms, openMSX explicitly documents that:

- **Blur** simulates that “TVs and MSX monitors are less sharp than PC monitors,” with a continuous 0–100 control. citeturn44view1  

- **Scanlines** emulate the visible gaps between CRT lines. citeturn44view1  

- **Gamma correction** is necessary because “PC monitors can have different gamma values than MSX monitors,” and openMSX frames it as a ratio of display gammas. citeturn44view1  

These aren’t cosmetic: they change perceived colour mixing, edge readability, and the “density” of dithering textures—exactly the features MSX artists relied upon. citeturn44view1turn41view1

### Timing and raster effects: “accuracy” as an artistic enabler

A second authenticity axis is **VDP timing**. openMSX documents an “accuracy” setting with modes including **screen**, **line**, and **pixel** synchronisation, noting that certain demos require higher accuracy to display correctly. citeturn44view1  

MSX2 documentation further supports that scanline-level behaviour is part of the platform: the V9938 can generate interrupts after a specific scanline, enabling raster-timed effects. citeturn43view0

### Real-hardware variability and uncertainty

Even staying “on hardware,” MSX is not perfectly uniform: the openMSX project discusses behaviour differences on specific MSX1 VDP implementations (e.g., Toshiba VDP mirrored-mode behaviour). citeturn46view1  

This means that “authentic MSX look” is often a **range** rather than a single reference image—especially for edge-case effects and palette/monitor interactions. citeturn46view1turn41view1

## Comparisons with other 8-bit systems

### Technical differences table

The goal here is not ranking, but identifying **how each platform’s graphics model pushes artists toward characteristic solutions**.

| System | Typical resolution & colour model | Attribute / constraint granularity | Sprite support | Common “art pressure” | Representative sources |

|---|---|---|---|---|---|

| MSX1 (TMS9918A / SCREEN 2) | 256×192 active, character/pattern graphics; colours defined via luma/chroma table. citeturn41view1turn41view0 | Two colours per 1×8 line within an 8×8 character; colour table segmented for Graphics II. citeturn39view2turn42view0 | 32 sprites total; **4 sprites per horizontal line**. citeturn41view0 | Strong silhouettes; dither textures; careful horizontal colour boundaries; sprite choreography/flicker management. citeturn39view2turn41view0 | TI VDP manual; MarMSX Screen 2 Layout. citeturn41view0turn39view2 |

| MSX2 (V9938) | Higher resolutions; programmable palette (512 colours, 9-bit palette; up to 256 on screen; bitmap modes). citeturn43view0turn51search5 | Multiple modes; less “forced” attribute clash in bitmap screens, but still memory/bandwidth and sprite rules. citeturn43view0 | More capable sprite system (e.g., more sprites per line), plus scanline interrupts for effects. citeturn43view0 | Allows richer shading, but strong MSX “readability-first” legacy remains in many works. citeturn43view0turn37view0 | MSX2 Technical Handbook; V9938 DB. citeturn43view0turn51search5 |

| ZX Spectrum | 256×192 bitmap plus attributes per character cell; 8 ink/paper colours + brightness/flash per cell. citeturn47view0 | **Two colours per 8×8 block** (“attributes”), causing classic “attribute clash.” citeturn47view0 | No hardware sprite system in the MSX sense (software-drawn). (General Spectrum model implied by attribute-based graphics discussion.) citeturn47view0 | Artists often structure sprites to avoid attribute clash; heavy outlining and colour containment. citeturn47view0 | ZX Spectrum +3 manual (attributes explanation). citeturn47view0 |

| NEC PC-88 | Commonly used 640×200 mode with 8 colours; higher-res modes exist but constrained. citeturn19view1turn48view0 | Not attribute-clash the same way; performance and pixel shape become aesthetic factors. citeturn48view0 | Generally not console-style sprite hardware; action often limited by draw speed (noted as tearing/slow redraw). citeturn48view0 | Dithering and static/low-motion presentation; scrolling/action limited by redraw speed. citeturn48view0 | 1000BiT spec; Retronauts PC-88 analysis. citeturn19view1turn48view0 |

| Sharp X1 | Multiple graphics modes; specs note RGB/composite output; extensive display configuration in later Turbo models. citeturn19view2turn21search16 | Uses programmable character generator (PCG) and text/graphics composition. citeturn21search16 | Not an MSX-like sprite engine; flexibility comes from PCG/text/graphics handling. citeturn21search16turn19view2 | PCG-driven quick graphics and “computer screen over TV” compositing become part of identity. citeturn21search16turn19view2 | engineers@work X1 specs; Sharp X1 overview. citeturn19view2turn21search16 |

A key comparative intuition: **MSX SCREEN 2’s 8×1 constraint is stricter than MSX2 bitmap modes, but in some ways *less* restrictive than Spectrum’s 8×8 attribute blocks**, enabling finer horizontal colour detail—one reason MSX1 art often features horizontally rich textures while still exhibiting “colour discipline.” citeturn39view2turn47view0turn42view0

## Practical reproduction techniques in modern engines

### Technique comparison table

| Target look component | Practical technique | Notes for Unity / Godot / WebGL | Key sources |

|---|---|---|---|

| SCREEN 2 layout rules (2 colours per 8×1) | Maintain an **attribute map** (per 8×1 row) and enforce at export time (quantisation) or in shader (palette + attribute lookup). | Unity: apply as full-screen pass; Godot: screen-reading + custom postprocess; p5.js: filter shader over canvas. citeturn53search0turn53search9turn53search2 | SCREEN 2 per-line colour model. citeturn39view2turn42view0 |

| TMS9918A palette character (luma/chroma) | Use a measured/reference palette; treat it as CRT-era, not “flat sRGB.” Optionally simulate slight channel crosstalk. | Calibrate by comparing against emulator palettes and real captures; expect variation. citeturn41view1turn44view1 | TMS9918A colour assignments table. citeturn41view1 |

| Sprite-per-line artefacts | Emulate a 4-sprites-per-scanline budget; when exceeded, drop or flicker sprites per scanline. | Implement as a CPU-side scheduling rule in your renderer (more accurate than a pure shader). citeturn41view0 | 4 sprites/line rule. citeturn41view0 |

| CRT sharpness vs blur | Apply **controllable blur** that primarily blends neighbouring pixels (especially horizontally), plus scanlines. | Use postprocessing: openMSX-style blur (0–100), scanlines for line structure. citeturn44view1turn53search0turn53search9turn53search2 | openMSX blur/scanline docs. citeturn44view1 |

| “Composite bleed” feel | Encode to YIQ/YUV, low-pass chroma, decode back; add mild ringing. | Unity/Godot: implement in fragment shader; WebGL: filter shader; validate visually (avoid overdoing). citeturn53search0turn53search9turn53search2turn53search3 | TMS9918A chroma basis. citeturn41view1 |

| Gamma and brightness | Apply gamma correction and optionally per-channel tweaks to match CRT feel. | openMSX frames gamma correction as matching display gammas; replicate conceptually. citeturn44view1 | openMSX gamma section. citeturn44view1 |

| Raster/scanline timed effects | Simulate scanline interrupts and per-line palette/scroll changes; ensure deterministic timing. | Godot/Unity: typically approximate; for demoscene-like authenticity, update effect parameters in a per-scanline simulation step. citeturn43view0turn44view1 | V9938 scanline interrupt description; emulator accuracy notes. citeturn43view0turn44view1 |

| Overscan/pixel aspect | Render at 256×192 (or MSX2 mode target), then scale to 4:3 with slight border/overscan. | “Authentic framing” matters as much as palette; avoid modern ultra-sharp integer-only presentation unless that’s the goal. citeturn41view0turn44view1 | TMS9918A active resolution; emulator scaler discussion. citeturn41view0turn44view1 |

### Implementation tips by platform

For entity["company","Unity Technologies","game engine company"] projects using URP, the **Full Screen Pass Renderer Feature** is the most direct way to inject a postprocess-style MSX shader (palette, blur/bleed, scanlines) at a chosen injection point. citeturn53search0turn53search8

For entity["organization","Godot Engine","open source game engine"], official documentation recommends building custom post-processing by reading from the screen texture (“screen-reading shaders”), which aligns well with CRT/composite simulation as a final pass. citeturn53search9turn53search5

For WebGL sketches (including p5.js), `createFilterShader()` is intended to apply a shader to the whole canvas via `filter()`, making it a good match for a unified “MSX display pipeline” filter. citeturn53search2turn53search14  

Texture sampling fundamentals are covered in MDN WebGL tutorials, which you’ll need for multi-pass setups (render-to-texture then postprocess). citeturn53search3turn53search15

### Gaps and uncertainties to note

- **Palette fidelity is not singular**: because TMS9918A colour is defined in luminance/chrominance terms, RGB conversions vary and many screenshots incorporate emulator palettes and scaling filters. citeturn41view1turn44view1  

- **Real MSX hardware variance exists** (e.g., vendor differences in VDP behaviour), so “authentic” may be “authentic to a subset of machines.” citeturn46view1  

- **Date/metadata disagreements happen** in secondary databases (e.g., Space Manbow year differences across sources); treat year/platform metadata as “best available,” not absolute truth unless corroborated by primary-era releases/manuals. citeturn17search11turn17search15  

- **Many images are compressed or scaled**, which can destroy the very artefacts (scanline gaps, bleed) you may be trying to emulate; prefer direct PNG captures (MSXdev, some scene archives) when calibrating. citeturn27view2turn29view0turn23view2  

### Suggested next deep-dive topics

A high-value next stage would be to build a **repeatable calibration set**: a small library of real-hardware captures (composite vs RGB, multiple machines/VDPs) and matching emulator outputs with known settings, so reproduction shaders can be tuned to measurable targets rather than taste. The need is motivated by VDP palette definition style and known hardware variance. citeturn41view1turn46view1turn44view1

Another deep dive is to catalogue **mode-specific MSX2 art** (SCREEN 5/7/8) and identify which aesthetic patterns persist even when attribute clash is relaxed, leveraging the MSX2 handbook’s mode breakdown. citeturn43view0turn37view0

A third is a “scene techniques” study: map specific demo effects to VDP features (scanline interrupts, palette changes, sprite line-colour tricks) using dated productions as anchors. citeturn43view0turn28view0turn30view0turn32view0

### Actionable checklist for reproducing MSX colour and bleed

- Decide your target: **MSX1 SCREEN 2** look (attribute-limited) or **MSX2 bitmap/palette** look (more colourful, still retro-structured). citeturn39view2turn43view0  

- Lock your base raster: render internally at **256×192** (MSX1) or your chosen MSX2 mode resolution, then scale to 4:3 with a modest border/overscan. citeturn41view0turn44view1  

- Adopt a palette model consistent with the target VDP (remember TMS9918A colour is given in luma/chroma terms). citeturn41view1turn43view0  

- Enforce **two colours per 8×1 strip** (SCREEN 2) using an attribute map; if you need a “third colour,” treat it as sprites/overlays, like many authentic mockups do. citeturn39view2turn34view2turn41view0  

- Respect sprite limits: design (or emulate) around **4 sprites per scanline**; decide whether you’ll reproduce flicker/dropout or avoid it via scheduling. citeturn41view0  

- Apply a display shader chain: mild **blur**, optional **scanlines**, and carefully tuned **composite-like chroma bleed** (avoid over-softening). citeturn44view1turn41view1  

- Validate your look using known references (commercial screenshots + modern MSXdev PNG captures + at least one demoscene production), and document your settings for reproducibility. citeturn51search0turn27view2turn29view0turn33view0