PCL3 raster interpreter for Kodak Diconix 150

Posting the thing that started this project, because it is the oldest open question I had and it took until now to answer it properly.

I grew up on one of these. From 1989 to about 1995 a Kodak-badged Diconix was the only printer in the house: school papers, cards, Print Shop banners. Every single thing with a graphic in it came out at roughly two thirds size. Not cropped, not clipped, just small, floating in a sea of white margin. Plain text was fine. Anything else was two thirds, and the aspect always looked faintly squeezed on top of that.

I was nine. I assumed that was just how printers were.

The answer is in HP's own service manual for the ThinkJet 2225, which is the same print engine under a different badge. This family lays its dots on a fixed grid:

96 or 192 dots per inch horizontal. 96 dots per inch vertical.

Epson's FX graphics standard assumes something else entirely: 60, 120 or 240 dpi horizontal depending on which density command the software sends, and 72 dpi vertical, because an Epson 9-pin fires eight pins across a ninth of an inch. The printer faithfully places every dot it is handed, on its own grid, and nothing anywhere in the chain rescales.

• Vertical: 72 requested into 96 actual = 3/4 height. Always, no exceptions.
• Horizontal, double density, which was the common software choice: 120 into 192 = 5/8 width.

Two different fractions on two axes. That is the two-thirds page, and that is also why the aspect looked wrong rather than merely small.

DiKon does not emulate anything. It takes 300 dpi PCL3 raster and does the interleave to the head's native grid on-chip, so the geometry is correct by construction instead of by accident. Which means the specific annoyance that made me pick this project up is now a thing the firmware handles, thirty years after it first bothered me.

Side-by-side prints of the same file, stock Epson mode versus DiKon, to follow.

<p>After the brick, the self-test still printed garbage in four of its six sliding-ASCII diagnostic rows, because those rows render out of the two fonts my blob is sitting on.</p>
<p>Turns out the stock ROM already ships a DIP-selected quality lock at 0x0ACB that forces every font class to one of the two fonts I did not touch. Making it unconditional is one byte, <code>0x0ACE: JR -> NOP</code>.</p>
<p>Forty years later and whoever wrote this thing had already left me the exact lever I needed. v5i then puts the visual variety back a different way, by rewriting the class-to-parameter-block pointer table at 0x0AFF so every class resolves to an intact font base while the metrics still differ.</p>

The v5f banner ran to 0x3018. I had cleared that window two ways, an instruction-operand scan and a runtime read-watch, and both said it was free. Both were wrong.

The font base addresses that reach into it live as data inside parameter blocks behind a pointer table at 0x0AFF, so no operand scan will ever see them, and my test jobs only ever selected the two font classes that do not point there. I had written over live glyph cells for @, A and B.

Result: constant BUSY on every interface, a crash-reset loop every few seconds, garbage on the rare moments it held still. A dead scan plus an incomplete test equals a bricked printer.

Nothing goes at or above 0x3000 now, and the build asserts it rather than trusting me to remember.

I prepended one carriage return to the emit path to force column-zero anchoring. On hardware that CR hit the stock CR handler at 0x1B48, which checks motion-in-flight before it checks buffer-empty, queued a pending print on an empty buffer, and made the next ESC L abort after its header. 224 raster bytes leaked into the text path and hard-wedged the machine.

My stubbed simulator was perfectly happy with all of it. I had to build an unstubbed audit rig before I could see the thing at all, and then it reproduced instruction for instruction. One character.

v3d and v3e both carry it. Do not burn either one.