Area 5150, a reflection

As I said in my previous coverage of Area 5150, I was not sure whether I should comment on the demo. But I have given it some thought, and have decided to give some background info on the development process.

There was a 7-year period between 8088 MPH and Area 5150. After 8088 MPH, the original team kept in contact. We evaluated 8088 MPH, and tried to assess its strong and weak points, both from our own perspectives, and also taking into account what other people said about it. We used this as input for our next demo.

For the first 5 years of that total 7-year period, I remained part of the team (I left around August 2020). This even included an attempt to release the demo at Revision 2020, which ultimately failed, partly because the demo wasn’t quite finished, and partly because we did not want to release the demo at an online-only party, so we aborted that attempt.

Most of the demo that you now know as Area 5150 was already done at that point, however. The main missing piece was the music. Most of the basic effects and artwork were already done, and in fact, some of them ended up in Area 5150 with little or no changes. Others were slightly modified to match the final theme and music of the demo.

Criticism of 8088 MPH

Perhaps the biggest ‘weakness’ of 8088 MPH, I thought, was that it has a very ‘oldskool’ feel to it: it was an oldskool ‘effect show’. You see an effect for a certain period of time, then some in-between text from the loader, and then the next effect is shown. There is music playing in the background, but there is little or no relation to what is happening on the screen.

Related to that was also that some effects were shown for quite a while, which broke the overall ‘flow’ of the demo. And while there were some minor transitions into or out of certain effects, they were developed independently, and had no connection to any kind of overarching ‘theme’ or anything.

I mean, sure, you could argue that it fit the aesthetic that we were going for anyway. Which is true. But it is also an aesthetic we chose because it was technically the least demanding. 8088 MPH was very much driven by all sorts of technical-tricks-turned-into-effects, but they were isolated effects. Making a cool effect is one thing. Making a number of cool effects and smoothly transitioning from one to the next is even more challenging, especially if you also want to sync it to the soundtrack, and have some kind of ‘theme’ to tie the effects together in terms of style and graphics. It was difficult enough to get a full demo working with all the effects we were aiming for, from a technical point-of-view. Trying to also take on cutting-edge design at the same time would have been too big an effort all in one go. So we had to pick our battles.

Getting a demo that smoothly flows from one effect to the next, not only requires designing effects to transition from one scene to the next… You also need to design your code and data in a way that you don’t have to load huge chunks of data from disk in one go, or have to spend many seconds on precalcing certain things. You need to cut everything up in small pieces so you can keep the show going on screen.

Another thing was that the music, with the exception of the endpart, was not exactly groundbreaking from a technical point-of-view. It was a very ‘safe’ 60 Hz PC speaker routine, with 3-channel or 4-channel multiplexing. It didn’t sound bad, but it had been done many times in various games from the 80s and 90s, so it was par-for-the-course at best, technically.

So those are some of the shortcomings we wanted to address in the next demo. I dug up various examples of C64 and Amiga demos that showed good ‘flow’ and had interesting transitions between effects that may translate to the PC in some way. If I see the responses to the demo, various people actually say it feels like a C64 or Amiga demo. Someone even said that they are the Booze Design (famous C64 group, who made some of the demos I showed for inspiration) of the PC platform. So I would say: mission accomplished.

And for those who have been following this blog, it is no secret that I mainly focused on audio after 8088 MPH. One of the first things I did after 8088 MPH was to make a few improvements to MONOTONE, so it would be a more effective tool for composers (most importantly, the playback no longer jumps when you are on the tracker view, which was very annoying. It now asynchronously updates the screen, so the performance of the redrawing does not affect replaying anymore. It always plays correctly, the display may just not keep up with every row in complex situations). MONOTONE already supported other speeds than just 60 Hz, and using 120 Hz or 240 Hz was considered as a possibility for future demos.

I also looked into streaming digital audio from disk, and using various old sound devices from the 80s, which may have been an acceptable target. Being able to stream from disk while also playing music and showing graphics would also be an important factor for getting a smooth flow. Eventually some of these experiments ended up in the release I did recently at Revision 2022: my 8088-compatible ST-NICCC 2000 port, which streams the data from a floppy disk, like the original (a final version and write-up should arrive eventually).

