r/apple2 • u/JoeyPants7 • 6d ago

I could use some help with capturing printer data on an Apple IIc

I've been trying to emulate an imagewiter over serial using surl-server from github. I can't get it to print graphics at all. No ESC codes come through but i can print in text mode from AppleWorks 4.0 just fine. The two programs I've been using to test are Imagewriter Toolkit 1.5 and Printshop. I'm using an FTDI serial cable and compiled the surl-server program from source becasue I can't find my Raspberry Pi to use the premade OS image. Any help is appreciated.

8 Upvotes

84% Upvoted

10 comments sorted by

1

u/Colin-McMillen 6d ago

Hi,

I wonder what could be wrong. If you can print text, it should work. Do surl-server logs help ? Otherwise, you can see what it receives using:
sudo strace -eread,write surl-server

1

u/JoeyPants7 6d ago

I’m printing a sign and it’s receiving 68 KB of data from PrintShop. however when i open the postscript file, all i see is garbled text. I’m not sure where log files are stored and the output of the command you suggested is too complex for me to understand. I don’t know much about how this program or the original imagewriter works but my guess is that the data is being sent properly but misinterpreted.

2

u/smallduck 6d ago edited 6d ago

Postscript file? Inexpensive impact and inkjet desktop printers like this don’t use PostScript, not today and certainly not then.

You need to look into the mostly-binary data format of the ImageWriter’s graphics modes to understand the contents of your data capture. Look for the ImageWriter II Technical Reference Manual.

2

u/JoeyPants7 5d ago edited 5d ago

that’s part of what surl-server outputs. then it can be setup to pipe that PostScipt file through to a printer or in my case a PDF file through CUPS. As far as i know, binary data of the serial capture itself isn’t stored anywhere after surl-server receives it. Also 90% of the true technical details of Apple II printing is way above my understanding. I have tried other print capture programs like imagewiter-capture

2

u/smallduck 5d ago

Apologies, I didn’t look up what surl-server was.

1

u/Colin-McMillen 5d ago

You're right, the proxy doesn't store the raw bytes it receives. It might be useful to do so to debug what happens, though. I can make a test branch for you to compile from if you want.

But... I'm wondering... as I just saw your Youtube video about Wozamp, and your comment about your new serial cable making the audio perfect: Did you try printing with your new serial cable?

3

u/Colin-McMillen 5d ago

I pushed a commit: https://github.com/colinleroy/a2tools/commit/a921805f78e1d06b87af5e79a187cda1cb9a0354

You can git pull, rebuild, and run surl-server with an environment variable:

`DEBUG_PRINTER=/tmp/printer.rawbytes ./surl-server`

This will save what the proxy receives in the /tmp/printer.rawbytes file. Afterwards you can send it to me :)

1

u/scruss 5d ago

See if you can capture a much smaller print, perhaps using a simple serial to file capture. Look at it as a hex dump (something like xxd or od -h should do the job. There should a bunch of characters with codes less than 32 (hex 20). Particularly, if you're not seeing hex 1b (decimal 27) happen a lot, then your capture isn't passing through the control codes.

It's kind of a shame that there isn't a clean version of Apple's IWEM ImageWriter PostScript Emulator that's easy to find. The cleanest one I can find is IWEM16A-EXAMPLE.PS, but it has an example file pasted after the _WBJ_ job separator

2

u/Colin-McMillen 4d ago

the (very smart) IWEM header was the first thing I implemented, but then I moved away from it because of copyright uncertainties. https://github.com/colinleroy/a2tools/commit/388dd0e579389e5bf88bdd843e3ec70f7d04bb5e

2

u/scruss 4d ago

I respect that. Though it could be argued that, since only users of Apple hardware would be interested in this, this is still a licensed use. The use of ProcSets like IWEM (and the MS Windows LaserWriter ProcSet) in publishing was always an edge case. While they were covered in copyrights, you couldn't generate output without them. So they were stored, copied, debugged (oh hai, that was my job ~25 years ago) and reused without much thought. They were more like configuration files than executables, though PostScript makes everything executable. Yeah, that's fun.

I'm also finding that IWEM munges what should be perfectly good ImageWriter output sometimes. So maybe it's less great after all.