Re: 6809 / 6702 puzzle

Funnily enough I was thinking about a hardware implementation of the 6702 only yesterday - and came up with exactly the same concept that 
Mike has. An EPROM to store the data table in and a binary counter. The counter would be reset when the RESET pin of the 6702 is active 
and would read the content of the addressed EPROM cell on a read and then increment the counter. All writes would be ignored. The counter 
will then either need to be reset to 0 after all the data table has been read out (when the counter reaches 29 (decimal)) - or multiple 
tables (or copies of the tables) stored in the EPROM - assuming they will fit to exactly a power of 2 to avoid some silly counter 
resetting nonsense.

I can't see any reason to not patch the Waterloo disks so they bypass the hardware checks automatically. The addresses of the entry point 
to the check routines for all of the languages are known, and the first few instructions can be patched to load up A, B and the condition 
codes correctly and return back to the caller. As Olaf mentioned, the "check check" routine will also have to be changed as the computed 
checksum is now different (because we have modified the instruction stream of the check routine).

The only part of the process I am missing is how the executable binary file is stored on the disk to identify the correct load and bank 
addresses to know exactly where I need to patch. Can anyone help here? If so, I will quite happily have a go. I was going to reverse 
engineer the file format anyhow for my own benefit - but if someone knows where I can find the information already that would save me some 
time.

I left my "6702 cracking" software running last night and it identified a few more byte sequences that appear to work - although I have 
not actually tested them with the emulator and the Waterloo software to double check. I provide them here for anyone who might be 
interested. Only the 'even' bytes of the table are provided. The 'odd' bytes of the table are used by the ASL instruction and (in our 
current implementation of the 6702 for VICE) are replaced by 'dummy' bytes (I have used 0xFF) [see previous code snippet post]. Hit 1 has 
been implemented in VICE.

Hit 1: 04 91 3C AC C7 F0 E3 36 5A BB C3 6A 75 A3 3E
Hit 2: 67 96 9C 53 4B A4 08 F0 E3 5A 0A B7 87 5F 8B
Hit 3: 59 0F 8B 8C 35 17 3D 48 18 A5 A0 F0 C0 8C 0A
Hit 4: D5 A4 23 75 5E 31 8F 5A 02 D5 4F 0E 26 45 93
Hit 5: D6 4C 6D 17 27 2D 5E 56 D0 31 AD 2D 60 06 52
Hit 6: 03 3D 83 2C AF D8 CE 05 E3 53 29 64 EA 6F 5A
Hit 7: 91 58 85 2A A1 51 27 82 2E FC 0F 83 A2 5B 6E

How do you want me to publish my 'C' cracking program? I can either copy it into a post, attach it as a file or send it via a PM to people 
who are interested. The file is some 400 lines long and about 14KB in size. I don't know what the list's etiquette is about posting large 
files. Be aware that execution of the code is very dependent upon the random number generator that your C compiler libraries use. My first 
attempt yielded no solutions at all. I changed the random number generator and got the hits above. Olaf has tried my 'good' code and got 
no hits at all (I assume he was using a different compiler?).

It would be great if a number of people could run the code and publish any other different hits than the ones I got. This may be useful 
for identifying the correct functionality of the 6702 in future. One problem we potentially have with the current lookup table 
implementation is if it gets out of step for some reason it may never recover. I assume that in the 'real' device code, the first LDA 
instruction provides an initial 'seed' as to the numbers that will follow. Our current implementation will not do this - although I should 
be able to try it by writing a program in MicroBASIC to PEEK from the 6702 and disturb it's number sequence. My C code contains a full disassembly of the check routine for the Waterloo editor along with some of my own comments.

Regards,

Dave

> Message Received: Apr 12 2012, 07:06 AM
> From: "Mike Naberezny" <mike@naberezny.com>
> To: cbm-hackers@musoftware.de
> Cc: "Baltissen, GJPAA (Ruud)" <ruud.baltissen@apg.nl>
> Subject: Re: 6809 / 6702 puzzle
> 
> Hi Ruud,
> 
> On 4/11/12 10:34 PM, Baltissen, GJPAA (Ruud) wrote:
> > What about creating a device the mimics the 6702 as good as possible?
> > Preferably one that can be reprogrammed in circuit? IMHO a much better
> > idea then changing programs only to find out that there is still part
> > that needs to be changed :)
> 
> I saw the snippet that Olaf posted with dongle_values.  If it only needs to 
> loop a fixed sequence, how about an EPROM and a counter?  The counter would be 
> connected to the address lines of the EPROM and would increment by one on each 
> 6702 read.  It would also need a little logic to reset the counter at the end 
> of the sequence.
> 
>  > I already agreed to lend my SuperPET to Olaf so he can study the 6702 in
>  > real. And I wouldn't mind if he replaced the real 6702 with such a
>  > device.
> 
> It seems that the 6702 is only for protection and is only used by the Waterloo 
> disks.  It may be easier to remove the protection from the disks than to build 
> a replacement.
> 
> Regards,
> Mike
> 
> -- 
> Mike Naberezny (mike@naberezny.com) http://6502.org
> 
>        Message was sent through the cbm-hackers mailing list
> 

       Message was sent through the cbm-hackers mailing list