7

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?

Omar and Lorraine
  • 38,883
  • 14
  • 134
  • 274
  • 1
    At least the VIC-I can add an extra line. I don't know this VIC-II hack. – Polluks Mar 07 '19 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 07 '19 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 08 '19 at 05: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. – Omar and Lorraine Mar 08 '19 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 '20 at 19:25
  • @supercat interesting.It has been decades since I saw it, but I do not remember anything appearing badly. The text was smaller than I like, but that was to be expected. – RichF Nov 17 '20 at 06:14
  • @RichF: If memory serves, both chips displayed interlaced text by making fields alternate between (e.g.) 262 and 262.5 lines, rather than having every field be 262.5 lines but skewing the timing of vertical sync relative to the horizontal sync. – supercat Nov 17 '20 at 06:24

3 Answers3

9

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.

Omar and Lorraine
  • 38,883
  • 14
  • 134
  • 274
  • 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") – Felix Palmen Mar 12 '19 at 07: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. – Omar and Lorraine Mar 12 '19 at 08: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. – Felix Palmen Mar 12 '19 at 08:51
  • 1
    @FelixPalmen I suppose so. But who said anything about delaying a badline? – Omar and Lorraine Mar 12 '19 at 08:57
  • Huh? Me, just because technically, scrolling down the screen is delaying badlines ;) – Felix Palmen Mar 12 '19 at 09:02
  • 1
    @FelixPalmen I suppose so, but the trick I described is better described as repeating a badline -- really the same badline happens twice. – Omar and Lorraine Mar 12 '19 at 09:41
  • That's impossible. Each badline fetches the next row from screen/color ram. – Felix Palmen Mar 12 '19 at 10:01
  • Let us continue this discussion in chat. – Omar and Lorraine Mar 12 '19 at 10:06
  • @FelixPalmen Triggering a badline is not necessarily about delaying - you can also make a badline occur earlier than it normally would (part of how FLI works is making every line a badline). Also, a badline does not necessarily fetch the "next" row from screen/color ram. VCBASE is only increased when the VIC goes into idle-mode (see the VIC Article 3.7.2). So if you trigger a new badline before the VIC has gone into idle-mode, it will do its usual 40 char-fetches, but it will read the same data again (unless the screen has been changed by $D018 or the bank has been changed by $DD00). – DisplayName Mar 30 '19 at 03:21
  • @Bjarke so if the bank changes, the VIC will re-read the 40 chars again? Why? That's outside of the control of VIC-II, since $dd00 is mapped to CIA2 – Omar and Lorraine Mar 30 '19 at 03:30
  • No, that's not what i meant :) It all about idle-mode, not about the bank. What i meant was: If you trigger a badline "too soon" (before the VIC has gone into idle-mode after the previous badline), it will still be at the same row as it was at the previous badline (it will not have advanced to the next row). This will normally make it read the same data again at the new badline you triggered. ...Unless you changed $D018 or $DD00 in between, because even though it hasn't advanced to the next row, there is now different data at the same row. ($DD00 selects the VIC-bank) – DisplayName Mar 30 '19 at 03:40
  • @Bjarke "too soon" might mean something like "part way through a raster line"? Or how can I measure if the "too soon" condition holds? – Omar and Lorraine Mar 30 '19 at 04:00
  • Basically, if you trigger a new badline earlier than 8 rasterlines after the previous badline, it will be "too soon". So it's too soon if you make it occur earlier than it normally would. (I don't think there is any way around this - the VIC-chip goes into idle-mode (and advances to the next row) at cycle 58 when RC=7. Badlines set RC=0 and there is no way to force RC to count up faster than it does). And the next rasterline must again be 8 rasterlines away, etc. (Unless you do FLI-badlines by triggering them at cycle 14 - that's kind of an exception, as a FLI-badline does not reset RC=0). – DisplayName Mar 30 '19 at 04:10
  • (RC can be thought of as "the pixel-line we are at within the current text-row", if you're not familiar with the VIC-Article terminology. You should check out the document if you're not familiar with it. So RC=0 is the first pixel-line of a text-line, RC=1 is the second pixel-line, etc. It is not until at the end of the last pixel-line of a text-line (i.e. where RC=7), that the VIC-chip advances to the next row (and also goes into idle-mode at the same time). (it advances to the next row by incrementing "VCBASE" by (usually) 40)) – DisplayName Mar 30 '19 at 04:20
  • Just read my comments again. Just for completeness: There is of course one more way to make a badline which has been triggered "too soon" (=VIC haven't advanced to the next row) display different characters than the previous badline, apart from modifying $D018 or $DD00: Change the characters on the screen itself in between the two badlines. :) – DisplayName Oct 26 '19 at 16:36
  • Another correction: I wrote that "advancing to the next row" is all about idle mode. That is not completely true - it just happens at the same time as going to idle mode (at cycle 58 when RC=7).

    However! You can prevent going to idle mode by making sure there is a badline condition at that cycle - but the VIC will still advance to the next text-row (by setting VCBASE = VC) at that cycle if you do so.

    So one can happen without the other. (Unless it actually does go to idle-mode but just immediately returns to display-mode?)

    (See sections 3.7.1, 3.7.2 and 3.14.5 of the VIC-article)

     – DisplayName Nov 03 '19 at 00:17
7

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.

peterh
  • 1,749
  • 1
  • 14
  • 26
  • 1
    I would be very much interested in the youtube video. – dirkt Mar 07 '19 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. – Omar and Lorraine Mar 08 '19 at 09:22
  • As for your footnote #2. are you able to get that video somehow? – Omar and Lorraine Mar 08 '19 at 09: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) – Felix Palmen Mar 09 '19 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 '19 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. – Felix Palmen Mar 12 '19 at 07:15
5

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.

Felix Palmen
  • 1,502
  • 1
  • 10
  • 12