Rick Hawkins wrote:

> Now, for the magic question:  what is that kernel synced with?  do I want
> 1.2.1, or current, or something in between.

Not sure. Takashi?

> OK, sleep would be nice :)  I assume that it can turn back off, though?  I
> don't think I ever managed to get below 1:20 on a full charge, even with all
> power management defeated.  And I have three batteries and a long extension
> cord . . . and toshiba is making 810mb drives, $399 . . .

Oh, cool. Where?

> I've read through this, but I don't understand the nature of the failure.  Is
> it a single call which is never returned from?  or is it useless data
> returned?  And if it returns, is there a way of judging "partial" success?  If
> so, and assuming that the search space isn't more than a few hundred bits, a
> genetic algorithm isn't too hard to implement.  We could use an adb modem or
> some such to send the "attempt" characters, and just leave the two machines
> alone for a couple of days.

If you are using the DIRECT method then the problem could be anything.
Misinterpreting a state, a missed interrupt, a misunderstanding of how
the interface's "state" machine works, etc. 

On the non-PowerBooks, there are only 3 bits that control the ADB
interface,
plus 1 that controls the data direction. You'd probably need to include
the interrupt line in your calculations somwhow. On the Powerbooks,
there are
2 or 3 control lines and sort of a "parallel" connection for the data
instead of a single bit line for data as with the non-PBs.

Sometimes you can determine a success. Sometimes if you do things wrong
you can get the chip into a really hosed state. We could probably
detect such a thing, and we know fairly well how to "reset" the 
interfaces, so this may be acceptable.

We know how the interfaces work for the most part, but an algorithm
such as you describe might help us weed out some problems. Do you have
any examples of code for such a project so we can determine how 
difficult it would be?

Thanks!

	--John