shulman@caip.RUTGERS.EDU (Jeff Shulman) (08/13/86)
Delphi Mac Digest Tuesday, 12 August 1986 Volume 2 : Issue 36
Today's Topics:
RE: List Manager LDEF (Re: Msg 525)
RE: Very Weird Problem (Re: Msg 542)
RE: Very Weird Problem (Re: Msg 553)
RE: Very Weird Problem (Re: Msg 552)
RE: Very Weird Problem (Re: Msg 553)
RE: Very Weird Problem (Re: Msg 542)
RE: Very Weird Problem (Re: Msg 563)
RE: Very Weird Problem (Re: Msg 563)
Laserwriter FONDs
Driver Needed
lightspeed c
RE: lightspeed c (Re: Msg 11541)
RE: LW cartrige recharging
Medical Uses of a MAC
RE: Medical Uses of a MAC (Re: Msg 11554)
RE: Medical Uses of a MAC (Re: Msg 11554)
Medical Uses of a Mac
RE: lightspeed c (Re: Msg 11541)
Paranoia Vindicated
RE: Paranoia Vindicated (Re: Msg 573)
RE: Paranoia Vindicated (Re: Msg 575)
char speed
lightspeed C (more grumbles)
RE: lightspeed C (more grumbles) (Re: Msg 11617)
RE: lightspeed C (more grumbles) (Re: Msg 11622)
RE: lightspeed C (more grumbles) (Re: Msg 11623)
-----------------------------------------------------------------------
From: MARSHG (551)
Subject: RE: List Manager LDEF (Re: Msg 525)
Date: 9-AUG-12:37: Developers' Corner
Strictly speaking, yes that extra byte is the high half of the word that the
compiler uses. I just like to think of it as structure alignment... The
problem is that somewhere inside the list manager, the code checks for the
signed byte to be negative rather than for the bit being set hence the need for
filling the upper byte with -1's.
As far as the scroll bars disappearing, that's the way IM says scroll
bars shoul be implemented. I think it's a little strange but I do
like the Bible says...
Marsh
------------------------------
From: PEABO (553)
Subject: RE: Very Weird Problem (Re: Msg 542)
Date: 9-AUG-16:29: Programming Techniques
I bet something is trying to use A0 to reference memory. Mouse-freeze
is caused by trying to reference memory above 8 megabytes, due to the
cretinous design of the Mac hardware (TAKE THAT BURRELL SMITH! ZAM!
POW!)
The problem is that all the I/O logic is wired into the upper 8 megs
of address space, and the command, status, and data registers of these
I/O devices respond to 'memory' reads and writes over many, many
thousands of bytes of address space, and they do things when
referenced, such as reset the SCC (and hence lose mouse interrupts).
This was done because it saved a few gates in the design of the Mac digital
board. It was a "neat hardware hack".
I think it makes the Mac a unnecessarily fragile programming environment, and I
mutter under my breath everytime I do something that causes a mouse freeze
because I know what a trivial programmer error can cause it.
peter
------------------------------
From: ASMCOR (557)
Subject: RE: Very Weird Problem (Re: Msg 553)
Date: 9-AUG-22:09: Programming Techniques
Peter -
I've never heard it explained before... do you know how to unfreeze the mouse,
then? Like TMON does?
Jan
------------------------------
From: LOFTUSBECKER (559)
Subject: RE: Very Weird Problem (Re: Msg 552)
Date: 10-AUG 00:49 Programming Techniques
What do you mean, "then using A0 as an address"? The hangup comes
_before_ any instructions other than Move.L #$28EFFFF,A0 are executed!
I am beginning to think that this may be a bug in TMON, since it must
be doing something to make the move, display results, etc., etc. But
the problem definitely isn't anything I'm doing afterwards -- it happens
even if I don't do anything afterwords.
- Lofty
------------------------------
From: LOFTUSBECKER (560)
Subject: RE: Very Weird Problem (Re: Msg 553)
Date: 10-AUG 00:51 Programming Techniques
Hmm. Okay, that's probably what's causing the freeze. So maybe
it's a bug in TMON? (all right, all right -- a feature). Sounds as if I
should boot up with Macsbug and see if that has the same problem. If
not, it's definitely TMON.
- Lofty
------------------------------
From: LOFTUSBECKER (563)
Subject: RE: Very Weird Problem (Re: Msg 542)
Date: 10-AUG 02:53 Programming Techniques
Mystery solved. It came from the fact that a read to any of quite a
few high-memory addresses (above the Mac's real address space) will reset
the serial ports, with disastrous consequences for the mouse; and the fact
that, while running TMON, one window I had open displayed the memory
starting at the address in A0.
The result was that when I loaded a large number into A0, TMON would
quite properly try to read the memory that A0 pointed at. This read would
cause the mouse freeze. It's not a problem with my Mac, and not really a
bug in TMON. But it's worth a warning: if you get a mouse freeze while
debugging, look to see what windows you have open and whether (as I did)
you are accidentally causing high-memory reads.
(much relieved) Lofty.
------------------------------
From: MACLAIRD (564)
Subject: RE: Very Weird Problem (Re: Msg 563)
Date: 10-AUG 04:08 Programming Techniques
Perhaps we need a _SCCReset trap?
_Laird
------------------------------
From: PEABO (567)
Subject: RE: Very Weird Problem (Re: Msg 563)
Date: 10-AUG 15:33 Programming Techniques
I think it's a bug in TMON. The restrictions on accessing high memory are well
known to the guy who wrote it (after all, he wrote an unfreeze routine!!) so I
think he should check for that kind of thing before doing an automatic refresh
of an anchored window. Yes, it should be possible to read or write the I/O
space from the debugger, but you should have to work at it to do it.
peter
------------------------------
From: DSACHS (11530)
Subject: Laserwriter FONDs
Date: 9-AUG-23:03: Programming
I have noticed that the flag word n the FOND resources for the Laserwriter (
except Courier) has a value of $1000. According to the documentation in the
latest supplement, bits 2-12 of this word should be zero. Can anyone cast
further light on this situation?
------------------------------
From: GTALMO (565)
Subject: Driver Needed
Date: 10-AUG 04:29 Programming Techniques
Hello;
I'm looking for a ( hoppefully free) modem driver for use with MS BASIC. i.e. I
will be writing a BBS program in MS BASIC, and I don't really wnt to wright my
own driver (If there's allready one out there). Also any help in finding XMODEM
subroutines would be VERY helpful.
Thank You!
Greg TALMO
------------------------------
From: CHUQ (11541)
Subject: lightspeed c
Date: 10-AUG 04:46 Programming
I've got some questions/comments on LightSpeed C. Anyone want to help out or
kibbitz?
o I'm running into "out of memory" errors. Usually when I have a
window open to a changed file. It always happens when after the
compile, probably when the code is being written into the segment. My
segments are about 30K or so. I'm running a 512K with RAM HFS. Is
the memory used by HFS THAT critical to LSC? Closing the open windows
or moving the module to a new, smaller segment solves the problem.
(sigh)
o Related: LSC doesn't talk about tuning. Am I better off with fewer, larger
code segments or lots of small ones (say one per module)? I'm porting a major
piece of Unix code, to the tune of 54 .c files and 20+ .h files. Total compile
from scratch is about 70,000 lines.
o Comments: There are some major missing pieces to the Unix side of
LSC. index () and rindex() are missing, although strchr() and
strrchr() are there. The directory reading routines (readdir(),
opendir(), etc...) are gone, as is stat() and fstat(). this means
that any Unix program that touches or looks for a file has to be
hacked to use Macland oriented calls. feh. Major reduction in utility
of the emulation, and that stuff could all be handled without a lot of
hassle.
o There is NO earthly reason why some of the "unix" calls couldn't be
generalized away from the emulation. Like printf(). Why force us into a glass
tty for these things when you could make our life easier hacking Mac programs?
again, a strange restriction of functionality.
I should point out that it took me about 10 hours from the time I downloaded
that code (about 400K of source) to the time I got it compiled and run,
including hacking out some Unix stuff I couldn't emulate (and didn't need) and
hacking in replacements for Unix stuff I didn't have and DID need (like curses
based routines). Overall, I'm now REAL impressed, although there is a strong
tendency for LSC to degrade in really large environments like this. Clicking
"multi-file-search" takes forever, for example, and doesn't cache so every time
you start it you can go get a Coke or something. Running it (and returning to
LSC) also take a long time. Relatively speaking.
Oh, well. when I tried to port this code in Mac C, I gave up in
disgust after a month of trying to get it compiled. I guess THAT says
something, too....
chuq
------------------------------
From: PEABO (11557)
Subject: RE: lightspeed c (Re: Msg 11541)
Date: 10-AUG 15:53 Programming
The more segments you have, the larger your jump table (in CODE 0)
will get. There is a little bit of overhead from the jump (after the
target segment is loaded), but thats all. You might also consider the
overhead of having more objects in the heap, of loading (or
preloading) the extra segments, and of tying up more heap because of
the larger CODE 0.
If you have any segments with libraries in them, then may build to be
smaller than they link (because unused modeuls are discarded during
the build). What that means is that a segment that you know perfectly
well will fit in 32K may fail to link because of excess baggage. What
I wound up doing is sticking most of the Lightspeed library code off
in a segment by itself, where it's guaranteed to fit.
The 'Out of Memory' error has only happened to me when I had a mangled .RSRC
file. (But I am living in luxury with a megabyte of RAM ...) You should be
aware of this other way of getting that message though. I guess you will have
to close your windows before linking.
I found the LightspeedC library to be very poorly organized ("Hello,
world" drags in an incredible amount of stuff, and anything that calls
exit() does too, even if it isn't explicitly using the standard I/O
package.) Overall, I like MANX's approach to a shell a lot better
than LightspeedC.
peter
------------------------------
From: MOUSEKETEER (11552)
Subject: RE: LW cartrige recharging
Date: 10-AUG 14:01 MUGS Online
To: brucer@pwcs.UUCP (Bruce Alan Riebe)
For info on recharging Laser carts (either purchase recharged, send in for
recharging, or do-it-yourself kits) contact: Laser Printer Products,
11 Freeman Street, Stoughton, MA 02072 (617) 893-9000 (24 hrs.) or (617)
341-3005 (9-5 Eastern, human voice...near mooselike). A kit to recharge
2 carts and manual is $99, toner for charging one cart is $20, recharging
service is $40, etc.).
While you can save a few bucks by going this route, my incentive was more to
attain a better print-out from the Laserwriter. The folks have done a lot of
work to determine the optimum toner and procedure, and the results from the
carts is (to my eye) much nicer than an Apple supplied cart...deep blacks!
Note: They also sell "Laserlube and Clean" Disks for monthly cleaning, though
I haven't the foggiest what they are or how they work.
Alf
------------------------------
From: PUGDOG (11554)
Subject: Medical Uses of a MAC
Date: 10-AUG 14:16 SIG Business
I do not visit this sig very often, infact, upon entering this sig,
I was informed my access was purged in Jan, and well, you know how it goes.
One of the main reasons I do not visit this sig very often, is that I
am a confirmed IBMer. (As was my stance in the IBM vs MAC debate).
BUT, lately, due to availability at work, I have been playing with the MAC
a little, and realize it does have some nice features. I am still not
convinced it is a legitimate machine for anything but graphics, ESPECIALLY
FOR USE IN MEDICINE -- I AM NOT CONVINCED!
In fact, no one has been able to convince me. I haven't found one legitimate
application -- enven "manufacturers" of "rumored" products have not sent
the information they have promised.
I am in medical school, and am designing and installing medical office
systems. I would like a good package for the MAC. BUT I need to FIND ON
first!!!
Does anyone out there know of one? Can anyone out there sned, or have the
manufacturer send, information? My attitude is, If I inquire about
distributing a product, I SHOULD NOT BE THE ONE TO HAVE TO FOLLOW UP ON
IT! I am looking for a manufacturer that stands behind their product.
(That is why I am at the point of REFUSING to sell IBM's system).
Not one manufacturer of MAC based systems I have contacted has followed
through. I can't work with a manufacturer who's attitude is that he
is doing ME a favor by letting me sell his product. I need one who
hustles as much as I do, and for whom each sale is as important as -- or
mor important -- than anything else.
If you can help, I'd appriciate it. I might even be convinced to say that
the MAC is pretty neat,
:-),
-r-
Robert S. Pataki
Professional Systems Consultant
Medical Systems Specialist
President,
Man & Machine Integration:
The BioDigital Connection, Inc.
(PS. The medical systems I install are backed by the services of
Computer Corp. Of Westchester, which owns 4 ComputerLand franchises,
and a Corporate/Outside Sales Office. So, I need a Software Package
that lives up to our reputation.... Thanks....)
------------------------------
From: JIMH (11564)
Subject: RE: Medical Uses of a MAC (Re: Msg 11554)
Date: 10-AUG 17:44 SIG Business
Bob, if the mac isnt a serious machine for medicine why does the local med
school use them both for the professors, and all the student courses on
computeres in medicine are taught on them. they are also writing a computers in
medicine textbook for u se with a mac. jim
------------------------------
From: LAMG (11575)
Subject: RE: Medical Uses of a MAC (Re: Msg 11554)
Date: 10-AUG 20:37 SIG Business
Robert:
I think that saying that "the Mac isn't a good machine for medicine"
is an unfair generalization. It may very well be that none of the
medical office management systems are adequate or well-supported; I've
just begun to look into them myself for a Medical Mac SIG I'm
organizing. But there's much more to medicine than office
management... I use the Mac for everything from writing manuscripts
for publications to creating exhibits for meetings to organizing and
managing patient data. There's also a lot of interesting work being
done on using the Mac for medical compter assisted instruction.
I have no hesitation in recommending the Mac to other physicians, though if the
need is for office management software the system has to be checked out
thoroughly first. I'd like to know which companies you've had such a poor
response from.
-Franklin Tessler, M.D. / LAMG
------------------------------
From: PIZZAMAN (11586)
Subject: Medical Uses of a Mac
Date: 10-AUG 23:47 SIG Business
Bob,
I would have to agree with Franklin Tessler that the Mac is a
wonderful tool for the physician who is in the business of information
transfer. Many fields of medicine are very visually dependent, such as
radiology, pathology, surgery, etc. In order to transfer information,
diagrams are often a necessary part of the process. There is no better
desktop computer on the market for this type of work. Granted, the
office management software hasn't caught up yet, but it seems that
simple accounting and database management would be a snap for the Mac+
with any of the presently available hard disks. I would be very
surprised if someone doesn't have a very nice package available in a
short period of time. I know that many of my friends in the medical
field would Macintize their offices in a minute if the software was
available.
By the way, there is software available right this very moment for
sportmedicine. I happen to have a nice template for Filevision that combines
anatomic diagrams interactively with the database of information on various
jogging, skiing, etc. minor injuries. It is a very effective way of keeping
track of this information, for reference as well as patient education. I'd be
glad to send you a demo if your interested. I don't believe that there is
anything on the IBM that even comes close to the filevision program.
Barry
------------------------------
From: DWB (11596)
Subject: RE: lightspeed c (Re: Msg 11541)
Date: 11-AUG 02:37 Programming
Hi Chuq,
strchr and strrchr are the system v equivalents of index and rindex.
Hack should already have floating around in it somewhere the ability
to make it compile for sysV. If it does turn it on and that problem
should go away. If it doesn't put '#define index strchr' and '#define
rindex strrchr' somewhere in a global include file. This is actually
a fairly major (# of occurences, not time to fix) problem in porting
unix code amongst machines.
If you haven't yet kludged up the directory routines and stat (fstat is harder
though) and you need them, let me know. I have some stuff that can be easily
and quickly modified to give you that.
BTW, I have a port of the 4.2BSD ar program if you have a source license and
want/need it. Unfortunately it only works as a project.
Guess this stuff really should have been done via usenet as more folks
there are probably interested in it than here, but here's where I saw
your note.
I tend to ignore the Lightspeed libraries (except for MacTraps) and
drag in precisely what I need. But, then again, I don't like to
settle for command line interfaces anyway. Yuk!
Good luck.
David
------------------------------
From: LOFTUSBECKER (573)
Subject: Paranoia Vindicated
Date: 10-AUG 23:48 Programming Techniques
THE VINDICATION OF PARANOIA, or, A Strange Bug and How To Avoid It.
I thought I would post a report of a strange bug I came across and
how I have (I hope) fixed it. For some time I've been working with DA Key
2.1, and found it had an occasional, and generally unreproducible, habit of
freezing the mouse (and my MacBottom) shortly after the SFGetFile dialog.
I finally found an odd series of events that made it repeatable (involving
the Aztec Shell), and started tracking it down. Here's what I found.
_OpenResFile is passed a pointer to a string. I passed the pointer
by doing a LEA (stringaddr),A0; Move.L A0, -(SP). In some circumstances,
depending on the previous contents of A0, the result of the LEA would not
be simply the address (i.e, not simply 00xxxxxx, but rather A0xxxxxx). In
theory (I think) this shouldn't make a difference. In practice, however,
this would often cause the mouse freeze. Tracing through the ROM, I
found that at one point the _OpenResFile routine does a _RecoverHandle
on the string pointer passed to it. If that string pointer was passed not
as 00xxxxxx, but as A0xxxxxx, _RecoverHandle will -- sometimes --
freeze the mouse. I can now replicate the freeze with ease.
The solution? A few more bytes. Instead of
LEA [stringaddr],A0
Move.L A0,-(SP)
I now do a
LEA [stringaddr],A0
Move.L A0,D0
And.L #$00FFFFFF,D0
Move.L D0,-(SP)
This assures the high byte is cleared and seems to have removed the
bug.
The moral, I suppose, is that those who have paranoiacally been
clearing the high bit of all addresses are right. Does anyone know
(a) why LEA doesn't do it automatically?
(b) any more details about this apparent ROM bug, and whether
Apple is aware of it?
(c) an easier way to do things?
- Lofty
------------------------------
From: DWB (575)
Subject: RE: Paranoia Vindicated (Re: Msg 573)
Date: 11-AUG 03:03 Programming Techniques
Instead of using
lea addr,a0
move a0,-(sp) try using
pea addr it does the same thing, (well almost a0, doesn't have the address,
but
then after the trap it doesn't anyway, so....), takes up fewer bytes, and
probably puts appropriate stuff in the high byte.
The 68K probably doesn't clear that byte because it doesn't expect the outside
world to ever see it. Lame excuse but... Lot's of things were done to save
microcode.
RecoverHandle probably barfs on '0xA0000000' because that A0 gets
interpreted as a flag byte and means it's a locked resource and thus
there must be a handle for it somewhere. Conjecture here!
David
------------------------------
From: LOFTUSBECKER (576)
Subject: RE: Paranoia Vindicated (Re: Msg 575)
Date: 11-AUG 04:04 Programming Techniques
Hmmm. I never did look at IM on flag bytes. That could be
the problem. I'll see whether PEA has similar problems.
Incidentally, I've noticed that Aztec C generates similar code
(using LEA not PEA), and has sometimes given me similar problems....
- Lofty
------------------------------
From: JOSEF (577)
Subject: char speed
Date: 11-AUG 21:17 Programming Techniques
This issue of what baud rate the Mac can run at and keep up really has me
puzzled. A long time ago I wrote a communications program for the Mac which
peaked out at about 2400 baud. I also remember someone telling me that
DrawChar() took about 300 microseconds to draw a character to the screen, which
implies that 9600 baud should be no sweat.
So today I wrote a program that sits in a tight loop just doing DrawChars. The
average time per character came to about 1.5 ms. Since this seemed unusually
long, I fired up QUED, filled a window with 2000 characters, covered that with
another window, then reactived the full window; LO & BEHOLD, the window was
redrawn in something that was clearly less than a second, which makes 300
microseconds sound entirely believable.
What's going on here? Obviously my "for" loop does not use up an overhead of
1.2 ms per character, so what does the TextEdit Manager know that I don't?
Joe
------------------------------
From: CHUQ (11617)
Subject: lightspeed C (more grumbles)
Date: 11-AUG 21:52 Programming
I think I'm starting to sound like a crotchety old man. You'd never
GUESS that I love LSC. IF you are running a 512K, and IF you are
running old ROM's AND the RAM HFS, AND MACSBUG, Lightspeed C becomes
VERY memory bound. It is fairly obvious they use ALL of the 512K.
You can't compile anything with a modified open window, you can't use
segments larger than about 10K, and you have to be willing to coax it
along. At one point, it wouldn't load its own <stdio> library (16K)
into its own segment with nothing else at all taking up memory except
the make. Manually using "load library" did the job, though.
This is real nasty. I am gonna see if I can find a ROM upgrade this
week, but people should be aware that LSC wants LOTS of memory. I
suggest (from this kind of memory usage) people should plan on 1 Meg
for serious LSC development.
It's STILL a helluva compiler...
chuq
------------------------------
From: VINDICATOR (11622)
Subject: RE: lightspeed C (more grumbles) (Re: Msg 11617)
Date: 11-AUG 22:48 Programming
It should be noted, from my own experience, that while LSC is very
fast, it goes to disk a lot, at least with my own system (FatMac, old
ROM, externa drive). LSC will probably be a dream with a hard disk and
TMON, so anyone interested in buying me a hrad disk, please tell me.
Really though, LSC not only requires a lot of RAM, but to do real
seriouis work probably requires a hard disk too.
------------------------------
From: PEABO (11623)
Subject: RE: lightspeed C (more grumbles) (Re: Msg 11622)
Date: 11-AUG 22:52 Programming
Have you had much trouble with the Project file getting big? I have noticed
that is worth while compacting the projects every once in a while, and I would
expect that to be much more noticeable on a floppy system.
A feature I would very much like to have in LSC is a way of unloading and
compacting a project (ie.e, so that the next time I reference it I go through a
complete load and compile of all its components). I would do this routinely
with things that I have hanging around but which I am not working on all the
time. And it would be nice to be able to rearrange segments (the Mac may not
care which segment is which, but I do, when I'm looking at the project's
component listing).
peter
------------------------------
From: JOSEF (11629)
Subject: RE: lightspeed C (more grumbles) (Re: Msg 11623)
Date: 11-AUG 23:29 Programming
An excellent suggestion, peter! Just the other day I was thinking
about all the multiple copies of <MacTraps> and <Stdio> that I must
have lying around in various projects on my hard disk. (I guess that's
what hard disks are for!)
Joe
------------------------------
End of Delphi Mac Digest
************************bass@dmsd.UUCP (John Bass) (08/13/86)
> > From: PUGDOG (11554) > Subject: Medical Uses of a MAC > Date: 10-AUG 14:16 SIG Business > > BUT, lately, due to availability at work, I have been playing with the MAC > a little, and realize it does have some nice features. I am still not > convinced it is a legitimate machine for anything but graphics, ESPECIALLY > FOR USE IN MEDICINE -- I AM NOT CONVINCED! > > In fact, no one has been able to convince me. I haven't found one legitimate > application -- enven "manufacturers" of "rumored" products have not sent > the information they have promised. Mac memory run's without parity and certain ESD events, AC line faults, and other powersupply problems can leave bits corrupted in memory without detection. Furthermore the error detection on Mac floppies is very poor. Using computers without parity protection in critical medical service is a timebomb -- the resulting missinformation may kill someone. I would say than any use of a mac to maintain charts, medication, or provide advisory AI services should be avoided ... use an IBM computer or some UNIX machine with parity memory and much better disk channel error detection. Non-parity machines make nice toys, but I hope they stay out of medicine and other critical applications (fire, police, military, CIA, FBI, etc) where peoples lives are at stake. -- John Bass (DBA:DMS Design) DMS Design (System Design, Performance and Arch Consultants) {dual,fortune,polyslo,hpda}!dmsd!bass (805) 541-1575