Re: 6809 / 6702 puzzle

On Sat 21 Apr 2012 at 14:55:00 +0200, davee.roberts@fsmail.net wrote:
> Interesting...
> 
> I notice that the initial value of $D6 is one of our "hit" values.

yes...

> By looking at the schematics I am also led to believe that the 6702
> should be accessible from the 6502 processor (as the 6809 and 6502
> appear to be "next door to each other" in the schematic diagram and
> share the address and data buses). This means that you should be able
> to boot the SuperPET into 6502 BASIC and use good old PEEK and POKE to
> access the 6702 without any interference from the BASIC interpreter.

Indeed it is. I started making a Basic version of the dongle check, at
least as far as it is reading out values (I skipped the checking). For a
while I was baffled since it didn't seem to read proper values. I
discovered that the basic POKE command uses a STA ($zp),Y instruction to
store the value - which does an extra read from a memory location which
is a partial addition of the zero page pointer and the Y register...
Since Y was 00, this read $EFE0 before writing it, and due to the
emulation, it advanced the byte counter.

So I changed the emulation to advance the counter on writes, instead of
reads. The dongle check routine does a write anyway before each read.
Except for the very first read, which I've dubbed the seed. This must
mean that the seed for the next call of the check routine is identical
to the last byte checked in the previous call. It makes the internal
state more "even", it seems to me, so this may make some sense.

Perhaps the read-before-write property of STA (zp),Y is also a reason
why reads don't change the value.

;6702i ==0401==
  100 x = 6
  110 q=61408 : rem efe0
  120 a = peek(q) : print"seed:";a
  125 a = a or 17 : rem $11
  130 s4 = a
  140 s5 = a
  150 b = 64 : rem 9869 ldb #$40
  200 b = b * 2 : rem 986b lslb
  210 s1 = b
  220 poke q,b : print"stb";b;:  rem 986e stb [6,s]
  230 a = s4: b = s5
  240 d = a * b
  250 a = int(d/256): b = d - a*256
  260 s5 = b
  270 a = a or s5
  280 s4 = a
  290 rem 987a eorb #$d7 b xor= $d7 (215, not 40)
  300 b = (b and 40) or ((not b) and 215)
  310 t = peek(q) : print "asl"t;: rem 987c
  320 poke q, (t * 2) and 255
  330 t = peek(q): print"b^="t;: rem   987f
  340 rem eorb [06,s]
  350 b = (b and (255-t)) or ((not b) and t)
  360 a = s5
  370 poke q,a : print"sta";a; :rem    9884
  380 t = peek(q) : print"asl"t;: rem  9887
  390 poke q, (t * 2) and 255
  400 a = peek(q) : printa : rem       988a
  410 s0 = a
  420 x = x -1
  430 b = s1
  440 y = 0
  450 rem omit small loop
  460 a = 0: s1 = 0
  500 b =int (b / 4)
  510 if b goto 200: rem               986b
  520 print"klaar!

I've made a few actual screen shots with my camera, I'll transcribe them
later. Not every write to EFE0 changes the value, but at least some do.
I had some weird trouble with my ZoomFloppy copying files to the one
working 8050 drive I had on hand. Someting, somewhere, randomly turned
on some bit (the $20 one) in the data coming back from the drive. (The
copy program reported things like "02, ok, 00 00" errors, and the
directory listing looked corrupted)

I tried with 2 different IEEE cables, both had the problem. But the
basic program seemed to be ok when loaded into the PET so the problem
may not have occurred in both directions.

Gotta go now...

> Dave
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- There's no point being grown-up if you 
\X/ rhialto/at/xs4all.nl    -- can't be childish sometimes. -The 4th Doctor

       Message was sent through the cbm-hackers mailing list