Lightspeed 3.0-Source Code Debugger

By David E. Smith, Editor & Publisher

Lightspeed C 3.0

Kirk Chase

Lightspeed C has jumped into hyperspace with their version 3.0 of their popular C development system. THINK Technologies Division has upgraded their Lightspeed C to version 3.0 due out by the time you read this. The new version is a significant improvement in application development containing support for Inside Macintosh I-V, 68881 and 68020 code generation, precompiled headers, and a source level debugger!

The greatest addition to version 3.0 is, of course, the source level debugger. The debugger has a source window that allows you to step through your code to see how it is executing, either line by line or function by function. You can set break points that are absolute or conditional. There is also a data window that will allow you to view and modify the various variables and structures in your application. But, if source level debugging isn’t enough for you, you can drop right into your favorite low level debugger like TMON.

Sounds too good to be true? Well, there is a catch. Although Lighspeed C 3.0 will run under System 4.2 or higher with the 128K ROMs, in order to use the debugger you need 2 megabytes of RAM and run it under MultiFinder; it is also recommended that you use System 6.0. The source level debugger is a nice addition, but it is not without some price.

In addition to the debugger, there are some more goodies. There are precompiled headers, Lightspeed C’s or your own, that speed up compilation. I was told in the interview with THINK that to compile a program before with all the headers took approximately 22 minutes; the precompiled headers reduced that to under 5 minutes. Version 3.0 also includes libraries and inline code generation for the 68881 and 68020 chips for those who are programming for speed. Also, all the color object as well as the rest of Inside Macintosh I-V is supported.

The upgrade is a nominal charge especially if you already have 2 megs of RAM and MultiFinder to run the debugger (obviously if you plan to run the debugger and need a memory upgrade, it will cost you more). This version is a major breakthrough for you developers, like I am, that like source level debugging.

Mac Power Supply History Reviewed

Dr. Ray A. Gaskins

It could be argued that 1987 was the year of the power supply (analog board) problem. Don Ritter, writing in MACazine, mentions the power supply in seven out of twelve of his M.U.G. WRESTLING columns. MacTutor, in six of its monthly issues, devotes more (and useful) words to it than any other publication. The Active Window (Boston Computer Society publication) mentions something about the power supply in three of its monthly issues. Perhaps not surprisingly, MacUser and MacWorld mention the power supply in only one issue each.

The earliest reference to the power board problem that I have seen is one mentioned by Ritter in MACazine (Jan 87, page 61). He references an article by Howard Upchurch which appeared in the July/August 1986 issue of Apple Gram. Upchurch blames the problem on two underrated capacitors and on the flyback transformer. Other 1986 articles referenced by Ritter are a “bad power supply board survey form” in which Apple admits to a power board problem with Mac Plus upgrades. However, MACazine itself makes no mention of power board problem in 1986 (nor, for that matter, do MacUser, MacTutor or MacWorld).

Apart from recommending the removal of the heavy aluminum RFI shield mounted across the top of the power supply board as a means of increasing air flow and reducing heat, Ritter has little to suggest short of suing Apple. Instead he tells an endless string of horror stories about multiple power board failures.

In my own fixed population of just over 100 Macintoshes, I have the full range of Macs (1984-1988). I can remember two Macs out of this population that seemed like characters out of Ritter’s horror stories. In both cases, replacing the video tube fixed the problem. Therefore, my advice to anyone whose mac eats power boards (say, three boards in six months) would be to replace the video tube (along with the third or fourth power board). A symptom of this problem is a discoloration due to heat of the four-pin connector that connects the video tube to the J1 connector on the power board and a history of eating power boards.

I believe that there is some truth to the rumor that Apple felt that part of the power board problem was due to the procedure being used to discharge the video tube - you know, two crossed screw drivers. I have lost a couple of power boards because of this and began not discharging the video tube for doing routine things not involving the power board (e.g., replacing the logic board). My failure rate declined. Now there is a neat tool for discharging the video tube that meets Apple’s approval and I use it religiously.

In the 15 months prior to July 1987, I replaced 13 power boards. In the 9 months since then, I have replaced only 4. I attribute this to three things: Loy Spurlock, Chuck Rusch, and Mysteray. MacTutor published long and detailed letters from Loy Spurlock (March 87, page 4) and Chuck Rusch (June 87, page 13) concerning the power board problem and what you could do about it (short of suing Apple). Mysteray (July 87, page 17) wrote two long comments in MacTutor’s Mousehole Report concerning the J1 connector on the power board - why it tended to develop a cold solder joint, how to detect it and how to fix it. I am grateful to these three people for their words of wisdom.

