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" <email@example.com> > To: firstname.lastname@example.org > Cc: > Subject: Re: 6809 / 6702 puzzle > > On Sat 21 Apr 2012 at 14:55:00 +0200, email@example.com 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 listReceived on 2012-04-22 16:00:25
Archive generated by hypermail 2.2.0.