[Coco] DS-69B Reverse Engineering

[Joel Ewy]

L. Curtis Boyle wrote:
> On Fri, 04 Aug 2006 09:18:08 -0600, Joel Ewy <jcewy at swbell.net> wrote:
>
>> ...
>>  2.  Does anybody have any bright ideas about what the following code
>> snippet
>>   could possibly be doing?  It may be corrupt.  It may be
>> intentionally obfuscated.
>>   Maybe there's some other place in the code that I haven't noticed
>> yet that
>>   modifies this section so that it makes sense.  I don't think that's
>> likely, but it
>>   certainly doesn't make much sense to me as it is.
>>  The code segment is part of the routine that reads brightness values
>> of a pixel.
>>   I think we are doing successive approximations, at least partially
>> in software,
>>   which is why it takes about 4 hours to digitize a 256x256x6-bit
>> image with this
>>   software, unless you use the high-speed POKE.
>>  ...
>>   7F9D    8607    8:     LDA   #7
>>   7F9F    B7FF71       STA    $FF71   -> PIA register on the DS-69B
>>   7FA2    10AC9DDEF4    CMPY    ( 57076,PC)   Mysterious section begins
>>                                    We  haven't been using Y, and
>> don't seem to later
>>   7FA7    12                    NOP
>>   7FA8    12                    NOP
>>   7FA9    12                    NOP
>>   7FAA   1012            ????   The disassembler chokes on this, and
>> it does
>>                                       appear to be an illegal opcode
>> (on the 6809).
>>   7FAC   E661            LDB   1,S   Now we start making sense again
>>   7FAE    B6FF22        LDA    $FF22   I think we're enabling an IRQ
>> here
>>   7FB1    B6FF70        LDA    $FF70    Ditto in the DS-69's PIA
>>   7FB4   13                SYNC   Here we wait for the IRQ.  This 
>> makes sense
>>   7FB5    E484              ANDB    X+0
>>   7FB7    ...
>>  3.  If anyone is interested I can email the rest of the code and
>> comments and
>>   scans of my provisional schematics.
>>  JCE
>>
>
>     Is there self modifying code later on, that fills in the NOP's? Or
> have you disassemlbed from an incorrect offset, and are looking at a
> data table?
>
>
>
> --L. Curtis Boyle
>
I'm fairly sure this doesn't get modified anywhere else though it's
possible I'm missing something.  I'm almost positive it's disassembled
from the correct offset.  There's quite a bit before and after this that
is perfectly sensible code.  It's just this little section that lapses
into apparent lunacy.  It would be far too much of a coincidence if all
the rest of it just happens to look sensible even though it's
disassembled wrong. 
I've remembered that in addition to the RANDACB.BAS for the DS-69B there
is a RANDAC.BAS for the older DS-69 model.  I should do a hex dump of
that and see if it has corresponding wackiness.

JCE