For the music in Area 5150, Shiru was ultimately recruited, based on the System Beeps music disk he made, with his own VST-powered 120 Hz PC speaker engine. He has published an article on it. His engine takes the music up a notch from the 60 Hz MONOTONE music in 8088 MPH. Although, to be fair, there were some 80s/90s games that also used more than 60 Hz for PC speaker (I believe Zak McKracken is one, and Commander Keen may not have music on PC speaker, but its sound effects run at 140 Hz), so it’s a bit more state-of-the-art, but still not technically groundbreaking.

Even so, games on CGA generally didn’t do anything time-critical, so the music routine could be any rate. For CRTC effects on CGA, you need to carefully design your effects so that you can distribute the two PC speaker updates per frame at 120 Hz evenly in your per-frame code somehow.

Please adjust antenna for best reception

The reception of 8088 MPH was a huge success. Not all of that was because of the demo itself. There was also the novelty-factor. It was the first true megademo for the original IBM PC. And as far as I know it was also the first megademo to target composite output (the only other CGA composite production I know of is 8088 Domination). At the very least, it was a platform that was ‘new’ to the demoscene, as the PC demoscene didn’t start until around 1989, and really took off in the early 90s when 486es, VGA and soundcards had become commonplace. Only people who had experienced early PC gaming in the 1980s would have been familiar with what 8088, (composite) CGA and a PC speaker could do.

But we knew that whatever we did after 8088 MPH, the ‘novelty factor’ would be gone. Any kind of sequel was unlikely to have the same impact that 8088 MPH would have, simply because it would not be the first of its kind. People have seen and heard it before.

And from a technical point-of-view it was a similar story: with 8088 MPH we could do many things for the first time, break a lot of limitations of the hardware. It was unlikely that we would be able to combine as many technical breakthroughs in a sequel as we did for 8088 MPH.

And while there certainly are a few technical breakthroughs again in Area 5150, there are also various effects that are based on basically the same ideas that were already in 8088 MPH, but just executed better, with more polish, resulting in new effects.

So I think we can say that a major goal for a successor was: better flow and better polish.

Central to Area 5150 is the 80×25 column textmode, which effectively gives 640×200 resolution at 16 colours. This mode was also used in 8088 MPH in various parts, and the main issue with the mode is that accessing the video memory while the display is active will result in so-called snow. The technical reason is that the memory is single-ported. This means that the memory can be accessed either by the data bus, or by the video output circuit. CGA is designed to give CPU access priority. This means that the CPU can always access memory, and read and write operations are consistent. When the video output circuit tries to read memory while a CPU transfer is in progress, then its read will simply be ignored, and it will just receive whichever data is on the bus at that particular moment. This will be ‘random’, and as such you get a kind of ‘snow’ pattern where some attributes and/or characters are not read correctly, but replaced with this random data on screen.

Why do other modes not suffer from snow? That is because they require only half the bandwidth. The CGA circuit inserts wait states onto the bus whenever the video output circuit needs to read video memory. This means that if the CPU wants to access video memory, it will wait until the CGA card has finished its transfer.

So why did they not just add extra wait states for 80c mode? Likely because it would mean that the CPU would be locked out of accessing video memory almost entirely. It would make video access very slow. So they kept the one wait state, but didn’t add an extra one. A trade-off between speed and visual quality. You can actually see that on screen, as there are columns with and without snow, vertically. That’s because the wait state prevents snow in some places, not in others.

The plasma effect in 8088 MPH is one effect that runs in 80c mode, and tries to write only during the inactive periods of the display, to avoid snow. You can actually buffer some writes in main memory or registers and wait for the DISPLAY_ENABLE flag to go low before writing them to video memory without snow.

So basically, if you thought 8088+CGA was slow… it just got even slower, as you only have a very limited window of opportunity to update parts of the video memory without snow. The key is to stick to effects that only require very small updates to video memory. In the case of the plasma, the resolution was actually 80×25, so it was easy to update a large part of the screen at a high frame rate, at the cost of low resolution, so the plasma was somewhat blocky. For tweakmodes with higher vertical resolution, such as 80×50, 80×100 or 80×200, that won’t be possible.

