Re: [stella] Trick to avoid black line on screen after HMOVE ?

Subject: Re: [stella] Trick to avoid black line on screen after HMOVE ?
From: emooney@xxxxxxxxxxxxxxxx (Erik Mooney)
Date: Tue, 18 Mar 1997 19:01:14 GMT
>There is always a short black line at left of screen after HMOVE
>(when not done in Vertical Blank) following a WSYNC.
>
>Some games like HERO, Decathlon and Enduro just 'skipped' the first
>two bits of PF0, so it is not visible any more. But they used the last
>two bits of the screen (on right side), so PF0 must be updated twice every 
>scanline, right ? (Quite a lot of cycles wasted just to avoid this problem).
>
>I want to use this trick, too. The thing is that PC Atari does seem
>to have problems with this type of code so I cannot test my program
>properly. 
>
>Anyone with a solution to this problem ?
>I could skip the last two bits as well, so I do not waste time by updating
>PF0 all the time, but this reduces the size of the display too much.

The game I'm working on uses a non-reflected, non-duplicated playfield, so
I set CTRLPF to zero and update PF0, PF1,and PF2 twice each scanline (once
right after WSYNC and once just before the middle).. here's some code, with
cycle counts and numbers showing at which cycle counts PFx needs to be
updated by.  "buffer" is simply a buffer containing the six values we need
to write to the playfield registers, in order.  (assume Y set to zero for
the moment - the actual code is part of a loop during which Y is changed.)

    lda buffer,Y        ;+4  66
    sta WSYNC           ;begin scanline
    sta PF0             ;+3   3    <= 22
    lda buffer+1,Y      ;+4   7
    sta PF1             ;+3  10    <= 28
    lda buffer+2,Y      ;+4  14
    sta PF2             ;+3  17    <= 38
    nop                 ;
    nop                 ;
    nop                 ;
    nop                 ;
    nop                 ;
    nop                 ;
    nop                 ;
    nop                 ;
    nop                 ;
    nop                 ;
    nop                 ;+22 39 for the block of NOPs
    lda buffer+3,Y      ;+4  43
    sta PF0             ;+3  46    28 <= z <= 49
    lda buffer+4,Y      ;+4  50
    sta PF1             ;+3  53    38 <= z <= 54
    lda buffer+5,Y      ;+4  57
    sta PF2             ;+3  60    49 <= z <= 65
    inx                 ;+2  62

As you can see, you've got enough cycles at the end (after inx) to do a
CMP/BNE if you want, and you've got 22 cycles in the middle to do whatever
you need (actually 23, because the second STA PF1 could occur one cycle
later without a problem.)  If you can avoid using indexed addressing,
that's another six cycles.  PC Atari runs this code perfectly, so testing
it isn't a problem.

Updating playfield registers twice per line isn't extremely hard.. Pac-man,
Centipede, Millipede, and many others use it.  The key is to set up so that
you don't need to do much else during the scanline.  Also, try to have
scanlines during which you don't need to rewrite the playfield - Centipede,
Millipede, and my as yet unnamed program rewrite the playfield twice per
line for four lines, then turn the playfield completely off for four lines,
during which you can position objects and so on.  Pac-man only needs to
rewrite the playfield twice in a line every eighth scanline - the rest of
the time, it's a standard reflected playfield.  (also, I believe Pac-man
does its object positioning during vertical blank.)

--
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