Since July 1987, I have had 10 power board problems that, prior to reading Spurlock, et. al., would have meant 10 power board swaps. However, applying their advice, I was able to save 6 of these boards by resoldering. The symptoms were varied:

(a) three had the classic thin vertical white line in the center of the screen,

(b) two had the shakes (screen jitter), occasional spikes and expanding/contracting screen,

(c) three had horizontal lines across the top and/or bottom of the screen, and

(d) two had a faint vertical line just to the left of center.

Resoldering the four pins of the J1 connector fixed two (a)’s , one (b) and two (c)’s. Resoldering two other joints that appeared dull under close inspection fixed the other (b).

Resoldering had no effect on one of the (a)’s , one of the (c)’s nor on either of the two (d)’s. (Rumor has it that the faint vertical line means that the power supply will fail within six months.) Fixing six out of ten power boards by simple resoldering isn’t bad. These Macs range from 128K to Mac Pluses. None had fans.

Using a jewelers eye piece (10X), I also examined the joints at J2 (9 pin connector) and J4 (11 pin connector) on each of these boards. More often than not, one or two solder joints on each end showed cracks. Resoldering these, although good preventative maintenance, is usually not as critical as resoldering the four joints at J1.

I looked at a couple of the replacement power boards and noticed that some of the connections had been resoldered by hand, including the four pins of the J1 connector. I couldn’t tell their resoldering from mine. The only difference was that they put on a new paper backing with new double-stick pads. If you are careful in peeling back the double-stick pad (use a plastic video alignment tool with a screw driver blade to help peel it back), you won’t have much residue to clean off before resoldering and you can restick the pad without applying additional glue.

What caused the cold solder joints? I believe that the explanation given by Mysteray (loose video yoke connector) is probably correct. Therefore, I always tighten this connector whenever I resolder the pins at connector J1. For a thorough explanation of this, see Mysteray’s comments in MacTutor (July 87, page 17).

As far as voiding your warranty is concerned, after 90 days you are on your own unless you have AppleCare. Since the connectors we are talking about are not heat sensitive components, there is very little likelihood of making matters worse by resoldering and there is a better than a 50% chance of fixing the problem. But, if you are still under warranty or if you have AppleCare, you don’t have to worry about resoldering - just let your friendly dealer replace the power board.

One suggestion that Don Ritter probably made in jest turns out to be a good one. He suggests that you “buy yourself a smoke alarm and place it above your Mac.” I’ll go him one better. If you intend to leave your Mac on unattended, install a stand-alone automatic halon fire extinguisher as well as a smoke detector above your Mac.

HyperCard Needs a Diet

Neil Rieck

I just sold my 4 year old Mac (it was a 512KE with an external floppy when we parted company) in order to buy an SE with an internal hard disk. I thought that a 20 Meg disk and one Meg of RAM would satisfy my computing requirements through 1990 until I loaded the HyperCard (version 1.0.1) package that accompanied the SE. I now believe that HyperCard is a scheme by Apple to sell hard disks and memory upgrades (see “What you need to use HyperCard” on page xvi of the “HyperCard User’s Guide”).

Although HyperCard seems very powerful, I can see no reason why the STACKS (HyperCard programs) must be so large. A very nasty example is Apple’s “1987 HyperCard Supplement” which is 773.5K bytes (Data 762.3 K, Resource: 11.2K). An ASCII dump of the Data Fork revealed that the script commands are not stored as tokens (as was done in AppleSoft BASIC days when both RAM and Disk space were scarce), but are actually in their original text form. Didn’t we learn anything in the 70’s? I found 957 occurrences of “MouseUp” which would save 4785 bytes if replaced with 16 bit tokens (or 5742 bytes in the case of 8 bit tokens). Can you imagine the savings if ALL the script commands were tokenized and SPACES between them removed? (Note: The thought of jump tables and command tokens reminds me of the trap dispatcher).

At first glance, you would think that the 221 page “HyperCard User’s Guide” would tell you everything you needed to know about HyperCard. Wrong! If you want to know how to SCRIPT (program in HyperCard) or even get a list of the legal script commands, you must order the “HyperCard Script Language Guide” from APDA. This would be similar to getting a BASIC language package, then finding out that you can only use it to run/modify the demos until you purchase further documentation. At least Apple could have listed the script commands in an appendix.

