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