Re: 6809 / 6702 puzzle

Olaf,

It's good to see that you are getting some valuable data from a 'real live' 6702!

I can't see why the BASIC POKE command (using an STA instruction) should invoke a memory read from the 6702 though? One of the functions 
of PEEK and POKE is to interface BASIC programs with 'strange' device hardware (like robots which I used the PET for in my final year 
project at University). A read on a control and status register of a piece of hardware instead of (or as well as) an expected write could 
have caused havoc!

Just one minor observation on your BASIC program. I would suggest the use of integer variables (e.g. a% = peek(q%) etc.) rather than the 
default floating point variables. You should be OK however using pure integers in a floating point environment - it would rule out one 
potential source of error.

I will be really interested in your results...

Dave

> Message Received: Apr 21 2012, 03:34 PM
> From: "Rhialto" <rhialto@falu.nl>
> To: cbm-hackers@musoftware.de
> Cc: 
> Subject: 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
> 

       Message was sent through the cbm-hackers mailing list