The Mac II Hardware

By David E. Smith, Editor & Publisher, MacTutor

Apple held it's Spring Developer Conference this week at the TechMart / Doubletree Inn in San Jose, just as IBM announced their new PC System 2 computers. In fact, the six hundred Mac and Apple developers had to cross through the reception area for the big IBM announcement to get to the conference rooms where the new Mac II hardware was being discussed. A few Mac fans slipped off their Apple badges and infiltrated the IBM crowd to carry off the product descriptions of the Mac-alike PCs. The new IBM machines look very much like the Mac II, having 256 colors out of 250,000 even! Of course the Mac II with color quickdraw uses 16 bits each for the blue, red and green, making a 48 bit color selection, which allows 16 million color combinations, using 24 bit color table entries. The number of colors available at one time is dependent only on the amount of memory on the NuBus video card, which in 24 bit mode can be up to 1 megabyte per NuBus slot. The initial Apple video card (and SuperMac Spectrum card) allows 256 colors from the pallette at one time, using an 8 bits per pixel index, but the intricate color quickdraw is far superior to the modes of the IBM, allowing sophisticated mixing of color into new colors, and animation of the color tables. Each window retains its own color table, which are switched as each window becomes active by the color manager. The generalization of color quickdraw means it will support new video hardware well into the future without any changes to current application software. By comparison, the IBM implementation is grammar school stuff. The generalization allows applications to specify color in RGB space, a cube structure 16 x 16 x 16. The RGB color is then matched to a best fit for that color in the video card's color table automatically. Better video cards just make the match that much closer to being exact. A color picker utility and improved control panel access allow the user complete freedom to configure the desired 256 colors from the pallette.

Multiple video displays are automatically supported by the window manager and color manager so that you could set up a Mac II with three video displays and move windows across screen boundaries. When future multi-tasking Finders are ready, each window will be an active application, switchable by a simple mouse click. With alternative CPU cards acting as NuBus masters, each window could also be an emulation of another computer architecture as well. It may be possible to open an MS/DOS window on one video, Mac Finder on another, and Unix on yet a third, with complete movement of information between the three. In fact, the Mac II may be the most flexible computer ever designed. No doubt a complete Apple IIGS emulator card will arrive from someone in the near future that would allow the Mac II to run Apple II software without modification.

Mac II Hardware

The most fascinating part of the conference was the description of the Mac II hardware. This is truly a beautiful 68020 single board computer implementation as shown in figure 1, with every consideration given to the on-going development efforts both within Apple and from Motorola. The Integrated Woz Machine has been reduced even further so that now it is a tiny custom IC. The IWM is socketed to allow an upgrade path for Sony 1.2 meg disk drives and alternative encoding schemes in the future, both being actively pursued by Apple engineering. In fact, the real message of the conference may have been the confidence that Apple is designing products on a continuous upgrade basis, rather than on the shotgun approach of the past.

Fig. 2 Memory Maps

24 versus 32 bit Mode

One area of confusion is the memory map. On the Macintosh, the 68000 allowed 24 bits of address space. The memory manager used the upper 8 bits of master pointers for various flags like whether or not the relocatable block was locked or purgable and so forth. Many Mac applications check these flag bits directly although they aren't supposed to. The result is that in 32-bit mode, many Mac programs bomb because they try to make use of the upper 8 bits of address space. So Apple made up a simple mapping controlled by a custom memory management chip called the HMMU, which selects between 24 bit mode and 32 bit mode from a switch signal in the VIA2. A trap allows application programs to switch back and forth. Apparently all the ROM routines have been cleaned up so they will work in 32 bit mode except the memory manager. Hence, normal Mac mode applications will run in 24 bit mode on the Mac II, which allows 8 megabytes of address space on the motherboard and 1 megabyte per each of the 6 NuBus slots. However, programs can also switch to 32 bit mode, gaining full access to the address space of the 68020 (4 gigabytes!), allowing far greater memory capacity in both the motherboard and in the NuBus slots. In 32 bit mode, up to 128 megabytes can be supported on the motherboard, and up to 16 megabytes per NuBus slot as unique address space. An additional "super slot" scheme can support up to 256 megabytes per NuBus slot although the application must check that no other NuBus card is currently using the super slot the card selects. Apple is committed to phasing out 24 bit mode and promises to upgrade the memory manager as third-party developers upgrade their programs and stop using the flag bits in handles. The Motorola PMMU also does this 24 bit mapping when it replaces the HMMU, but in addition to this simple switch, provides the full page memory management functions required for 32 bit address space so that a full-featured multi-tasking operating system like Unix can be supported. It is expected that the current Finder will migrate to a quasi multi-tasking status in the very near future and in fact, the 600 developers were being allowed to receive advance information on a non-disclosure basis at the conference. A list of do's and don'ts is being provided developers so that applications can be made compatible with such a multi-tasking environment.

