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.
========================================================================