All DatabasesMacTech Vol 03-1987
Mac II
Volume Number: 3
Issue Number: 5
Column Tag: Developer's Conference
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 e specially bad for both shared and multi-tasking situations. Files
opened by an application should remain open until the application ends thus pr eventing
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, pr eventing
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.
Referenced by (144):