wrstuden@loki.stanford.edu (Bill Studenmund) writes:
[snip]
>> The Stylewriter actually works similarly: sending this 'status poll'
>> command causes the printer to send back a single byte. If it is ready for
>> more data, the byte is 0xA0. If it's busy doing something, various other
>> bytes are returned (0x90 and 0x10 seem to be error conditions, and there
>> are many others). The serial connection must be at 57600 baud, _no_
>> handshaking. (I have watched the Apple drivers specifically turn off
>> handshaking, and turning it on doesn't do anything helpful.)
>
>Sounds like you've done some real hacking! How didi you watch them
>do this? I ask as I'd like to do some spying on other MacOS drivers
>too.

You are absolutely correct.  Serious hacking was involved.

(I should mention that I'm mostly a MacOS programmer, but I can hold my
own in unix.)

*** Caution: MacOS hacking tricks to follow -- if you aren't pretty
    good with Macsbug, they may not make sense.
***

I spent some time fooling with both the StyleWriter and StyleWriter II
drivers.  It turns out that they do things quite differently, and it=20
helped a lot to have two examples to work from.

To see how the serial port was being set up, I set an A-trap break (atb) on
_Control that only stopped on the right driver numbers (-6 and -7 for port
a input/output, or -8 and -9 for port b input/output). I don't remember
exactly what the Macsbug command line was, but it was a conditional atb
that compared a word on the stack to the desired driver number. You then
get to decode the arguments on the stack and poke around in the parameter
block to see what arguments are being passed.  Newer versions of Macsbug
have templates for the parameter blocks that make this _much_ less
painful than it sounds.

I spent a long time tweaking two Macsbug macros to set up the
serial data snooping.  I ended up putting them in a 'mxbm' resource in
my Debugger Prefs file because they are longer than the Macsbug command
line.  Here they are (straight from my Debugger Prefs):

atb write (a0+#24)^.W=3Dfffffff9 ';echo write (a0+#36)^;
dm (a0+#32)^ (a0+#36)^;g'

atb read (a0+#24)^.W=3Dfffffffa ';t;echo read (a0+#36)^ (a0+#40)^;
dm (a0+#32)^ (a0+#40)^;g'

(I split the lines for this message -- each 'atb' and all that follows
should be on one line)

To use these, first turn on logging ('log filename'), and then execute
each macro once.  They will install A-trap breaks that dump information
to the Macsbug log each time _Read or _Write is called on the proper=20
device, and then continue execution. (In the commands, fffffff9 and=20
fffffffa are hex representations of the negative serial driver=20
reference numbers for port A (the modem port, if memory serves).)

The write snooper displays the number of bytes to write, and the data
buffer passed to the trap. The read snooper steps over the _read trap, and
then displays the number of bytes requested, the number of bytes actually
read, and the contents of the data buffer. (At least it tries. Looking at
it again, I don't think the read snooper ever really got anything but the
number of bytes requested. Oops. Fixing it is left as an exercise to the=20
reader. ;-) Output in the Macsbug log looks like this:=20

A-Trap break at 00230D3C 'PDEF 007D 0F6E'+579C: A003 (_Write)
 write
  0000001B
 Displaying memory from (a0+#32)^
  00D6CBA0  4717 00BE BEBE BEBD  037F FFE0 8E02 01FC  G**=E6=E6=E6=E6=87*=7F=
**=E9***
  00D6CBB0  8903 1FFF C083 0203  F88F 0044 68FF F740  =E2***=BF=C9***=E8*Dh*=
*@

A-Trap break at 00230D2A 'PDEF 007D 0F6E'+578A: A002 (_Read)
Step (over)
  'PDEF 007D 0F6E'
     +578A  00230D2A   _Read      ,Sys                       ; A402       | =
A402
 read
  00000005
  00000000

Pretty ugly, but it had the information I needed.

This is a REALLY slow way to get serial data.  I did the testing
on a 7100, and it took a couple of hours to dump all of the data for
the Stylewriter I driver printing one page.  (Of course, I just left it
unattended with the Macsbug screen flashing every few seconds and went
out to lunch. :-)

Oh yeah, to turn off the whole mess, turn off logging and do an A-trap
clear ('atc').

If I were going to do much more of this sort of thing, I'd probably write
an INIT that did it without Macsbug and logged to a file in a nicer format.
It shouldn't be difficult to do, and it would make the whole process much
easier.=20

-- monroe