#quicktakeforappleii
Everything I wanted to implement is implemented, I now consider the Kodak DC50 support complete in my #appleii digital photography program!
https://www.colino.net/wordpress/archives/2026/08/23/kodak-dc50-now-usable-on-the-apple-ii/
#retrocomputing #quicktakeforappleii
Kodak DC50 now usable on the Apple II
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 make 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. 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?
www.colino.net
August 23, 2026 at 10:15 AM
I am very much back on my bullshit! #retrocomputing #quicktakeforappleii
August 20, 2026 at 8:50 PM
Could we have a Sierra-class driver in #quicktakeforappleii ? Seems very likely.
This might be quite neat as A LOT of vintage cameras use the Sierra protocol.
#retrocomputing #appleii #retrophotography
August 24, 2026 at 4:37 PM
Sneak peak into my next release (which will probably come soon, after finalizing the Canon Powershot 350 driver) of #quicktakeforappleii

#retrocomputing #appleii
https://www.colino.net/wordpress/archives/2026/09/11/sierra-digital-cameras-on-the-apple-ii/
Sierra digital cameras on the Apple II
After successfully adding support for the Kodak DC-50 camera in Quicktake for Apple II, I investigated what else was there that had vastly overblown “System requirements”. The Epson PhotoPC user manual page with their System Requirements Based on libgphoto2’s source code, I chose to give a closer look to what I (and they) call the “Sierra-class” cameras. There are a lot of cameras sharing the same class of protocol there, more than 80 models are referenced. Not all of them will be usable on Apple II, as my JPEG decoder is hardcoded to 640×480 images (de-hardcoding it would be possible, but memory and CPU expensive, and it’s already slow enough as is that I don’t want – yet – to even try decoding and scaling down 800×600 or 1024×768). Even limited to 640×480 cameras, this will open a number of options. I bought a pair of very cheap Sanyo cameras on eBay (a VPC-G1 from 1995, also sold as Epson PhotoPC PCDC001 and Sierra Imaging SD640, and a VPC-G200 from 1997), and started my 2026 summer staycation implementing my driver: during the previous release cycle, leading to the Kodak DC50 support, I reworked my code so that cameras drivers are now modules with a defined interface. This allows my program to only load the relevant driver into memory, making Quicktake for Apple II extensible with an arbitrary number of drivers as long as it fits on the floppy! Sanyo VPC-G1 (1995) Sanyo VPC-G200 (1997) Here’s my “skeleton” driver that does nothing but the boilerplate. It basically defines a bitfield of supported features, and 16 “API methods”, most of which being optional. The only required endpoints are `_wakeup`, `_set_speed`, `_get_information` and `_get_picture`. #define sierra_features 0b0000000011011111 // ||||||||_ SET_CAMERA_NAME // |||||||__ SET_CAMERA_TIME // ||||||___ SET_QUALITY, // |||||____ SET_FLASH, // ||||_____ TAKE_PICTURE, // |||______ GET_THUMBNAIL, // ||_______ DELETE_PICTURES, // |________ RESERVED, /* Camera callbacks */ void *sierra_callbacks[] = { /* FEATURES */ (void *)sierra_features, /* WAKEUP */ sierra_wakeup, /* SET_SPEED */ sierra_set_speed, /* SET_CAMERA_NAME */ sierra_set_camera_name, /* SET_CAMERA_TIME */ sierra_set_camera_time, /* GET_INFORMATION */ sierra_get_information, /* SET_QUALITY */ sierra_set_quality, /* SET_FLASH */ sierra_set_flash, /* TAKE_PICTURE */ sierra_take_picture, /* GET_PICTURE */ sierra_get_picture, /* GET_THUMBNAIL */ NULL, /* DELETE_PICTURES */ sierra_delete_pictures, /* GET_FILENAME */ sierra_get_filename, /* THUMB_HISTOGRAM */ NULL, /* THUMB_LOAD_DATA */ NULL, /* GET_QUALITY_STR */ sierra_get_quality_str, /* GET_FLASH_STR */ sierra_get_flash_str, }; In the end, my Sierra driver implements almost everything my program supports: all information fields (camera name, camera time, quality mode, flash mode, pictures taken, pictures remaining, battery status) are readable, flash and quality modes are settable, we can snap a picture, etc. The libgphoto2 Sierra driver has made things very easy as it is functional and easy to understand. It’s sprinkled with a a few magic numbers here and there, but they were easy to make sense of and #define. The only feature not available is `sierra_get_thumbnail`. It actually is implemented, because it is easy to fetch a thumbnail from the camera: it’s the same procedure as getting a picture, using two different camera registers. But it’s not wired in the UI, as the thumbnails are JPEGs. There is no way I have room to load the JPEG decoder in the UI program, where thumbs are displayed, so I left it out. Another small annoyance with the Sierra cameras (at least the two Sanyos I have) is that it seems they cheaped out on the serial chip. I can talk to them at 115200bps on the PC, but not on the Apple II. Sigrok captures of the signals show that the start bits start too soon after the stop bits, and this confuses the Apple II’s ACIA 6551, which throws framing errors. So, speed is limited to 19200bps – even on the IIgs. A Sigrok capture, viewed in Pulseview, with the start bit starting on the stop bit. The stop bit also starts early. A picture of a building with trees, straight out of the Sanyo VPC-G200 ## Supported cameras Only noting the cameras I tested with, this will add support for: * Sanyo VPC-G1 * Epson PhotoPC PCDC001 * Sierra Imaging SD640 * Sanyo VPC-G200 I strongly suspect that the following cameras might work out-of-the-box, but that is untested.: * Agfa ePhoto 307 * Agfa ePhoto 780 * Epson PhotoPC 500 * Epson PhotoPC 550 * Olympus C-400 * Olympus C-400L / D-200L * Olympus C-410L * Olympus C-420L / D-220L * Polaroid PDC-640 * Sanyo VPC-G210 * Sanyo VPC-G250 ## Refactoring again and next steps Now that the Sierra driver is written, and even if the camera drivers themselves are stored compressed (using zx02) on the floppy, I had only 6kB left on the program’s floppy disk. Not really enough to add anything important… and I plan on adding more camera drivers! So I kept on compressing things, and compressed the UI and image decoders binaries themselves. I could have made them self-decompressing, but that would have meant having multiple copies of the decompressor, one per binary. So instead, I extended Oliver Schmidt’s LOADER.SYSTEM to handle zx02-compressed binaries. The next step is finding a new camera driver to implement, and it will be the Canon PowerShot 350, a 1998 camera, 18 years younger than the Apple II, with apparently a hell of a protocol. I wonder if I should rename the Quicktake for Apple II project to reflect the fact that it supports more and more cameras? But I like the current name, and I have no better idea.
www.colino.net
September 11, 2026 at 6:12 PM
Canon PowerShot 350 on #appleii: Started implementing image download. I'm not there yet. It is ugly, inefficient, buggy, and does not even fit in the Apple II binary. But it will work at some point.
#retrocomputing #quicktakeforappleii
September 8, 2026 at 8:42 PM
Two things achieved today: good reset/wakeup procedure, and 🥁 getting pictures from the camera's internal storage!

