Well, this tutorial is on Chain-4. When asked to do a trainer on Chain-4, I felt that I would be walking on much travelled ground (I have seen numerous trainers on the subject), but the people who asked me said that they hadn’t seen any, so could I do one anyway? Who am I to say no?

DENTHOR, coder for ...
_____   _____   ____   __   __  ___  ___ ___  ___  __   _____
/  _  \ /  ___> |  _ \ |  |_|  | \  \/  / \  \/  / |  | /  _  \
|  _  | \___  \ |  __/ |   _   |  \    /   >    <  |  | |  _  |
\_/ \_/ <_____/ |__|   |__| |__|   |__|   /__/\__\ |__| \_/ \_/
The great South African Demo Team! Contact us for info/code exchange!  

Grant Smith, alias Denthor of Asphyxia, wrote up several articles on the creation of demo effects in the 90s. I reproduce them here, as they offer so much insight into the demo scene of the time.

These articles apply some formatting to Denthor's original ASCII files, plus a few typo fixes.

What is Chain-4?

You people out there all have at least 256k VGA cards. Most of you have 512k VGA cards, and some have 1MB VGA cards. But what you see on your screen, as discussed in previous trainers, is 64k of data! What happened to the other 192k? Chain-4 is a method of using all 256k at one time.

The way this is done is simple. 1 screen = 64k. 64k * 4 = 256k. Therefore, chain-4 allows you to write to four screens, while displaying one of them. You can then move around these four screens to see the data on them. Think of the Chain-4 screen as a big canvas. The viewport, the bit you see out of, is a smaller rectangle which can be anywhere over the bigger canvas.

     +----------------------------+ Chain-4 screen
     |          +--+              |
     |          |  | <- Viewport  |
     |          +--+              |
     |                            |

The size of the chain-4 screen

The Chain-4 screen, can be any size that adds up to 4 screens.

For example, it can be 4 screens across and one screen down, or one screen across and 4 screens down, or two screens across and two screens down, and any size in between.

In the sample program, the size is a constant. The size * 8 is how many pixels across there are on the chain-4 screen, i.e.

   Size = 40   = 320 pixels across = 1 screen across, 4 screens down
   Size = 80   = 640 pixels across = 2 screens across, 2 screens down

We need to know the size of the screen for almost all dealings with the Chain-4 screen, for obvious reasons.

Layout of the chain-4 screen, and accessing it

If you will remember all the way back to part 1 of this series, I explained that the memory layout of the MCGA screen is linear. That is, the top-left hand pixel was pixel zero, the one to the right of it was number one, the next one was number two etc. With Chain-4, things are very different.

Chain-4 gets the 4 screens and chains them together (hence the name :)). Each screen has a different plane value, and must be accessed differently. The reason for this is that a segment of memory is only 64k in size, so that we could not fit the entire Chain-4 screen into one segment.

All Chain-4 screens are accessed from $a000, just like in MCGA mode. What we do is, before we write to the screen, find out what plane we are writing to, set that plane, then plot the pixel. Here is how we find out how far in to plot the pixel and what plane it is on:

Instead of the linear model of MCGA mode, i.e.:


Each plane of the Chain-4 screen accesses the memory in this way:

Plane 0:


Plane 1:


Plane 2:


Plane 3:


In this way, by choosing the right plane to write to, we can access all of the 256k of memory available to us. The plane that we write to can easily be found by the simple calculation of x mod 4, and the x coordinate is also found by x div 4. We work out our y by multiplying it by the size of our chain-4 screen.

NOTE: It is possible to write to all four planes at once by setting the correct port values.

Uses of Chain-4

The uses of Chain-4 are many. One could write data to one screen, then flip to it (the move_to command is almost instantaneous). This means that 64k of memory does not need to be set aside for a virtual screen, you are using the VGA card’s memory instead!

Scrolling is much easier to code for in Chain-4 mode.

It is possible to “tweak” the mode into other resolutions. In our demo, our vectors were in 320x240 mode, and our dot vectors were in 320x400 mode.

The main disadvantage of chain-4 as I see it is the plane swapping, which can be slow. With a bit of clever coding however, these can be kept down to a minimum.

The sample programs

The first sample program is GFX.PAS. This is a until in which I have placed most of our routines from previous tuts. All the procedures and variables you can see under the INTERFACE section can be used in any program with GFX in the USES clause. In other words, I could do this:


  cls (vaddr,0);

This program would compile perfectly. What I suggest you do is this: Rename the file to a name that suites you (e.g. your group name), change the first line of the unit to that name, then add all useful procedures etc. to the unit. Make it grow :-).

The second file is the sample program (note the USES GFX,crt; up near the top!). The program is easy to understand and is documented. The bit that I want to draw your attention to is the constant, BIT. Because I am distributing this file to many places in text form, not binary form, I could not just add a .CEL file with the program. So what I did was write some text in one color then saved it as a .CEL . I then wrote a ten line program that did the following: moving from left to right, it counted how many pixels were of color zero, then saved the byte value to an array. When it came across color one, is counted for how long that went on then saved the byte value and saved it to an array and so on. When it was finished, I converted the array into a text file in the CONST format. Not too cunning, but I thought I had better explain it ;-)

In closing

There are other documents and sample programs available on Chain-4 and it’s like: Try XLIB for one…