Technical Note HW535

Processors & General Logic Q&As

CONTENTS Downloadables

This Technical Note contains a collection of archived Q&As relating to a specific topic--questions sent the Developer Support Center (DSC) along with answers from the DSC engineers. Current Q&A's can be found on the Macintosh Technical Q&A's web site. [Oct 01 1990]

Macintosh models and product test strategy

Date Written: 6/3/92

Last reviewed: 9/15/92

Is there a recommended test strategy that I can follow to guarantee that our software will work on all Macintosh CPUs without having to actually test it on all CPUs?

There isn't any way to guarantee that your program works on all Macintosh models other than testing it on all models. One of Apple's greatest costs in releasing system software is the amount of time it takes to test it on all machines, back to the Plus. However, if you can't afford the time or money to test everything on everything, there is a smaller set of CPUs which will allow you to get the most "bang for your buck." You should, at minimum, test on the following CPUs:

• One with a 68000 (Macintosh Plus or SE) and a small screen
• One with a 68020 (Macintosh II or LC)
• One with a 68030 (Macintosh SE/30, IIx, IIci, IIsi, IIcx, or IIfx)
• One with a 68040 (Macintosh Quadra 700 or 900)
• One with memory-shared internal video (Macintosh IIci or IIsi)
• One with VRAM internal video (Macintosh LC or Quadra)
• One with IOPs (Macintosh IIfx or Quadra 900)
• A PowerBook (100, 140, or 170)92

If your product interacts with any particular hardware, you should check all the revisions of that hardware. For example, if you're dealing with SCSI, you would want to check on the Macintosh Plus for original SCSI, the Macintosh IIfx for its DMA SCSI, and the Macintosh Quadra for its new SCSI chip, in addition to any machine with a more standard SCSI interface.

As you can see, you'll still need to test on a variety of machines, but you can easily cut down the set of CPUs you test on without totally crippling your strategy. For example, testing on the Macintosh IIx and the IIcx would be somewhat redundant; the machines are almost identical except for size, so most products wouldn't see any difference.

PowerBook trackball buttons

Date Written: 4/7/92

Last reviewed: 8/1/92

Does the PowerBook provide any way to differentiate between a mouse click from the top or bottom button?

The top and bottom buttons of the PowerBook trackball are wired together, so no differentiation is possible.

Macintosh LC and MC68030 load limits

Date Written: 4/25/91

Last reviewed: 6/14/9392

Can you explain the apparent differences between the information contained in the Macintosh LC Developer Notes concerning the MC68030 load limits for A0-31 and D0-31 and page 13-2 of the MC68030 User's Manual?

The loads listed on page 24 of the Macintosh LC Developer Notes are the total loads allowed on the TTL lines. The table on page 27 listing the lines and their loads has different values because they are the values of each line after considering the loads that are already on these lines. In other words, some of the lines already have loads on them (such as pull-up resistors) and these loads have been subtracted out of the total load allowed and then listed. The load values to follow are those listed on page 27 of the Developer Notes.

Identifying a unique system and why Apple doesn't serialize ROMs

Date Written: 4/4/91

Last reviewed: 8/1/92

Is there any way to uniquely identify a Macintosh? For example, if we have 20 Macintosh IIfx systems, can we tell which is which? Is the ROM unique?

The ROMs are all identical. The best you can do with software is to look at some combination of things, like the user name, internal disk name, something like that. 'STR ' -16413 (the Macintosh name entered at the Sharing Setup control panel) in the System file might be one way to ID a system. Or you could create files in the System Folder that had unique serial numbers. Of course, the user could change any of this.

The last Apple machine to have serialized ROMs (in the video PALs on the CPU board) was the Lisa. When the software was installed, it copied the serial number onto the master disks and would work only on that machine. The serialized ROMs caused lots of problems. Making and tracking the ROMs was expensive in manufacturing, and when the user took a machine in for service, if the CPU board got exchanged, the service people had to remember to pull out the old PAL and put it in the new board. If the PAL was the thing that went bad, it got even worse, since only the factory could program them.

Back to top

Downloadables

Back to top