Re: 6809 / 6702 puzzle

Hi guys - I have only just found this mail list.

I have also been working on an implementation of the SuperPET for VICE - and got as far as Rhialto had until yesterday. Finding this site 
(and the post) has spurred me on to crack the 6702...

I offer what I deduced yesterday:

I believe there is an instruction missing from the disassembly of the first post (right at the beginning). I think the first few 
instructions should be:

9860:
LDA [<$06,S] ; Read from 6702.
ORA #$11
STA $04,S ; This instruction appears to be missing from the disassembly.
STA $05,S
LDB #$40

I assume the disassembly has come from the EDITor - as I get the same addresses and instruction stream as Rhialto does.

The entry point to this subroutine actually starts at address $9852 with a TFR S,X (transfer S to X) instruction.

If you follow the disassembly through it finishes at:

9087: BEQ >$908C ; Equal = Zero = All good!
9089: JSR >$B003  ; According to the Waterloo ROM disassembly; this entry point is called "suicide" (hmmm).

I patched the ROM so that it performed a RTS (return from subroutine) instead of the intended suicide action - and this appeared to get 
the editor to work.

I then tried all of the other languages - but to no avail - they all seemed to do something different and bypassed the suicide routine (or 
if they called it - returning from suicide had some unintended results).

However - I did find out that all of the Waterloo software has identical 6702 code - but at different addresses for the different 
languages. A good use of "re-usable code"!

I also noted that the 6702 code was entered via a JSR within the ROM bankswitch code - so I hacked the 6809 emulator's JSR code to trap 
this address (when combined with the bank switch value) to NOT invoke the subroutine call. I also worked out what I think the register and 
flag values should be after a successful 6702 call and set the CPU state accordingly. I provide my code for your information below:

// 6809 emulator provided by Jerome Thoen Copyright (C) 1998
// Modified by Dave Roberts

void jsr()
{
  tt_u16 nrpc = GET_EAW;

#if 1

  // ******************************
  // ***                        ***
  // ***  DER FOR 6702 dongle.  ***
  // ***                        ***
  // ******************************

  extern unsigned char BANK_LATCH;

  if( // ((nrpc == 0x9852) && (BANK_LATCH == 0x01))   // EDIT    - WORKS WITH THE PATCH
      // ((nrpc == 0x9000) && (BANK_LATCH == 0x05))   // PASCAL  - FAILS AFTER RUN (BUT EDITOR WORKS) (6809 EMULATOR PROBLEM?)
         ((nrpc == 0x93F0) && (BANK_LATCH == 0x05))   // BASIC   - WORKS WITH THE PATCH
      // ((nrpc == 0x960C) && (BANK_LATCH == 0x00))   // FORTRAN - FAILS AFTER RUN (BUT EDITOR WORKS) (6809 EMULATOR PROBLEM?)
      // ((nrpc == 0x9F12) && (BANK_LATCH == 0x06))   // APL     - NOT QUITE RIGHT YET? (I DON'T KNOW APL)
      // ((nrpc == 0x9240) && (BANK_LATCH == 0x00))   // COBOL   - SORT OF WORKS? (I DON'T KNOW COBOL)
      // ((nrpc == 0x9A05) && (BANK_LATCH == 0x05))|| // DEVELOPMENT (ASSEMBLER) - WORKS WITH THE PATCH
      // ((nrpc == 0x94B6) && (BANK_LATCH == 0x08))|| // DEVELOPMENT (LINKER)    - WORKS WITH THE PATCH
      // ((nrpc == 0x9852) && (BANK_LATCH == 0x02))   // DEVELOPMENT (EDITOR)    - WORKS WITH THE PATCH
                       ) {
    ra  = 0x00; // register A
    rb  = 0x00; // Register B
    ccz = 1; // Z (Zero/Equal) flag
    ccc = 0; // C (Carry) flag
    ccv = 0; // V (overflow) flag

    // Ignore the JSR!
    return;

  } // End if
#endif

  rs -= 2;
  set_memw(rs, rpc);
  rpc = nrpc;
}

This now seems to work!!! I have tried all of the Waterloo languages and things "seem" to work - with a few exceptions that I am currently 
putting down to 6809 emulator issues. I have found no further attempts to communicate with the 6702 chip. I have used the following 
Waterloo software:

EDIT V1.1 1982
PASCAL V1.1 1982
BASIC V1.1 1981
FORTRAN V1.1 1981
APL V1.1 1982
COBOL V1.0 1981
DEVELOPMENT ASSEMBLER V1.1 1981
DEVELOPMENT LINKER V1.0 1981
DEVELOPMENT EDITOR V1.1 1982

I will now concentrate on the actual routine itself and try and work out what it actually does.

William - the 6702 is unlikely reveal its secrets by using an EPROM programmer to read it. I believe it contains internal latches (state) 
and would need both reading and writing to identify the internal content. The readback values may also depend upon the value that was 
previously written. I do believe (however) that the 6702 is a relatively simple device so it should be doable...

It would significantly help if someone with a 'real' superPET could identify what the values returned from the 6702 were in the first 
instance.

I will work on a commented disassembly next and post that later on during the holidays if that would be of interest?

Regards - and great to find this site :-)

Dave

       Message was sent through the cbm-hackers mailing list