[comp.sys.mac.misc] Macintosh IIci Compatibility Report - Detailed

noah@Apple.COM (Noah Price) (06/11/90)

Filename:  IIci-Compat-Report


IIci Compatibility Report 3/30/90
=================================
                

The Price of Progress
---------------------

The Macintosh IIci represents one of the most significant steps forward
in the evolution of the Macintosh architecture since the introduction
of the Macintosh II. Whenever you introduce a product with as many
significant architectural enhancements as the IIci, there are going to
be incompatibilities revealed. The IIci is not only the first system
with a higher clockspeed and built-in video, it is also the first
system with 32 bit QuickDraw in ROM and the first system to utilize
non-contiguous memory and the first system to utilize the PMMU for
memory addressing. These are all significant internal modifications,
intended to strengthen the Macintosh architecture and provide even
greater flexibility for future hardware and software developments.

The remainder of this report describes the leading causes for IIci
incompatibilities, how developers were effected, and what has been done
or is being done to correct the problems.


________________________________________________________________________

    IMPORTANT!/IMPORTANT!/IMPORTANT!/IMPORTANT!/IMPORTANT!/IMPORTANT!

    The majority of the modifications that third party developers are
    having to make to support the IIci are changes that are going to be
    necessary to support future CPU's and future versions of the Mac
    operating system.

     * Addressing changes necessary to support non-contiguous memory
       and the utilization of the PMMU are changes that will be
       required to run correctly with VM in System 7.0.

     * 32-bit QuickDraw will be built into all future ROM's which
       offer color support.

     * The built-in video monitor identification scheme will be
       included in future CPU's and is also part of our new video
       cards.

     * Changes to the ADB manager and the video configuration (i.e.
       gamma correction table) will both be included in future
       systems.

     * And, the fact that Apple will design systems that run at greater
       than 16 MHz is obvious.

________________________________________________________________________



Leading causes for IIci incompatibilities 
-----------------------------------------

IMPORTANT NOTE:
A significant number of IIci compatibility problems are related to the
improvements outlined below. Keep in mind that the majority of appli-
cations were not effected by these changes and that most of those that
were have been corrected.

________________________________________________________________________

1) Non-contiguous memory

On all Macintosh systems prior to the IIci physical memory is
represented as one "contiguous" range of addresses. Despite the fact
that memory is typically located in two separate banks with separate
physical address ranges, these two ranges are presented as one
"contiguous" range. The knitting together of bank A and bank B is taken
care of by the memory controller. During startup the memory controller
determines the amount of memory in bank A (i.e. 1MB or 4MB in case of
Macintosh II) and then maps the starting address of the bank B range on
top of the final address of the bank A range, which makes the two
physical address ranges contiguous.

Making memory's physical addresses contiguous allows the contiguous
logical memory map which is presented to software to be identical to
the physical memory map. All Macintosh systems up to the IIci utilized
this 1:1 translation which means that starting at address 0, all
logical and physical addresses are the same and an application knows
where in physical memory an address is located.

                     _____________________________

On the IIci the lowest physical address of bank B is fixed at physical
address $0400 0000, regardless of where the highest physical address of
bank A is located. This leaves a gap between the top of bank A and the
bottom of bank B which is a condition referred to as non-contiguous.

The move to non-contiguous physical memory on the IIci was made to
reduce the clock cycles associated with address translation and provide
greater flexibility when configuring the system. By making physical
memory non contiguous you may have as many banks of memory as you like
and you can put whatever density RAM in whichever bank you like.

Non-contiguous memory requires the use of the PMMU on the 68030. The
PMMU performs a translation of logical to physical addresses which
permits the two to be different. And, in fact on the IIci they are
different. The address ranges of the two RAM banks are made logically
contiguous even though the physical address ranges of the two banks are
not contiguous. The PMMU plays the role of a dispatcher. On the one
side it is accepting logical address requests made by software. On the
other side it is mapping these logical address requests to physical
locations in RAM.

This means that the operating system must keep track of the physical
location it assigns a particular logical address. It also means that an
application no longer knows where a given logical address is located in
physical memory. While this change did not have an impact on most
developers, it did have an impact on Nubus master card developers.

                     _____________________________

A Nubus master card is any Nubus card which possesses the intelligence
necessary to take over either Nubus or the CPU bus.  Examples of Nubus
master cards include communications co-processor cards (i.e. Apple's
MCP card), high-end video overlay and graphics cards, and intelligent
I/O cards (i.e. DSP or SCSI DMA). One of the standard operations a
Nubus master card performs is the reading and writing of data stored in
the CPU's main memory.

When a Nubus master card wants to utilize main memory it must create a
buffer within main memory, which it requests from the memory manager.
This request specifies not only the size of the buffer but also that it
be contiguous, non-cacheable and non-relocatable. In all Macintosh II
systems before the IIci, after the memory manager returned a logical
address range that met these criteria the Nubus master card could
immediately begin directly addressing physical memory. This was
possible because in all designs up to the IIci a given logical address
range had an identical physical address range, which meant that a Nubus
Master card could determine the location of the physical addresses by
virtue of the logical address range it was provided.

