November 11, 2015 @ 22:29 EST
October 17, 2015 @ 20:15 EDT
September 27, 2015 @ 22:35 EDT
September 22, 2015 @ 08:49 EDT
I've always loved the Subaru Impreza WRX, a watered-down street-legal rally car. This bug-eyed 2002 example was everything I was looking for.
....And it's an absolute blast to drive.
(Sorry about the lousy picture, but I didn't want to play musical cars before I left for the office. More/better pics to follow when I get around to it..)
September 01, 2015 @ 17:40 EDT
Lifting the skirts of Kodak photo printers
You have to hand it to Kodak. They have been selling their workhorse 6850 dyesub photo printer for more than ten years, and are still actively supporting it with updated drivers and firmware. It's even outlasted one of its successors (the 605), which is no longer sold, yet is still actively supported.
One of those firmware updates led to a discovery that resulted in a flurry of hacking on the 6800/6850 and 605 backends, resulting in considerably improved reliability, robustness, and performance. As well as many bug fixes, both backends now support full job pipelining and vastly improved status and error handling.
So what had I learned? The Kodak 68x0 family are variations of the Shinko S1145 and the Kodak 605 is actually a Shinko S1545. Digging deeper into other Kodak models, I discovered that the 7000/7010/7015 are variations of the Shinko S1645, and that the 8810 is a Shinko S1845.
I'd done my earlier reverse-engineering work on these Kodak models before some kind folks at Shinko/Sinfonia sent me documentation on several of their printers -- So when I re-examined what I had previously figured out with the other docs as a reference, I discovered that from a protocol perspective the 68x0/S1145 models were 6" variations of the 8" S1245, the 605/S1545 and 70xx/S1645 models were very close to the S2145, and the 8810/1845 are apparently identical to the S6245.
This means that I should be able to support the 70xx and 8810 printers with only minor modifications to the existing backend code. Granted, until I can get my hands on any of these printers all of this is conjecture.
So, I'll re-iterate my call for testers for these printers:
- Shinko CHC-S1245 (aka Sinfonia E1)
- Shinko CHC-S6245 (aka Sinfonia CE1)
- Kodak 8810
- Kodak 7000/7010/7015
- Kodak 605 (Need to ensure no regressions were introduced)
As my personal printing needs are very well met at this point and these are all fairly expensive models (especially the 8810 and 70xx series), I can't justify buying more printers just to try and make them work with Linux. Someone else is going to have to step up to help make this possible.
On that note, I should mention the S6145/CS2 (and the Ciaat Brava 21), where the situation is a bit more complex. The backend is already written and partially tested, but it currently relies on a proprietary library that is only available in binary form - and which I lack permission to redistribute.
I'm pursuing a multi-prong approach to rectify that situation. In order of desireability:
- Obtain source code to the library
- Obtain algorithmic documentation so I can independently re-implement the library
- Obtain permissions to redistribute the (binary) library, and also get it compiled for a variety of ARM targets
- Reverse-engineer the library so I can re-implement it
Let me just say that curiousity, in of itself, is poor motivation for enduring the the combination of tedium and frustration that comes from trying to reverse-engineer an opaque blob of x86 code.
Ugh. I need to get out more.
July 25, 2015 @ 22:07 EDT
July 19, 2015 @ 19:11 EDT
It'll buff out
Last week there was a bit of excitement just outside the office.
July 03, 2015 @ 15:41 EDT
Shinko S1245 and S6245 (AKA Sinfonia E1 and CE1)
A few months ago I received a semi-official documentation dump from
Sinfonia. Thanks to that information, Gutenprint now claims full
support for both the S1245 and S6245. These models required new
backends, and last night I committed the last of the necessary changes.
Both printers should now work -- in theory, anyway.
As I don't own or have access to either printer, this code has received no testing whatsoever, and as such might result in kittens swallowing the earth with impeccable wide-eyed cuteness as they mew and cry out for belly rubs. Oh, the humanity!
If there's someone out there who wouldn't mind donating a printer to the cause, or at least be willing to go a few rounds of testing, drop me a line.
Do it for Free Software. Do it for World Peace. Do it for Kittens.
June 30, 2015 @ 22:27 EDT
June 29, 2015 @ 08:15 EDT
Ongoing Dyesub Photo Printer Developments
Gutenprint 5.2.11-pre1 was released this weekend. It contains the usual support for a pile of new printers, and improvements for many previously-supported models. I'll only speak about stuff I had a hand in:
First, the newly-supported models that are reported to be working quite well:
- Canon SELPHY CP820 and CP910
- Citizen CW-01 / Olmec OP900
- DNP DS620/DS620A
- Mitsubishi CP-3800DW
Next, new models that were added but have received no testing:
- Sony UP-CR10L (aka DNP SL10)
- Shinko S1245 
Models that have much-improved support:
- DNP DS40/DS80/RX1 
- Citizen CX/CX-W/CY 
- Canon SELPHY CP900
- Kodak 605, 6800, and 6850 
- Mitsubishi CP9550 family (including the CP9550DW-S!)
- Sony UP-DR200
Finally, models that are improved or added, but will require muh more work before they are considerd useful:
- Mitsubishi CP-D70/D707/K60/D80 
- Ciaat Brava 21 
- Kodak 305 
- Kodak 8810
- Shinko S6145 
- Shinko S6245
 The Shinko S1245 is notable in that I've already completed a full-featured backend that just needs testing with a real printer.
 These models are all related, and use an unknown color scaling/dithering algorithm that must be reverse-engineered before the printers become usable.
 The Kodak 68x0 family in particular is consirerably more robust in the face of errors, media mismatches, and status reporting.
 The DNP/Citizen backend was greatly improved, and is far, far more robust than it used to be. Error detection and recovery, general buffer management, handling media/printjob mismatches, and even general status queries were all improved.
Oh, just to forestall the question, all printers with multicut modes (eg 2x6 strips) have full support, but will require a minor patch to be applied to Gutenprint before compiling.
I'll end this with my usual request for testers, especially ones with access to the Shinko S1245, Sony UP-CR10L, and DNP SL10 models since the work is already completed. As for what's next, the Shinko S6245 is the most promising candidate.
Thanks go out to everyone who has helped -- be it testing or providing USB dumps; sending over documentation (Yay, Shinko!), or actual printers (Yay, LiveLink!). There are others I would like to acknowledge but they have asked to remain anonymous. Thank you, all.
June 12, 2015 @ 21:47 EDT
May 26, 2015 @ 02:38 EDT
May 24, 2015 @ 14:09 EDT
May 14, 2015 @ 15:32 EDT
May 13, 2015 @ 20:53 EDT
May 12, 2015 @ 18:06 EDT
May 01, 2015 @ 21:23 EDT
April 28, 2015 @ 20:33 EDT
April 22, 2015 @ 02:00 EDT
Holy Exploding Battery, Batman!
- Battery acid doesn't smell particularly good
- You can never have too much baking soda on hand
- I got damn lucky that the only other damage was some paint
One bit of luck -- These batteries have two weeks left on their no-questions-asked 2-year full replacement warranty. With luck they'll replace them both.
April 11, 2015 @ 14:11 EDT
April 05, 2015 @ 09:37 EDT
February 17, 2015 @ 23:17 EST
Progress on the Shinko S1245, S6145, and S6245
A few weeks ago, a kind gentleman at Sinfonia sent me a pile of documentation on their S1245, S6145, and S6245 printers.
The S6145 and S6245 use a similar command language to the S2145, but the S1245 is quite different. So I decided to start with the latter, and created a new backend for it. It's now complete, but needs testing.
Support for the S6245 will probably follow, likely added into the existing S2145 backend as most of their code will be shared.
Unfortunately, the S6145 is another matter. While its command language is quite similar to the S2145, it has some peculiar data format requirements.
While the spool data is packed 8-bit RGB, the printer driver (aka our backend) is expected to convert it to 16-bit planar YMC+L data. That is easy enough to accomplish, except the data also needs to be massaged via an unknown algorithm combined with an opaque data blob that the printer supplies.
If this sounds familiar, it's because that sounds eerily similar to what the Mitsubishi K60/D70/D707/D80 printers require, complete with a file providing the raw lamination data and pile of tabular data that feeds into the transformation algorithm. This is strong evidence that the S6145, the CIAAT Brava 21, Kodak 305, and those Mitsubishi models all use the same basic print engine.
The Sinfonia rep wasn't able to provide any further details on the algorithm, though he did provide a set of binary x86 and x86_64 libraries that perform the necessary transformations. So it's a sort of bad news, good news situation.
Anyway. At this point, the S1245 backend is ready for testing, and since I can't justify buying yet another high-end photo printer, that means I'll need a volunteer to test this stuff out.
In the mean time, I'll probably work on support for the S6245, which will also eventually need testing. Then I'll move on to the S6145, get the core backend in place, then teach myself some x86_64 assembly and get to reverse-engineering the necessary algoritms and maybe eventually get somewhere.
So, does anyone have a spare S1245, S6245, and/or S6145 printer to toss my way? It's for a good cause!
January 18, 2015 @ 08:36 EST
January 07, 2015 @ 06:58 EST
Happy new year, y'all...
Due to some major unexpected expenses and an annoying (if minor) bout of pneumonia, my new year's plans were considerably less ambitious than in recent years.
This time, I watched the sunrise from Alice Wainright Park, with a view over Biscayne Bay, in the Vizcaya district of Miami.
It was a fallback position, because for some ungodly reason the powers that be locked up all parks on both Key Biscane and Virginia Key.
I'm not sure if I'll write up some sort of retrospective of the year, but I have been keeping myself busy.