The RISC OS Printing System (part 6)

Printer connection checker

While writing last month's article, I remembered a small application I had written to check the printer connection, stopping the computer hanging when the printer was off-line or there was fault. This was included on a past Archive disc but since then I have upgraded it, and I realised that looking at the programming involved would help to explain the connection between prin ers and computers, so I have included it in this series.

Printer connections...

Most printers are connected to computers by either a serial port or a parallel port. The parallel port is by far the most common, so I will describe this connection in detail. Remember, all signals mentioned here are digital. The signals have only two states, on and off. On means there is a voltage on the wire (usually about 5 volts) and off means no voltage.

As its name implies, a parallel connection involves sending data down a set of wires in a parallel fashion. There are 25 wires, 16 of which send the actual data - hence they are known as the data lin s (eight signal + eight earth lines) - the others help the computer and printer to 'talk' to each other. Most printers have a buffer memory to help speed up the printing process (printers are very sl w devices compared to computers). This means data is sent to the printer in blocks (the size of the block being dependent on the printer buffer size).

Buffer full?

How does the computer find out if the printer buffer is full?

A technique called handshaking is used. One wire is used by the printer to send a signal to the computer. This line, called BUSY, has a signal (goes high) when the printer is busy! Another line OT FAULT goes low (no signal) when there is a fault or if the printer is off-line. Both of these lines are part of the status register for the parallel port. There is a SWI called "Parallel_Op" which can be used to read the state of all the lines. To read the data and status registers

SYS "Parallel_Op",0 TO ,data%,status%
Nbsy%=status%>>7:REM NOT BUSY line (inverse of BUSY)
Nerror%=(status%>>3)AND1:REM NOT error line

I have a small non-WIMP Basic program called PPort which does this (hopefully on this month's disc). Run it and see the Nbsy (NOT busy) and Nerror (NOT error) lines change when your pr nter is off-line or switched off or even disconnected. (Only disconnect or connect with all  equipment switched off!)

So these lines tell the computer what state the printer is in, and whether it is ready to receive data. It should therefore be possible to produce an application to detect these conditions and s op the RISC OS printing system hanging the computer when printing cannot start. The main problem to overcome is the interception of a start print routine from any application. This routine could be triggered by pressing the Print key, a mouse button click on a menu print option or on a print start icon in a window.

Intercepting WIMP events

There is a method of intercepting WIMP events before they are passed on to the application to which they belong. This method uses the WIMP filter system. Since this is straying from the printing syst m, I will only outline the technique.

When any WIMP event occurs, a programmer may intercept it, find out under what conditions it was produced and elect to either pass it on to its application or not. So, if an event is about to st rt up the printing routines in the application, and the printer isn't ready for some reason, the event can be intercepted. All this has to be done in a relocatable module, but is reasonably straight- orward. This would cure the problem but is less than user-friendly, leaving the user in the dark as to why the printing fails to start. An improvement can be made by having the module not only i tercepting the print starting event but also signalling a WIMP program to open a small message window.

The application !PrtChkCon (on the monthly disc) uses this technique; it doesn't place an icon on the iconbar (since it is only a small background utility). To quit it, open the task window and click the menu button with the pointer on PrtChkCon entry, then move down to Task 'PrtChkCon' and across to the quit option.

I have included inside the !PrtChkCon directory the source code for its module (modsrc) for those of you who would like to see how the filtering/intercepting is achieved. The small WIMP front-en application that takes care of the error reporting and printer connection checking has been squashed down a little so that it takes up minimal memory.

The parallel port checking is in FNF (in the status registry the 'NOT busy' line is bit 7 and the 'NOT error' is bit 3). If the printing has been re-directed to file, the connection to the printer is irrelevant, so this is checked by reading a system variable Printer$Path. This variable contains the path for the output of the currently selected printer. If the printer output is directed to the pa allel port, its value is devices#buffers3:$.Parallel . If the printer output is to file, its value is the full file path. If the character string '::' is contained in this value, the output mu t be a file path.

Well that wraps it up for this month - I hope this utility is useful. Next time, I hope to look into intercepting a PDumperSupport SWI so that colour separation may be added o the printing system.


Source: Archive Magazine 13.9
Publication: Archive Magazine
Contributor: Brian Pickard