Another effect that wasn’t really used as an effect, aside from the Kefrens bars, is to reprogram the screen offset mid-screen. This effectively allows you to choose any scanline from video memory at any part of the screen. Or well, technical limitations of CGA mean that you work in sets of 2 scanlines, so you can only start at even scanlines. Or at least, that is what we did for 8088 MPH.

As said, it wasn’t really used as an effect in itself, but it was required to make the 1024-colour mode possible. In order to use only the first row of the characterset, the CRTC had to be reset every other scanline. Effectively we were ‘stacking’ 100 frames of 2 scanlines on top of each other. These frames had no vertical blank area, so they fit together seamlessly on screen, leading to a continuous picture.

A new CRTC frame normally means that the screen offset (the pointer to video memory) is also reset to the starting value stored in the CRTC registers. So in order to display the pictures, we had to ‘manually’ point each frame to the correct position in video memory. We could have pointed it to any position if we wanted (and there were some simple transition effects that did this), but it wasn’t really exploited.

The upside of this trick is that it doesn’t require any access to video memory, only to the CRTC registers, so it does not generate snow.

These are the two main ingredients for many effects in Area 5150: A few small updates to the video memory every frame, and manipulating which scanline is shown where on the screen. That allows you do to many tricks in 640×200 resolution at 16 colours, with no snow. It was already in the DNA of 8088 MPH, but at the time, we only made limited use of the possibilities. Now it was time to push it further with some polished effects.

Most of these effects were done by VileR. Many of them were actually done shortly after 8088 MPH.

Let’s run down some of the effects and discuss them.

The demo starts off with a very C64-like trick: the first effect manipulates the current screen itself, so it has a ‘seamless’ start:

Since you can assume what mode the screen is in, you can easily manipulate the existing contents. In this case by changing the font height to shrink the screen, and then playing with the position of the visible window to get an interesting first bouncing transition, right off the bat, before the demo even seems to have started officially. The border is also set to blue, so the effect stands out better.

Then a similar trick to 8088 MPH is pulled: a screen that appears to be 40c text mode, is suddenly displaying graphics. Spoiler: it is not actually 40c textmode. It is faked with ANSI-From-Hell graphics in 80c textmode (just like 8088 MPH faked textmode in graphics).

While it is possible to switch between certain modes per-scanline (we will get to that later), it is virtually impossible to switch between modes reliably within a scanline. Also, it is not possible to switch reliably between 80c textmode and any of the other modes, because 80c is the ‘odd one out’, as also discussed above with the snow.

Here we have the first effect that manipulates the screen offset mid-frame. It uses 80c mode, but in overscan, so the entire screen is covered, including the border area. By cleverly re-using the same scanlines multiple times, the various gradient patterns can be drawn and animated. By updating the data on-the-fly, the colours are changed over time. Because it runs so smoothly, and the dithering at 640×200 resolution is so fine, it gives an Amiga copper-effect kind of feel with thousands of colours.

I suppose that’s also because RGBI has really bright colours. It’s only 16 colours, but it gives this VGA/Amiga-like RGB richness to it. The C64 doesn’t really have that, its colours are more subdued (as is CGA composite).

In the capture on YouTube you can actually see some snow at the bottom of the screen. This is where some updates to video memory are done. On a real monitor this is usually outside the visible area.

This is the first effect that was not in the works yet for Revision 2020. It appears to be a relatively simple 40c mode effect. 40c is used for two reasons: no snow, and the low resolution makes it easy to move large parts of the screen around.

It seems pretty straightforward, just some sort of masked blit routine. The main remarkable thing is again that it is in full overscan.

Now we are getting to the transitions. These image-transitions give a very C64-like feel, and give the demo a coherent feel and flow to it.

On C64, most graphics are character-based, and by manipulating the colorram, you can create interesting effects like fading colours in/out, creating glow-effects etc. This is often done in interesting patterns. It cannot be done per-pixel, but only per-character, in 40×25 resolution. But this coarse resolution is good enough for various effects.