NuBus

Each NuBus card contains a configuration ROM that allows the card to be plugged into any slot, and configured accordingly, eliminating jumpers or switches found in other bus systems. Cards may be either slaves as in video cards or masters as in another CPU card. Each card can communicate with each other and within the complete 32-bit address space of NuBus. Communication with the Mac II bus and the 68020 is controlled through an arbitration scheme that allows fair access to the bus for all cards. DMA between NuBus and the Mac II bus is not supported however. In 24-bit mode, quickdraw access to a NuBus card allows up to 1 megabyte of the slot's 16 megabyte address space to also be visible to the 68020. The Macintosh II is actually another NuBus slot itself (slot 0). An extensive list of slot manager trap calls controls communication between the NuBus card's configuration ROM and the Mac II. Unlike previous Mac family computers, the Mac II contains extensive hardware documentation on how to design a NuBus card and firmware.

Video Card

The first Apple NuBus card is a video card that demonstrates how the NuBus works. As mentioned previously, color quickdraw generates digital information of 16 bits each for red, blue and green. It is the video card's responsibility to generate the video signal from this information. A frame buffer controller is implemented as a CMOS gate array with control registers to define the video array configuration. With 512K bytes of video memory on board, the card allows an 8 bit color depth per pixel, thus generating 256 colors at one time within a resolution of 640 pixel screen width. The frame buffer controller drives the color lookup table, which controls which 256 colors to select from the 16 million possibilities, and generates the analog red, green and blue video signals. The video RAM array uses ICs with a built-in shift register and separate serial port for video data to maximize the speed with which the 68020 can modify video memory.

The color lookup table takes digital video information from the frame buffer controller and passes it through a RAM based color table to three 11-bit DACs to generate the RS343A compatible RGB video signals. The color table can be modified dynamically by the 68020 to animate the video screen by changing the current set of 256 colors available. The Pallette manager arbitrates this color lookup table scenario so that multiple windows and DA's don't contend with each other over which color table will be active at any one time. Video cards with additional memory could increase either the resolution or the color table possibilities without any effect on applications. Additional video cards are linked by the window manager to be extensions of the same active GrafPort, again, independent of the application.

Sound Chip

The custom sound chip is also socketed so it can be upgraded in the future. The current sound chip is able to sample audio at 44KHz, which allows a wider bandwidth than the previous limit of the 22KHz sampling rate in the Mac Plus. There is, however, a low pass filter in hardware that starts rolling off at 7.5 KHz. In future versions of the sound chip they will use a switched capacitor filter to notch filter the sampling clock which will allow for an improved high end in the audio response. They also plan to expand the 8 bit linear coding of the sound samples to a pseudo-12 bit digitization. This will make for better signal to noise ratio and distortion figures. If Apple makes these improvements in the sound chip, it will be up to the level of currently available "sampling" music synthesizers. The output jack provides for a stereo output to an external amplifier and speaker set.

One change in the Mac II is that the external floppy disk interface is not provided. The Mac II box has room internally for two floppy drives and a hard disk. Another feature from the Lisa days is that the power switch is programmable. A clock NuBus card could turn the Mac on at a pre-set time, perform an operation like logging a call and saving data to disk, then shut off the Mac when the call completes. The video display is also controlled by the Mac II switch so the entire computer can be turned off and on under program control.

Another point worth noting: the alternate sound and video buffers are not supported, since the video is unbundled from the CPU and main memory.

Compatibility Issues

Applications should observe some obvious precautions to run on the new machines. Neither the video address space nor the application heap space should be thought of as either fixed in size nor in location as both will change. The system heap may also become dynamic, managed by a future operating system for multi-tasking and as such should not be used by an application. Flag bits for handles may be moved out from the handle itself to allow full 32 bit addressing for relocatable blocks. When this happens, the appropriate trap calls to lock and unlock handles will change, so applications should check flag bits through traps rather than directly themselves. Since system timing will change, delays should be done using the Delay proc rather than in timing loops which depend on the current clock speed of the machine.

Some programmers declare data using DC statements in their programs and then modify those locations. This won't work on the new machines because of the memory management and separation of code and data blocks. Data should be declared global with the DS command and allocated on the stack or in the heap in relocatable blocks rather than within the code block itself.

