Implement SCSI printer device (SCLP)

[uweseimet]

See https://www.staff.uni-mainz.de/tacke/scsi/SCSI2-11.html) for information on the SCSI-2 printer device.

Steps a client has to take:

1. The client sends RESERVE UNIT in order to get exclusive access to the printer device. rascsi shall remember this reservation based on the initiator ID of the client. Implementing RESERVE/RELEASE UNIT is mandatory for printer devices,
2. The client sends the data to be printed with the PRINT command. rascsi shall save these data to a temporary file, which will later be printed. Clients may send these data in chunks, i.e. there can be several PRINT command before the data to be printed are complete. New data are just added to the temporary file. This is consistent with how WRITE for block devices works, where data for a sequence of blocks can be sent as a complete sequence, or be split into smaller WRITE requests.
3. The client triggers printing by sending SYNCHRONIZE BUFFER. Without an explicit trigger the printer device would not know when the data are complete. This is a conceptual difference to parallel port printers, which are character devices. This is also the reason why maybe only printing of files can be supported: A well-defined end of data marker is required.
4. The client sends RELEASE UNIT.

Notes:

• SEND DIAGNOSTIC is mandatory for printer devices, but currently does not return any data.
• Printing can be cancelled before SYNCHRONIZE buffer was sent with STOP PRINT.
• The maxium transfer size per PRINT command is limited to 4096 bytes, see https://github.com/akuker/RASCSI/issues/669 for details.
• "lp -oraw" as default command ensures that the data are sent to the printer unchanged.
• The print command to be used can be specified as parameter when attaching the SCLP device, e.g. "cmd=lp ...".
• The timeout in seconds a reservation is valid without receiving new printer commands is configurable with the "timeout=numeric_value" property. Default is 30s.

[uweseimet]

@akuker @rdmark I am interested in your feedback. Initially this ticket was about a proprietary printer device, but SCSI-2 supports an "official" device. Are you aware of any existing drivers for the Mac?

[rdmark]

@uweseimet This is a neat and potentially very useful idea, in particular for platforms that don't have a network printer spooler. For Macintosh it's slightly less valuable, since it comes with Apple's LaserWriter drivers which can be used over Ethernet with a modern CUPS printer server via, say, Netatalk's papd daemon. It's relatively straight-forward to set up network printing: https://github.com/akuker/RASCSI/wiki/AFP-File-Sharing#Print_Server

I don't have first-hand experience with SCSI printers on Mac, but after some cursory research I ran into the MicroDry line of printers from ALPS, which has an interesting connectivity solution in that they use the parallel port on PCs, but has a SCSI dongle for hooking up to Macs. There are references to drivers for Mac but I haven't been able to find them archived yet:

https://aikishugyo.no-ip.org/alps/maint/mac-scsi.html http://www.alps-printer.com/printers-md5000-c-3_12.html https://web.archive.org/web/20170322022853/https://www.alps.co.jp/brand/printer/drive/main.htm

[rdmark]

@uweseimet Have you considered creating an interface between the RaSCSI printer device and CUPS? This would give you plug'n'play network printing to any CUPS/AirPrint compatible printer that resides on the same network, potentially.

[akuker]

I am interested in your feedback. Initially this ticket was about a proprietary printer device, but SCSI-2 supports an "official" device.

(The opinions below are my own, and may not reflect the greater community) I very rarely use a printer anymore (except for printing shipping labels ;] ). From what I've seen, a lot of the vintage Mac community will use their machines for playing games from their childhood. I spent a bunch of time restoring an old ImageWriter, and after I got it working, I haven't used it since.

IMHO, there are other existing solutions that would allow for this. For example: https://www.retroprinter.com/

That being said.... I fully support adding this feature "because we can". I'm just not sure it will get a lot of use.

[uweseimet]

@rdmark An interface to CUPS might be a second step. Not sure, though, whether it would be worth the effort. But let's try to do the first step first ;-). Actually, by being able to select the printer to print to, you would be able to print to any available printer without knowing about CUPS on the client side. One could have, for instance, several LUNs, each LUN being a different printer, or representing different printer properties.

[uweseimet]

@akuker I agree that the group of users using this device would be limited. But just as you say, this is also about "because we can". And for platforms with some active develpment left (Atari) I assume that some users would not mind being able to print (again) without the need for a printer for the parallel port. Regarding Retro-Printer, that's hardware. Doing this in software (well, at least the RaSCSI hardware is needed) is more exciting ;-).

[rdmark]

Two arguments for this feature:

• When I got papd working seamlessly in my fork of Netatalk, there was a surge of interest and people sharing stories about printing from their old Macs to modern printers. Again, this may simply be because of the novelty of it, but at the very least it could be another "marketing" talking point for RaSCSI to raise awareness and interest in the project. :)
• Arguably, the by far broadest potential utility for vintage computers in this day and age, beyond the hobbyist aspect, is word processing. Word processing and printing go hand in hand. I've seen articles and blog posts over the years about a vintage computer as being an ideal tool for an author, what with the lack of distractions, so the idea is not entirely novel.

[uweseimet]

@rdmark Regarding word processing you are absolutely right. There were popular word processing applications for the Atari, and usually you cannot just (without losing formatting etc.) convert files in their proprietary format to, let's say, OOXml, in order to print it from a current platform with an up to date word processing application. I would definitely not be able to convert my thesis, for instance, which contains a lot of embedded graphics, footnotes, a table of contents and an index, everything automatically generated and/or maintained on the fly (WYSIWYG) by the word processor. I remember that somebody once told me that it was obvious that I had used TeX for it. I had to smile, because I never ever used TeX, but the TempusWord word processor for the Atari.

