Skip to content

Pasi Ojala

Documenting effects and compression as Albert

Pasi Ojala, also known as Albert, wrote C64 technical articles and developed pucrunch. His work explains both the display tricks a reader can reproduce and the trade-offs behind compact data and small decompressors.

Pasi Ojala, also known as Albert, explains the Commodore 64 through effects, algorithms and working implementations. His signed Demo Corner articles in C=Hacking examine display techniques; his pucrunch work tackles a different constraint, the cost of storing and unpacking data.

Both kinds of work make the conditions visible. A raster effect depends on where the display is in its cycle. A compressed program depends on the memory and code needed to restore it.

Showing the mechanism

The sprite-stretching article in C=Hacking 5 identifies its timing as PAL-specific while explaining that the principles also matter on NTSC machines. That qualification is part of the method, not a footnote to discard when copying the code.

Later Demo Corner pieces discuss DYCP, where individual letters move at different heights, and tech-tech effects. These names describe results; the articles examine the representation and timed work that produce them. An effect with more independently moving characters than the hardware has sprites needs a different way to build the picture. (C=Hacking 5–7.)

Compression with a small destination

Ojala’s pucrunch documentation describes a hybrid of LZ77-style references to earlier data and run-length encoding for repeated values. The compressor can perform substantial work on its host machine, but the decompressor must fit and run on the target.

That is why the smallest compressed file is not automatically the most useful result. The destination also needs the unpacker, working space and enough time to recover the data. The documentation explains those choices rather than promising the best ratio for every input.

The site’s revision history and the compression articles in C=Hacking 16 and 17 make the development traceable. They are Ojala’s own technical accounts, so they support statements about his implementation and reasoning; they are not independent evidence for a broader claim of priority.

His work connects demoscene effects with everyday development concerns. In both, understanding the limit is what makes a technique reusable: another programmer needs to know not only that it worked, but under which conditions.

Sources

  • Pasi “Albert” Ojala, Demo Corner in C=Hacking 5, 6 and 7: signed original technical articles.
  • Pasi Ojala, pucrunch documentation: algorithm, implementation and revision history.
  • C=Hacking 16, April 1998, and 17, November 1998: original compression articles.

Checked. Verified against primary sources and signed off by a person.