Page 1 of 1

Re: Amstrad CPC

Posted: Tue May 15, 2018 2:00 pm
by spectron
Joefish wrote: Tue May 15, 2018 1: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!

Re: Amstrad CPC

Posted: Tue May 15, 2018 6:19 pm
by Joefish
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.

Re: Amstrad CPC

Posted: Tue May 15, 2018 6:43 pm
by AndyC
spectron wrote: Tue May 15, 2018 12:12 pm 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 6: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).

Re: Amstrad CPC

Posted: Wed May 16, 2018 5:24 pm
by 1024MAK
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

Re: Amstrad CPC

Posted: Thu May 17, 2018 11:49 am
by Joefish
AndyC wrote: Tue May 15, 2018 6:43 pmThe 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...

Re: Amstrad CPC

Posted: Thu May 17, 2018 7:02 pm
by AndyC
Joefish wrote: Thu May 17, 2018 11:49 am
AndyC wrote: Tue May 15, 2018 6:43 pmThe 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.

Re: Amstrad CPC

Posted: Fri May 18, 2018 11:46 am
by Joefish
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.

Re: Amstrad CPC

Posted: Fri May 18, 2018 6:34 pm
by AndyC
Nope, the border is a whole different colour entirely.

Re: Amstrad CPC

Posted: Tue Jan 12, 2021 7:37 pm
by PeterJ
I've been playing with the Amstrad CPC over the last few days. I've always had some negativity about it, but thought I would give it another go.

Mode 0, which is the 160 x 200 does have the huge advantage of having the option of having a different colour on each double width pixel (max 16). So multi-colour characters look very nice.

Image

Now, can someone invent a computer with an 8bit feel, with the same advantages as Mode 0, but at 320 x 200 please

Re: Amstrad CPC

Posted: Tue Jan 12, 2021 9:27 pm
by Pegaz
PeterJ wrote: Tue Jan 12, 2021 7:37 pmNow, can someone invent a computer with an 8bit feel, with the same advantages as Mode 0, but at 320 x 200 please
Enterprise and MSX 2 are closest to what you want.
I'm not sure there are stronger 8bit models, in terms of graphics capabilities.

Re: Amstrad CPC

Posted: Tue Jan 12, 2021 10:51 pm
by Matt_B
The SAM Coupe comes pretty close, with 256x192 at 4bpp.

There are a bunch of Japanese machines like the Sharp X1 Turbo, NEC PC88 VA and Fujitsu FM7 AV which can go way beyond that, even. Mind you, they were all around the Amiga in terms of price, so not exactly competing with the regular 8-bit market.

Re: Amstrad CPC

Posted: Wed Jan 13, 2021 8:09 am
by Jbizzel
https://youtu.be/kHH1V-zOlZk

This remake of Rtype for the CPC is astonishing.

The original Rtype spectrum port was a mistake, they should have devoted more time to it.

Re: Amstrad CPC

Posted: Wed Jan 13, 2021 9:16 am
by lovebug
oh my that r-type remake is amazing