Re: [stella] Supercharger internals...

Subject: Re: [stella] Supercharger internals...
From: bwmott@xxxxxxxxxxxx
Date: Thu, 15 May 1997 11:18:06 -0400 (EDT)
> 1. The supercharger cannot actually count processor cycles since the are no signals going to the cart connector that would allow this (like PH2 clock). I could concievably have a free running timer built in that runs the same speed as the processor clock.

Humm, hadn't thought about a free running timer... 

> 2. I know the RAM write works when the code is running from the cart ROM, but I am not sure if it works running from the VCS RAM. This would be an interesting thing for someone to try. If it did not work from RAM then it is possible that the SC is counting cart memory accesses.

If anyone out there has the time and resoures please check this out.  It
would be very helpful.

> Even with all this information I still do not see how the Supercharger differentiats between opcode accesses and data accesses. If anyone has can put this info together into a logical explenation of how the Supercharger works I would love to hear it. 

I don't think it knows the difference between an opcode an an operand.  I
think it's based entirely on a time delay after a write to f000 to f0ff.

Here's some additional things I've figured out:

Assume X = $ff

  $f800  cmp $f000,x

    cycle   cpu action
      1     read opcode
      2     read low byte
      3     read high byte and X to low byte
      4     read from resulting address, fix high byte if needed (no fix needed)

  So in this example a read to $f0ff occurs at cycle 4 and the value to
  be poked is $ff

  $f800  cmp $f0ff,x

    cycle   cpu action
      1     read opcode
      2     read low byte
      3     read high byte and X to low byte
      4     read from resulting address, fix high byte if needed (needed)
      5     read from resulting address

  The thing to notice here is that a read to location $f0fe occurs on 
  cycle 4 before the read to $f1fe at cycle 5.  This "false" read doesn't
  affect most software but when your hardware has side effects it does :-)
  So the value to be poked is $fe.

This same sort of thing happens for both $nnnn,Y and ($nn),Y.

Some more observations:
 
  ldx #$ff    
  cmp $f000,x   4 cycles
  nop           2 cycles
  lda $f800     4 cycles (poke occurs on read to $f800 6 cycles after cmp)

  80 = 00, 81 = f0 
  ldy #$ff
  ldx #$00
  cmp $f000,y   4 cycles
  lda ($80,x)   6 cycles (poke occurs on read to $f800 6 cycles after cmp)

So it seems in these two cases a delay of 6 is a good choice :-)

Brad

--------------------------------------------------------------------------
Bradford Mott (bwmott@xxxxxxxxxxxx)        Computer Science Department
http://www4.ncsu.edu/~bwmott/www           North Carolina State University
--------------------------------------------------------------------------

--
Archives available at http://www.biglist.com/lists/stella/archives/
E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.

Current Thread