[Coco] DS-69B Reverse Engineering

[Joel Ewy]

poco6809 at hotmail.com wrote:
> I did some programming on one of those things years ago. Actually
> wrote a cute little VCR program.
> If I remember correctly the 69B scanned in columns, 8 to be exact. You
> would program a comparator register to tell it what luminance level
> you were looking for another register telling it what column you
> wanted, then wait for the scan beam to be in the right spot, read 16
> bits from another register and wait for the next scan line. that would
> give you 1 column of video, then just do it again for the next column.
> If you want to send me the code I'll sell if it shakes any cobwebs loose.
>
> ...
Cool.

    Your description generally meshes with what I've been able to figure
out so far.  It certainly does scan in columns, and the .PIX images it
creates from the C-SEE application are saved on disk that way.  My
pseudo schematics show an LM319C comparator, a 74164 shift register, a
74161 counter, some 74374 flip-flops, a couple GALs, a 68(B)21 PIA, and
a Schmitt Triggered hex inverter.

    You say it scans in 8 columns and reads 16 bits at a time.  Would
this be in the 16 gray level mode?  Are you saying that you read 16
horizontal partial pixel values at a time, then wait for the next
horizontal sync pulse, then (wait, count?) until you get to the same
horizontal position again and grab another 16 bits?  If I understand
what you are saying correctly, you must be describing the 128 x 128
mode.  8 columns, 16 pixels wide, would get 128 pixels horizontal
resolution.
    The code I disassembled is for RANDACB, which only digitizes in 256
x 256 mode, and resolves each pixel to 64 gray levels.  I took a few
shots using the SLOWPIC.BAS program (which really is extremely slow),
and got weird results.  It digitized in 16 columns, but it appeared to
scan like this:  1, 1, 3, 3, 5, 5, 7, 7, 9, 9...  In other words, there
were duplicate columns.  But they weren't just duplications of the
data.  You could see that they were slightly different.  Each odd column
was actually digitized twice, and the even columns were skipped.  I had
thought that RANDACB was digitizing only a single pixel at a time.  But
what you describe sheds some light on the bug I've apparently found (not
sure yet whether it's in SLOWPIC or RANDACB).  It's not digitizing a
single pixel each time around, but 1 bit slice of 16 consecutive
pixels.  Hence my 16 16-pixel wide columns.  I still don't know why it
is skipping and duplicating columns, but the general behavior doesn't
seem quite so weird now.

    The copy of the disassembly I've been working with is 2 1/4 pages of
yellowed fanfold tractor feed, dashed off in draft mode on a Star NX1000
Rainbow, probably around 1988 or so, with annotations in red pen and
pencil.  The micro-perforations have finally given out between pages 1
and 2, but the third partial page is still barely hanging on to the end
of page 2.  And there are lines of text being decapitated by the page
breaks.  Let me dig around on my old CoCo disks and see if I can find a
file of the original disassembly.  Failing that I'll see if I can dig up
the disassembler and recreate it.  I'll try to copy my comments into the
text.  I could also scan the rough schematics if that would help shed
any light.  Sometime if I make them more complete I'll do em up in
TinyCAD or something.

    A couple more thoughts.  If the DS-69 can scan consecutive pixels
(pixel-slices), why couldn't it scan an entire horizontal line in one
go?  (Assuming we're not worried about hogging the CPU or losing clock
interrupts, etc.)  Is it a hardware issue with the DS-69?  I need to
look into how that 74161 is used.  Is that counting out pixels for the
comparator?  If so, how does it get reset?  It actually looks like it's
clocked by the comparator.  Better take the electrical tape off the
DS-69's cover and get out the ohm meter...

JCE