CBS Cruncher V5.5
Help & format guideOpen compressor
Measured cartridge study · 1 August 2026

Ten streams.
Six images, two delivery paths.

This page dissects the new 128 KB demo ROM, built from images used in my MSX translation projects, byte by byte. Four images appear twice so buffered and direct-VRAM delivery can be compared with exactly the same compressed payload. Two larger images use direct VRAM because their output cannot fit in the 24 KB RAM stage.

ROM128 KB

ASCII16 · 10 table entries

Image data26,052 B

17,722 B across six unique images

Best ratio95.3%

Entry 7 · 32,768 → 1,548 bytes

Largest VDP job22,568 B

One HMMV fill in entry 10

SHA-256 · EB0BE08B77BB5569948FF54B105E6F18D6954215CBF0AC24F53EF5C722263CAD

01 · ROM inventory

What each table entry contains

Raw size is the exact VRAM rectangle in bytes. “Saved” compares the complete packed stream—including its three-byte CBS image header—with that raw size. Addresses are CPU-visible ASCII16 addresses.

#RouteMode / geometryRawPackedSavedBank : address
01BufferedScreen 7 · 68×885,984 B376 B93.7%1 : 4000h
02DirectScreen 7 · 68×885,984 B376 B93.7%1 : 4178h
03BufferedScreen 8 · 70×805,600 B1,556 B72.2%1 : 42F0h
04DirectScreen 8 · 70×805,600 B1,556 B72.2%1 : 4904h
05BufferedScreen 5 · 128×12816,384 B4,068 B75.2%1 : 4F18h
06DirectScreen 5 · 128×12816,384 B4,068 B75.2%1 : 5EFCh
07DirectScreen 5 · 128×25632,768 B1,548 B95.3%1 : 6EE0h
08BufferedScreen 7 · 72×966,912 B2,330 B66.3%1 : 74ECh
09DirectScreen 7 · 72×966,912 B2,330 B66.3%1 : 7E06h
10DirectScreen 7 · 248×22455,552 B7,844 B85.9%2 : 4720h
PAIR 1/2

Same CBS tokens

The payload after byte 0 is identical. Only the route ID changes: C3h buffered, C5h direct VRAM.

PAIR 3/4

Same CBS tokens

The payload after byte 0 is identical. Only the route ID changes: C3h buffered, C5h direct VRAM.

PAIR 5/6

Same CBS tokens

The payload after byte 0 is identical. Only the route ID changes: C3h buffered, C5h direct VRAM.

PAIR 8/9

Same CBS tokens

The payload after byte 0 is identical. Only the route ID changes: C3h buffered, C5h direct VRAM.

02 · Delivery paths

Compression is shared. Reconstruction is not.

C3hBuffered / HMMC
  1. DecodeZ80 expands CBS tokens into contiguous RAM at 8000h–DFFFh.
  2. TransferHMMC sends the finished rectangle from CPU/RAM to VRAM.
  3. Trade-offPredictable and often fast, but every raw byte crosses the CPU–VDP port and output is capped at 24 KB.
C5hDirect VRAM
  1. LiteralsThe CPU writes new bytes directly to their VRAM destination.
  2. MatchesLong back-references become HMMM VRAM-to-VRAM copies; long one-byte runs become HMMV fills.
  3. Trade-offNo full-size RAM buffer. Performance depends on whether the picture produces large VDP-friendly matches.
Why the VDP can look instantaneous

HMMM and HMMV receive a rectangle and start autonomous command-engine work. The Z80 waits on the command-executing flag rather than copying each byte itself. A repeated color run can therefore become one HMMV command, while repeated rows become HMMM copies from VRAM already drawn.

03 · Exact image reconstruction

See where the VDP fills and copies the image

These six images are reconstructed directly from the packed streams and palettes inside the verified ROM. Orange regions are exact HMMV fill rectangles. Cyan regions show the full-row destination zones of the largest HMMM copy tokens; the decoder may divide one zone into several commands at row, source-row, or overlap boundaries.

HMMV fill / clear HMMM copied destination Unmarked: CPU or smaller operations
ENTRY 1 / 2

Riverhill Soft logo

SCREEN 7 · 68×88 BYTES
Riverhill Soft logo, reconstructed from ROM entry 1

Screen 7 is squeezed to half horizontal display width, matching its 512-pixel mode.

  • HMMVrows 1–3 · 204 B
  • HMMMrows 48–77 · 2,040 B · source distance 68 B
  • HMMMrows 45–46 · 136 B · source distance 2,924 B
ENTRY 3 / 4

Aleste Girl

SCREEN 8 · 70×80 BYTES
Aleste Girl, reconstructed from ROM entry 3
  • HMMVrows 79–79 · 70 B
ENTRY 5 / 6

Illusion City · A00 map data

SCREEN 5 · 128×128 BYTES
Illusion City · A00 map data, reconstructed from ROM entry 5
  • HMMMrows 88–95 · 1,024 B · source distance 8,192 B
  • HMMMrows 85–85 · 128 B · source distance 8,192 B
