[snip]
Dick> In the event that the manufacturer is not cooperative, some
Dick> third party can WRITE A SPECIFICATION, detailing all he/she
^^^^^^^^^^
Dick> is able to determine by any means whatsoever including
^^^^^^^^^^^^^^^^^^^^
It's not sufficient to detail all that one is able to determine. You
must detail all that is required, and as a functional specification.
If the bits that are being loaded are indeed tables for some finite
state machine, then you can't specify the bits, but you can describe
the machine and detail what transitions need to be made and why.
Dick> disassembling code. This specification must address what has
Dick> to be done, NOT how to do it. This is the way Phoenix wrote
Dick> the first "clone" BIOS for the IBM/PC/AT. They had a bunch
Dick> of "dirty" engineers that disassembled code, etc., and wrote
Dick> a complete specification.
^^^^^^^^^^^^^^^^^^^^^^^^
The specification has to be functional in nature, so the person
writing it can't just say blast a particular bitstream across. So
*much more* analysis would have to be done before you could use the
clean-room/dirty-room approach that Dick is suggesting.
After all, people intent on cloning the Mac can't include the Mac ROMs
in their code by getting someone to write a spec. that says "then,
during bootup, load these 512k bytes into memory..."
>From Dick's description, it appears that he knows this, but since the
original question was "I have a bunch of bits that need to be sent,
but I don't know what they do", I just want to make sure that everyone
knows that clean-room/dirty-room engineering will require the big step
of figuring out exactly what those bits do. Only then can someone
write a description of the requirements for those bits. And nobody
can write down the bits themselves (there are exceptions, but I don't
think they would apply to this particular case) and pass that
information on to the implementor without tainting the implementation.
--Cliff
ctm@ardi.com