The Living Daylights (Extra colours in Mode 1... Rasters? Screen splits?)

[Longshot]

Basically, instead of setting the CRTC registers to output a regular PAL video frame at 50hz and leaving it alone to do its job (as you normally would), you disable vsync, then tell it to output a much smaller screen fragment. Then when it gets to the end of that you send it updated values to draw a second one, or a third, and so on, and providing you get all the timing right the whole thing will add up to something that resembles the timing for a complete PAL frame at the end. Then you trigger vsync and hope your monitor doesn't notice any difference.

With the RFD (Rupture For Dummies  ) technique (see Compendium chapter 11.6), there's no need to build frames or worry about vsync (This requires 4 outs for the entire frame. See 11.6.3).
This technique "force" and "keep" the CRTC's internal state true, allowing R12/R13 to be updated during the whole frame.
But this only works on CRTC 1...

[Xyphoe]

Hi again everyone. So I posted this originally because this was for a video project and to describe what is going on in simple terms for the average person watching - so they could understand too, and maybe learn a little bit themselves as well.

So I've written up a summary, a basis of a script of sorts. How does this sound? Feel free to correct or add anything, some of this I have used some of your words and phrases. Thanks in advance and also thanks everyone so far! It's been a very interesting topic!



The Living Daylights is unusual and fairly unique in that it uses a mixture of clever screen coding techniques to achieve how it looks and moves, very rarely seen combined together in other games. It's setup in Amstrad's "Mode 1" screen mode which is normally limited to a maximum of 4 colours, but here we can see they have actually 8 colours on screen. And also some very nice fast and smooth moving scrolling, with layers of parallax in the background to go with it too! What have they done here to achieve it?

Without access to the original source code we can't know for definite, but with debugging tools and knowledge learned within the community over many years we can make some very accurate guesses.