Once more point I'd like to point out, Atari once againi: Besides excellent software emulators there are also some clones, i.e. you do not necessarily need an original Atari machine in order to be able to print with a word processing application for the Atari. Instead, you can run your Atari emulator, print to a file from within the emulator, and then use your native OS to print this file. This is not the real thing, of course ;-).

[uweseimet]

There is at least one feature that is required but currently not support: Transfers of data chunks that are no multiples of 512. The printer device requires this feature. When it is present there is also a better chance to improve the currently incomplete implementation of READ/WRITE LONG, which also works on data chunks of any size.

[uweseimet]

:-) It works! My Atari just printed the first page.

>lpstat -t
scheduler is running
system default destination: LaserJet
device for LaserJet: ipp://lp/ipp
LaserJet accepting requests since Mo 14 Feb 2022 23:46:59 CET
printer LaserJet now printing LaserJet-14.  enabled since Mo 14 Feb 2022 23:46:59 CET
LaserJet-14             root            733184   Mo 14 Feb 2022 23:46:59 CET

Regarding CUPS I don't think anything special is needed. Everything (printers) can be configured on the Pi. The client needs to use a printer driver that matches the printer connected to the Pi anyway. The Pi just passes these data to the printer, using the "-oraw" option. In addition, the Pi may be running LPRNG instead of CUPS. Anything CUPS-specific would not necessarily work.

[uweseimet]

@rdmark I was faster than expected. You might want to add support for the SCLP device to the web UI. Two optional parameters are supported, which is reported by the protobuf interface, including their defaults.

  SCLP  Supported LUN numbers: 0-31
        Parameter support
        Default parameters: cmd=lp -oraw:timeout=30

[akuker]

Great job, @uweseimet !!! This is a very cool feature! Thank you for adding it!

Do you have any documentation that we could put on the wiki for Atari users to take advantage of this new functionality? The documentation in the code is probably too low level for 99% of the users.

[akuker]

Tonight I learned that Apple made a SCSI Laser Printer..... so looks like there's going to be a Phase 2 to this project. ;] Hopefully I can find one!!

https://lowendmac.com/1988/laserwriter-iisc/

[uweseimet]

@akuker The RaSCSI printer implementation is not Atari-specific. I claim (but can be wrong), that it is a generic SCSI printer with a minimum set of features. I am sure that the Apple printer is more specific, and it should be possible to extend the existing implemenation accordingly, provided there is documentation on the Apple printer. It is possible, of course, that the Apple printer uses a proprietary protocol, which would require a special implementation. There were also two printers for the Atari that can be classified as SCSI printers, but they could only be connected to the ACSI port, which is a subset of SCSI. These printers used their own protocol and expected the computer to send a bitmap with the rendered data for a page.

Regarding user documentation, this documentation will have to be part of the printer drivers, because each platform has its specific approach on how to print to such a printer. I assume that usually you just install SCSI printer drivers, just like you install your drivers for the Daynaport.

Regarding the Atari in particular I will publish a documentation together with my set of RaSCSI client tools for the Atari (realtime clock, shutdown, printer). I intend to release this tools as soon an official RaSCSI release with the new features is available.

[uweseimet]

There is a webpage now with more information on the Atari tools: https://www.hddriver.net/en/rascsi_tools.html.

[uweseimet]

@akuker Do you know where to get a driver/system extension for a LaserWriter SC? I only can find extensions for printers with network support, but not with SCSI support. But such drivers must exist for the two SCSI printer models once offered by Apple.

[marciot]

I managed to track down some documentation on implementing print drivers for classic Mac OS and added it to this page SCSI Printer

[marciot]

Does this SCLP driver take Postscript or bitmaps? Writing a Mac OS PostScript driver from scratch would be a herculean task, but it may be possible to use the documentation in the Learning to Drive document to implement a simple driver that sends over a B&W bitmap for printing, similar to the ImageWriter driver.

[marciot]

Also, it looks like Apple actually made two SCSI printers. They made the LaserWriter SC, which uses bitmaps like the ImageWriter while the LaserWriter IISC is a PostScript printer. The Learning to Drive document does mention that the low-level print drivers can either support text (i.e. postscript) or bitmaps.

[uweseimet]

@marciot It takes raw printer data by default, but this can vary depending on the print command. Please see the initial comment in scsi_printer.cpp for details.

[marciot]

So I wrote the developer of PrintToPDF, a classic Mac OS print driver, and asked for the source code for that. He sent me his work, but not the source for a PDF library he did not own, so it is a start but not a turn-key solution. With the documentation I found earlier, I might now have enough info to implement a Mac OS print driver from scratch. A couple of observations, however:

• Converting QuickDraw calls to vector-based PostScript would be a huge undertaking. I believe emulating the LaserWriter IISC and using Apple drivers would be the best solution for high-quality print graphics.
• Making a quick and dirty QuickDraw bitmap print driver seems like it might be within the scope of a one-man project, however.
• Since the SCLP driver doesn't know about bitmaps, perhaps one approach is to embed a bitmap inside a Postscript file. This does not appear to be hard.

[akuker]

@marciot - FYI: PotatoFi has tracked down a LaserWriter II, and I found a LaserWriter IISC controller board on ebay, so I'm thinking of going down the LaswerWriter IISC route. I just need to figure out how to get a LaserWriter half-way across the US for a reasonable price :) Then I can merge the two together and start doing some data captures.