shulman@topaz.RUTGERS.EDU (Jeff Shulman) (11/08/85)
Delphi Digest Thursday, 7 Nov 1985 Volume 1 : Issue 4
Today's Topics:
CRC Algorithm
Print to disk
RE: Print to disk (Re: Msg 3073)
RE: Print to disk (Re: Msg 3079)
new 300/1200 baud apple modem
Manx C & Hyper
Chernicoff Wrong?
RE: Chernicoff Wrong? (Re: Msg 3092)
RE: Chernicoff Wrong? (Re: Msg 3109)
----------------------------------------------------------------------
From: CHESLEY (3055)
Subject: CRC Algorithm
Date: 3-NOV-20:02: Developer's Corner
I was approached recently by someone who wanted my PackIt CRC
algorithm. I said, "Sure, I'll mail it to you," and then forgot all
about him... Sorry about that, whoever you were.
The following is the CRC routine used in PackIt. I thought some other people
might find it usefull as well.
The routine calculated the CRC on a block of bytes, and can be called
repeatedly to do the CRC over more than one block. It's taken from
some documentation on XModem/CRC, and then verified against
Tanenbaum's book Computer Networks. It's supposed to be CRC-CCITT, but
I never swear to these things...
Function: Return the CRC on the block pointed to by blk, of size
sz, starting with the crc oldcrc.
Algorithm: From Tanenbaum and some XModem/CRC documentation.
Comments: There are faster, table driven algorithms for CRC, but
most applications are speed limited by the comm channel, so this
is plenty good enough. */
crc(oldcrc,blk,sz)
unsigned oldcrc; char *blk; long sz;
{
register unsigned crc;
register char *ptr;
register long cnt;
register unsigned i;
crc = oldcrc; ptr = blk; cnt = sz;
while (cnt--) {
crc = crc ^ ( ((int) *ptr++) << 8 );
for (i = 0; i < 8; i++)
if (crc & 0x8000) crc = (crc<<1) ^ 0x1021;
else crc <<= 1;
};
return(crc); }
------------------------------
From: RICHARDGROSS (3073)
Subject: Print to disk
Date: 5-NOV-18:22: Programming
Does anyone know of a utility for printing a report or other printer
oriented file to the disk instead? In other words, a spooler or other
utility which will intercept and redirect printer output to a disk
file, on a floppy system. Obviously, the spooled files would have to
be manipulatable, and not self-destructive after printing the way some
utilities seem to work. Thanks. -Rich Gross
------------------------------
From: PEABO (3079)
Subject: RE: Print to disk (Re: Msg 3073)
Date: 5-NOV-19:19: Programming
Rich,
Most Mac programs take advantage of the graphics features of the Mac
when printing ... the file which is put on disk is a series of
Quickdraw pages, and it not directly manipulable (as you point out)
even if you manage to capture it. It is just barely possible that you
could write a substitute print spooler that would convert such a thing
into a MacDraw document ...
However, I assume what you really want is some kind of draft mode disk file,
that could be captured and manipulated as a text-only file. Within the
limitation of text -only output, I imagine that could be done. Would you want
to be able to do this with any program, or are you really after something like
an export of selected records from a database?
peter
------------------------------
From: RICHARDGROSS (3113)
Subject: RE: Print to disk (Re: Msg 3079)
Date: 6-NOV-15:01: Programming
Thank you for your cogent reply. I need to worry only about text
files in order to upload datafiles in a particular format. The
utility would have to work with a variety of output sources--data
bases, word processors, etc.
------------------------------
From: PIZZAMAN (3083)
Subject: new 300/1200 baud apple modem
Date: 5-NOV-19:38: Bugs & Features
Has anyone had the opportunity to try the new apple modem? I tried one
using the Hayes Smartcom II software, to see if it really was Hayes
compatible. It seemed to work o.k. at 300 baud, following the auto-log
on sequence nicely. However, whenwhen switched to 1200 baud, it would
not respond to the aauto-log on commands. It did respond to manual
log-on, and sseemed to work without hitch. any experience out there?
barry
------------------------------
From: KENWINOGRAD (3084)
Subject: Manx C & Hyper
Date: 5-NOV-19:52: Programming
Hi. Okay....PRAM, BRICKLES and HangMan are now submitted to Peabo and
should shortly show up in the User-Supported Database. A word or two
of interest to Manx C users: it appears the reason why these programs
bombed with the hyperdrives, is the way I linked the final standalone
version of each of these programs. As Manx specified, I linked each
program with the 'mixcroot.o' module and included Manx's '.con' DRVR
resource in the application file....this presumably would allow
perfectly acceptable MAC stand-alone programs while at the same time
allowing the use of Unix-style I/O calls. Out of desperation (no one
likes getting letters and messages about how your programs
bomb....especially when they are your main source of income !!), and
with the hint that not only did these programs bomb with HyperDrive
but also with a cache called PowerCache (none of which do I have)....I
decided to re-link the programs with the 'sacroot.o' module, remove
the '.con' DRVR from the application resource file and ensure that no
Unix-style I/O is used anymore. VIOLA !! Now everything works fine on
all systems. So what exactly is the problem ?? Sheepishly, I must
admit, I don't know. It's hard to get to into the problem for me
without a hyper or a cache....my guess, sight unseen, is that both
hyper and cache, work by either installing a new desk accessory in the
apple menu or by somehow creating another dedicated DRVR, and that
that DRVR and Manx's DRVR are not at all compatible roommates. Sorry
about that not-too-technical guesswork.....but if your programs ever
work fine almost everywhere but bomb on a hyper, I hope this message
helps you. WHEW !!@@#$#!
[ I have the new versions uploaded to Topaz. Rather than post these programs
I will mail them out to people who request them. NOTE: The *only* changes
made affect people who use the HyperDrive or PowerCache. If you run from
floppies you do *not* need these new versions. Please only one request
per site. - JSS]
------------------------------
From: MACMAG (3092)
Subject: Chernicoff Wrong?
Date: 5-NOV-23:33: Programming
I was just looking at Stephen Chernicoff's book: Macintosh Revealed, unlocking
the toolbox Volume 1.
On page 99, Second phrase from the top, you can read the following:
"The pointer at 0(A5) points to the first of the QuickDraw globals, ThePort"
So we can conclude that he states that A5 points to ThePort.
On the same page, just before the green box, we see the following line:
InitGraf (@ThePort)
We can conclude that in Pascal, Initgraf needs a pointer to ThePort.
So why can't we write in Assembly
PEA (A5)
_InitGraf
Why does everyone write:
PEA -4(A5)
_InitGraf
Isn't (A5) supposed to point to ThePort and not -4(A5) ???
Or i Or is Chernicoff wrong?
Rich.
------------------------------
From: BRECHER (3109)
Subject: RE: Chernicoff Wrong? (Re: Msg 3092)
Date: 6-NOV-04:42: Programming
In Chernicoff's "The pointer at 0(A5) points to the first of the
QuickDraw globals, ThePort," note that "at 0(A5)" is not the same as
"A5." It is not A5 which contains the pointer to thePort; rather, it
is the memory location pointed to by A5 which contains the pointer to
thePort.
Here is the situation after the customary InitGraf (just using some arbitrary
addresses for example):
A5 contains $60008:
Address Contents
$60008 $60004
$60004 thePort (pointer to current grafPort)
$60002 and below Other QuickDraw globals
The parameter to InitGraf is the address of the last (in ascending
memory order; first as listed in IM QuickDraw chapter) of the
QuickDraw globals, namely, thePort. Pea -4(A5) tells InitGraf that
QuickDraw's globals are to lie just below the address contained in A5;
InitGraf puts the address you pass to it into A5 (and initializes the
globals).
If you did Pea (A5) -- which is the same as Move.L A5,-(SP) -- then
you would be trying to put two things into one register: a pointer to
the globals, and one of the globals (thePort).
------------------------------
From: MACMAG (3114)
Subject: RE: Chernicoff Wrong? (Re: Msg 3109)
Date: 6-NOV-15:06: Programming
That's a good explanation, but it doesn't clarify the situation.
From what I remember, when you read @ThePort in Pascal, it means: A pointer to
ThePort.
Chernicoff says: 0(A5) is a pointer to ThePort.
Do you agree with these statements?
If so, why can't we just pass 0(A5) instead of -4(A5). He does say
that InitGraf needs a pointer to thePort and that 0(A5) is a pointer
to ThePort.
Can you further clarify this bit?
Thanks. Rich.
------------------------------
End of Delphi Digest
********************