It's been a while since I've posted anything about the Tick Farm. The simple explanation is that very little work has been accomplished over the past two years, due to a lack of time and money.
I hope that will change just after the new year, when I finish getting my now-tenant-free Melbourne house fixed up and put on the market, freeing up a pile of capital and greatly improving my cash flow. My agent tells me it should sell pretty quickly.
In the mean time, last weekend I popped up there for the first time in three months, and encountered this:
The service line was completely tangled up in the downed tree, but thankfully the damage was isolated to the formerly-attached-to-the-pole conduit, which needed to be completely replaced.
The local power cooperative came out to kill the power so I could effect repairs, and two days, $30 worth of supplies, a great deal of cursing (punctuated by a severe bout of no-running-water assplosions) later, the county inspector signed off, SVEC hooked me back up, and the Tick Farm was returned to its half-completed, neglected glory.
The Melbourne house was intended to be on the market a month ago, but thanks to the time of year, it's been impossible to schedule painters, which is just as well as I've needed the time to effect a pile of necessary repairs. With luck, I'll complete all but one of them this weekend. The three hour drive each way is getting quite old though...
There is a scene in The Mummy where Beni, confronted with the titular Mummy, cycles through prayers of multiple religions in an attempt to find the one that will work.
This sight, next to a porcelain throne at work, reminded me of that scene.
(Or maybe this post should be called Teach the Controversy?)
I'm happy to announce that I just committed support for the HiTi P520L to Gutenprint and the selphy_print backend repos. There's still some more work to be done to round out the feature set (eg the full complement of print sizes and job accounting), but it works well enough to generate properly corrected 4x6" prints.
As per tradition, I included the first successful print, and followed it up with a color chart to make sure the color correction was functional.
This was an independent implementation, using HiTi's "Open Source (All Rights Reserved)" driver, USB sniffs, and decompiled chunks of the Windows drivers as references.
Looking forward, the P525L, P720L, and P750L should work with only minimal additional effort, but their other models will require generally more work -- Despite HiTi's use of a consistent command language across most of their model line, they rely on host-supplied data tables and a lot of magic nubmers.
Consequently, additional models will require direct access to the specific printers (or at least detailed USB sniffs). Donations, hardware, and/or documentation welcome!
...onto the next bit of joy!
Update 2019/11/15: P520/P525 firmware v1.19-v1.21 fail to communicate under Linux. This affects HiTi's official drivers as well. I was able to identify the underlying problem and managed to implement a workaround.
I'm pleased to announce that the recent Gutenprint 5.3.3 release includes nearly-complete support for Kodak 7000/7010/7015 and 8810 printers. This effort has led to enhancements and bugfixes in other Sinfonia models, most notably the Kodak 605 and Sinfonia CE1/CHC-S6245, but all models have seen further robustness improvements.
I say 'nearly complete' because over the last couple of weeks, I've been enhancing their capabilities beyond the features exposed by their Windows drivers, notably:
- Additional print sizes (eg multicut sizes on the 8810)
- Backprinting support for the Kodak 7010/7015 models Note: completely untested, likely broken!
Last week I stumbled upon a major bug in Gutenprint's dyesub driver core. It's a very old bug, going back all the way to the beginning, resulting in an incorrect gamma curve being applied. It's now fixed, yielding visibly improved output, with better contrast and tonal range. It's win-win-win!
To get this fix you will need a post-5.3.3 release, snapshot, or compile the code out of revision control.
Over the last month or so I've been doing a lot of work on the Shinko/Sinfonia printer codebases, with the goal of unifying and re-using code that is identical between the various models. This will make adding new printers easier, and also reduces the opportunity for bugs.
I've about reached the end of the second phase, with a net reduction of about 1600 lines of code. This is in spite of adding quite a bit of functionality to the Kodak 605 backend.
Meanwhiile, last week I briefly had access to a Kodak 7000 and a Kodak 8810 printer. I learned enough to add preliminary support for them into the codebase, and while I believe status queries, media reporting, and printing should now work, printing has yet to be confirmed.
The Kodak 6900 and Sinfonia S3/S2245 also landed some experimental support, but I expect there's still quite a bit of effort required to get things to the point where everything works properly.
Anyway. to make a long story short, there has been a great deal of churn
in the codebase, and I only have access to two of the affected models.
Here is the full list:
- CIAAT Brava 21
- Kodak 605
- Kodak 6800
7000, 7010, and 7015 Kodak 8810
- Kodak 6900
- HiTi M610 (Not the X610!)
- HiTi P910L
- Sinfonia E1 / CHC-S1245
Sinfonia S2 / CHC-S2145 Sinfonia CS2 / CHC-S6145
- Sinfonia CE1 / CHC-S6245
- Sinfonia S3 / CHC-S2245
As always, if you have access to one, send me an email. Or better yet, a printer!
Update 2019/06/05 -- Added HiTi M610 as another S2245 variant
Update 2019/08/12 -- Marked off the models that are confirmed working
After the recent improvements to the older Sony printers (Most notably, the UP-CR10L is now confirmed working after a bunch of little modifications!) I decided to take another look at some more recent (but not necessarily new) models:
They're a diverse bunch, but share a common data format and communications protocol built on top of what appears to be standard HP-PJL.
I believe I've successfully figured out the data format for all of these models, and written the intial backend parser. The next step is to write the Gutenprint rasterizer code, but anything beyond that will require access to one or more of these models so I can obtain details about the communication protocol they use, and of course, test my code out.
I still don't know how to obtain media type and counter information out of the older Sony models (UP-DR150/UP-DR200/UP-CR10L) too, so without someone out there willing to perform sniffs of Sony's Windows or OSX drivers doing their thing (or send me a printer!) I'm not likely to be able to progress beyond the current state of affairs.
There are a bunch of other Sony models, mostly consumer-focused, that may be worth trying to support too, but I'd rather spend my time on models that are still commercially relevant. Of course, hardware in hand trumps everything else!
Anway. Back to the bit mines..
Over the past month or so I've been figuring out the Sony UP-D895 & UP-D897 Medical/Scientific Thermal printers. They're most commonly seen on ultrasound workstations, but can be found nearly everywhere.
I'm happy to report that Gutenprint (5.3.2-pre or newer) now has full support for these two models with feature parity with the Windows drivers, including basic status & error reporting.
In the process of figuring out the UP-D895/897, I discovered a lot more about other Sony printers, resulting in the UP-DR150 & UP-DR200 getting basic status reporting and error handling as well. Now I just need someone to test this out and let me know if my guesses are correct! :)
Looking ahead, the UP-D898 series is a somewhat different beast, eschewing the old Sony comms format/protocol in favor of something wrapped in HP-PJL. It shouldn't be too hard to support, but someone's going to have to send me one first.