This could be translated to CGA textmode, as it also has a sort of ‘colorram’ with its attributes per-character. Again, we see here that there are only slight changes per-frame, so these can be done in 80c mode without snow.

These particular transitions have a sort of ‘pre-glow’ effect as the image is unveiled. Especially the searchlight-pattern is nice.

Another variation here where one image can be slowly dissolved into another, following a certain pattern.

And later we again see a similar effect, with a circular pattern this time.

Then we see another interesting transition. This one runs in overscan. It again makes use of re-using scanlines. Only a few unique scanlines are required to create the wavy pattern. You can store about 100 unique scanlines in memory, which should be enough to get a smooth motion from left-to-right, or right-to-left. And the actual ‘transition’ in colours is only a few characters wide, so you could update it on-the-fly without snow if required.

This effect is probably my favourite. Again running in overscan. And very clever use of repeating scanline patterns to get the rotating animation going, and a nice smooth scroller as icing on the cake. The colour changes are also really nice. Again, this feels almost like an Amiga-effect, with that richness of the RGBI colours and dithering.

Then it transitions seamlessly into a classic twister-effect. From a technical point-of-view again very similar: repeating scanline patterns. But again, nicely done, with lots of colours, good dithering, and even a drop shadow.

The ending is also nice, again, making use of repeating patterns of scanlines to do a wavy animation, and then some small updates to dissolve them.

This is actually two effects really. The first is a vertical scroll. The interesting thing is that it actually scrolls per-scanline. With regular CRTC manipulation of the start offset, you can’t do that in this mode.

So instead this effect manipulates the timing of the frame as well, in order to get more fine-grained positioning. Tricky to do. On Amstrad CPC464, which also uses the 6845 CRTC, people have even managed to do 1/64th subpixel vertical positioning:

So while the sprite-effect in 8088 MPH performed perfectly smooth 60 fps scrolling, it still was a tad ‘jumpy’ because it had to scroll at 2-scanline increments. This does 60 fps scrolling with 1-scanline increments. As good as it gets.

Then we get to the crystal ball effect. This might remind you of other C64 effects. They tend to make scrollers with various patterns, usually full-screen, where they can manipulate the colorram to paint the letters.

This is similar, except it can’t be done in fullscreen. But the attributes are turned on and off based on the scroll-text which is a 1-bit pattern.

Then we see another transition. This one is very straightforward: just plotting gray blocks in a simple pattern. Again, not too much per frame, avoid snow.

This is another effect I don’t think we had on the table yet for Revision 2020. It seems like basically a chunky table-based effect in 40c textmode.

Here is the classic checkerboard effect. It again makes use of repetitive patterns of scanlines, and small updates per frame cleverly. We had an earlier version of this effect, which ran at 30 fps in fullscreen, or 60 fps if the width of the screen was a bit smaller. Apparently in this version it is 60 fps at full width, so some optimizations have been found to get the best-of-both-worlds. Another classic demoscene effect done to perfection on the 8088+CGA, which can be crossed off the list.

The end of this effect introduces another transition. This one again runs in full overscan, and uses repeating scanlines.

Here is another classic effect, a sine scroller. Again this is done with a clever combination of updating small bits of videomemory on-the-fly and modifying the start offset register per-scanline. In this case the actual active display is very small, which allows for more CPU-time to update the scroller data without snow.

Then the actual dancing elephant. To my knowledge this is the first time that an actual animation has been tried in ANSI-from-Hell. The result is very nice. It also gives the PC a sort of ‘cartoony’ feeling, which it never quite had, because CGA was not colourful enough and animation was not fast and smooth enough to do this kind of thing. Until now.

Another nice touch is that this is one of the few parts in the demo where the visuals are closely synced to the soundtrack (another obvious one is the part where the Cacodemon is shown, and the soundtrack plays a reference to the DOOM soundtrack). So this shows the kind of flow and polish that we did not have in 8088 MPH yet, but which is common in good C64 and Amiga demos. Of course this idea was first popularized by Desert Dream, and then taken even further with Second Reality.