Much of the hardware of the Mac II may change in the future so access to hardware should be done through the toolbox routines. This includes the IWM and sound chips, which are socketed and sure to be upgraded in the future, as well as VIA2 which may disappear altogether into a custom NuBus manager chip. Presently VIA2 manages most of the interrupt functions of the machine, and so is an obvious target of improved integration and memory management in the future. The Enivrons trap call is being expanded to allow machine identification and this is the proper way to figure out what you are running on. The Mac parameter will identify a classical Mac, Mac SE or Mac II. The version parameter will identify the ROM set as either 64K, 128K, SE or Mac II ROMS. Apple is trying to develop a Universal System File that can run on all machines, making identification of system file goodies unnecessary. If this can be achieved, it would greatly simplify life with multiple Macs. The new trap calls of the SE and II would be available as trap patches in the system file to the Mac Plus so applications need not worry about which Mac is running. However, this cannot be done for color, which is only available on the II. By supporting SANE, applications would automatically get improved performance on a Mac II without having to code special cases for the 68881 being present or not. The Universal System File is expected to ship for all Macs with the Mac II.

Shared Environments

Just when things were starting to become clear, not only do new machines and new ROMS make it cloudy again, but new ways of doing things also confuse the issue. With Apple Share, applications must worry about multiple users of a single program on the net. Applications should plan both for shared environments and multi-tasking as future extensions of the Mac design. To be compatible with multiple users double clicking on a program in a shared environment, the application must not write configuration information to it's own data or resource forks. In fact, the resource manager is something to be avoided whenever possible when writing to disk by the application as it is especially bad for both shared and multi-tasking situations. Files opened by an application should remain open until the application ends thus preventing them from being changed by another user. The file manager has new error messages indicating the status of existing files so that shared data files are not corrupted by multiple users. A new tech note describes how programs should operate in a shared environment.

In general, everything you knew before is now the wrong way to do it in a shared environment. Here are some example of traditional ways of working that no longer work. A memory based application opens a file, reads the contents, closes the file and lets the user modify the data. When the user saves, the file is opened and the new data written out. This won't work with multiple users since another application could have opened the file in the meantime and made modifications that would be destroyed by the close operation. The solution is to open the file and leave it open until done, preventing another application from modifying it.

Another well used scenario is to open the file, read it and close the file, then create a new file and copy the finder information to the new file when the user selects close, deleting the old file and renaming the new file. This bombs because another user could have already saved and deleted the old file by the time the first user is ready to close. The solution is to get the Finder information at open time, then check for file errors when closing in case the file has already been deleted or renamed. However, the tech note recommends that this so-called switch approach is not the best way to handle files.

The final situation is disk based applications. They should keep the file open as either read or write status, locking out other users until the file is released. When the file is closed, the temporary file holding the changes can be written to the primary file and the file closed. An alert should be posted if the user tries to open a file in use by someone else. If your application supports concurrent access to a shared data file, you'll have to invent a reliable locking mechanism yourself.

Language Support

In the last session of the conference, developers heard from a number of vendors on the status of popular development systems. MPW and MacApp are undergoing revision to version 2.0 and 1.1 respectively. Object Pascal will also be released as version 2.0 as well. With this version, MPW gains a Mac like friendly interface that eliminates typing file names! This next release of both MPW and Object Pascal 2.0 seem particularly robust and powerful with many new features developers have requested including file markers. MacTutor plans to start using these new versions on a more extensive basis in articles published in MacTutor.

The popular Lightspeed products are also being revised to work on the Mac II. Both C and Pascal will have new versions in the same time frame as the Mac II begins shipping. Another major release of Lightspeed Pascal is expected this summer that will greatly expand on the already powerful debugging features.

Paul Snively demonstrated a version of TMON that works on the Mac II. Icom Simulations is working on a new, more powerful TMON for release late this year.

One oversight at this session was the fact that Steve Jasik was not invited to discuss his new debugger for MacNosy. His debugger will also be Mac II compatible.

TML announced a new version of Modula 2 that produces 68020 code and should be a welcome addition to the Mac language family. MacTutor has asked TML to supply us with more details which we will report to you in an upcoming issue. They are also continuing to update their Object Pascal.

Aztec C has greatly modified their product to both work on the Mac II and continue to support many of the Unix features that make this C product popular. Now that Unix is an Apple sponsored product on the Mac II, Aztec C may become much more influential in Macintosh program development. Look for major advances from this re-vitalized product.

Consulair is now shipping MDS 2, which they have taken back from Apple. We expect Consulair will now actively support MDS and keep it up to date with the new Mac II traps. (If they don't we'll raise a big fuss!)

The conference concluded with statements by Apple that they expect the September time frame to be an important one for new product announcements and encouraged developers to shoot for the summer Apple World to release new products. It is expected that the Mac II will be shipping in quantity by then and Apple wants to show that you can do it on a Mac today rather than wait for an IBM tomorrow. Apple is expected to release some significant new products at that time. A final tidbit at the conference was the base address of an interesting PICT in the Mac SE ROMS: $41D898. Dump this out and you'll know why the SE and the Mac II both have 256K ROMS even though the Mac II contains color quickdraw. Apple still retains some corporate sense of humor from the Steve Jobs era.