Macintosh IIci: Causes for IIci Incompatibilities (Part 4 of 4)


This is part four of a four part article detailing the changes which
caused the compatibility problems the Macintosh IIci faced. A significant
number of Macintosh IIci compatibility problems were related to the
improvements outlined below. Keep in mind that the majority of
applications were not affected by these changes and that most of those
that were have been updated.

Leading Causes for Macintosh IIci Incompatibilities (Con't)

5) ADB manager

In an effort to reinforce the ADB standard, protocols surrounding the
polling of ADB devices were more explicitly defined. Clarifying the rules
surrounding the polling process revealed the fact that certain developers
had made false assumptions. This especially affected developers using an
ADB hardware lock for copy protection. As it turns out there was really
only one third-party vendor affected by this change. However the impact
was magnified because this one developer sold their lock to a number of
third-party software developers who include the ADB lock as a standard
part of their application. Once the problem was diagnosed, Apple worked
with the developer of the ADB lock on a solution.

6) 25Mhz Clock Speed - "Too fast"

Certain applications were designed around the assumption that a call to a
particular chip or location in memory would be returned within a given
interval of time. Those developers who made this assumption ensured that
their product would break when Apple introduced a higher clock speed
system. The Macintosh IIci turned out to be that higher speed system. This
change affected only a small number of developers who had instituted
timing-dependent copy protection schemes and developers who designed
timing-dependent games.

7) Gamma correction

Since its introduction, all Macintosh II systems perform color
correction, commonly called "gamma correction", on video displays to
compensate for non-linearity in the monitor's phosphor response. The
effect of a proper gamma table is to make a monitor appear brighter and
colors more vivid. Theoretically each brand of monitor has its own unique
phosphor composition and therefore each monitor should have its own
"device specific" gamma table.

The fact is that most third-party vendors do not provide a gamma
correction table data with their monitor, so machines released prior to
the Macintosh IIci set all displays to the gamma correction designed for
the Macintosh Hi-Res RGB Display. While this was not really correct, it
nonetheless ensured that all displays had at least some form of gamma
correction.

In order to encourage third parties to offer their own gamma correction
information, the new video card architecture (incorporated into the
Macintosh IIci ROM) supports improved methods of carrying this
device-specific data with each card. As a result of this change the
Macintosh IIci scans for gamma table data in each video card and sets each
card with its own customized gamma tables. In many cases, third-party
cards do not properly initialize their own hardware, expecting to be set
with the Hi-Res RGB gamma table. As a result, displays connected to these
cards are left uncorrected, which means that they tend to look
significantly darker when connected to the Macintosh IIci.

As an aid to improving the appearance of old cards on the Macintosh IIci,
Developer Technical Support made available source code to an INIT that
allowed developers to load the appropriate gamma table information.

8) Problems related to bugs in the Macintosh IIci ROM

In addition to those problems that we were aware of, there were a number
of unanticipated problems that were discovered in the Macintosh IIci ROM.
These changes have been corrected through bug fixes incorporated into the
6.0.5 release of system software.

- Palette Manager

There was a patch file for the Palette Manager which failed to be
included in the final Macintosh IIci ROM. This patch file helps to correct
a minor problem in the 32-bit color QuickDraw code built into the
Macintosh IIci ROM, which determines the color palette for an application
when it is opened. By not including this patch, certain paint and image
processing applications ended up displaying colors incorrectly.

- Zero-width Characters

This is a bug which was inadvertently introduced in the Macintosh IIci
ROM. It causes zero-width characters to not be drawn. Zero-width
characters include characters used for musical notation, foreign languages
(i.e. Kanji and Arabic) and mathematical notation. This caused particular
problems for developers doing musical typesetting and some mathematics
programs.

- Serial Driver

Due to an anomaly in the serial driver code, when a Macintosh IIci is
being used with a modem and a break character is returned during a
communications session, the system will crash or hang. This does not occur
frequently, but does occasionally occur when a user is engaged in a
session with one of the remote information services.

- TextEdit

There were a handful of bugs in TextEdit which were incorporated in the
Macintosh IIci ROM. The majority of these problems are cosmetic and do not
cause the system to fail. TextEdit is used by a number of applications
including AppleLink and HyperCard. In addition, TextEdit is used in all
dialog boxes that appear on your screen.


Published Date: Feb 18, 2012