Code, maps, text and arbitrary bytes
v5.2 formats 0/2, combined v5.3/v5.4 and the v4.3 baseline, with matching RAM decrunchers.
Browser compressor · Z80 integration toolkitKeep the best.
Keep the best.
Use it where it fits.
Compress ordinary binary data, Screen 5–8 pictures, tiles, fonts and pattern streams. Compare the active CBS formats, choose RAM, RAM-tail, buffered VRAM or direct VRAM delivery, and download the matching Z80 source. Every candidate must decrunch byte-for-byte in the browser before it can win.
ACTIVE COMPRESSION PATHS
48v5.4 adaptive nearMEASURED PER FILE
40v5.3 state flowSHARED RAM CORE
00/80v5.2 compact pairTAIL-CAPABLE
C3/C5v5.5 line-awareBUFFER / DIRECT
42/4Alinear VRAMTILES / FONTS
43–4Dv5.3/v5.4 imagesBUFFER / DIRECT
CBS v4.3 remains beside them as the trusted historical baseline.
CBS v5.3 · v5.4 · v5.5 compression lab
Your file stays localv5.4 versus v5.3, v5.2 and v4.3
This is a build-time choice. Packed CB5 files carry no mapper bits.
HL advances linearly in unpaged ROMThe compact original LD A,(HL) reader is retained.
Drop binary, BMP, PNG, SC5–SC8 or CB5 dataContinuous-data comparison or recommended Screen 5–8 direct-VRAM compression · maximum 65,536 packed bytes
One linear byte stream tested with v5.4, v5.3, v5.2 formats 0 and 2, and CBS v4.3
The same window is used for both v5.2 formats.
0x48 + 0x40 + 0x00 + 0x80 + v4.3v5.4 adaptive near · v5.3 state flow · v5.2 compact · v5.2 near · CBS v4.3 baseline
The same compressor from a Python command line
The downloadable package uses the same compiled engine and parameters as this page. It handles continuous data, Screen 5–8 images, native BMP/PNG import, SC5–SC8 BSAVE files, CB5 decrunching, RAM-tail output, linear VRAM and one-image MSX test ROMs.
CBS Cruncher v5.5 CLI · release 9
Cross-platform compressor plus the practical Z80 source set
Continuous data
python cbs_cruncher.py game.bin
python cbs_cruncher.py game.bin --ram-tailScreen image + test ROM
python cbs_cruncher.py picture.png --mode 7 --rom
python cbs_cruncher.py tiles.bin --linear-vram-screen 5 --romRequires Python 3.10+ and Node.js 22+. Pillow is needed only for BMP/PNG input. The website-only multi-image demonstration ROM remains intentionally separate from the CLI.
The core system is complete enough for game integration
The browser no longer presents every abandoned experiment. These are the implemented paths that have survived compression, browser round-trip and generated-ROM testing.
Reuse the destination block
Safe files receive destination 0x1 and relocate themselves with LDDR before forward expansion.
Buffered or direct VRAM
v5.3, v5.4 and line-aware v5.5 share paired payloads; change the destination without recompressing.
Tiles, fonts and pattern data
v5.3/v5.4 destination 0x2 follows physical Screen line width without forcing rectangle geometry.
Five mapper families
One mapped Screen 5–8 decoder mixes buffered and direct images across ASCII8, ASCII16, ASCII16-X, Konami and Konami SCC banks.
Generated ROMs and WebMSX
Single images and ordered multi-screen mapper ROMs verify decompression, palettes and VDP delivery.
Still planned
See the roadmapMSX Memory Mapper RAM output is the main missing backend
Cartridge ROM mapper reading now serves both buffered and direct VRAM. What remains is unpacking into selected MSX Memory Mapper segments, plus an optional hybrid row/chunk backend if a real game benefits from it.
How CBS Cruncher grew into v5.5
A Motorola 68000 cruncher and tiny Z80 decruncher became a verified browser tool, a family of RAM/VRAM writers and a real MSX ROM builder.
THE ORIGINAL
CBS Cruncher is written for the Amiga
The 68000 cruncher produces CBS v3. Its small Z80 decruncher originated on the ZX Spectrum and also works on MSX. A ROM-reading MSX version was later developed during the Romancia translation while the executable decoder still ran from RAM.
RECOVERY + FORMAT DESIGN
The surviving sources become a verified browser tool
We restored v3 and v4.3, reproduced the Romancia result, replaced the unsafe four-byte overlap assumption with exact measurement, imported BMP/PNG pixels, and developed the v5.2 compact formats with a documented three-byte header and optimized Z80 RAM core.
LEARNING FROM ZX0
One excellent decoder changes our direction
ZX0's state flow, interlaced Elias coding, last offset on the stack, EX (SP),HL copying and impossible-offset EOS guided v5.3 and v5.4. CBS kept its own headers, offsets, adaptive-near choice and destination system.
DIRECT VRAM + ROM BANKS
Large pictures stop requiring a full RAM buffer
CPU literals, HMMM matches and HMMV fills made direct Screen 5–8 output practical. Five cartridge mapper readers, palettes, E000h decoder relocation, F500h controller code and ordered multi-image ROMs followed.
V5.5 INTEGRATION RELEASE
The experimental pieces become one usable system
v5.3/v5.4 gained one combined RAM decoder; v5.5 line offsets joined buffered and direct image routes; destination 0x2 added linear VRAM; destination 0x1 added measured RAM-tail relocation; the Python CLI gained matching outputs; and the website was divided into a focused compressor plus this complete integration guide.
ONE MAPPED IMAGE DECODER
Buffered and direct pictures share the same ROM
The five cartridge-mapper builds gained a shared consecutive-bank reader and an optional mixed destination dispatcher. Direct-only lists now keep the smaller direct decoder; lists containing destination 3 automatically receive the combined RAM-stage/HMMC and direct-VRAM decoder. Machine ports, the initial Screen mode and an unchanged palette are initialized once before playback, while later setup runs only for a real mode or palette transition. The buffered uploader now waits for final HMMC completion before returning, and demo ROMs disable sprites to prevent artifacts while freeing VDP bandwidth.
LOCAL WEBMSX + CLI RELEASE 9
Long mapper ROMs run without an address-length limit
A dedicated local WebMSX player replaced ROM-sized Base64 launch URLs. The browser now transfers complete cartridges directly between local tabs, preserving Japanese MSX2 NTSC, palette and mapper selection without uploading the ROM. The Python CLI was regenerated from the same engine, given reproducible packaging and tested across every continuous codec, buffered/direct images, linear VRAM, RAM-tail, BSAVE handling and all five mapped-ROM readers.
COMPACT TABLE-DRIVEN ROM PLAYER
Large image lists stop consuming the F500h controller area
The multi-image builder replaced per-picture playback code with one shared loop and a compact RAM table containing Screen mode, VRAM page, mapper bank, packed address, palette and clear-command references. The HMMV clear now sends an eleven-byte VDP command block with OTIR, identical mode/black-colour blocks are reused, and a new public E009h decoder entry owns VDP-command waiting. A ten-image mixed ASCII16 player now occupies only 643 bytes at F500h, including its table, palettes and clear parameters.
The Help & format guide contains the byte layout, calling conventions, worked examples and remaining roadmap.