Skip to content
HN On Hacker News ↗

Kodak DC50 now usable on the Apple II

▲ 41 points 8 comments by ibobev 10h ago HN discussion ↗

Pangram verdict · v3.3

We believe that this entire text is human-written.

0 %

AI likelihood · overall

Human
100% human-written 0% AI-generated
SEGMENTS · HUMAN 1 of 1
SEGMENTS · AI 0 of 1
WORD COUNT 620
PEAK AI % 0% · §1
Analyzed
Aug 23
backend: pangram/v3.3
Segments scanned
1 windows
avg 620 words each
Distribution
100 / 0%
human / AI fraction
Verdict
Human
Pangram v3.3

Article text · 620 words · 1 segments analyzed

Human AI-generated
§1 Human · 0%

2026/08/23 - About 4 minutes read I have just released a new Quicktake for Apple II version, and it is a quite large upgrade! Most importantly, the program now supports a new camera, the Kodak DC50 Zoom, released in 1996, thirteen years after the Apple IIe. The camera’s custom cable is rather easy to make (and my serial hardware allows to skip making a custom cable altogether). All features are supported (picture download, thumbnail preview, date/name/flash/quality settings, picture deletion). Transferring a picture A picture of my partner A picture of buildings The main menu Various notes on the Kodak DC50 and my implementation The camera is able to do 115200bps on the serial port, which makes transfers blazing-fast compared to the Quicktakes! It has both internal storage and a PCMCIA slot. Mine came with a 6MB storage card, which is a ludicrous amount of storage, allowing for 92 low quality pictures or 36 high quality ones. My program will work with the storage card when it is inserted, and the internal memory otherwise. What a luxury! The DC50’s resolution is a weird-ass 756×504 pixels, and as its image format (KDC) is RADC-compressed – like the Quicktake 150, I’m reusing that decoder. But that resolution is very hard to quickly scale down to my renderer’s required 256×192 resolution, so the DC50 pictures that my program displays are cropped to 640×480 during decoding. I have managed to reverse-engineer everything that I needed using different helpers: dcraw for the subtle RADC decoding differences wrt QT150’s format; libgphoto2‘s Kodak DC120 implementation for a few serial commands/packet format (but not all of them… both cameras differ in protocol); the ancient kdcpi Perl program for a few other serial-related things (but not all of them… It seems kdcpi was full of bugs!); the ancient official Kodak Windows 3.1 software, pta31.exe; and finally, a large dose of hexadecimal buffers dumping and comparing. The cable wiring is documented on the project’s home page. Full release changelog Adding support for a brand new class of camera required and/or induced a large number of changes, that all contribute to making Quicktake for Apple II better and more maintainable: Improvements to the serial configuration screen. Upgrade serial and camera drivers to be able to use IRQ-less I/O. Generalize RADC decoder (the Quicktake 150’s image format), so that it can handle Kodak DC50’s KDC pictures, as those are RADC too. Fix an RADC decoder bug that could corrupt images on some specific input data. Generalize JPEG decoder (the Quicktake 200’s decoder, for now), so that it can handle subformat YH1V1 in addition to YH2V1. This might prove useful if/when adding support for more cameras. Fix a JPEG decoder bug that could crash the program on some specific input data. Save the last used camera driver, so that program startup is faster when re-using the same camera. Rework UI / drivers respective responsibilities. Each driver is now in charge of setting up the serial port as it needs, each driver provides its own strings for flash/quality settings, and each driver provides its own thumbnail decoder to the UI. Use the image’s filename as provided by the camera by default when possible (Quicktake 200, Kodak DC50). Add the long-missing feature of previewing thumbnails with the Quicktake 200. Fix the decoding of Quicktake 150’s thumbnails. Large source tree reorganization, by responsibilities (UI / cameras / decoders). Switch to Sierra Lite dithering on thumbnails, as it now looks better (in DHGR) than Bayer. Size optimization pass, allowing this release to use one less kilobyte on disk than the previous one, and 100 bytes less in memory. A few small performance optimizations in the decoders and renderer, yielding barely noticeable speed improvements… But every cycle counts, right?