With the IIci design a Nubus master card must take some additional
steps before it can begin accessing physical memory. The first step is
the same, the card requests a contiguous, non-cacheable and
non-relocatable chunk of memory from the memory manager, and in turn
the memory manager will return a logical address range. However on a
IIci, because the logical addresses are not the same as the physical
addresses the master must make two additional requests. First, it must
request that in addition to the logical address range being contiguous,
the physical address range must also be contiguous.  Second, it must
request the location of the physical address range.  Only after these
requests are returned may the Nubus master begin to access physical
memory directly. These two additional steps meant that all Nubus master
card developers were forced to re-write their drivers to work with the
IIci.
________________________________________________________________________

2) Utilization of the PMMU - No invalid addresses

Another change related to the utilization of the PMMU in the IIci
memory addressing architecture is the rejection of invalid addresses.
This is perhaps the most prevalent cause for software compatibility
problems on the IIci. As described above the PMMU plays a critical role
in interfacing between logical and physical memory.  As part of the
process of translating logical to physical, the PMMU also evaluates the
"validity" of the logical address requests it receives. An address is
considered valid if it falls within the valid address range and the
valid address range is determined by how much physical memory is
available. A 2MB configuration has a 2MB valid address range and a 5Mb
configuration has a 5MB valid address range. This is determined at
startup, and the PMMU tables are set accordingly.  If an application
requests access to an address that lies outside of this range, the PMMU
generates a bus error.  That all sounds logical. So why should this
cause a problem?

Because on previous systems invalid addresses were not identified.
When an application requested access to an address it would go straight
to RAM, which would decode whatever bits within the address it could
and ignore the rest. For instance if you had 1MB of RAM installed, your
valid address range would theoretically include all addresses up to 20
bits wide (2 to the 20th is 1024K), which means that memory would only
be capable of decoding up to 20 bits of address information. Now let's
say an application requests access to a 21 bit address that is beyond
your 1 MB address range. On all systems up to the IIci, RAM decodes the
lowest 20 bits (ignoring the 21st bit) and grants access to an address
within the valid address range. The fact that a bad address had been
written was concealed.  There is the potential for problems with this
model if an application overwrites data stored in a particular address
or it reads in bad data, but often the problem is never revealed.

In the case of a IIci this errant behavior is always revealed and
therefore a number of applications, CDEVs, INITs, and drivers that
worked fine up until the IIci suddenly broke. Embarrassingly enough,
this change revealed problems with two internally developed Apple
products, version 3.0 of the CD-ROM driver and version 2.3 of
MacTerminal.

The majority of developers who have encountered this problem are aware
of it and have either already made the corrections or are in the
process of making corrections necessary to make their applications IIci
compatible. However this problem, which is difficult to diagnose, took
many developers by surprise.

IMPORTANT NOTE:
It is important to understand that both the move to non-contiguous
memory and the utilization of the PMMU to capture invalid addresses
presage changes that will be required for compatibility with system 7.0
and virtual memory.

________________________________________________________________________

3) 32 bit QuickDraw in ROM

