[Coco] DS-69B Reverse Engineering

[Arthur Flexser]

My guess (unless you've ruled this out) is that it's code that doesn't actually
get executed, existing in a gap between assembled code segments and containing
junk left over from previous assemblies.

Art

On Fri, 4 Aug 2006, Joel Ewy wrote:

> 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
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>