Firstly it starts with 'interupts'. The Amstrad has an interrupt that goes off every 300th of a second - 6 times per frame, or every 52 scanlines - which you can sync to with it being the fastest clock you can do on the CPC. Interrupts are a way to temporarily suspend the Z80 CPU at regular points and do things with some code. We can see it happening on this screenshot [insert Axelay's screenshot with the blue borders] and they have setup and used 6 interrupts. And it's these interrupts that the coders Graham Stafford and David Fish have used to both place their screen splits (called 'ruptures') and then also change the palette colours within them to give us the 8 colours on screen.

With the palette changes you can see originally this was the usual 4 colours [insert Axelay's video memory screenshot] then rasters were used in each of the screen splits to change the palette within them. More on that shortly.

As for the scrolling this is very difficult to achieve because there's essentially 3 different areas being scrolled here within the ruptures and screen splits - in level 1 the first is the mountains being the slowest, secondly the middle area where Bond is running slightly faster, and lastly the 3rd area at the bottom with bushes scrolling the fastest - for a nicely layered parallax effect.

And it must be using a hardware scroll for this, utilising the Amstrad CRTC video chip. So you first disable vsync (vertical synchronisation) which normally would result in chaos! But with careful coding and timing, you're going to tell the chip (because you've done a rupture or screen split) to output a much smaller screen on one of your interrupts (and of course you've changed the palette colours too just to make things more complex!). Then you move onto the next screen split, and so on - including the HUD (heads up display where the score, lives, etc are) at the bottom. When all that's completed - and fingers crossed you got all your timings correct, you re-enable the vsync and pray the monitor likes it!

For those interested in terms of the hardware scrolling technique being used here, the CRTC chip has registers you can change to define the start address of the screen which are registers 12 and 13, known as R12 and R13 - and it looks like this is what the coders are using here.

So why wasn't all the above used more in other games?

Possibly because it was discovered that it was hard to ensure it worked on all Amstrad CPC models due to different revisions of the CRTC chip. On what is known as CRTC 1 model "The Living Daylights" actually glitches and becomes unstable, and some of the HUD appears in the middle of the game area. It's likely the coders didn't know about this revision and were coding on a CRTC 0, the most common model. By the late 80's this 'bug' or known difference was probably more well known about and coders didn't want to deal with the headache.

Additionally their usage of rasters to change the palette colours in game caused additional complexities on top of the screen splits and ruptures, it meant their game loop code had to run at 50Hz without fail or it would simply fall apart.

Coders under severe time pressure from publishers and their bosses to turnaround games, especially conversions or licenced properties simply wouldn't have time to go to these lengths for their games and would have taken easier routes to complete their projects for a deadline.

[Axelay]

Additionally their usage of rasters to change the palette colours in game caused additional complexities on top of the screen splits and ruptures, it meant their game loop code had to run at 50Hz without fail or it would simply fall apart.

Seems mostly accurate from a quick read, but this stood out as incorrect.  If you are using interrupts to perform the palette changes and ruptures, your game loop can take as many screen refreshes as it likes, even vary between game frames, the interrupts will handle it at 50hz because that is their purpose.

It is only if you choose to do a rupture or palette change without using interrupts, making them part of your 'main code loop' that you need to maintain them 'manually' at a 50hz rate.  Even then, your game loop does not need to run at 50hz as such, you could have a 25hz game loop that executes the required colour changes or rupture code at the correct time twice per game loop.

[lmimmfn]

Chibi Akumas has some great pix on the interrupts and Z80 examples on changing screen mode per interrupt(simple to just change the colours using same interrupt code) 
https://www.chibiakumas.com/z80/platform5.php#LessonP41

[Interrupt]

Additionally their usage of rasters to change the palette colours in game caused additional complexities on top of the screen splits and ruptures, it meant their game loop code had to run at 50Hz without fail or it would simply fall apart.

Seems mostly accurate from a quick read, but this stood out as incorrect.  If you are using interrupts to perform the palette changes and ruptures, your game loop can take as many screen refreshes as it likes, even vary between game frames, the interrupts will handle it at 50hz because that is their purpose.

It is only if you choose to do a rupture or palette change without using interrupts, making them part of your 'main code loop' that you need to maintain them 'manually' at a 50hz rate.  Even then, your game loop does not need to run at 50hz as such, you could have a 25hz game loop that executes the required colour changes or rupture code at the correct time twice per game loop.

I think this may have come from my comment. I was coming at it from the perspective that you have to solve the problem of setting the CRTC configuration and palette at exactly the right moment every frame. You can't simply set some registers to configure a permanent split. Interrupts are an easier way to do that but I think that the fact you can't "fire and forget" some settings goes some way to explain the relatively infrequent use of these techniques in games. 

[Interrupt]

I agree with Axelay that the penultimate paragraph isn't quite right - I'd probably just remove it as I think that by the time it is corrected it won't add much.

[lightforce6128]

In my opinion, the text looks good now (with the suggested change).

One additional observation about the game, an idea that was new to me and that is quite interesting: In the screenshot of the video memory we see a big gap between the mid scrolling layer and the lower scrolling layer. In this gap still the level name is visible. The upper scrolling layer moves slow, the mid scrolling layer moves faster. So the slower layer will never catch up with the faster layer. But the faster layer eventually will arrive at the status/HUD. The gap gives it some space so that it can scroll for some time (until the end of the level) without collision.

A similar trick could have been done to the mid scrolling layer and the lower scrolling layer. The problem here is that the lower scrolling layer moves so fast that it would consume the whole gap in half of the time. Then the levels would be quite short. So it seems here another trick has been used (but I'm not sure about which one).

What was new to me: My first idea would be to distribute each scrolling layer to its own 16K memory page. Then there wont be any collision (because of the wiring of the CRTC). But with three scrolling layers also three out of four memory pages would be in use, and the last one would be needed for the non-scrolling status/HUD and all the program, sprite data, music, and sound effects. This would not be an effective use of memory, because in the three memory pages for the scrolling layers most of the available memory would be unused (but never the same part, so it cannot be used for anything else but for temporary data). The trick described above solves this problem. It only cannot scroll forever, but only for a limited time. If the game is split into several levels, this is perfectly ok.

[Xyphoe]

Thank you everyone!

I think then, it would be fine to just end and leave it with ....

"Additionally their usage of rasters to change the palette colours in game caused additional complexities on top of the screen splits and ruptures.

Coders under severe time pressure from publishers...."

Just chop off the "it meant their game loop code had to run at 50Hz" bit which was incorrect. Yea?

Cheers!

[Anthony Flack]

Yeah, I think some of the wider conversation complicated things more than they needed to be. The rupture/colour change code does need to run at 50hz, and synced to the monitor. But putting it on the interrupt already takes care of that.

The interrupt is handy for triggering anything you want to happen at a regular interval, somewhat independently of your main code. Most games that use a colour split will do it on the interrupt and that was something coders used right from the early days (eg Sorcery, Jet Set Willy). In Frank N Stein you can very clearly see colour changes happening at each interrupt, with visible timing glitches as they change colour mid-line. 

What is most remarkable about The Living Daylights for the time is the parallax hardware scrolling using ruptures, which was much less well understood. 

[Longshot]

It's likely the coders didn't know about this revision and were coding on a CRTC 0, the most common model. By the late 80's this 'bug' or known difference was probably more well known about and coders didn't want to deal with the headache.

At the end of the 1980s, the various CRTC models were just beginning to be identified.

I think it was difficult to be exhaustive on this subject without knowing the components ordered by Amstrad.
We had to investigate numerous CPCs (our own and those of the A100% editorial team) to get a clearer idea.

From memory, the most notable difference experienced by some game programmers was the loss of monitor Vsync with the CRTC 2.

The first fullscreen displays (demos, games) involved centering the screen (via R2), which could cause this problem.
Rémi Herbulot also experienced the problem in his game "Get Dexter" with scrolling using R2.

More recently, the Compendium allows these differences to be detailed and described precisely.

For your article, you can also add this image, which is quite clear about the HUD.

[ZorrO]

Maybe this emulator doesn't work properly because I had a CPC with CRTC 2 and this game was displayed normally and not like on picture above.

[Longshot]

Maybe this emulator doesn't work properly because I had a CPC with CRTC 2 and this game was displayed normally and not like on picture above.

You misread. This problem only occurs on CRTC 1.

Amspirit is the most accurate CPC emulator currently available.

[poulette73]

I confirm! 

Tested now on real hardware with a CPC CRTC Type 1 :