[Coco] DS-69B Reverse Engineering

[L. Curtis Boyle]

On Fri, 04 Aug 2006 09:18:08 -0600, Joel Ewy <jcewy at swbell.net> wrote:

> Years ago I disassembled the little assembly routine loaded by the
>   RANDACB.BAS program for the DS-69 Digisector.  I also cut open the  
> glued
>   plastic case of my Digisector, got an ohm meter in there and scribbled  
> up a
>   partial schematic.  I even have vague memories of having unsocketed  
> the GALs,
>   stuck them in my programmer, and learned that the security fuses  
> hadn't been
>   blown, but a cursory search hasn't yet turned up the fuse maps.
>  I have a couple pages of semi-commented disassembly and notes that  
> floated to
>   the top of the piles recently, and my interest in the DS-69 is at a  
> high ebb again.
>  There's a mysterious section of the code that doesn't make any sense to  
> me and
>   I wonder whether I just don't get it (entirely plausible) or if the  
> copy of the program
>   I disassembled 15 years ago was already corrupt.  (Mind you, this is  
> the
>   RANDACB program, not C-SEE, the main program.)
>  I just tried making a new copy from the original floppy.  It took me 3  
> tries to get
>   DECB to make a backup without I/O errors.  I have little faith that  
> what I got is a
>   faithful replica of the original.  Since RANDACB is only used by the  
> sample
>   BASIC programs (which I never really used back in the day), and not  
> the regular
>   digitizer software, my copy of RANDACB may have been bad all along,  
> for all I
>   know.  I chose to disassemble it instead of C-SEE because it is much  
> simpler,
>   smaller, and easier to understand than C-SEE, and is really only  
> involved with
>   running the digitizer and communicating with a BASIC program.
>  I might add that I recently tried using the SLOWPIC.BAS program to make  
> a
>   64-level image that I could massage into something useful with netpbm  
> tools.
>   It did create an image, but it was peculiarly distorted in that every  
> 16 columns it
>   would appear to back up and re-digitize the previous 16 columns.  If  
> anyone's
>   interested in seeing what I mean I can email you a picture.  The type  
> of error it is
>   would seem to me to be coming from a bug in the BASIC program instead  
> of the
>   assembly routine.  But I haven't yet ruled out that the mysterious  
> code section
>   might be causing this problem.
>  1.  Does anybody have a working DS-69B setup?  Any interest in aiding a  
> project
>   to understand how the thing works with the aim of writing a driver for  
> (Nitr)OS-9?
>   I'd like to compare my version of RANDACB with another presumed-good  
> copy.
>  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