Amstrad CPC

Anything relating to non Sinclair computers from the 1980's, 90's or even before.
spectron
Berk
Posts: 19
Joined: Thu Mar 29, 2018 2:27 pm

Re: Amstrad CPC

Post by spectron » Tue May 15, 2018 1:00 pm

Joefish wrote:
Tue May 15, 2018 12:34 pm
Knight Lore doesn't even use the remaining colour in the backdrops. But it's sprites won't take up any more memory than the Spectrum ones.
I'll bet it unpacks the required ones to 4 colour mode when switching screens though!
0 x

Joefish
Manic Miner
Posts: 267
Joined: Tue Nov 14, 2017 10:26 am

Re: Amstrad CPC

Post by Joefish » Tue May 15, 2018 5:19 pm

I thought you could do it without unpacking, but the Amstrad doesn't do its graphics in separate bitplanes, so you can't easily form a mask from the sprite data. Maybe it does expand 2-bit sprite images into more data before it can use them. Seems a lot of trouble though.
0 x

AndyC
Microbot
Posts: 161
Joined: Mon Nov 13, 2017 5:12 am

Re: Amstrad CPC

Post by AndyC » Tue May 15, 2018 5:43 pm

spectron wrote:
Tue May 15, 2018 11:12 am
You might also notice a similarity with the BBC micro. Could be because they both used the Motorola 6845 video generator.

& CGA in the PC for that matter
Although the Amstrad does use a 6845 in it's video generation, it's really only to provide signal timing for a frame with most of the display work actually being done by a custom gate array.
Joefish wrote:
Tue May 15, 2018 5:19 pm
I thought you could do it without unpacking, but the Amstrad doesn't do its graphics in separate bitplanes, so you can't easily form a mask from the sprite data. Maybe it does expand 2-bit sprite images into more data before it can use them. Seems a lot of trouble though.
The usual way of masking sprites on the CPC is just to treat INK 0 as the transparent colour, giving you three other sprite colours in Mode 1 or 15 in Mode 0. A completely separate mask (as on the Speccy) is usually overkill and requires a lot more memory. Usually a 256 byte page aligned masking table is used to look up the correct mask byte value for any given byte in a sprite (this can also allow for other tricks like flashing a sprite solid white by just using a different masking table).
1 x

User avatar
1024MAK
Microbot
Posts: 164
Joined: Wed Nov 15, 2017 2:52 pm
Location: Sunny Somerset in the U.K. in Europe

Re: Amstrad CPC

Post by 1024MAK » Wed May 16, 2018 4:24 pm

On any system, the Motorola 6845 CRT controller (which was also available from other semiconductor manufacturers) ONLY provides timing signals and address control lines for screen memory control. It has nothing to do with pixel data.

Other circuitry has to be provided to generate the pixel information. In text only systems, this would be some memory chips (RAM or RAM and ROM, the ROM containing character font data) and a parallel to serial converter. Plus some logic support chips.

In the Acorn BBC Micro, there is a custom Acorn chip (either a "Video ULA" or "VideoProc"). Plus some logic support chips.

In the Amstrad CPC machines, the Amstrad custom chip (the gate array, an application specific custom chip) does all the handling of the pixel data.

Mark
1 x

Joefish
Manic Miner
Posts: 267
Joined: Tue Nov 14, 2017 10:26 am

Re: Amstrad CPC

Post by Joefish » Thu May 17, 2018 10:49 am

AndyC wrote:
Tue May 15, 2018 5:43 pm
The usual way of masking sprites on the CPC is just to treat INK 0 as the transparent colour, giving you three other sprite colours in Mode 1 or 15 in Mode 0. A completely separate mask (as on the Speccy) is usually overkill and requires a lot more memory. Usually a 256 byte page aligned masking table is used to look up the correct mask byte value for any given byte in a sprite (this can also allow for other tricks like flashing a sprite solid white by just using a different masking table).
That makes sense. With the pixels packed into bytes you couldn't easily implement a single-bitplane mask. It explains why the sprites in Head Over Heels don't use all 4 colours, but the backdrops do.

But you don't have to re-use the background (black) as one of the sprite colours. They've retained it because they've simply done a re-colouring of the monochrome Speccy sprites, which need black for outlining. The sprites could be drawn in three distinct colours, though in that case the sprites would have to be drawn solidly in those three colours; any black pixels would be transparent...
0 x

AndyC
Microbot
Posts: 161
Joined: Mon Nov 13, 2017 5:12 am

Re: Amstrad CPC

Post by AndyC » Thu May 17, 2018 6:02 pm

Joefish wrote:
Thu May 17, 2018 10:49 am
AndyC wrote:
Tue May 15, 2018 5:43 pm
The usual way of masking sprites on the CPC is just to treat INK 0 as the transparent colour, giving you three other sprite colours in Mode 1 or 15 in Mode 0. A completely separate mask (as on the Speccy) is usually overkill and requires a lot more memory. Usually a 256 byte page aligned masking table is used to look up the correct mask byte value for any given byte in a sprite (this can also allow for other tricks like flashing a sprite solid white by just using a different masking table).
That makes sense. With the pixels packed into bytes you couldn't easily implement a single-bitplane mask. It explains why the sprites in Head Over Heels don't use all 4 colours, but the backdrops do.

But you don't have to re-use the background (black) as one of the sprite colours. They've retained it because they've simply done a re-colouring of the monochrome Speccy sprites, which need black for outlining. The sprites could be drawn in three distinct colours, though in that case the sprites would have to be drawn solidly in those three colours; any black pixels would be transparent...
There isn't really a "background" colour, per se. As far as the Amstrad hardware goes all colours are equal - it's not like the C64 for example, where one of the palette entries is a special colour across the whole screen.

In the case of Head Over Heels on the Amstrad, it's actually using the second colour in the palette as the transparent colour (which is the one also being used for the "unselected" items/character in the status panel). You are entirely right that they've clearly chosen to just colour in some of the Speccy graphics which isn't strictly necessary. Aside from being quicker form a work perspective, it probably also helps with the "unselected" bit too as that can then be the same graphic data but mapped onto just two colours whilst still looking correct - that would be harder to achieve with a "solid" three colour arrangement.
0 x

Joefish
Manic Miner
Posts: 267
Joined: Tue Nov 14, 2017 10:26 am

Re: Amstrad CPC

Post by Joefish » Fri May 18, 2018 10:46 am

Ah, but is colour index 0 then also the border colour, or is that a separate setting?
One thing that can catch Speccy coders out on moving to the ST or Amiga is that you can no longer set the border colour independently of the screen - it assumes the colour of palette index 0.

It's particularly a problem on the Amiga when you want other scenery layers to show through or sprites to go behind things, then you have to use colour 0 as your see-through background index. Then if you want to do a pretty raster effect on your horizon, the colour changes spill over into the border! One of the stunts you might not realise Shadow of the Beast is doing is redefining colour 0 at the edges of the 'border' from black to sky and back again individually on every line of the display (whilst sneakily lopping 16 pixels off each side). On the ST you just arrange your (software) masking logic to leave a different colour index in the background.
0 x

AndyC
Microbot
Posts: 161
Joined: Mon Nov 13, 2017 5:12 am

Re: Amstrad CPC

Post by AndyC » Fri May 18, 2018 5:34 pm

Nope, the border is a whole different colour entirely.
0 x

Post Reply