Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!captkidd
From: captkidd@athena.mit.edu (Ivan Cavero Belaunde)
Newsgroups: comp.sys.mac
Subject: Re: Mac clone rumor (long)
Message-ID: <11632@bloom-beacon.MIT.EDU>
Date: 24 May 89 14:19:24 GMT
References: <20335@uflorida.cis.ufl.EDU> <600039@zaphod>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: captkidd@athena.mit.edu (Ivan Cavero Belaunde)
Organization: Massachusetts Institute of Technology
Lines: 57

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