I am a VAX programmer by day (I am fluent in several languages) and was quite disturbed by comments from colleagues who criticized 4GL type packages like HyperCard. Although HyperCard seems to be a hardware hog as I’ve just shown (but it can be fixed), it does allow the average person to program the Mac without having to know about GrafPorts & GetNextEvent, etc.

The best analogy I can come up with is the automobile. The first cars required the owner to understand the basic theory of operation so he could crank start the engine, manually advance the spark, set the choke, and shift the gears. Today’s cars do all these things for you which makes the car available to more people. This increases sales, which drops the price for everyone. Just imagine, a more powerful Mac at a cheaper price.

My advice to MacTutor readers is to accept and learn HyperTalk (the language of HyperCard) as another language because the script market will be huge, and there will be people who will find this method of programming difficult and will require your advice. A second point to consider is that there will be GOOD scripters and BAD scripters, and if MacTutor readers set a high standard now, we can have a positive effect on what we will be forced to deal with in the future. And if after all this there are some people who are still skeptical of newer and easier to use software packages, please remember that in the movie “2010”, Doctor Chandra (the system designer) talked to HAL & SAL when it was convenient to do so, but also used a keyboard when it was required.

HyperCard Wish List

Javier R. Blanqué

I’m sending a wish list for HyperCard - really a fantastic product. If the gurus of Apple, (Bill and the other masters) are doing a survey about upgrade priorities among users, I’d like to participate (The list is divided in some themes and subthemes, by order of priority):

General Topics:

• Classic windows for Cards by default (By coherence); that we can move it, resize it, close it. With scroll bars for window content greater than the screen. Many simultaneous cards open at a time.

• MultiUser (Tops, AppleShare) compatible.

• MultiFinder (working in background) compatible. It would be a graphic command shell for the Mac.

• Colors(Other than B&W).

Data Base Upgrade (make it SQL compatible):

• Report Generator (in HyperTalk commands such as SUMARIZE, COUNT, etc.). Multiline reports, multilevel subtotals (i.e.: as special backgrounds), and multistack printing embedded in HC, each of us need not to invent the wheel each time, building procedures to manage it.

• Complex Finds in one verb (SELECT, SEARCH to deal with subsets of Cards).

• Data Types in elemental Fields, (BOOL, Integer, Real, char, STRING, Image). It speeds up computations, and is conceptually more clean.

Programming:

• Friendly access to the entire ROM ToolBox.

• Short Cut verbs (Less typing time).

• Incremental compiler to machine code for HyperTalk. With a native mode compiler, the Cards will fly, and permit stand alone applications without the entire environment, or a run time module. [We agree with this one! -Ed]

• Arrays and structures, and data types in local and global variables.

• Convert HT in a complete Object Oriented Language. Include a selective optimizer garbage collector.

Education:

• Artificial Intelligence to help the user (Expert Assistant).

• Natural Intelligence to help HyperCard (Artificial Learning).

With all this, it will be the perfect oracle!

Notes on the Modifier Keys Article

Warren Michelsen

I just wanted to correct the mis-impression you may have created in some people’s minds regarding the short LSP unit source of mine which you published in the May issue. You may recall that it showed how to detect the press of a modifier key in LSP and was sent in response to a writer’s Question in the March issue.

