I seem to remember some demo, or a game, which displayed 26 rows of text (that's one more than the usual text mode resolution of 40x25). My memory of it is very hazy, but at least is corroborated by this answer on our sister site.

How exactly is that effect achieved? Is it related to the trick that opens up the top/bottom borders? Can both of these tricks be used at once?

  • 1
    At least the VIC-I can add an extra line. I don't know this VIC-II hack.
    – Polluks
    Mar 7, 2019 at 13:57
  • @Polluks On VIC-II, there was a way to remove a line. On this way, combined with an option to move the whole screen with 0-7 pixels, a seamless scrolling was possible.
    – peterh
    Mar 7, 2019 at 16:42
  • As a side note, the "80-column" chip (8563) on the Commodore 128 had a very flexible screen. I doubled its video RAM, then programmed its various registers to achieve something like a 120 col by 50 row screen. I think I read that the 128D came with doubled 8563 RAM, so you should have been able to program a high-res screen right out of the box.
    – RichF
    Mar 8, 2019 at 5:35
  • After thinking about it for a little while some theory has entered my brain, theory about how it could work. I'm not sure yet. I'll try and code it up later on in the week when I have time. Mar 8, 2019 at 10:21
  • @RichF: Unfortunately, I don't think the designers of that chip, nor the Motorila 6485 upon which it is loosely based, understood how interlaced video timing was supposed to work. Both chips support 50-line interlaced modes, but the lines of alternate fields don't fall symmetrically between each other.
    – supercat
    Nov 16, 2020 at 19:25

3 Answers 3


How exactly is that effect achieved? Is it related to the trick that opens up the top/bottom borders? Can both of these tricks be used at once?

Not only can both tricks be used together, they must be used together. TLDR: Open the borders, and scroll the entire image up and down at the right time to increase the vertical resolution.

Three days ago I said:

After thinking about it for a little while some theory has entered my brain, theory about how it could work. I'm not sure yet. I'll try and code it up later on in the week when I have time

As promised:

The trick involves YSCROLL. This gives us a way to scroll the entire image up or down a little. The maximum distance is eight pixels, which is the height of one line of text.

Usually when we meddle with YSCROLL we also use RSEL to reduce the vertical resolution by eight pixels, so that we don't get some glitchy stuff at the border of the screen. But this trick is different because we don't use RSEL to reduce the resolution, but to increase it. And I'll describe how that works here.

  • At the top of the screen, set YSCROLL to 0 and set RSEL to 1
  • At raster line 247 set YSCROLL to 7. This means the VIC-II will blithely proceed to draw the previous 8 lines again. Of course, you could switch to a different bank or whatever to get different graphical data here.
  • At raster line 249 set RSEL to 0. This removes the top and bottom borders. That's important because otherwise the last eight pixels get hidden under the border.

There's one limitation I can think of. It's the Color-RAM, which occupies exactly the same 40 locations for the 25th and 26th row. Maybe you can design around that limitation somehow, or maybe quickly copy some new data in to that location. Or of course use some mode that does not use color ram, such as the hires bitmap mode.

  • well, see my answer ;) ok, I just assumed opening the border doesn't have to be explained :o -- still two things: 1.) avoiding the badline by fiddling with y-scroll can also leave the vic-ii in idle mode, depending on your timing, 2.) the color ram is read in the same fetch as the screen ram, so it will be organized the same way (and displayed "scrolled down") Mar 12, 2019 at 7:22
  • 1
    @FelixPalmen 1.) This trick does not use yscroll to avoid a badline, it uses yscroll to cause a new one right when the display would normally end. That's one way to increase vertical resolution that I found. 2.) that's right. Mar 12, 2019 at 8:34
  • 1.) which is exactly the same -- the badline fetches the new data (from screen AND color RAM), to delay this until you're further down the screen, you avoid the badline condition by fiddling with y-scroll. Mar 12, 2019 at 8:51
  • 1
    @FelixPalmen I suppose so. But who said anything about delaying a badline? Mar 12, 2019 at 8:57
  • 1
    @FelixPalmen I suppose so, but the trick I described is better described as repeating a badline -- really the same badline happens twice. Mar 12, 2019 at 9:41

No, the VIC chip couldn't do that. However, an equivalent effect was possible on at least two ways:

  1. Sprites could be easily put to the top and bottom border (and, on a much harder way, also to the left and right). However, you can have at most 8 sprites in a single pixel row1, which is not enough to cover a whole line (24 pixel * 8 = 192, which is smaller than the 320 px wide screen). More can you read about in this post.

  2. There was a way to scroll down the whole screen with a pixel with some interrupt-based hack. There was a way to put characters (or graphical screen) to the bottom border on this way.2

1It is possible that also this limit can be somehow circumvented, but it is surely not easy.

2I don't know, how did it work, but I can dig a youtube video for ask. Hopefully another answer will give more details.

  • 1
    I would be very much interested in the youtube video.
    – dirkt
    Mar 7, 2019 at 19:44
  • As for your footnote #1: Yes, it can be circumvented. You can get 9 sprites by manipulating the x-coordinate of one sprite when the raster is halfway across the screen. Mar 8, 2019 at 9:22
  • 1
    @wilson AFAIR while 9 sprites in a raster line are technically possible, noone was able to do this in two consecutive rasterlines, so it's still useless for "faking" a text line (and even then, 9 sprites still would only allow for 27 chars, still far from 40) Mar 9, 2019 at 10:06
  • 1
    @FelixPalmen: My recollection is that the VIC-II chip latched the data for all three sprites during the horizontal blank, and then starts shifting it when the sprite is triggered. Once data gets shifted out, it's gone and cannot be redisplayed until the next fetch. It may be possible to show a sprite before and after a fetch on the same line, but that would leave the shifter empty until the next fetch.
    – supercat
    Mar 11, 2019 at 22:46
  • 1
    @supercat this would perfectly explain the only 9-sprite demo I know of ... done by crest, forgot the name: it shows 9 sprites, but every other rasterline is empty. Mar 12, 2019 at 7:15

Mostly conforming peterh's answer here: more text lines aren't possible, but there are tricks to give the illusion.

The first option, using sprites, is quite limited, but ok if all you want is a 24 chars wide line.

The second option seems more plausible as it allows for a full/normal text line in the bottom border. It works by opening the borders and applying FLD (flexible line distance) somewhere. The VIC-II uses "badlines" to fetch data for a new character row, and these badlines are triggered when the lowest 3 bits of the raster line number equal the y-scroll. So you achieve FLD by constantly fiddling with y-scroll, therefore avoiding the badline until you're further down the screen. Of course, this means you're missing a text line somewhere in the middle of the screen instead.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .