[Coco] DS-69B Reverse Engineering
L. Curtis Boyle
curtisboyle at sasktel.net
Fri Aug 4 17:57:42 EDT 2006
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
More information about the Coco
mailing list