# -------------------------------------------------------------------
# 68K                                   (c) Copyright 1996 Nat! & KKP
# -------------------------------------------------------------------
# These are some of the results/guesses that Klaus and Nat! found
# out about the Jaguar with a few helpful hints by other people, 
# who'd prefer to remain anonymous. 
#
# Since we are not under NDA or anything from Atari we feel free to 
# give this to you for educational purposes only.
#
# Please note, that this is not official documentation from Atari
# or derived work thereof (both of us have never seen the Atari docs)
# and Atari isn't connected with this in any way.
#
# Please use this informationphile as a starting point for your own
# exploration and not as a reference. If you find anything inaccurate,
# missing, needing more explanation etc. by all means please write
# to us:
#    nat@zumdick.ruhr.de
# or
#    kp@eegholm.dk
#
# If you could do us a small favor, don't use this information for
# those lame flamewars on r.g.v.a or the mailing list.
#
# HTML soon ?
# -------------------------------------------------------------------
# $Id: 68k.html,v 1.16 1997/11/16 18:14:39 nat Exp $
# -------------------------------------------------------------------

Preface:

There isn't much we need to tell you about the 68K. First you already know the chip since ten years probably, and secondly there are enough reference books available in case your memory is failing you.

For your convenience here is a list of useful links, where you can get all the low down dirt. I highly recommend the DTACK GROUNDED Archive which is a tribute site to one really great - though historic now - non-mainstream 68000 magazine.

Some Amiga hackers also put up a lot of useful info, which might be all you need, and is named MC680x0 Reference 1.1, by Flint/DARKNESS

Motorola, classy as always, also provides you with the complete documentation in Adobe Acrobat PDF format at their site under Motorola Microprocessors.

Let's just look at the way the processor is bound into the system and some things to watch out.

1. IRQs

2. Superstitions / Things to watch out for

3. Addendum
   1. Timing
   2. The Code

IRQs:
=-=-=

      IPL         Name           Vector            Control
   ---------+---------------+---------------+---------------
       2      VBLANK IRQ         $100         INT1 bit #0 
       2      GPU IRQ            $100         INT1 bit #1
       2      HBLANK IRQ         $100         INT1 bit #2
       2      Timer IRQ          $100         INT1 bit #3

   Note: Both timer interrupts (JPIT && PIT) are on the same INT1 bit.
         and are therefore indistinguishable.

   A typical way to install a LEVEL2 handler for the 68000 would be 
   something like this, you gotta supply "last_line" and "handler".
   Note that the interrupt is auto vectored thru $100 (not $68)


   V_AUTO   = $100
   VI       = $F004E
   INT1     = $F00E0
   INT2     = $F00E2
   
   IRQS_HANDLED=$909                ;; VBLANK and TIMER

         move.w   #$2700,sr         ;; no IRQs please
         move.l   #handler,V_AUTO   ;; install our routine

         move.w   #last_line,VI     ;; scanline where IRQ should occur
                                    ;; should be 'odd' BTW
         move.w   #IRQS_HANDLE&$FF,INT1  ;; enable VBLANK + TIMER
         move.w   #$2100,sr         ;; enable IRQs on the 68K
         ...

handler:
         move.w   d0,-(a7)
         move.w   INT1,d0
         btst.b   #0,d0
         bne.b    .no_blank

         ...

.no_blank:
         btst.b   #3,d0
         beq.b    .no_timer
      
         ...

.no_timer:
         move.w   #IRQS_HANDLED,INT1      ; clear latch, keep IRQ alive
         move.w   #0,INT2                 ; let GPU run again
         move.w   (a7)+,d0
         rte

   As you can see, if you have multiple INT1 interrupts coming in,
   you need to check the lower byte of INT1, to see which interrupt
   happened.


Superstitions / Things to watch out for:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

   It looks like word/byte accesses to ROM space don't work. Looking
   at some code in the Jaguar Server indicates that the MEMCON registers
   come into play here.

   I have a hunch that RWM cycles (like CLR.W (a0)) on TOM registers
   aren't 100% safe.

   NEUROMANCER adds: 
      NEVER do a clr.l (a0) into GPU/DSP memory you must do a 
      move.l #0,(a0) or a move.l d0,(a0).
   
   The special thing about a CLR (on the 68000, fixed in the 68010
   and onwards I believe) is, that the processor does a source read 
   before doing a destination write. It could be that this buggy read
   is done in a slightly incompatible fashion to the other RMW
   instructions like TAS <memory>, BCLR <??>,<memory>> ASL <memory>
   et.c.

   Otherwise you must refrain from using any RMW instruction on
   GPU/DSP memory.

   If the 68K does not soak up leftover cycles, but does use up valuable
   bus resources its best to put it to sleep with

         HALT  #2000

   so it will sleep until the next IRQ wakes it up again.

$Id: 68k.html,v 1.16 1997/11/16 18:14:39 nat Exp $