Skip to content

DYCP

Different Y Character Position

The C64 demo scroller in which every letter bobs up and down on its own point of a sine wave as the text crosses the screen. It fakes a small bitmap out of redefined characters, because eight sprites are too few and a real bitmap is too slow to clear. Pasi 'Albert' Ojala wrote the method down in 1991, and C= Hacking published it in 1993.

DYCP, short for Different Y Character Position, is the Commodore 64 demo scroller in which every letter rides its own point of a sine wave as the text runs across the screen. Pasi ‘Albert’ Ojala’s definition:

DYCP - Different Y Character Position - is a name for a horizontal scroller, where characters go smoothly up and down during their voyage from right to left.

It looks like an effect the C64 should give away for free. It is not. The VIC-II can move the whole text screen sideways a pixel at a time, but it cannot move one column up while its neighbour goes down. DYCP gets round that by drawing the text into characters it redefines every frame, and the trick was common enough by 1991 for Commodore Format to report that “it’s possible to have 25 on-screen DYCP (different y-axis char position) scrollers each with a different speed and colour”.

Why the obvious ways fail

Ojala starts with the two approaches a programmer would try first. Sprites move freely in both directions, but there are eight of them: “One possibility is a scroll with 8 characters - one character in each sprite, but a real demo coder won’t be satisfied with that.” A bitmap screen can show anything, but drawing into it is slow: “Plotting the characters take absolutely too much time, because you have to handle each byte seperately and the graphics bitmap must be cleared too.”

The character hack

The answer was a small bitmap faked out of the character screen:

The whole DYCP started using character graphics. You plot six character rows where the character (screen) codes increase to the right and down. This area is then used like a small bitmap screen.

Each column of that 40-by-6 block is a strip of six characters, 48 pixel lines tall, and the program draws each letter into its column’s characters at whatever height the sine table gives it. Because the block is still ordinary text, the sideways movement costs almost nothing: the three low bits of $D016 shift all 240 positions a pixel at a time, and after eight pixels the program moves the text along by one character, “like in any scroll”. The screen is set to 38 columns so that the jitter at the edges is hidden under the border.

The cost lies elsewhere. Every frame the old letters must be wiped out of the character set before the new ones go in, and Ojala names that clearing as “the biggest” difficulty.

Two characters per column

His refinement cuts the work down. A letter is eight lines tall, so a 16-line window is enough to hold it at any offset:

We can use two characters for the graphics bitmap and then move this in eight pixel steps up and down. The lowest three bits of the y-position then gives us the offset where the data must be plotted inside this graphical region.

So each column owns two consecutive character codes, 16 bytes of character data. The upper bits of the letter’s height choose which screen row the pair sits on, and the lowest three choose where inside those 16 bytes the letter’s pattern is copied. Ojala’s demonstration program, written for a PAL machine, does exactly this from a raster interrupt. Each frame it clears 640 bytes of character data, writes each column’s two character codes into screen memory with a blank above and below to erase the previous position, and copies seven bytes of each letter from a RAM copy of the character ROM. The sine table is built at start-up from a quarter of a cycle, “by mirroring it both horizontally and vertically”. Both the clearing and the plotting have to happen while the VIC-II is not drawing the scroll, “so there is a slight hurry”. Ojala calls the NTSC version “a bit crippled”: it covers only 32 columns, so the letters “seem to appear from thin air”.

Sprites, borders and finer steps

Sprites come back in when the scroll has to run into the side borders, where characters cannot go. “Eight horizontally expanded sprites will be just enough to fill the side borders”, but “sprite-dycp is even more slower than char-dycp”. The sine is less restricted than it looks: each sprite holds three letters, so the only rule is that “the vertical position difference between three consequent text character must be less than 14 pixel lines”. Ojala adds sprite stretching to keep the border open and sprite multiplexing to get more letters.

The next step was a separate height for every pixel column rather than every character. That means masking bits in with ORA and STA, which “will take much more than eight times the time a simple LDA+STA takes”, and coders who tried it by plotting into several character sets at once got scrolls not “much larger than 96x32 pixels”.

Who wrote it down

Ojala wrote the article on 16 May 1991 and dated its translation 2 June 1992. It appeared in the Demo Corner column of C= Hacking issue 6, on 5 September 1993, alongside his piece on opening the borders. The scroll text in his example program reads “THIS IS AN EXAMPLE SCROLL FOR COMMODORE MAGAZINE BY PASI OJALA”. The article describes a technique the scene already used; it does not claim to have invented it, and the public sources do not record who first showed a DYCP.

Records

DYCP also became something to compete over. Cruzer’s history of speedcode on the Codebase64 wiki says loop unrolling “was probably first done to get the most rastersplits on the same line, and then later utilized to break DYCP records”: the more letters a coder could plot in a frame, the bigger and fuller the scroll.

Sources

  • Pasi ‘Albert’ Ojala, “The Demo Corner: DYCP - Horizontal Scrolling” (written 16 May 1991, translated 2 June 1992), C= Hacking issue 6, 5 September 1993: the definition, the sprite and bitmap problems, the six-row and two-character methods, the demonstration program and its scroll text, the sprite and pixel-column variants. Mirrored on the Codebase64 wiki (web, secondary). https://codebase64.net/doku.php?id=magazines:chacking6
  • Commodore Format issue 9, June 1991, p. 42, “Demo maker discoveries”: 25 DYCP scrollers on one screen.
  • Cruzer/CML, “Speedcode”, Codebase64 wiki (web, secondary): speedcode and DYCP records. https://codebase64.net/doku.php?id=base:speedcode

See also

Checked. Verified against primary sources and signed off by a person.