Todo: a lot (thumbnails, camera controls, getting pictures from the PCMCIA card, ...)

#retrocomputing #appleii #quicktakeforappleii
August 21, 2026 at 4:45 PM
Cool news from the #QuicktakeForAppleII project: the Quicktake 200 driver now handles thumbnails!

Bad news from the #quicktakeforappleii project: My Fujifilm DS-7 (a clone of the Quicktake 200) is completely broken, making testing harder, as I depend on a friend […]

[Original post on piaille.fr]
August 14, 2026 at 4:32 PM
Implemented the "YCbCr4:4:4 (1 1)" (aka YH1V1) subformat of JPEG in #quicktakeforappleii 's decoder. The QT200 doesn't use it (it's YH2V1), but other cameras from the same decade do, so that's a first step towards maybe supporting more cameras!
#retrocomputing
August 9, 2026 at 4:56 PM
I'm doing a #kansasfest presentation of my #quicktakeforappleii project in 1.5 hours (1pm CDT). Stress level is rising.
I hope I will make it good as I am extremely rusty on presentations.
https://www.kansasfest.org/product/kfest26-virtual/

#retrocomputing
August 1, 2026 at 4:33 PM
Happy #caturday from Pirate, our extremely cute one-eyed cat that we adopted two weeks ago. He is SO GOOD at hugs.

Also #retrocomputing #quicktakeforappleii
May 2, 2026 at 9:00 AM
Apparently currently at #vcfeast, my #appleii community fellow Jonathan Adar is displaying his Apple IIgs with #quicktakeforappleii !
This is making me very happy and proud 😊
#retrocomputing
April 18, 2026 at 3:40 PM