The next effect is a plasma. A nice design-touch is that it is applied to a part of an image, in this case the sunglasses. A design-idea that is common with C64 and Amiga demos.

The transition out of the plasma-effect… I am not entirely sure if this is another application of the earlier table-based transition pattern routine, or if this is its own thing. At any rate, it looks different, and appears only in this spot in the demo.

Then we have the isometric scroller. This is exactly the opposite of what it looks like. It looks like the bars at the top-right and bottom-left are stationary, while the text is moving diagonally. In actual fact, the text is not moving in video memory. The start offset is changed so the position of the text changes on screen. The bars are the ones that are updated (only the endpoints need to be redrawn), and only the wraparound has to be handled to keep the text scrolling once the end of the video memory is reached.

This same concept had already been used in the game Zaxxon. It scrolls the screen by updating the start offset, and redraws the HUD to make it look stationary. Zaxxon uses graphics mode instead of textmode though, so it is less colourful. It also does not scroll as smoothly.

This is obviously a reference to the game Marble Madness. A nice 8-way scroller in 80c textmode. Again, this uses scanline-accurate scrolling, at 60 fps, so perfect smoothness.

I had seen an earlier version of this effect, which had different artwork at the time, and was still targeting a composite mode. It wasn’t planned for inclusion at Revision 2020. This effect is apparently not quite finished yet, and should show a larger playfield in the final version. Currently it just stops when the ball reaches the two chips, and sits there for the remainder of the timeslot.

Another interesting touch, which is only apparent when watching at 60 Hz, is that the ball sprite uses some kind of temporal aliasing to reduce the blockiness that is inherent in ANSI-from-Hell graphics. It gives a better sense of transparency and roundness at the edges.

Ah, polygons! My area of expertise! While we were planning on doing translucent polygons, aka ‘glenz’, in the Revision 2020 version, that was a different routine from the one that ended up in Area 5150. This effect was done by Utter Chaos, who you may know as William Hart from his PCRetroTech YouTube channel. On his channel, he has published a video where he discusses this effect, among other things:

In his video, he also shows some rough footage from the early version that I had made. What is interesting here is that there is more than one way to skin a cat.

I originally decided to try a glenz effect after 8088 MPH, when I realized that the delta-rendering technique gives you transparency almost for free. That is, I store the colour per-span. That means I only have to blend a single ‘pixel’ to blend two overlapping spans together. The actual drawing is the same regardless of whether there is transparency or not: just draw all pixels in the span with the same colour.

I also figured out that in RGBI-mode, even though you only have 4 colours in graphics mode, you could set up a specific palette that conveys translucency between red and gray.

So I could extend the 8088 MPH polygon renderer with transparency, while maintaining all of its other advantages, including the ability to only draw the differences between two frames. The examples you see in the PCRetroTech video are done with this delta-rendering technique.

However, as you may recall from 8088 MPH, the delta-rendering technique was specifically chosen because it allowed you to draw large images quickly. Which is also why the cube and donut in 8088 MPH cover nearly the entire screen.

My early attempts showed that the translucent objects I chose, were not scaling as well as I had hoped. There was more overhead than expected, since there were more changes on screen that took longer to draw than I had hoped. It can probably be made to run acceptably with some more optimization, but trying to draw large translucent objects with delta-rendering may not be the best choice for 8088+CGA.

Utter Chaos however took a different approach: focus on rendering small objects instead, on only a small part of the screen. He ended up using a variation of the so-called eor-filler that is commonly used on the C64. The basic idea is similar to the area-fill of the Amiga blitter, except the blitter works horizontally, where an eor-filler works vertically.

The key is that you draw the outline of your polygons, and then eor (or xor in x86-parlance) each pixel with the next (on the next scanline). When you hit the first outline (going from outside the polygon to inside the polygon), the bits will be enabled, and eor-ing with 0 will keep them on, so you paint these pixels, and fill the polygon. Once you hit another outline, the bits will be disabled again with the eor, so you no longer fill.