ENTRY 7

Romancia · Title screen

SCREEN 5 · 128×256 BYTES
Romancia · Title screen, reconstructed from ROM entry 7
  • HMMVrows 221–255 · 4,480 B
  • HMMVrows 198–219 · 2,816 B
  • HMMMrows 90–160 · 9,088 B · source distance 2,432 B
  • HMMMrows 28–38 · 1,408 B · source distance 128 B
ENTRY 8 / 9

Burai · Tiger

SCREEN 7 · 72×96 BYTES
Burai · Tiger, reconstructed from ROM entry 8

Screen 7 is squeezed to half horizontal display width, matching its 512-pixel mode.

  • HMMVrows 1–2 · 144 B
ENTRY 10

Burai · image

SCREEN 7 · 248×224 BYTES
Burai · image, reconstructed from ROM entry 10

Screen 7 is squeezed to half horizontal display width, matching its 512-pixel mode.

  • HMMVrows 1–91 · 22,568 B
How to read the overlays

A large orange block is a repeated color that the VDP can paint with HMMV. A cyan block is output reconstructed from pixels already in VRAM. Every preview uses a whole-number scale instead of stretching to the card width. Screen 7 PNGs retain all 512-mode pixels, but display at half width so they have the correct physical proportions.

04 · Measured work profile

Where the direct decoder spends its work

These are deterministic decoder counts from the ROM, not stopwatch timings. CPU bytes include literals, short copies and short fills. VDP bytes are output delegated to HMMM or HMMV; command setup and VDP speed still affect real elapsed time.

ENTRY 2 · SCREEN 789.1% VDP
CPU-produced
654 B
HMMM copies
129 · 5,005 B
HMMV fills
3 · 325 B
Largest VDP job
204 B
ENTRY 4 · SCREEN 831.9% VDP
CPU-produced
3,811 B
HMMM copies
121 · 1,649 B
HMMV fills
3 · 140 B
Largest VDP job
70 B
ENTRY 6 · SCREEN 556.7% VDP
CPU-produced
7,099 B
HMMM copies
332 · 9,285 B
HMMV fills
0 · 0 B
Largest VDP job
128 B
ENTRY 7 · SCREEN 592.2% VDP
CPU-produced
2,548 B
HMMM copies
400 · 21,870 B
HMMV fills
17 · 8,350 B
Largest VDP job
4,480 B
ENTRY 9 · SCREEN 735.7% VDP
CPU-produced
4,445 B
HMMM copies
140 · 2,219 B
HMMV fills
3 · 248 B
Largest VDP job
144 B
ENTRY 10 · SCREEN 771.1% VDP
CPU-produced
16,036 B
HMMM copies
734 · 16,291 B
HMMV fills
9 · 23,225 B
Largest VDP job
22,568 B
ENTRY 7 · 128×256

A full Screen 5 image in 1,548 bytes

Only 2,548 output bytes are CPU-produced. HMMM handles 21,870 bytes and HMMV fills another 8,350. The biggest single fill is 4,480 bytes.

ENTRY 10 · 248×224

One command paints 22,568 bytes

A very long distance-one match becomes one HMMV rectangle. Across the image, nine fills and 734 HMMM copies delegate 39,516 bytes to the VDP.

Wall-clock timing comes next

Exact milliseconds require the same emulator, machine timing, VDP setting and start/finish markers for every run. The next ROM revision can bracket each decode with a frame counter or border-color marker; this page currently reports reproducible workload, not invented time.

05 · Original-game comparison

CBS v5.5 versus the original game data

Four source measurements are now identified. The comparison uses the complete CBS stream size from this ROM and the original game's packed size. The images in entries 3/4 and 7 are identified, but their original packed sizes remain unknown.

GAME / DATAENTRYRAWORIGINALCBS V5.5CBS RESULT
Riverhill Soft logo1 / 25,984 B697 B376 B321 B smaller · 46.1%
Aleste Girl3 / 45,600 BUnknown1,556 BOriginal size needed
Illusion City · A00 map data5 / 616,384 B10,240 B4,068 B6,172 B smaller · 60.3%
Romancia · Title screen732,768 BUnknown1,548 BOriginal size needed
Burai · Tiger8 / 96,912 B3,277 B2,330 B947 B smaller · 28.9%
Burai · image1055,552 B12,701 B7,844 B4,857 B smaller · 38.2%
06 · Live cartridge

Run the measured ROM in WebMSX

This is the exact 128 KB ASCII16 cartridge analyzed above, SHA-256 EB0BE08B…263CAD. It opens in the project's local Japanese MSX2 player; the ROM stays in your browser and is not uploaded. Press any key after each image to advance through all ten entries.

Download 128 KB ROM

Preparing the 128 KB cartridge…

Technical basis

Command behavior and the CE busy flag are documented in the MSX2 Technical Handbook, Chapter 4 and the Yamaha V9938 Programmer's Guide. Compression sizes and command counts on this page were measured directly from the supplied ROM.