>Basically the purpose of that bit of experimental code was because I wanted
>to how many horizontal positions I could get for a sprite by just using the
>RESP command on it's own without an HMOVE to fine tune it. It would appear
>that RESP will give you 10 different horizontal positions on it's own
>(that is provided you don't overshoot a single scanline with your delay
>routine).
HMOVE is your friend. HMOVE is useful. HMOVE gives you single-pixel
positioning. HMOVE is in the hardware for a reason. Learn it, know it,
use it. :)
>Kind of sucks really, I was hoping to get enough to be able to fudge
>an okay horizontal motion at slower speed without having to use an HMOVE
>table.
Everyone else uses it :)
>>> ldx #$ab
>>>blow sta WSYNC
>>> dex
>>> bpl blow
>>> rts
>>
>>When X is decreased to $7f the branch isn't taken anymore and
>>therefore you are doing a lot less lines than you wanted to.
>>Your TV isn't ready to sync again after such a small number
>>of lines and just goes on displaying. The black stipes in your
>>display is the VBLANK routine.
>~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
>
>How the heckety heck did you figure out that the branch wasn't being
>taken after $7F?
>
>Changing the BPL to BNE fixed the problem, although I don't know why the
>problem existed in the first place. I can't see what would make the
>BLOW routine stop at $7F with a BPL in there, unless there is something
>about the nature of BPL that I just don't understand. Doesn't it just
>branch if the result is a positive number? BEQ branches if the result is
>zero, BMI branches if the result is a negative number, and BNE branches if
>the result is anything other than zero.
The BPL up top would never have been taken in the first place. X contains
$AB. We decrement it; X is now $AA. $AA in binary is %10101010. The top
bit is set, therefore the number is negative and the BPL ("branch if plus",
though I always read it as "branch if plositive"...) never happens in the
first place. Whoever said the >> paragraph above wasn't quote right, but
changing it to BNE would work.
>Although I don't see how code in the VSYNC could affect your Supercharger.
>Is it your Supercharger that goes wonky or is it that your TV set won't
>sync to it?
His TV won't sync to it. Why has been a subject of much discussion here.
:)
>Here's the new VSYNC segment of the vertical blank...
>
>vertb LDA #$02
> STA VSYNC
> STA WSYNC
> STA WSYNC
> STA WSYNC
> LDA #$00
> STA VSYNC
> LDA #$2C
> STA TIM64T
> RTS
Actually, that changed the timing of the vertical blank ever so subtly.
When the $2C is stored to TIM64T during the last line of vertical blank (as
in your first posting), it starts counting down immediately. This version
doesn't start the countdown until the next line plus a few cycles, or about
80 cycles later than the previous version... that difference might mean
something.
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
Don't post pirate BINs to Stellalist. Be a programmer, not a pirate.
Write the best game, win framed autographs of famous Atari alumni!!