The beauty of this technique is that you can draw all outlines first, and then do a single eor-pass over your entire buffer, and you’re done. On C64 anyway, where you can perform double-buffering easily. On PC you cannot. Also, on CGA, because of the waitstates, it is relatively slow to perform read-modify-write operations like xor directly on video memory.

So perhaps it’s better to have a buffer in main memory, and then copy that, to avoid flicker. But, once we do that, there is another trick we can pull. This time borrowed from the Amiga. I believe they call it ‘cookie-cut’. That is, you draw the outline in an offscreen buffer, and use that buffer as the input for the blitter fill. But you set the output directly to your framebuffer. So the outline is never physically filled in memory. The filled pixels are written directly into the output buffer. It’s like a fill-and-blit rolled into one.

This trick can also be made to work on the eor-filler for CGA: since you only read each pixel once, it doesn’t matter if you don’t write the actual filled pixel back to the buffer. So you don’t have to do read-modify-write in place. You can do the write directly to video memory. Even directly to the frontbuffer if you are fast enough.

Another very neat trick done here is that the top and bottom of the screen are 40c textmode, while the middle is 320×200 4-colour graphics mode. So unlike the ‘fake’ combinations of text and graphics that we’ve seen before, this is the real thing.

Some other details worth mentioning are that it runs in overscan mode, and the vertical motion of the object is actually done by varying the point at which the switch from text to graphics mode is performed, rather than the object physically moving in video ram.

Another classic effect translated to 8088+CGA: the voxel landscape. This runs in 40c textmode, as it is another chunky effect that needs to update large areas on the screen without snow.

I know we have discussed the voxel effect, and went into techniques used on Amiga, such as in Oxyron’s Planet Rocklobster, which had been adapted to Atari 8-bit in Arsantica 3. At the time we figured it should be possible to do a voxel like this on 8088+CGA, but I don’t think we had a prototype implementation ready yet for Revision 2020.

The parallax scroller. Another effect that cleverly makes use of repositioning scanlines. Technically clever, but the artwork really makes the effect shine as well. And again, this is 80c textmode, it’s ANSI-from-Hell.

Then one last effect before the end-part. Again, an 80c textmode image where the scanline positions are manipulated.

And the endpart, which you may think is the same effect as the previous one. But it’s not. The previous effect was a fullscreen 80c image. In 80c mode, each column takes up 2 bytes (character+attribute), so you have 160 bytes per scanline. Since CGA has 16384 bytes of memory, you can only fit 102 scanlines into memory. So a fullscreen image cannot use the full vertical resolution.

This however is not a fullscreen image. The whole videomemory is already used at the top, so it uses the full resolution. The bottom is just re-using the same scanlines, but mirroring them, and applying a sine-wave to it to give the illusion of reflection on a water surface.

We actually used this 80×200 tweaked textmode in the ‘mugshot’ part of 8088 MPH as well, to get the best possible resolution for the scanned photographs. However, at the time, we just showed it as a ‘letterboxed’ screen, so you only got 100 filled scanlines, and black borders on top and bottom. A more basic way to work around the fact that there’s not enough memory for an entire screen.

Another interesting trick is that the routine plays one PWM sample at every scanline. This gives us a replay rate of exactly 15.7 kHz. Slightly lower than the 16.5 kHz in the 4-channel MOD player used in 8088 MPH, but the trade-off is that there are now more interesting graphics.

What you may not know is that the Kefrens-effect in 8088 MPH was actually designed the same way: it is a cycle-counted effect, where originally there was a PWM-sample output at every scanline. But since our demo only had MONOTONE-based music, not sample-based (aside from the endpart, which was a specific mixing routine that could not be combined with the Kefrens effect), the Kefrens effect ended up just playing the MONOTONE music once per frame, and performing nops during the scanlines where the PWM output would otherwise be.

One last effect, which is the opposite of how the demo started: the effect drops us back to regular textmode first, then does a clever ANSI-animation, before dropping back to the DOS prompt as seamlessly as the demo started.

And that’s the end of Area 5150. I hope you liked some of the background information that I could provide.

Advertisement