Hello, Guest the thread was called609 times and contains 13 replays

last post from Hoogo at the

opening sideborders

  • Well time has come. Sideborders mystery. Spend two days reading all about VIC II and opening sideborders. Trickery with 38/40 columns and exact on time. First we need stable raster routine. Can we use something like to get stable raster first:

    NOP ;2
    BIT $00 ;2+3
    LDA #0 ;2
    STA $D020 ;3
    LDA #1 ;2
    STA $D020 ;3
    LDA #7 ;2
    STA $D020 ;3
    NOP ;2
    LDA #0 ;2
    STA $D020 ;3

    And for opening borders:
    DEC $D016 ;6
    INC $D016 ;6

    This is for opening one rasterline. Set under IRQ.asm where I use IRQ in chains at raster position $32.

  • Hi simun9

    You may need to rephrase this:

    Is it a specific question you are asking (if so, please be more specific) or are you just posting here an experience of your borderless journey? :D

  • There is nothing that makes this code running on stable position -> will MAYBE open the border, MAYBE not.

    Sounds like he has coded a randomizer... :D :thumbsup:

  • I am in learning phase and now my idea is to open sideborders where I will show logo mc bitmap for swinging (first line is set at $32).

    As I read so far we have this:

    1. Need stable raster and then we can open sideborders but at time exact position for each raster line. Must know at what cycles for each rasterline.

    We have 63 cycles (or 23 cycles in case of badlines) for every rasterline. When IRQ is set VICII fetch from 16 1/2 cycles from the start of rasterline.

    So we can do it in the loop for first seven lines and then every eight line outside loop. But because of showing bitmap its better using sprites for sync.

    And we need two sprites let and two sprites right to achieve this. And maximum sprites are also 4 for badline case.

    2. Default value of $D016 is C8 if we subtract 1 from that, it turns to #$C7 so effectively bit #3 turns to 0 => screen goes to 38 column mode

    and next INC changes it back to 40 column mode because bit #3 changes back to 1.

    That's what "opens" side borders. It has to happen just before VIC II start to draw right sideborder. We change screen to 38 columns, and

    VIC II "thinks" it's already drawing border and don't change state for that internally or something like that. So border stays open.

    Next that INC changes screen back to 40 columns, so same trick can be done again next line when border should be starting again.

    3. And for logo swinging code needs some more complexity than inc/dec something like:

    LDA ScrollRegX


    EOR #$08


    and in the code

    ...other code for timings...


    STX $D016

    STA $D016


    ...other code for timings...

    ScrollRegX is variable with !byte 7 which we must put in $D016 at certain point.

    Let summarize:

    How do we get sync with sprites for every rasterline we wanna open ? And what about badline ?

    I need to activate sprites without showing so I have to point the sprite pointer to blank area. We cant show bitmap in sideborders we need it to make from sprites.

  • So did you already decide what method for stabilized rasters you're going to use?

    At the beginning I used a simple method similar to double-IRQ. That worked, and I did not bother to waste a lot of rastertime.

    Only later I used a CIA timer to count 63 cycles to stabilize more quickly.

    => It's probably easiest to stabilize in the upper border, far away from the text area, and have no sprites there that could disturb the timing.

    Next you need the last 4 sprites (4-7), it won't work with the others.

    Place them all on the topmost rasterline where they should appear, but it's more easy if that is never a badline.

    => So again, starting in the upper border and placing the sprites already before the text area can make things more easy, especially if you want some scrolling.

    The timing is the same, no matter if you store to $d020, $d021 or $d016.

    1 char before the right 40 column border is the right place.

    I avoided to use inc $d016/dec $d016 due to scrolling.

    I preferred sta $cfff,y, stx $d016 instead.

    Or was it sta $d000,y?? Can't remember, but you will find out once you hit the first badline.

    So finally my simple code looked somewhat like this:

    sta $d021

    stx $d021

    jsr normalline

    jsr normalline

    jsr normalline

    jsr badline

    jsr normalline

    jsr normalline

    jsr multiplex


    That's not elegant, but easy to adjust.

  • The VIC can only display sprites in the side border area, not any kind of character or bitmap graphics. So you need to stick to sprites. Watch your raster time, as every displayed sprite steals some cycles from a line.

  • Now if I wanna move logo (multicolor bitmap) in sb whats the best way for that?

    You've already seen that badlines are a problem and the reason why you only used 4 sprites with open borders.

    There's a trick to disable badlines, but still have bitmap mode.

    But I'm not sure if it can be combined with open borders, and you have come so far with 4 sprites + badlines, better keep going that way.

    Yours screenshot show only colorful blocks for the sprites.

    I assume that you did not change the sprite pointers (usually 2040-2047) yet?

    That would be the next step to do.

    I think with only 4 sprites you can directly change the sprite pointers with lda/sta 2044/5/6/7 in one raster line.

    => You will spend the last raster line of a sprite for changing the sprite pointers, so the next line with the multiplexed sprite will start with a fresh graphic.

    Of the other 20 lines, you will spent 1 with multiplexing, and the rest is opening the sideborder as usual.

    That will not work if you have to change the pointers in a badline, there's just no time left!

    => Avoid Y positions where the sprites end on a badline! Or better: The last rasterline of your last sprite row can and should end on a badline. Then count 8 sprites up: You can have 8*21=168 lines of graphics without caring about that topic.

    => So your first row of sprites should not start on a badline, but 1 pixel below.
    => Double check that number 3 times, I might be wrong, and changing positions later might hurt.

    => And also test if it is really possible to change the sprite blocks in the last line of the sprites.


    If 168 pixels are enough, then you can use any tool to convert graphics into sprites.

    It would be easiest if your logo is restricted to 4 colors, multicolor.

    More colors are not a technical problem, but tools for 4 colors are more handy.

    For your code:

    Start with some simple test patterns, like 10*$00ff00, 11*$ff00ff, next sprites 10*0f0f0f, 11*f0f0f0, then repeat.
    This way you can easily tell if you switched the sprite patterns in the right moment or too early or too late.

    You can later replace that with the real graphics.

    If you want to add real movement, then it's obviously easiest if you only move left/right with charset.


    If 168 pixels are not enough:

    Then you have to change the sprite pointers in a wrong raster line.

    It will work fine, but the sprite format is somewhat distorted in memory.

    There's a thread about that somewhere here.

    I remember that I used this distorted sprites even with such few rasterlines, but I don't remember why...

    Maybe the 168 pixels are a lesson that I learned by doing it wrong.