No matter what acquisition method you use, you will finally get some compressed data. I expect most of data will be output at the baseport (0x378 at the normal parallel port), and if you are using my Bochs patched, you will see lines with O0,<something> in profusion. First try to run several distinct subjects, for instance, a blank page and your printer test page to see where large differences are found. Forget about sparse signals, like accesses tagged as O2,XX or I1(XX), for this first attempt.
Then you will need to prepare yourself for several discovering experiments. You will have to use simple programs like Xpaint or bitmap to make your "drawings". See some example test patterns I have used to inspect my printer:
A block of known dimensions like this is useful for some tests. You may need to experiment with several block sizes to discover what is the size of your packets. Some times it is not apparent where it have changed, for a change in one packet can propagate to many others. In that case, you will need a shifted pixel bitmap like the shown in the xpaint image below. A very important note is select margins zero when printing. Probably you will use MS-paintbrush for this purpose. It introduces a white margin in the paper (and so, in the compressed data stream), so before printing set the four margins to zero, after entering the dialog with Alt-t. If you forget to do this, all your bitmap will be shifted and much more difficult to understand.
In the first experiments, don't push too much. It is better to do many small experiments, than a large one trying to cover every possibility. And also, don't be so economic. Spare some time trying to "understand" the language of your printer. Print several times the same subject (a simple block like the first figure, for instance) and try to find where the similarities reside, and what's meaningful or what don't matter. Remeber the enemy have spoiled the terrain with many garbage to make your life difficult or near to impossible.
Thou that follow my counsel will reach the final victory!
This second bitmap was one of my final test patterns. Notice that the first line have an interesting, almost random pattern. It is not line noise. I made it to convince myself that my compression algorithm reconstruction was correct.
Draw a strategy to analyze your compressed data. For instance, draw many 1-line bitmaps with (1) 16 white dots + 1 black dot; (2) 64 black + 1 white, (3) 15 white + 1 black; etc. Your first goal is to know the size of a full filled packet. My packets were 4 bytes long, but yours can be oher sizes. If you do a systematic analysis, it is not so very difficult to find out.
Dont' desperate if something goes wrong, or seems too random. Nothing is random, because it must be printed and your printer is very, very much more stupid and dumb than you! If something is going wrong it is because you are not prepared yet to more complex experiments. Try many sizes of patterns and prefer simple patterns. Count the number of valid packets M$-windows is sending to your printer. Count both with white pages and with a page with a single 63 pixel line just at the upper row (to do this experiment, create a 64x1 with Xpaint and fill every pixel except the last with ink). Why 63 and not 64? Because this will cause most of bits in the packet flip and will be most visible!
Look at the compressed data for my winprinter, as I've given in the first article of this series. It was not easy at all to decipher it! I have made many experiments (about a hundred pages printed, I guess). Well, I'm not a genius, so I had to experiment more as I expect you will do.
Next time I will show more details on the protocol discovering and some settings of my printer and how I discovered them. It's just a wrap-up of the series. If you have some question, while the matter is hot, please ask me by e-mail. I plan to port more printers, if someone give me another winprinter as a gift. I will not buy another printer, because I have plenty of printers now. Who wants another GDI printer ported to Linux?