The Macintosh IIci is the first CPU to incorporate 32-bit QuickDraw in
ROM. With previous systems users had the option of installing 32-bit
QuickDraw in RAM through the addition of an INIT file to their system
folder. Although 32-bit QuickDraw was engineered for high compatibility
with the original QuickDraw and Color QuickDraw programmer's
interfaces, certain programming practices could lead to problems with
this new software.  Users of the 32-bit QuickDraw INIT could optionally
deactivate the software if there proved to be a compatibility problem.
Because 32-bit QuickDraw is in ROM on the IIci, it cannot be defeated.

   * Video card problems

     Generally, existing video cards have no compatibility problems
     with 32-bit QuickDraw.  However, newer cards designed to take
     advantage of 32-bit QuickDraw's features such as 16 and 32-bit
     direct color pixels and large frame buffers need to follow a
     special initialization sequence at startup to allow the card's
     special features to be activated after the 32-bit QuickDraw INIT
     has been loaded. On the IIci, 32-bit QuickDraw (and the new Slot
     Manager) are in ROM, so a simpler, but different, startup sequence
     needs to be executed.  Some third party developers unaware of this
     alternate sequence were incompatible with the IIci when it was
     first introduced.

   * Software Problem

     One major change in 32-bit QuickDraw is that the frame buffer
     memory is always accessed in 32-bit addressing mode rather than
     the 24-bit addressing mode used by previous versions of QuickDraw.
     This allows the applications to access frame buffers up to 16MB in
     length, as opposed to 1MB with non-32-bit versions of color
     QuickDraw. This additional frame buffer address space is becoming
     increasingly important as the use of 24-bit color becomes more
     prevalent.

     For a user to benefit from this 32-bit addressing mode they must
     install a video card capable of taking advantage of it. In turn, a
     video card possessing these capabilities must test the system to
     determine if 32-bit QuickDraw is present or not. If it is present
     then 32-bit QuickDraw capabilities of the card will be enabled,
     which means, among other things, the card will expect to be
     accessed in a 32-bit addressing mode. If 32-bit QD is not present
     most cards will default to the 24-bit addressing mode.  In this
     way, a new card possesses the flexibility to adjust to whichever
     QuickDraw environment it finds itself in.

     In a system where 32-bit QuickDraw is present and there is 32-bit
     QuickDraw capable card installed there is the potential for
     incompatibilities with certain applications that directly address,
     (i.e. bypassing QuickDraw) the video frame buffer. A number of
     paint applications fall into this category. Previously, these
     applications could directly access all frame buffers in 24-bit
     addressing mode and know that they would work. However if an
     application is running on a system with 32-bit QD installed and a
     32-bit QuickDraw capable video card is also installed and the
     application attempts to directly address the frame buffer a
     problem occurs. The application is attempting to access a 24- bit
     address in 32-bit addressing environment. In this case, the
     address request will be redirected to the 24-bit alias of the
     32-bit buffer and you end up with garbled screen data or a system
     that hangs.

     Keep in mind this situation can occur on any machine with 32-bit
     QuickDraw and a 32-bit QuickDraw capable card installed. The
     difference is that on a machine with 32-bit QuickDraw as an INIT
     in RAM, the INIT can be deactivated and the system will revert to
     24-bit addressing for the frame buffer (although it will lose new
     features).  Because on a IIci, 32-Bit QuickDraw is in ROM, it
     cannot be defeated, so these applications will not work correctly,
     and require revision. Once again, this problem occurs only with
     new video cards that expect 32-bit QuickDraw.

     Important Note:
     The revision to HyperCard from 1.2.2 to 1.2.5 was required to
     address this issue.
_______________________________________________________________________

4) Built-in video 

One of the features of the IIci's built-in video design is the fact
that it is self configuring, which means that all the user has to do is
plug the monitor into the video port and the system automatically
recognizes what monitor is attached and configures itself accordingly.
Offering this feature required that there be some type of monitor
identification scheme included in the design. The scheme used in the
IIci is to designate three of the 15 pins within the video connector
for monitor identification. This gives the system a 3 bit value (3 pins
pulled high or low, where high = 1 and low = 0) for identifying up to
to 8 different conditions, (7 different monitors + 1 no-monitor
condition).

It is significant to note that this scheme originated with the
introduction of the revised 4/8 bit video card introduced in the spring
of 89'. It is also important to note that it is being utilized on both
the 8/24 and 8/24GC cards introduced on March 19th and in the future it
will be utilized in all future systems which incorporate built-in video
and in all future video card designs from Apple.
________________________________________________________________________

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 effected
developers using an ADB hardware lock for copy protection. As it turns
out there was really only one third party vendor effected by this
change. However the impact was magnified because this one developer
sells 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) 25 MHz Clockspeed - "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
clockspeed system. The 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 Mac 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
IIci ROM) supports improved methods of carrying this device-specific
data with each card. As a result of this change the 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 IIci.

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

9) Problems related to bugs in the IIci ROM

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

   * Palette Manager

     There was a patch file for the Palette Manager which failed to be
     included in the final IIci ROM. This patch file helps to correct a
     minor problem in the 32-bit color QuickDraw code built into the
     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 IIci ROM.
     It causes zero-width characters 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 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 for instance
     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 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 dialogue boxes that appear on your
     screen.


Conclusion:

This report is intended to promote a better understanding of the issues
surrounding IIci compatibility, and encourage an appreciation of the
fact that the majority of the modifications necessary to support the
IIci are modifications that are going to be required to support future
versions of the O/S as well as future CPU's.  The Macintosh IIci should
not be viewed as an ill-behaved exception, but instead as a machine
that is contributing to the evolution of the Macintosh technology.

The good news is that the majority of third party applications run
perfectly fine on the IIci.  And, among the small number of third party
compatibility problems related to the IIci most have been revealed, and
if they have not already been corrected they are in the process of
being corrected.

To reinforce this point there is a IIci Compatibility List. This list
(posted by company and by product) was gathered through a survey of the
leading Macintosh third party developers and includes over 350 of the
leading hardware and software products, all of which are compatible
with the IIci.

Once again, I hope this report will contribute to your understanding of
the IIci and in so doing strengthen your confidence in the product. It
is critical that we move customers beyond any concerns they may have
regarding IIci compatibility and focus their attention on the
outstanding features the product has to offer. If you have any
questions please feel free to link me.*


Thx

Fred Benz
Macintosh IIci Product Manager 


========================================================================
 
* See the accompanying note "IIci-Compat-READ-ME" for instructions to
  send questions or comments regarding the IIci Compatibility Report or
  lists.
 
========================================================================