Laser Print DA
| Volume Number: | | 2
|
| Issue Number: | | 2
|
| Column Tag: | | C Workshop
|
Laser Print DA for Postscript 
By Mike Schuster, Software Engineer, MacTutor Contributing Editor
Mike Schuster wins $50 for the outstanding program of the month with this feature article. Congratulations Mike!
Using a POSTSCRIPT Server on AppleTalk
Most Macintosh applications generate printed pages by issuing a sequence of QuickDraw calls which are intercepted and translated into printer dependent commands by Apple's Printing Manager. This technique has the advantage that an application never needs to know what kind of printer the user has connected to the Macintosh. It also allows the application to write to the screen and the printer with a single device independent routine. On the other hand, it does not provide the application access to the extensive page description capabilities nor the wide range of printer resolutions available in modern electronic printing systems, such as those embodied in Adobe Systems' POSTSCRIPT page description language, Apple's LaserWriter™ laser printer and Linotype's Linotronic™ 100 typesetter. This is because Quickdraw is much more limited in it's abilities than is POSTSCRIPT, and hence only a fraction of the capability of a POSTSCRIPT machine is needed to interpret a set of Quickdraw commands.
In this article, I show how your application may overcome QuickDraw and the Printing Manager limitations by communicating directly with a POSTSCRIPT server on an AppleTalk network. In addition, I describe the implementation of Laser Print, a desk accessory that concurrently spools POSTSCRIPT programs you create with MacWrite, Edit or Just Text, and sends them to the Apple LaserWriter or other POSTSCRIPT compatibile printer. You can use this printing desk accessory to explore programming your LaserWriter directly, using an example postscript file in this article. In future issues of MacTutor, we will expand on postscript programming techniques with a regular postscript column and this desk accessory will be invaluable as a way of sending your programs over Appletalk to the LaserWriter. The Laser Print DA is written in MegaMax C.
Deep Background by The Editor
[When a Macintosh Application prints, the text and graphics that it writes to a quickdraw port to display on the screen are sent to a special quickdraw port used by the printing manager. You print text and graphics by drawing into this port with Quickdraw, just as if you were drawing on the screen. The Printing Manager changes the pointers to the low-level drawing routines so that Quickdraw calls drive the printer rather than the screen. In this way, MacWrite can display a what- you- see- is- what- you- get screen version of your document with one set of routines and it can go to either the screen or the printer thanks to the clever Printing Manager. The whole point of the Print Manager and associated device drivers is to convert Macintosh Quickdraw text and graphic descriptions into page bit maps that can be printed. This design works very well with the Imagewriter.
Now comes the LaserWriter, after the Macintosh. This device is very different from anything Apple has ever produced and one can only wonder who was the mastermind behind it. It is so much more powerful than the Mac itself, one has to wonder if it was an outside design. In some respects the LaserWriter is a high powered Macintosh. Substitute POSTSCRIPT for Quickdraw. Substitute 0.5 Meg of ROM for 64K ROM. Substitute 1.5 Meg of RAM for 128K RAM. Substitute a 12 Mhz 68000 for an 8 Mhz 68000. Connect the two with the Appletalk serial port. The problem for Apple was how the lowly Macintosh could be made to talk to this very intelligent device with a minimum of changes to the Mac itself.
The answer was since all Macintosh software writes to the screen (and hence the printer via the Print Manager) via Quickdraw, those same routines could drive a LaserWriter by converting Quickdraw descriptions into POSTSCRIPT. The purpose of the Laser Prep file is to convert quickdraw commands to POSTSCRIPT. The Laser Prep file is downloaded into the LaserWriter as a POSTSCRIPT application running within the LaserWriter. Normal Macintosh applications present Quickdraw documents to the Printing Manager, which invokes the LaserWriter device driver, downloads the Prep File into the LaserWriter (Initializing Printer...) which in turn converts quickdraw to POSTSCRIPT, which is interpreted by the built-in POSTSCRIPT interpreter within the LaserWriter (the 0.5 Meg of ROM) and finally converted to a 300 dot per inch page bit map (stored in the 1.5 Meg of RAM not taken up by Laser Prep, the POSTSCRIPT page description, and fonts) and printed! This double conversion is one reason the LaserWriter takes so long to print initially. It also explains why the LaserWriter often runs out of memory with some applications like Pagemaker, which uses a larger Prep file. In fact, the LaserWriter may be even more memory bound than the 512K Macintosh, if you can believe that! So limited is memory space that the new Laser Fonts from Adobe will probably require the new LaserWriter II to be useful, which is supposed to have 2 meg of RAM. A conversion kit is rumored to be available for upgrading current LaserWriters.
By sending a POSTSCRIPT file directly to the LaserWriter, you avoid having to down load Laser Prep, eliminate quickdraw to POSTSCRIPT conversion, free up RAM in the printer, and generally speed everything up. Plus, you avoid limitations of trying to represent in Quickdraw a much more extensive capability of POSTSCRIPT. Commands within the POSTSCRIPT file tell the printer that the file is to be interpreted and not printed. The fact that Aldus Corp. felt the need to write their own Prep File shows the limitations of trying to go from Quickdraw to POSTSCRIPT. Aldus needed some of the capabilities of POSTSCRIPT that the Apple Prep file would not supply. The very thin line in Pagemaker is one such feature that could not be represented without a new Prep file. This is not a happy situation since now you have two companies supporting two different prep file conventions. The smoothing algorithm of Apple is an example of how the user is stuck when two companies support a competing low level routine. The Aldus Prep file did not support smoothing until they had obtained a license from Apple.
Bill Bates of Knowledge Engineering saw all this conversion nonsense and recognized that the only way to really tap into the power of the LaserWriter was directly via POSTSCRIPT. His Just Text and LaserTool products create postscript files directly in the traditional typesetting method. The advantage of this is POWER. Direct control over every feature of POSTSCRIPT, with no Laser Prep quickdraw to POSTSCRIPT conversion hassles to slow things down. This brings up an interesting confrontation. Aldus follows the Macintosh guidelines using Quickdraw and converting to POSTSCRIPT. Would it be possible to go the other way and create a program that would interpret POSTSCRIPT into Quickdraw so that any POSTSCRIPT file could be displayed on the screen as a 'soft' LaserWriter Preview? We leave to the developer to ponder the implications of such a program.
POSTSCRIPT EXAMPLE
Figure 1 shows a drawing created on the LaserWriter by the POSTSCRIPT program listing in figure 2. As you can see, neither MacWrite, Word or Pagemaker could possibly create an image such as this, and yet for the LaserWriter, this is a snap! POSTSCRIPT is a programming language very similar to Forth. It uses reverse polish notation and a stack like Forth does. Arguments are pushed on the stack first, followed by the command that executes them. This requires the programmer to think backwards in some respects. Adobe Systems has just published two very good books on POSTSCRIPT programming. They are a tutorial and a reference manual, both available in Bookstores from Addison-Wesley. Look for a blue and red book under the title of POSTSCRIPT. This example is taken from the tutorial book on page 98. The lines beginning with %% are comments. The first line follows the Adobe specifications of %! to tell the interpreter within the LaserWriter that what follows are POSTSCRIPT commands to be executed rather than a bunch of text to be printed. This file can be executed by typing it in as a text file with Edit or MacWrite and using the Laser Print DA to down load it to the LaserWriter. After using postscript directly, I can see that what is now needed is some way that artistic POSTSCRIPT programs can be "placed" in page makeup programs like Pagemaker so that they can be edited and arranged with other text and illustrations. Of course Just Text does this, but without the advantage of a screen display representation of the final output. Well, enough of the introductions to the world of POSTSCRIPT programming. Let's get on with solving the hole Apple left us-- a utility to send POSTSCRIPT files directly to the LaserWriter. Our thanks to Mike for this very important and timely article. -Ed.]
A POSTSCRIPT Server at Work
When connected to an AppleTalk network, the LaserWriter functions as a server for the execution of POSTSCRIPT programs sent to it by applications running on client Macintosh workstations. The LaserWriter begins service by listening for an AppleTalk connection request from a client. It then executes the POSTSCRIPT program sent to it over that connection. Any error messages or other output produced by the program, other than the printed pages themselves, are transmitted back to the client over the same connection. When the LaserWriter receives an end-of-file indication from the client, it sends a matching end-of-file back to the client and terminates the execution of the program. After receiving the matching end-of-file indication, the client closes the connection and frees the server.
While the LaserWriter is busy servicing one connection, it refuses any additional connection requests. This refusal causes the requesting clients to queue up and wait for the server to become free. As soon as the current connection closes, the server accepts the request from the client that has waited the longest period of time. [This problem shows that a LaserWriter is really of no use to more than one person without a File Server to manage this queue of documents. Otherwise, everyone on the network sits around waiting for the printer to free up before he can get on with his work. Which brings us to the next great hole in the Apple Office-- a file server that spools files to the LaserWriter, allowing networked Macintosh computers to do something else after clicking print in the File menu! -Ed]
The communication between the LaserWriter and its client workstations is accomplished by means of the AppleTalk Printer Access Protocol (PAP). Apple specified this protocol in its publications Inside LaserWriter, Inside AppleTalk and the AppleTalk Manager chapter of Inside Macintosh. [See MacTutor, September 1985 for more on AppleTalk programming. -Ed.]
%!PS-Adobe-1.0
%%Title: Postscript Example
%%DocumentFonts: (atend)
%%Creator: Edit
%%CreationDate: 12/27/85 6:21 PM
%%Pages: (atend)
%%BoundingBox: 0 0 612 792
%%EndComments
%% Document prolog now follows
grestoreall
initgraphics
/pageproc {} def
%%EndProlog
%% Postscript Example Program
%% See page 98 of Postscript Tutorial Manual
%% Procedures now follow
/Times-BoldItalic findfont
36 scalefont setfont
/oshow %stack:(string)
{true charpath stroke} def
/circleofMacTutor
{15 15 345
{gsave
rotate 0 0 moveto
(MacTutor) oshow
grestore
} for
} def
%% Main Program Segment
250 400 translate
.5 setlinewidth
circleofMacTutor
0 0 moveto
(MacTutor Journal) true charpath
gsave 1 setgray fill grestore
stroke showpage
%% End of example program
%%Trailer
%%Pages: 1
%%DocumentFonts: Times-BoldItalic
Figure 2: A Postscript Example for Fig. 1
Calling the PAP Manager
The Printer Access Protocol Manager provides a set of routines which a client uses to communcate with a print server. Apple apparently intended that this manager was to be used only by the LaserWriter specific portions of the Printing Manager, since its documentation is not widely distributed. However, the manager does provide an easy way for applications to communicate directly with a POSTSCRIPT printer. [Apple has not been very forthcoming with any printing information on the Mac. -Ed]
The manager is implemented as a Macintosh device driver-like resource PDEF 10 in the LaserWriter resource file in your System Folder. The resource contains the implementation of the client PAP routines papopen, papwrite, papread, papclose, papstatus, and papunload. Before looking at the resource in detail, let us consider the functions of each of these routines.
The client application begins by issuing a papopen call to open a connection with the desired server. The C language form of the papopen call is as follows (int16 is a 16-bit signed integer and int32 is a 32-bit signed integer):
int16 papopen(refnum, printername, flowquantum, statusbuff, compstate)
int16 *refnum;
ptr printername;
int16 flowquantum;
papstatusptr statusbuff;
int16 *compstate;
Refnum is a pointer to a unique connection reference number returned after the connection has been opened. Printername is a pointer to the entity name of the server to which the connection is to be opened. Flowquantum is an integer specifying the size of the receiving buffer provided by subsequenct papread calls. Statusbuff is a pointer to a status record in which status information is returned to the client during the opening process. Finally, compstate is a pointer to the integer that the client monitors for call completion and error reporting. Its value is positive while the call is executing, zero if the connection was opened without error, and negative if the connection could not be opened.
Once a connection has been opened, the application sends data to the server by issuing papwrite calls and receives data from the server by issuing papread calls. Since the sending and receiving data streams are asynchronous with respect to each other, the application must be prepared to continuously consume data by reissuing papread calls while waiting for each papwrite call to complete. If this is not done, deadlock may result with the server and client each waiting for the other to consume data.
When all of the data has been sent, the application sends an end-of-file indication to the server by issuing a final papwrite call. The application must continue to issue papread calls until a matching end-of-file indication has been received. The application then closes the connection by issuing a papclose call.
The C language form of the papwrite call is as follows:
int16 papwrite(refnum, writebuff, datasize, eof, compstate)
int16 refnum;
ptr writebuff;
int16 datasize;
int16 eof;
int16 *compstate;
Refnum is the connection reference number returned by papopen.
Readbuff is a pointer to the buffer containing the data to be sent. Datasize is an integer containing the number of bytes in the buffer.
Eof is an integer containing a non-zero value if an end-of-file indication should be sent to the server. Compstate is a pointer to the integer that the client monitors for call completion and error reporting. Its value is positive while the call is executing, zero if the data was sent without error, and negative if the data could not be sent.
The C language form of the papread call is as follows:
int16 papread(refnum, readbuff, datasize, eof, compstate)
int16 refnum;
ptr readbuff;
int16 *datasize;
int16 *eof;
int16 *compstate;
Refnum is the connection reference number returned by papopen.
Readbuff is a pointer to the buffer into which the received data is to be placed. Datasize is a pointer to an integer in which the number of bytes of data received is returned when the call completes without error. Eof is a pointer to an integer in which then end-of-file indication received is returned when the call completes without error.
Compstate is a pointer to the integer that the client monitors for call completion and error reporting. Its value is positive while the call is executing, zero if the data was received without error, and negative if the data could not be received.
The C language form of the papclose call is as follows:
int16 papclose(refnum)
int16 refnum;
Refnum is the connection reference number returned by papopen.
At any time, whether or not a connection has been opened, the application may issue a papstatus call to find out the status of a server. The C language form of the papstatus call is as follows:
int16 papstatus(printername, statusbuff)
ptr printername;
papstatusptr statusbuff;
As in the papopen call, printername is a pointer to a three-part entity name of the server whose status is to be determined and statusbuff is a pointer to a status record in which the server's status is returned to the client. The structure of the status record is as follows:
typedef struct
{
int32 systemstuff;
Str255 statusstr;
} papstatusrec, *papstatusptr;
Statusstr contains a pascal string and systemstuff contains the AppleTalk network address of the server.
The final manager call, papunload closes all currently open connections, terminates all pending papread and papwrite calls, and disposes all of the manager's internal data structures. The C language form of the papunload call is as follows:
int16 papunload()
The PAP Manager Interface
As I mentioned previously, the client routines of the Printer Access Protocol are contained in the PDEF 10 resource of your LaserWriter resource file. As illustrated in figure 3, the resource begins with entries containing jump instructions to each of the client routines, followed by the routines themselves.
A client application calls a routine simply by loading the resource, pushing the appropriate parameters on the stack in the standard Pascal convention, and calling the appropriate entry point using a constant offset from the start of the resource. The implementation of this scheme for papopen is as follows (in this code, the global variable pap contains a handle to the resource):
int16 papopen(refnum, printername, flowquantum, statusbuff, compstate)
int16 *refnum;
ptr printername;
int16 flowquantum;
papstatusptr statusbuff;
int16 *compstate;
{
asm
{
subq.l #2,A7 % space for result
move.l refnum(A6),-(A7) % push parameters
move.l printername(A6),-(A7)
move.w flowquantum(A6),-(A7)
move.l statusbuff(A6),-(A7)
move.l compstate(A6),-(A7)
move.l pap(A4),A0 % get handle to resource
move.l (A0),A0 % get pointer to resource
jsr 0(A0) % papopen entry at offset 0
move.w (A7)+,D0 % return result
}
}
The Laser Print Desk Accessory
The Laser Print desk accessory spools POSTSCRIPT programs to a selected printer concurrently with the execution of many Macintosh applications. When Laser Print is selected from the Apple Menu, it presents a standard file dialog listing all of the text files on the current volume. You select the file containing the program you wish to send to a POSTSCRIPT printer. Laser Print will then send the contents of the file incrementally whenever your application calls the Macintosh routine SystemTask. Generally, Laser Print should continue to operate even if you quit your application and open another.
Before using Laser Print, you should connect your Macintosh to the AppleTalk network and choose a POSTSCRIPT printer with Apple's Choose Printer desk accessory. The POSTSCRIPT programs themselves may be either keyed manually (see the example in figure 2), or be generated by the Printing Manager itself if you hold down the command and F keys just after clicking on the OK button in your application's Print dialog. The Printing Manager will display the dialog 'Creating PostScript File' instead of the usual message 'Looking for LaserWriter.' When your application finishes the printing process, you can open Laser Print and select the file 'PostScript.'
When Laser Print is opened, its accopen routine is called. Accopen presents a standard file dialog and, if a file was selected, proceeds to open the file, obtain the resource containing the PAP Manager's routines, and then issues a papopen call to open the connection to the printer. The entity name of the printer selected with Choose Printer is contained in the system resource PAPA -8192 (0xE000).
When Laser Print's routine accctl is called by SystemTask, it first checks to see if the connection has been opened. If not, accctl simply exits. As soon as the connection opens, accctl issues a papread call, reads the first 512 bytes of the file and sends them to the printer by issuing a papwrite call. Subsequently, accctl issues papread calls while waiting for each papwrite to complete. When a papwrite completes, accctl reads the next 512 bytes from the file and issues another papwrite.
When accctl has sent the last byte of data, it sends an end-of-file indication to the printer. As soon as the matching end-of-file has been received, accctl closes itself by calling CloseDeskAcc. Accclose closes the file, the connection, and unloads the PAP Manager resource.
Laser Print itself is complied as a DRVR 25 resource and placed in a file of type DFIL and creator DMOV. Hence, you can use Apple's Font/DA Mover application to paste the desk accessory into your System file. (It will have the familar DA icon.) Before you install it, however, use Apple's ResEdit application to copy the resource PDEF 10 from the LaserWriter resource file into the file containing Laser Print. Then change the resource's identifier from 10 to -15574 and name it 'Laser Print PDEF'. Now you must use John Mitchell's FEdit application to change two occurances of the hex bytes 'A31E' to 'A71E' in the resulting PDEF -15574 resource. These changes causes the PAP Manager's routines to allocate space for their internal data structures in the system heap.
After you have installed Laser Print, you must use Apple's ResEdit application to set the 'System Heap' bit of both Laser Print's DRVR and the PDEF resources. Even though the resource identifiers may have been changed by the Font/DA Mover, you should be able to easily find them by name. This step is necessary to avoid a system crash if you exit your application before Laser Print DA completes it's task. [Since both ResEdit and FEdit are necessary utilities to complete this application, they are being provided on the source code disk #6 along with the Laser Print DA and the C source code listed below. -Ed.]
The remainder of the article contains the C source of Laser Print. This version uses header files supplied by MegaMax, Inc, version 2.1. You must link Laser Print with a slightly modified version of the file 'acc.c'. This version allocates and maintains a locked area in the system heap for Laser Print's global variables. The modifications are as follows (lines marked with a + should be added, lines marked with a - should be removed; unmark lines are included for context only). A complete listing of the acc.c file of desk acc. header information is given at the end of this article for those converting to another language.
add.l D4,D0 ;add size of string space
+ dc.w 0xa722 ;newhandle() & clear to zeros
- dc.w 0xa322 ;newhandle() & clear to zeros
move.l (A7),A1 ;save in dctlstorage
move.l D0,-(A7) ;save result code
+ btst #6,4(A1) ; locked?
+ bne nounlock
+ tst.l20(A1)
+ beq nounlock
move.l 20(A1), A0
dc.w 0xa02a ;hunlock() the storage
+ nounlock:
move.l (A7)+,D0 ;result code
+ move.l (A7)+,A0 ;remove second parameter
+ move.w D0,16(A0);force result code
- addq.l #4,A7 ;remove second parameter
move.l D0,-(A7) ;save result code
+ btst #6,4(A1) ; locked?
+ bne nounlock
+ tst.l20(A1)
+ beq nounlock
move.l 20(A1), A0
dc.w 0xa02a ;hunlock() the storage
+ nounlock:
move.l (A7)+,D0 ;result code
+ move.l (A7)+,A0 ;remove second parameter
+ move.w D0,16(A0);force result code
- addq.l #4, A7 ;remove second parameter
move.l (A7)+,SAVEA4
/*
* laser print, version 1.0, Megamax C v2.1
* a spooler of postscript programs
*
* copyright 1985 by mike schuster for MacTutor
* all rights reserved
*/
/* macintosh headers */
#include <acc.h> /* desk acc. */
#include <device.h>/* device managers */
#include <pack.h>/* package managers */
#include <res.h> /* resource manager */
#include <toolbox.h> /* toolbox routines */
/* n-bit signed integers */
#define int16 int
#define int32 long
/* desk accessory header */
ACC
(
0x2400,/* needtime, accctl */
6,/* 0.1 seconds */
0,/* no events */
0,/* no menu */
11, /* length */
"Laser Print" /* title */
)
#define PAPTYPE "PDEF" /* pap protocal resource type */
#define PAPID rsrcid(10) /* pap protocal resource id */
#define ENTITYTYPE "PAPA" /* server entity name res type */
#define ENTITYID 0xe000 /* server entity name res id */
typedef struct /* pap status record */
{
int32 systemstuff;
char statusstr[256];
} papstatusrec, *papstatusptr;
int16 dctlrefnum;/* driver reference number */
int16 fstate; /* file waiting */
int16 ostate; /* open waiting */
int16 wstate; /* write waiting */
int16 rstate; /* read waiting */
int16 frefnum; /* file reference number */
int16 prefnum; /* pap reference number */
int16 fres; /* last file result */
int16 pres; /* last pap result */
int16 weof; /* write eof */
int16 reof; /* read eof */
char wbuff[512]; /* write buffer */
char rbuff[512]; /* read buffer */
int32 fsize;/* file size */
int16 wsize;/* write size */
int16 rsize;/* read size */
sfreply reply; /* sfgetfile reply */
handle pap; /* handle to pap manager code */
handle entity; /* handle to server entity name */
papstatusrec status; /* pap status */
/* desk accessory open routine */
int16 accopen(dctl, pb)
dctlentry *dctl;
ptr pb;
{
/* save driver reference number */
dctlrefnum = dctl->dctlrefnum;
/* obtain a postscript program */
while (!fstate)
{
/* present standard file dialog */
if (!getfile(&reply))
break;
setcursor(*getcursor(watchcursor));
/* open file file */
if (fres = fsopen(reply.fname, reply.vrefnum, &frefnum))
{
frefnum = 0;
break;
}
/* get server entity name */
if (!(entity = getresource(ENTITYTYPE, ENTITYID)))
break;
hlock(entity);
/* get pap manager code */
if (!(pap = getresource(PAPTYPE, PAPID)))
break;
hlock(pap);
detachresource(pap);
/* open connection to the server */
if (pres = papopen(&prefnum, *entity, 1, &status, &ostate))
{
ostate = 0;
break;
}
/* file opened and connection opening */
fstate = 1;
wstate = rstate = 0;
weof = reof = 0;
}
initcursor();
/* close down if no file opened or no connection opening */
if (!fstate)
closedeskacc(dctl->dctlrefnum);
return 0;
}
/* desk accessory close routine */
int16 accclose(dctl, pb)
dctlentry *dctl;
ptr pb;
{
/* close file if opened */
if (frefnum)
fsclose(frefnum);
if (pap)
{
/* close connection if opened */
if (!ostate)
pres = papclose(prefnum);
/* unload pap manager */
pres = papunload();
disposhandle(pap);
}
return 0;
}
/* desk accessory control routine */
int16 accctl(dctl, pb)
dctlentry *dctl;
ptr pb;
{
/* file opened and connection opening? */
while (fstate)
{
/* if connection still opening, wait */
if (ostate > 0)
break;
/* if last papwrite has not finished, or if waiting for a match- */
/* ing eof indication, continue issuing papreads */
if (!pres && (wstate > 0 || (weof && !reof)))
{
if (rstate <= 0)
if (pres = papread(prefnum, rbuff, &rsize, &reof, &rstate))
rstate = 0;
break;
}
/* if any pap call failed or if done, close ourselves */
if (pres || ostate < 0 || wstate < 0 || (weof && reof))
{
fstate = 0;
closedeskacc(dctl->dctlrefnum);
break;
}
/* if last papread finished, start another */
if (rstate <= 0)
if (pres = papread(prefnum, rbuff, &rsize, &reof, &rstate))
rstate = 0;
/* read more from file, optionally, set eof indication */
fsize = sizeof wbuff;
if (fres = fsread(frefnum, &fsize, wbuff))
weof = 1;
wsize = fsize;
/* send data to server */
if (pres = papwrite(prefnum, wbuff, wsize, weof, &wstate))
wstate = 0;
break;
}
return 0;
}
/* desk accessory prime routine */
int16 accprime(dctl, pb)
dctlentry *dctl;
ptr pb;
{
return 0;
}
/* desk accessory status routine */
int16 accstatus(dctl, pb)
dctlentry *dctl;
ptr pb;
{
return 0;
}
/* return an device driver flavored owned resource id */
int16 rsrcid(id)
int16 id;
{
return (((- dctlrefnum - 1) << 5) | 0xc000) + id;
}
/* present the standard get file dialog */
int16 getfile(reply)
sfreply *reply;
{
point where;
ostype type;
where.a.h = 75; where.a.v = 50;
sfgetfile(&where, "", 0l, 1, "TEXT", 0l, reply);
return reply->good;
}
/* open a connection */
int16 papopen(refnum, printername, flowquantum, statusbuff, compstate)
int16 *refnum;
ptr printername;
int16 flowquantum;
papstatusptr statusbuff;
int16 *compstate;
{
asm
{
subq.l #2,A7
move.l refnum(A6),-(A7)
move.l printername(A6),-(A7)
move.w flowquantum(A6),-(A7)
move.l statusbuff(A6),-(A7)
move.l compstate(A6),-(A7)
move.l pap(A4),A0
move.l (A0),A0
;moveq #'o',D0
;dc.w 0xff01
jsr 0(A0)
move.w (A7)+,D0
}
}
/* receive data from server */
int16 papread(refnum, readbuff, datasize, eof, compstate)
int16 refnum;
ptr readbuff;
int16 *datasize;
int16 *eof;
int16 *compstate;
{
asm
{
subq.l #2,A7
move.w refnum(A6),-(A7)
move.l readbuff(A6),-(A7)
move.l datasize(A6),-(A7)
move.l eof(A6),-(A7)
move.l compstate(A6),-(A7)
move.l pap(A4),A0
move.l (A0),A0
;moveq #'r',D0
;dc.w 0xff01
jsr 4(A0)
move.w (A7)+,D0
}
}
/* send data to server */
int16 papwrite(refnum, writebuff, datasize, eof, compstate)
int16 refnum;
ptr writebuff;
int16 datasize;
int16 eof;
int16 *compstate;
{
asm
{
subq.l #2,A7
move.w refnum(A6),-(A7)
move.l writebuff(A6),-(A7)
move.w datasize(A6),-(A7)
move.w eof(A6),-(A7)
move.l compstate(A6),-(A7)
move.l pap(A4),A0
move.l (A0),A0
;moveq #'w',D0
;dc.w 0xff01
jsr 8(A0)
move.w (A7)+,D0
}
}
/* obtain server's status */
int16 papstatus(printername, statusbuff)
ptr printername;
papstatusptr statusbuff;
{
asm
{
subq.l #2,A7
move.l printername(A6),-(A7)
move.l statusbuff(A6),-(A7)
move.l pap(A4),A0
move.l (A0),A0
;moveq #'s',D0
;dc.w 0xff01
jsr 12(A0)
move.w (A7)+,D0
}
}
/* close a connection */
int16 papclose(refnum)
int16 refnum;
{
asm
{
subq.l #2,A7
move.w refnum(A6),-(A7)
move.l pap(A4),A0
move.l (A0),A0
;moveq #'c',D0
;dc.w 0xff01
jsr 16(A0)
move.w (A7)+,D0
}
}
/* unload pap manager */
int16 papunload()
{
asm
{
subq.l #2,A7
move.l pap(A4),A0
move.l (A0),A0
;moveq #'u',D0
;dc.w 0xff01
jsr 20(A0)
move.w (A7)+,D0
}
}
/* acc.c routines modified */
#define SAVEA4 694
extern int _GLBLSIZE;
extern accopen();
extern accprime();
extern accctl();
extern accstatus();
extern accclose();
_accopen()
{
static _callacc();
int oid;/* owned resource id number */
asm {
tst.l 20(A1) ;see if open() already called
beq cont ;do init stuff if not
pea accopen(PC)
jsr _callacc(PC)
addq.l #4,A7
unlk A6
rts
cont:
movem.l D1-D5/A2-A4,-(A7) ;save registers
move.l SAVEA4,-(A7) ;save old A4 value
move.l A0, -(A7) ;push parameters for user
move.l A1, -(A7)
move.w 24(A1), D0 ;compute owned resource ID #
neg D0;driver refnum = -ID - 1
subq #1,D0
asl.w #5, D0
ori.w #0xc000, D0
move.w D0, oid(A6)
subq.l #4,A7 ;load in the strings
move.l #'DATA',-(A7)
move D0,-(A7) ;string ID depends on DRVR ID
dc.w 0xa9a0;getresource()
clr.l D4;set size to 0 if str res not present
tst.l (A7);movea doesn't set cond. codes
movea.l (A7)+,A3 ;handle to string resource in A3
beq nodata
subq.l #4,A7
move.l A3,-(A7)
dc.w 0xa9a5;sizeresource()
move.l (A7)+,D4 ;size of string resource in D4
nodata:
dc.w 0x3a3c ;move.w #_GLBLSIZE,D5
dc.w _GLBLSIZE
ext.l D5
neg.l D5 ;_GLBLSIZE is negative
move.l D5,D0
add.l D4,D0 ;add size of string space
dc.w 0xa722 ;newhandle() & clear to zeros
dc.w 0xa029 ;hlock()
move.l (A7),A1 ;save in dctlstorage
move.l A0,20(A1)
move.l (A0),A4
adda.l D5,A4 ;A4 between strings and globals
move.l A4,SAVEA4
tst.l D4;if no strings, don't block move
beq nodata2
move.l (A3),A0 ;start of string resource
move.l A4,A1 ;strings go above A4
move.l D4,D0 ;length of strings
dc.w 0xa02e ;blockmove()
move.l A3,-(A7) ;get rid of the string resource now
dc.w 0xa9a3 ;releaseresource()
nodata2:
subq.l #4,A7 ;Get the init code
move.l #'INIT',-(A7)
move oid(A6),-(A7) ;init ID depends on DRVR ID
dc.w 0xa9a0 ;getresource()
tst.l (A7) ;movea doesn't set cond bits
movea.l (A7)+,A3 ;handle to init resource in A3
beq noinit(PC) ;check to see if init resource existed
move.l (A3),A0
jsr (A0) ;execute the init code
move.l A3,-(A7)
dc.w 0xa9a3 ;releaseresource()
noinit:
jsr accopen(PC)
move.l (A7)+, A1
move.l D0,-(A7) ;save result code
btst #6,4(A1) ; locked?
bne nounlock
tst.l 20(A1)
beq nounlock
move.l 20(A1), A0
dc.w 0xa02a ;hunlock() the storage
nounlock:
move.l (A7)+,D0 ;result code
move.l (A7)+,A0 ;remove second parameter
move.w D0,16(A0);force result code
move.l (A7)+,SAVEA4
movem.l (A7)+,D1-D5/A2-A4 ;restore registers
}
}
static _callacc(func)
int (*func)();
{
asm {
movem.l D1-D5/A2-A4,-(A7) ;save registers
move.l SAVEA4,-(A7)
move.l A0,-(A7) ;last parameter pushed first
move.l A1,-(A7)
move.l 20(A1), A0
dc.w 0xa029 ;hlock()
move.l (A0),A4 ;set up A4 globals and strings
dc.w 0x3a3c ;move.w #_GLBLSIZE,D5
dc.w _GLBLSIZE
neg D5 ;_GLBLSIZE is negative
adda D5,A4
move.l A4,SAVEA4
move.l func(A6),A0
jsr (A0) ;call user function
move.l (A7)+, A1 ;first parameter device cntrl entry
move.l D0,-(A7) ;save result code
btst #6,4(A1) ; locked?
bne nounlock
tst.l 20(A1)
beq nounlock
move.l 20(A1), A0
dc.w 0xa02a ;hunlock() the storage
nounlock:
move.l (A7)+,D0 ;result code
move.l (A7)+,A0 ;remove second parameter
move.w D0,16(A0);force result code
move.l (A7)+,SAVEA4
movem.l (A7)+, D1-D5/A2-A4 ;restore all saved registers
}
}
_accprime()
{
_callacc(accprime);
}
_accctl()
{
_callacc(accctl);
}
_accstatus()
{
_callacc(accstatus);
}
_accclose()
{
asm {
move.l A1, -(A7)
}
_callacc(accclose);
asm {
move.l (A7)+, A1
move.l D0,-(A7) ;save result code
move.l 20(A1),A0 ;deallocate global and string space
dc.w 0xa023
clr.l 20(A1) ;remove from device control
move.l (A7)+,D0 ;restore result code
}
}
