> Actually, reverse engineering is not a grey area, and a common practice
> throughout industry. The shrink wrap cover on the MacOS claims that it is
> supposedly illegal to disassemble their code, but shrink wrap licenses have
> been found unenforcable by court decisions.

Yes, there was some court case recently (I think it involved Saga) that
basically said that it's okay to reverse engineer someone else's
stuff.  It's not that we're afraid of losing in court, we're afraid of
being sued at all.  Apple seems to sue at the drop of a hat, and we
don't have the resources to defend ourselves at all.  I seem to
remember that a group of guys once wrote some kind of Desktop
lookalike, and they promptly got a very nasty letter from Apple with
threats of lawsuits; they had to stop distributing their work for fear
of being taken to court.  I'd like to avoid that here, if possible.
I want to give Apple absolutely no basis for sueing.

Notice that this is completely independent of whether what we do
is actually illegal or not.

> In order to figure out the driving of some peripheral, it might really help
> a lot to disassemble the code to see how it is done. It could be amazingly
> effective in clarifying some problems. After you know how to control the
> devices, one is in the position to write genuinely original code, that in
> no way infringes on Apple's copyright claims.

It's difficult to write original code after having read someone else's.
At one point, at the very beginning of this project, we considered
having some kind of clean-room environment where one person would
reverse engineer Apple's software, write down how it worked, and
someone else would implement it in MacBSD.  Even this we were afraid
of, and finally decided to take the long road and guess everything
from scratch.

Now, if one of *you* wants to reverse-engineer the code and tell us
in English (not in code) how it works by posting it to some public
place, we'll be happy to use that information.  :-)

> Can someone summarize the current state of knowledge on these ADB chips and
> point out what sticky unknown areas remain ?

Brad could probably talk for two hours on what he knows about ADB.  I
believe we're actually pretty close to understanding how it works
on many of the Macs.  It only took two years of experimenting.

> Also, what is the difference between the IIci and the IIsi ?

Different ADB system, and the IIsi only has 1 meg in Bank A.

> In some IIsi Developer Note, it says "Several bits in VIA1 have been
> redefined to allow the ROM to distinguish between different computers." I
> suppose those are just differences between IIci and the newer ADB, or is
> now every machine different ? Are the exact changes known ?

Many times on this mailing list people have said things like, "I don't
see why it's so hard to write code for the hardware, it's all
documented in 'Inside Macintosh'" or whatever.  It's difficult for the
exact reason that you give above -- the documents give vague
descriptions of how things work, but don't give the actual details.  I
remember back when we didn't have ADB working at all, I found a
sentence in Inside Mac that said something like, "Bits 2-7 of register
X are used to control the input system."  Of course, it didn't actually
say what the values of the bits *did*.  I spent all weekend (literally)
trying every combination of those bits and every permutation of reading
and writing to that register.  At 11:00pm on Sunday night, I finally
found the right combination and we had keyboard input.  Now re-read the
sentence above from the Developer Notes and try to guess how long it
would take you to figure out those bits.  Now try to guess how long
it would take *if you didn't have a IIsi*.

This is obviously not a flame at you, Markus.  You're one of the first
ones who's actually realized the difficulty we're dealing with here.

Anyway, maybe this will answer some of you all's questions about
why little progress is being made on the IIsi and other machines.
(At least for the Mac II we had a machine to guess on!)  I'm
hoping that Allen's purchase of a Q700 will help considerably,
and my purchase of a Mac II will help out in other parts of the
code, such as the console.

Lawrence

------------------------------------------------------------------------------