CODINGVIDEO / CRTC ★ WACCI CPC : AZ of CPC Chips - Part. 2 ★

Wacci CRTC (2/2)
★ Ce texte vous est présenté dans sa version originale ★ 
 ★ This text is presented to you in its original version ★ 
 ★ Este texto se presenta en su versión original ★ 
 ★ Dieser Text wird in seiner Originalfassung präsentiert ★ 

After last issue you may have been left feeling there were a few loose ends to tie up, like how does the monitor display colours if the CRTC chip is designed to display black and white?... I did say that didn't l? No? Oh, well it is, okay!

Putting the Colour in CPC

As mentioned the CRTC chip inside the CPC is only designed for black and white displays, and text, come to think of it, but the designers of the CPC wanted a graphical, full (well, 26) colour display. This proved a bit of a problem for Amstrad.

The graphical bit was easy enough to get around, because it just meant setting the chip up, in such a way that the memory was interpreted as pixels, rather than characters, but the colour bit wasn't so simple.

This is where the VGA (Video Gate Array) chip steps in (well, not literally!) The VGA chip was custom made, specifically for the CPC, so that the black and white data could be interpreted as colours. This was a very effective way of doing it, but it costs a bit to have microchips custom made, so Amstrad decided to make the most of it.

The VGA is chiefly concerned with creating those colourful hues, that we have all come to know and love, but it also does a hell of a lot more. The VGA has four modes of operation, two are concerned with colours, one controls the extra RAM, and the other controls the
screen mode and the external ROMs. The VGA also provides one other very important function. I said in the first article that the `Z80 was the heart of the CPC', or something similar. I am willing to admit that this may need a little modification.

If we are going to use analogies to the human body, the VGA would be more likely to be the heart of the CPC, because it provides all of the clock inputs for the chips, rather like a heart beat, funnily enough!

The clock input is a continuously changing signal that oscillates at a set frequency, and dictates how fast all of the processes go on inside the chips. This means that, in theory, the CPC could be speeded up, by altering this signal.

The only problem with this is that microchips are designed to operate at specific frequencies, and by exceeding the recommended frequencies, some damage can be done to the chip. If you were thinking of altering your CPC I'd think again!

Creating Colours

Anyway, getting back on track, the VGA does something very sneaky, after receiving the data from the CRTC. The data from the CRTC comes in digital form, since black and white can only be either 0 or 1. This means the VGA can group them together, into twos, or nibbles (four bits), to make up a number between 0 and 3, or 0 and 15. If you have ever done any programming this may start to sound familiar!

Once a number has been found the VGA looks up which colour is assigned to that value and outputs the colour to the monitor. In this case, to draw parallels to BASIC, you can say that the value from the CRTC is the PEN number, and the value that is looked up is the INK number. Neat isn't it?!

You may also have noticed that the number of PENs available, when grouping the bits, are the same as the PENs available in the different modes of BASIC. This is basically because the VGA controls the screen modes as well, but I'll come back to that a little later.

In mode 2 the data is passed straight through with the INK number being looked up for each individual bit. In mode 1 the bits are taken in groups of 2, which allows for 4 different colours. In mode 0 the bits are taken in nibbles (4 bits), which allows for 16 different colours.

A New Resolution

You may also have noticed that when the screen modes are changed in BASIC, the resolution available is reduced, as the number of colours displayed increases. This is an unfortunate by-product of the VGA operation.

Since the monitor is always scanning across the screen, the VGA must always provide the information for the next pixel at the time the monitor gets to the position of that pixel, otherwise there would be gaps in the display, which wouldn't be very fetching.
This is achieved by some very precise timing, and also because the monitor is controlled, in part, by the CRTC, but that is getting slightly off topic.

Since the CRTC chip (and the VGA, since it adds the colour) can't work at an infinite speed (if it could then there wouldn't be any pixels!) there has to be some point where the chip doesn't change the information relayed to the monitor ie. it is latched on the output lines, to use a technical term.

When the VGA prepares the information for one pixel, it sends it to the monitor, and doesn't change it until it has got the information for the next pixel.

This is basically how the pixels are formed. From this you can see that to increase the screen resolution the speed at which the data is sent to the monitor has to be increased, but since the CRTC only works at one speed the maximum resolution is 640x200.

The vertical resolution is affected by the speed because the whole of the screen must have been scanned after 1/50th of a second, otherwise the screen display would go out of sync with the monitor, and it would start to roll. Anyway, since the CRTC only works at one speed (determined by the clock pulse sent to it by the VGA) the VGA has to wait longer before it can send a pixel in mode 1, than in mode 2, because in mode 2 the VGA only has to process one bit per pixel, however in mode 1 it must wait for the CRTC to send 2 bits before it can send the pixel to the monitor.

During the time that the VGA is waiting for the CRTC, the monitor has moved on twice as far as it would have in mode 2, so the pixels appear longer, horizontally. The same applies in mode 0, only it is 4 times as long as the pixels in mode 2, because it is waiting for 4 bits from the CRTC.

This explains why the resolution is worse in the different screen modes. If the resolution were to stay the same, then the CRTC would have to be speeded up for the lower modes and more RAM would have to be allocated to allow for the extra colour information, since each pixel takes up either 2 or 4 bits more than in screen mode 2.

I think that this would just about be theoretically possible without Amstrad having to use any extra chips, but the VGA would have to be altered. The other problem is the amount of memory that it would take eg. In mode 0 it would require 64K to display 16 colours at the same resolution as in mode 2. As you can see this is clearly impractical with the 64K RAM of the 464 and 664.

You may be wondering why the vertical resolution isn't affected in the different screen modes.

This is because no matter what mode you are in, the amount that the monitor moves down with every horizontal scan is the same, hence the vertical resolution stays the same.

ROMs and RAM

Yes, the VGA's talents even extend beyond just controlling output to the monitor! The VGA is also responsible for deciding whether the ROMs should be accessible, and what configuration any extra RAM banks should have, as regards which banks will be paged into normal (that is, accessible by the processor) memory, and where.

The ROM control is pretty simple. The VGA just controls the ouput lines to romboxes, and the onboard hardware, which say whether they should be active or not. If the ROM (either the upper or the lower) should be active it tells the RAM to ignore any memory requests, and vice-versa.

The VGA only controls the reading though, all writes will still go to RAM. This doesn't affect the ROMs, since they can't be written to, but does cause a problem or to when writing to RAMROMs. The RAM configuration is controlled by the VGA in the 6128 computers. It decides which 16K blocks of RAM will be addressed when reading from different areas of memory, with a total of eight configurations per 64K of RAM (this excludes the first 64K, since it defaults to this block).

The VGA has control signals to each of the RAM chips to enable and disable them, depending on the address requested, and the RAM select number that is written to the VGA chip. If a selection requires RAM that isn't there, eg. A port address relates to the 3r1 bank of RAM on a 6128, all reads and writes will go to the first 64K of RAM. The details of the VGA select addresses can be found in the firmware guide (the AMSTRAD publication) and in various other places dotted around. These have the bytes required to access different functions of the chip, and the bit significance of all of the

values. Everything else they Crammed in Amstrad still had a miscellaneous function that they had to put on the VGA chip, the clear bit 7 of the raster count. This is used with the interrupts to make sure that no two interrupts occur consecutively. I should mention at this point that the VGA also sends the interrupt pulse, to the Z80, every 1/300th of a second.
This is determined by counting the number of scan lines, from the CRTC. Since every frame has to be completed in 1/50th of a second, and there are 312 scan lines in each frame, 1/300th of a second will have passed when 52 of the lines have been counted. The number of lines is stored in a register inside the VGA, and is incremented every time the CRTC sends an HSYNC signal.

This means that you can, theoretically, vary the length of time between interrupt pulses, but the problem with this is that the screen will probably become unstable. If you have any great ideas for demos using this, I wouldn't fancy your chances of it working out.

The problem with the aforementioned method is that it still counts while the Z80 is executing the interrupt routine, so it is possible that the Z80 will have just finished the interrupt routine and will then be re-interrupted immediately. This is obviously undesirable, so the interrupt routine clears bit seven of the raster count, to allow some time in between finishing the routine and the next interrupt.

The End. Hooray!

Phew! I think that about wraps up the VGA, so in the next issue I'll be talking about the PPI, but I might start with the PSG. I don't know! It will definitely not be the VGA though, unless John makes a major editorial mistake!

James Hoskisson, WACCI MAG

★ AUTHOR: James Hoskisson

Page précédente : Wacci CRTC (1/2)

★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):
» Coding » Sdcc - 11 - Attaquer le Crtc
» Coding » Graphic - 30 - Etude du Crtc (SOS Programmeurs)
» Coding » Dossier CRTC par GOZEUR/Paradox
» Coding Src's » RICHARD FAIRHURST SourceCode Collection
» Coding » Crtc - Scrolling (SOS Programmeurs)
» Coding » AMSLIVE n°19 - Crtc Detection - Retour Au Source
Je participe au site:

» Vous avez remarqué une erreur dans ce texte ?
» Aidez-nous à améliorer cette page : en nous contactant via le forum ou par email.

CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 557 millisecondes et consultée 1945 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.