Most importantly, the functions, as published, do not require a posted event, that is, they will detect the press of a modifier key entirely independently of “a normal key”, contrary to what you stated. While I suppose the functions could be used in lieu of checking the modifiers flags of an event, that is not what I wrote or use them for. Typical uses are: Upon program start “if OptionIsDown then” go directly to a certain function (much the way Font/DA Mover “starts up” in DA mode of the option key is down at start. Or, “if OptionIsDown” when a user selects “ About...” then I bypass the About dialog and go directly to the instructions, which are normally selected from a button in my About dialog.

Secondly, while the unit indeed “...does not handle all combinations of keys if both the shift and command key are held down together...” it is certainly easy enough to call multiple functions in succession: “if (OptionIsDown and ShiftIsDown) then...” It beats having to remember numerous constants representing each possible combination of modifier keys.

Your readers might appreciate clarification of these points.

4th Dimension Articles Wanted

Michael Billesbach

I have been a subscriber of MacTutor since early 1985. MacTutor has been very valuable over the yours as a source of programming information. There is one area of programming that has been overlooked by MacTutor. I refer to Database programming. While writing database applications is not as glamourous as writing the next great graphics program, it does require a certain level of programming sophistication.

Like many programmers I have migrated to database programming and consulting. I find it very satisfying to be able to write a program that solves real world problems. I also feel that I am, in a small way, helping to propagate the Macintosh in the business and health communities, But I would like to see more written on the subject. I would like to propose that 4th Dimension be the database “language” of the column. The inclusion of this column would certainly benefit MacTutor by broadening the appeal to an untapped segment of programmers (subscribers).

With the introduction of 4th Dimension, Database programmers were presented with a unique programming environment which includes a very complete Pascal-like procedural language and a graphic environment for defining screens and menus. Additionally, 4D can access routines, called “externals”, written in compiled languages. There are many areas of 4D and externals programming that are ripe for MacTutor articles.

Please consider my suggestions. Also I could like to invite you to check out the ACIUS section of Apple Vender Forum on Compuserve to see the kind of information exchanged by 4D programmers. I’m sure that finding writers will not be difficult. [We agree a Data Base Programming Column is needed and are adding such a column. -Ed]

Word Woes, Software Supply Credits, CMS Noise

Charles Dyer

I got my first hard drive, a CMS SD43 from Ehman Engineering, in February, and already I don’t know how I lived without it. I also realize just how much stuff I have; I only put the bare necessities on it, and I’ve got 20 Meg on board. One Meg of that is in my Fontl/DA folder, for Suitcase, which is vying with DiskTop as the most useful utility I own. The only problems that I’ve had with them are, as usual, when working with everyone’s favorite bug-infested application, MS Word 3.01. Command-K already means something in Word, so no Key-combinations there. And, naturally, there’s the way Word treats fonts. DiskTop’s main problem is that the Monster Which Ate Redmond also loves to eat menubar space. After you’ve got the JClock clock up, and a Word menu installed, and are running MultiFinder--1M allocated to Word, 256k cache, just love having 2.5M, really I do--there simply ain’t that much space left for anything else. And Microsoft went and didn’t make the menus MENU resources, so I can’t even go into the program with ResEdit and hack out a little extra space, the way I did with Word 1.05. I’m gonna change to FullWrite, really I am. Assuming that it ever comes out, that is. In any case, how about seeing if you could get the good folks at Software Supply and/or CE Software to write up how they pulled their respective tricks off? This is the kind of thing I’ve wished I could write. Stuff that’s small, useful, powerful. Stuff that you don’t know how you lived without it after you’ve been using it for a while.

‘Major’ problems to date: My drive sometimes sounds like an A300 on take-off. No mere SE that I’ve heard can come close to matching the noise level. I’ve got a Kensington System Saver fan/surge protector unit on my Plus, and I usually have to put my hand up by the outlet to be sure that the fan’s running. Not so with the CMS, you can hear that sucker at the other end of the room without any effort whatsoever. It also clucks like a chicken when it accesses the disk. Lastly, it’s grey. I’d asked for a beige unit, the better to match my Mac, but I guess that they don’t make those any more. Or maybe they don’t make it to handle 110V, 50Hz current, which is what we have in Jamaica. In any case, I’m certainly not going to send it back just because it’s the wrong color. Even if it does look like something that escaped from Boca Raton. It’s even got a little sticker with three letters on it put in the upper left corner of the box, but I love it anyway. My main problem with it was that it sometimes gave trouble on start up. I solved that by never turning it off. I turn the Mac off, but not the drive.

SemperSoft Modula 2 Compiler

I was going to get that SemperSoft compiler over Christmas, but I got MultiFinder and HyperCard and that meant that I just had to buy some extra RAM, which took Modula 2 off of my budget until this month (back in the age of thin Macs with one 400 kB drive, whoever would have thought that 1 Meg would be too small, or that someone could put a serious dent in the capacity of a 40 MB hard drive in the course of an afternoon? Not me..). Has TML gotten back to you about their Modula compiler? [No, I have never gotten the TML Modula Compiler from them, nor have they sent me anything about it. -Ed] When I saw my letter printed in the December issue, I was sure that they’d say something but so far nothing has arrived. I suppose that their saying nothing is equivalent to their saying that they don’t want my money. Just the same, I had to get something as MacModula-2 from Provo, Utah, finally bit the dust. Now that I have a hard disk, I know the awful truth: the AppiMaker, that kludge they built to create stand-alone applications, crashes with an ID=10 bomb under MultiFinder, as does each and every application that I’ve made with it. In addition, the compiler fails under MultiFinder, but more gracefully; MultiFinder has time to send you an error box and then returns to the Finder. Both Modula 2 and Modula-2, the two applications which interpret the compiler/linker and the .LOD programmes, do the same thing if you try to access them directly. One of the reasons I wanted MultiFinder was to be able to run ResEdit and my compiler at the same time. I can’t do that with MacModula-2, that’s for certain. I tried to call Utah, but got a busy signal every time.

For a good laugh, try to run ResEdit 1.1d4 under MultiFinder and then look at a DLOG or an ALRT. There’re other bugs, but that ones the most noticeable and the most obnoxious. Think that maybe certain Apple products ain’t as MultiFinder compatible as one would like? I do hope that there’s a later version out which patches that bug, things could get real thin if there isn’t. RMaker being the mess it is, I usually build resources in ResEdit and/or REdit, and it’d be nice to have them around at the same time as my compiler/editor system, the better to fine-tune stuff. It didn’t matter very much before I got MPW, because MacModula-2 won’t run under MultiFinder anyway, but it might be significant later. Rez is supposedly vastly superior to RMaker, but I’ll believe that when I see it, I haven’t had enough time to play with it yet.

I sent off to APDA for MPW 2.0.2 and the SemperSoft compiler, and finally got it last week. I promptly spent far too much time on it. I finally went to bed at 2:00 in the morning after I got the thing, after doing some reading of the Semper docs and the MPW boat anchors-those docs would make excellent anti-tank weapons if dropped from aircraft-and rereading parts of West’s and Kroick’s books. I transferred a few files over from MacModula to Semper. Comparative testing indicates that compile and link to application time drops from twenty five minutes to thirty seconds, and application size drops from 80k to less than 20k. The only changes that I made were to change the IMPORTs to match the weird way Semper wants them, and to make MacModula’s ModToMacStr and MacToModStr statements into Semper StrToPStr and PStrToStr statements, and the like. Minor stuff, just quick-and-dirty changes to get the thing to compile, without going into the docs to see if there were more efficient ways of doing things, and the source was actually about a k bigger after I made the changes. I knew that MacModula sucked, but I didn’t think that it was that bad.

The MPW Books

I’ve been putting in some time reading Joel West’s and Scott Kronick’s books on MPW, so I now know more about 68000 assembler in general and Mac tricks and traps in particular than I even thought existed, so that I managed to be thoroughly confused when MPW arrived. I’ve got one project I’ve been working on and off-mostly off-since 1983, when it was BASICA on a certain machine with three initials. It got converted to MS Basic on the Mac as soon as I had both a Mac and Basic, then was converted to Mac Pascal--that was interesting, as I didn’t know Pascal when I started. When I got MacModula-2, I moved it to Modula-2--I didn’t know Modula-2 then, either, and had just gotten my “phone book” edition of Inside Mac, and therefore didn’t know the Mac either, so this was another learning experience--and since then there have been several major changes, including one episode where I simply trashed all previous code and started over from scratch. Along the way the source’s grown from a quick-and-dirty command-line and simple menu Basic program that took up maybe 20k to fifteen modules, counting definition and implementation modules as one, totaling maybe 420k plus resource files and all kinds of junk. I figure that reworking it into Semper Modula should keep me busy for a while.

Phone Book Still Useful?

Oh, yeah. Something that I’ve been meaning to ask: I’ve got Inside Mac V4, and APDA draft V5, but I still use the old “phone book” version of V1-3. Are the differences between AW’s version of V1-3 and the “phone book” big enough to justify getting the AW version? Us third world engineers don’t make that much Yankee dollars, and I’ve about blown my budget getting hardware and MPW and the Semper compiler. The “phone book” version of Inside Mac worked okay with MacModula-2, but that does not necessarily prove anything. One of the good parts about MacModula was that it had its own condensed version of IM. MacModula’s procedures and IM’s procedures are not necessarily identical, especially where INTEGERs and STRINGs are concerned. I used IM as a reference, but usually wrote code with MacModula’s docs in hand. Doing that with the Semper docs might be a bit difficult. I’d rather not spend any more US dollars just now if I can avoid it, but if making proper use of the Semper compiler requires the latest version of IM v1-3, so be it. [In general, I advocate the latest version of everything, System Software, manuals, applications and documentation. In practice, most of the differences from the “phone book” version have been mentioned in Tech Notes, so if you have the Tech Note library, the phone book version is probably generally good enough. -Ed]