mfi@beach.cis.ufl.edu (Mark Interrante) (05/20/89)
This is reposted without permission (i'm not sure if any is needed) from:
*---== ST REPORT ONLINE MAGAZINE ==---*
May 05, 1989 Volume III No.86
R.F. Mariano Publisher - Editor
Voice: 904-783-3319 10 AM - 4 PM EDT
BBS: 904-786-4176 12-24-96 HST
CPU INSIGHTS?
=============
Turning Point: The End of an Era
---------------------------------
James McHugh, President of C.E.K.A., recently announced that he was
selling a hardware Macintosh emulator for the Atari ST for $250-300, which
not only can read/write to Mac Disks, but runs most Macintosh MIDI programs
and doesn't require Apple's Macintosh ROMs for its use. While Spectre GCR
can already read/write to Mac disks, NO Macintosh-compatible system,
Emulator or otherwise, can operate without the Macintosh ROMs, which hold
significant parts of the Mac's operating system. So how did they do it?
The answer to this question is deceptively obvious: C.E.K.A. has
developed a ROM chipset which CLONES the 128K version of Apple's Macintosh
ROMs.
[description of Mac deleted.]
With the exception of Macintosh Emulators. When Dave Small invented
this industry in 1986 with the Magic Sac, the only warning that Apple gave
was that he could not bundle the Macintosh's ROMs with it. Even though the
Magic Sac (and later the Spectre 128) used software to emulate the Mac, it
required Apple's Mac ROMs to function. Apple's early attitude resulted in
an increasing market for Mac Emulators, such as Spectre 128, Aladdin (a
European Mac Emulator), and Readysoft's AMax, a Macintosh emulator for the
Amiga. However, it seems that now, with Apple telling dealers not to sell
Mac ROMs to anyone using a non-Apple environment, the popularity of Mac
Emulators has grown a tad too much for Apple's tastes. And so, with no
Macintosh Clones, no Apple ROMs with which to operate Macintosh Emulators,
and no competition, it seemed as if Apple's monopoly (as well as its legal
department) was going to continue its domination of the industry....
[Description of Phoenix BIOS and IBM clones deleted]
James McHugh of C.E.K.A. used a variation of the "Clean Room" method
to clone the 128K Apple Macintosh ROMs. Utilizing over twelve books on the
Macintosh, including Inside Macintosh Volumes I, II, III, IV, and V
(a total of 2224 pages of pure information about the Macintosh), he and his
company were able to singlehandedly produce a Clone of the Apple 128K Mac
ROMs within a 2 1/2 year period. The result of his labor, collectively
termed the "Macintosh Replacement Project", has just recently been
completed.
According to C.E.K.A, their 128K Mac ROMs are not only completely
compatible with Apple's Mac ROMs, but run from 10 to 30 percent faster in
most operations, due to the fact that they are written purely in 68000
assembly language (Apple wrote their Mac ROMs using C). Also, C.E.K.A's
Mac ROMs are much less buggy than Apple's 128K Mac ROMs, performing some
functions (such as memory allocation) more efficiently.
However, C.E.K.A. has added a few conveniences to their Mac ROMs
which aren't in Apple's Mac ROMs. In order to prevent possible piracy of
their Mac ROMs, C.E.K.A stores their Mac ROM code in modified EPROMs
designed at IBM's Research Labs, which ERASE themselves if anyone tries to
dump their code onto disk using software, or copy them using an EPROM
Burner. This, however, brings up some interesting points. There are about
30 badly behaved Macintosh programs that C.E.K.A knows of which make the
same illegal memory calls that the EPROMs "protect" themselves against, and
if you run any of these programs, you risk losing your ROMs. C.E.K.A.
provides a FULL LIST of these programs, and since a pirate may have erased
their EPROMs in an attempt to copy C.E.K.A's code using an EPROM Burner,
C.E.K.A. will not replace any ROMs that were erased UNLESS the program that
triggered the EPROMs into erasing themselves is not on their list of buggy
Mac programs. Inconvenient, but since software pirates....
Also, C.E.K.A.'s Mac ROMs provide some defense against any onslaught
by Mac viruses. According to C.E.K.A., their Mac ROMs monitor all activity
in the Mac's Resource Handler, watching for operations (such as illegal
system calls) which, while not common among ordinary Mac programs, are
usually used in Mac viruses. If it detects any sign of a Mac virus, a
dialog box automatically appears on the screen with a description of the
problem, its diagnosis of whether it is virus-related or not, and (in case
the program causing the trouble may just be a ill-behaved Mac application)
a prompt on whether to eliminate the problem or not....
In response to C.E.K.A.'s work, several of the biggest US computer
manufacturers in the industry, and at least one Japanese corporation, are
said to both be funding C.E.K.A.'s research with a war chest of around
100 million dollars, and using the C.E.K.A. Mac ROMs as a basis for their
own development of Macintosh Compatible computers. Also, C.E.K.A. is
planning to make a pseudo-clone of Apple's NEW 256K Mac ROMs. Apple's
upcoming revision of their 256K Mac ROMs is said to be upgraded for 32-bit
operation, and to have a 32-Bit Color QuickDraw. The difference between
C.E.K.A.'s pseudo-256K Mac ROMs and the Apple 256K Mac ROMs will be that
Apple's 256K Mac ROMs require a 68020 or 68030 to operate, and C.E.K.A.'s
256K Mac ROMs will be able to function with a 68000 installed.
Since some of the Mac "Clones" being made by the companies dealing
with C.E.K.A.'s will be announced before the end of 1989, and given that
the Japanese have wanted to enter the US computer market for a VERY long
time, one could easily see that before 1991....
[description of Atari ST package using Clone chipset deleted]
C.E.K.A. is a registered licensee of Apple's System/Finder, so with
C.E.K.A. bundling the latest releases of the Mac's System software AND the
ac ROMs necessary for its operation, ST Users have "plug in and play"
functionality that was lacking in previous Macintosh Emulators.
C.E.K.A. is also making versions of their Mac Emulator for the NeXT
and Sun Workstations, which will also cost $250.00. Since the NeXT and
the Sun run Unix, the C.E.K.A. Mac Emulator uses a special driver to allow
them to multitask Macintosh programs as a task under Unix. However,
because of some aspects of Unix, the C.E.K.A. Emulator will only be 70
percent Mac Compatible if it is run as a task under Unix. C.E.K.A. also
allows Users to let the Emulator take over the machine, using it like an
ordinary Macintosh. In this mode, 99 percent Mac Compatibility is assured
by C.E.K.A. However, the Mac Emulators for the NeXT and Sun/1 workstations
may not appear until the Third or Fourth Quarters of 1989, as C.E.K.A.
plans to use their 256K Mac ROMs in those versions of their Mac Emulator
to allow the NeXT and Sun to run Mac II software....
[description of possible Amiga chipset deleted]
Editor Note:
-----------
Although Mr. McHugh has assured us that the products he speaks of do
exist, and that he has shipped a test unit to us at STReport, we can neither
endorse or verify that such products exist. When we receive the device
we will provide a complete and impartial review.
-----------------------------------------------------------------------------
Mark Interrante Software Engineering Research Center
mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611
-----------------------------------------------------------------------------
"Imagine what it would be like if TV actually were good. It would be the end
of everything we know." Marvin Minskytrebor@biar.UUCP (Robert J Woodhead) (05/22/89)
In article <20335@uflorida.cis.ufl.EDU> mfi@beach.cis.ufl.edu () writes: >C.E.K.A stores their Mac ROM code in modified EPROMs >designed at IBM's Research Labs, which ERASE themselves if anyone tries to >dump their code onto disk using software, or copy them using an EPROM >Burner. The first case is flat out impossible to protect against. Any debugger that can single step will be able to read the EPROMS, and worst case, a modicum of extra hardware could easily snoop out the contents of the EPROMS (they have to be read during instruction/data fetches anyway, and you can just monitor the address and data lines). In addition, it's foolish. If it's possible to write a program that trashes the EPROMS, what happens if, just by accident, System 7.0 just happens to do this? Ooops. Bottom line; assuming they have a real product, they will lose more sales because of pissed off customers trashing their EPROMS (plus god knows how much $ spent in support) than they will from pirates stealing the EPROMS. -- Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP "The lamb will lie down with the lion, but the lamb won't get much sleep." -- Woody Allen.
fiddler%concertina@Sun.COM (Steve Hix) (05/23/89)
In article <20335@uflorida.cis.ufl.EDU>, mfi@beach.cis.ufl.edu (Mark Interrante) writes: > > According to C.E.K.A, their 128K Mac ROMs are not only completely > compatible with Apple's Mac ROMs, but run from 10 to 30 percent faster in > most operations, due to the fact that they are written purely in 68000 > assembly language (Apple wrote their Mac ROMs using C). Interesting. This must explain why Mac Toolbox calls take their arguments in Pascal rather than C order. And why the various C implementations on the Mac use glue routines to pass parameters correctly to and from the Toolbox routines.
mahan@zaphod.ncsa.uiuc.edu (05/24/89)
I don't know what method CEKA is using to protect their roms, but one possible way is to have just a few memory addresses trigger the wipe. Since a typical rom copy routine is going to read every address. Since we don't know which addresses ( or block of addresses ) would trigger the wipe....
lsr@Apple.COM (Larry Rosenstein) (05/24/89)
In article <20335@uflorida.cis.ufl.EDU> mfi@beach.cis.ufl.edu (Mark Interrante) writes: > most operations, due to the fact that they are written purely in 68000 > assembly language (Apple wrote their Mac ROMs using C). Also, C.E.K.A's Well this is false. The 128K ROMs were written 100% in assembler. Later ROM version have included some C code (I think), but are still primarily in assembler. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (05/24/89)
In article <600039@zaphod> mahan@zaphod.ncsa.uiuc.edu writes: > >I don't know what method CEKA is using to protect their roms, but one >possible way is to have just a few memory addresses trigger the wipe. Since >a typical rom copy routine is going to read every address. Since we don't >know which addresses ( or block of addresses ) would trigger the wipe.... There still would be multiple ways around it if you want to figure out how to copy them. You might need quite a few ROMs (to play with and experiment where they wipe out), but you could just read through the ROMs, recording which locations trigger the wipeout. You could even read, wait a few cycles, and read again to check if the same contents are still there (just in case the ROM erasure is delayed). However, if the protection is done this way, *one* bad system crash that sends the CPU fetching instructions where it's not supposed to, and your ROMs are gone. It seems to me that CEKA's protection scheme is more trouble than it's worth, since pissed off people about wiped-out ROMs while using their machines can wreak havoc with your reputation as a supplier as well as yell loud enough to make other people pissed off at you as well. I have further reservations about these ROMs, some of which have been discussed in the net: 1) If development was done in a "clean room" environment (ie w/o looking at the originals but only at what they do) then how the heck do they work around the code in the system file which is location dependent (you know, the stuff that checks the stack to check where it was called from and what not). 2) How do they work around Apple's patents on display technology (discontinuous regions, specifically)? Or do they completely disregard them and leave themselves wide open for a lawsuit? 3) Who are these people, anyway? I mean, I was under the impression that the 128K ROM code was written in assembly code and "hand-optimized" by hotshot 68K programmers. It seems a little off-the-wall, to say the least, for an outfit to appear seemingly out of nowhere claiming to have done what they do, and to have written faster code than Apple's. Not impossible, but they're pushing it. 4) How are they going to work around System 7 if Apple decides to put random checks inside the System software? Needless to say, I am *very* skeptical about these people's claims, especially in light of the various mistakes in the article (Apple's ROMs written in C, their being able to provide Apple's System and Finder to run on non-Apple machines [that's a big no-no in the licensing agreement], etc.) I'll believe it when I see it, and if that happens I hope to see them squashed in court. -Ivan Cavero Belaunde "War is Peace. Freedom is Slavery. ARA is Edible." EMail: captkidd@athena.mit.edu USnail: 407 Memorial Dr. Cambridge, MA 02139 Phone: (617) 621-0312
rubinoff@linc.cis.upenn.edu (Robert Rubinoff) (05/24/89)
Has anyone actually seen one of these clones? The description struck me as very unlikely. The idea of erasing the (EP)ROM if you try to read it strikes me as nuts; the machine is guaranteed to self-destruct sooner or later. And I don't think many people will be happy about the idea that if they do destroy the ROM, they can get it replaced eventually (if they can prove it was an accident). This will go over real well: my paper's due in 12 hours, but oops! my machine just self-destructed. Well, I can get it fixed day after tomorrow (if the dealer has spare ROMs in stock). And what business would even consider buying such a machine? Not to mention the unlikely claims that they're much faster than Apple's code, and that it's legal to use Apple software on these machines. I suspect the information is either drastically garbled or a delayed April Fool's joke. Robert
Cj.Flynn@f823.n102.z1.FIDONET.ORG (Cj Flynn) (05/30/89)
Good C code doesn't take 30% longer anyway...some people jsut like to complain. -- Cj Flynn via cmhGate - Net 226 fido<=>uucp gateway Col, OH UUCP: ...!osu-cis!n8emr!cmhgate!102!823!Cj.Flynn