Revision as of 15:37, 29 April 2011 (view source) Arnoldemu (Talk | contribs) (→‎Sound) ← Older edit		Revision as of 15:38, 29 April 2011 (view source) Arnoldemu (Talk | contribs) (→‎CPU, RAM and basic Hardware) Newer edit →
Line 72:		Line 72:
	* The Amstrad had function/numeric keys. Only the later Spectrums (+2 and +3) had these.		* The Amstrad had function/numeric keys. Only the later Spectrums (+2 and +3) had these.
		+
		+	* Later Spectrums (+2 and +3) had a RS232/Midi port, the CPC didn't have this. If you wanted this on the CPC, you needed to buy extra hardware.
	====Video====		====Video====

---

Revision as of 15:38, 29 April 2011

A Speccy Port or Spectrum port is the name given to a game which has been converted directly from the Sinclair Spectrum with little or no changes to the Amstrad CPC.

Mostly the Amstrad version ended up fairing worse than the original Spectrum version with the following results:

• Less colours
• Slower gameplay

These facts are not true for all "Spectrum Ports" because some ended up decent.

There is anger from Amstrad users in general, because they feel that if more time had had been taken on the Amstrad version, we could have had a version that used the abilities of the Amstrad better, looked better, perhaps sounded better, and played as well or better than the Spectrum version.

On a more positive tone, those speccy ports had the merit to exist, or else Amstrad may have a smaller games catalogue.

It is worth noting that Spectrum ports also existed on MSX, Enterprise and C64.

Reasons

The ZX Spectrum shared similar hardware with the Amstrad CPC (see Machine comparions).

The Spectrum was very popular and with the CPC having a much smaller market share, it made sense to develop the Spectrum version first and to save on time and money, the Spectrum code, music and graphics were re-used. (A typical port to the Amstrad is said to have been done in 3 days so was financially good).

This phenomenon was more prominent in the UK, where the Speccy was the dominant machine. In other markets, such as France of Spain, where the CPC was very popular, games were coded from scratch for the CPC, often using an Atari ST for Cross Development

Machine comparisons

General

• The Spectrum 48K was released in the UK in 1982. The Amstrad CPC464 was released in the UK in 1984.

• Spectrum 48K sold for £99. The CPC464 with Green Screen monitor sold for £299 and with colour monitor for £399. One selling point was that the Amstrad needed only 1 plug, and that you didn't need to use the family television to use it. Also the Spectrum 48k wasn't supplied with any monitor nor storage device.

• The Spectrum was designed to be used with a television, the Amstrad was designed to be used with and was sold with either a green screen or colour monitor.

• Amstrad's monitors include the powersupply for the Amstrad CPC. A "TV connection + power supply" solution was also available : Amstrad MP1/MP2 modulator

• The Spectrum was sold as a games machine, the Amstrad was sold more as a multi purpose machine (in the UK anyway).

• The Amstrad's BASIC and firmware are said to be better than the Spectrum's BASIC and OS functions.

CPU, RAM and basic Hardware

• Spectrum 48K machine has 48K RAM, approx 6.5k of this is screen. The Amstrad CPC464 and 664 have 64K ram, approx 16K of this is screen.

• Latter Spectrum were supplied with 128K RAM (Spectrum 128, +2 and +3) and Amstrad CPC6128 was supplied with 128K RAM too (same amount of RAM used by Video as earlier machines)

• Spectrum and Amstrad both have a Z80 CPU.

• The CPU runs at a similar speed (3.5Mhz in Spectrum, 4Mhz in Amstrad) (Note, both systems do not run at optimum speed due to waits inserted by the video hardware).

• The Spectrum 48k can't do double buffering in hardware (the later 128K machines can), the Amstrad could from the start. On the Amstrad and Spectrum 128K you can use hardware double buffering, but then you need to sacrific twice as much video ram (e.g. For Amstrad: 2 x 16K).

• The Spectrum has 1 interrupt per 50Hz frame, the Amstrad has 6 in fixed locations through the frame.

• Neither have hardware sprites, therefore you have to use the CPU to both draw and erase the sprites.

• Amstrad has hardware scrolling, Spectrum does not.

• The Spectrum 48 didn't come with a joystick port, you had to buy one. There was two variants, Sinclair and Kempston, thankfully the hardware was cheap and easy to obtain, and both were well supported by software. The Amstrad came with a joystick port built in.

• The original Sinclair ZX Spectrums didn't come with a tape player, you had to buy one. The Amstrad CPC464 had a tape player built in, however neither the CPC664 or CPC6128 had a tape player built in, you had to buy one if you wanted to use tape based software with them.

• Later Amstrad's ZX Spectrums (+2 and +3...) had in-built storage devices as they shared the common Amstrad CPC design.

• Both the Spectrum and Amstrad had to use the CPU for loading or saving on cassette. The Spectrum ROM loader used the border colours to indicate loading (especially the use of striped bars in the border to indicate each data bit) a small block for a header, and then loaded the program with one larger block. The checksum/error detection was done using XOR. The Amstrad's ROM loader used many smaller blocks (so you could rewind if there was an error), it indicated loading progress with text that updated on the display, and used the better CRC for error detection. However, if the loading messages were turned off, you didn't have any indication of loading progress.

• The Spectrum 48K's keyboard was made from rubber, the CPC had a proper keyboard. The later Spectrum's had proper keyboards too.

• The Amstrad had connections for printer, stereo sound output and expansion. It had an internal speaker, with volume control. The Spectrum 48K had connections for tape player, TV aerial and expansion. It had an internal piezo electric buzzer, the volume of which couldn't be controlled.

• The Amstrad could control the cassette motor, turning it on and off under software control to pause loading of software. The Spectrum didn't have this, you had to manually stop and play the tape.

• The Amstrad had function/numeric keys. Only the later Spectrums (+2 and +3) had these.

• Later Spectrums (+2 and +3) had a RS232/Midi port, the CPC didn't have this. If you wanted this on the CPC, you needed to buy extra hardware.

Video

• Spectrum and Amstrad both have a bitmapped display.

• They have a similar screen size. But Amstrad CPC actually produces smaller pixels in it's "equivalent" video mode (mode 1). The normal display resolution on the Amstrad CPC is 320x200 (mode 1) while ZX Spectrum produces "only" 256x192 pixels. Amstrad's screen can be reduced in size to match the Spectrum's (256x192, in Mode1) but then the actual display window is quite smaller as on a spectrum and has a larger border because the pixels are slightly smaller.

• The size and aspect of the pixels in the Spectrum's bitmapped display are comparable to the pixels in Amstrad's mode 1 bitmapped display in that both produce approximately square pixels.

• The Spectrum's video ram takes approx 6K.

• The Amstrad CPC's video ram takes 16K (approx 12K when screen is reduced to Speccie's resolution).

• The Spectrum has a fixed palette of 15 colours (8 colours with bright versions of each making 15 in total - LIGHT black is still black).

• The Amstrad has 3 different Video Modes. Mode 0 is 160x200 with 16 colours, mode 1 is 320x200 with 4 colours, mode 2 is 640x200 with 2 colours. All are bitmapped. The Spectrum only has 1 video mode, 256x192 which is bitmapped.

• Amstrad CPC has a palette of 27 colours. In mode 0 you can choose 16 of these, in mode 1 you can choose 4 of these, in mode 2 you can choose 2 of these. The Amstrad's palette includes equivalent colours that match closely the Spectrum's colours.

• The Spectrum's screen is "attribute" based. Each 8x8 cell can be assigned a background and foreground colour (and both colours must either be non-bright or bright). There is also the choice to flash the colours in each cell (the flash is a fixed rate and alternates between paper/pen and pen/paper). This colouring results in "attribute/colour clash" on the Spectrum. The Amstrad's screen doesn't have this, and there is no restriction on how the colours can be placed.

• The colours of each 8x8 "attribute" cell is defined by a block of ram following the Spectrum's bitmapped screen, each byte represents one cell and each byte defines paper colour, pen colour, flash enabled and bright enabled. The colours for the pens on the Amstrad are defined by writing to the Gate-Array's palette I/O registers. The pens are read from the pixel data and the resulting colour is looked up in the palette registers.

• The Spectrum can display all 15 colours on the screen.. With limitations (2 colours per 8x8pix squares...)

• The Amstrad can only reproduce the attributes and 15 colours at the same time as shown by the Spectrum by using Amstrad's 16 colour mode, mode 0. However, this has wider pixels (approx 2x1 ratio) and a lower horizontal resolution. If the CPC's mode 1 resolution is chosen, it is not possible because only 4 colours can be chosen.

• On the Amstrad the 6 raster interrupts allow palette colours to be changed allowing more than the theorical amount but this is also with limitations. This technique was commonly used in Speccy ports.

• Normally Spectrum graphics is stored in 2 colours, which means 8 pixels for each byte. In Amstrad mode 1, each byte defines 4 pixels. So for the same graphics you often need twice the RAM on the Amstrad. (This is a case where graphics without transparency are used). If transparency is used, then the amount of data can be the same.

• The Amstrad's screen size and position can be reprogrammed, the Spectrum's screen size and position is fixed. It is possible to program the Amstrad's screen to use the entire monitor display area (at the expensive of approx. 22K of video ram being used).

Sound

• Spectrum (128K model and later) and Amstrad both have an AY-3-8912 sound chip. (1.7Mhz clock for AY in spectrum, 1.0Mhz clock for AY in Amstrad).

• Spectrum 48K had a 1-bit beeper sound. Playing sounds through the beeper is very CPU intensive. The Amstrad doesn't have a beeper. The only way to simulate the beeper sound would be to convert it to AY sound.

NOTE: Sinclair Research (the Spectrum's manufacturer) was acquired by Amstrad after the Spectrum 128K had been made.

Amstrad then improved the build quality and enhanced the Spectrum's design. The result was that the Spectrum +2, which was closer in looks and build to the CPC464/6128 (same kind of compact keyboard as CPC6128, but built-in "Datacorder"). The Spectrum +3 was also quite similar to the Amstrad CPC6128 because both had a internal 3" drive. So the Spectrum became closer in design to the CPC. However, the overall hardware of the Spectrum didn't change, the graphics were the same, the sound was the same, but those later Spectrum's had built in joysticks, built in cassette or disc, connections for printer etc, just like the CPC, but almost all of which the Amstrad had starting with the CPC464.

Consequences

Tape Loading

Both the Spectrum and Amstrad had a similar method for loading or saving on cassette. For both it is CPU intensive and for both the method of representing the 1 or 0 bits is the same.

Some CPC games used a modified Spectrum tape loader (extracted from the Spectrum's ROM and modified for the Amstrad's hardware).

Sometimes the Spectrum loader was modified for the CPC without exact knowledge of how it worked, this resulted in some games with bad loaders that either didn't check for errors, or which didn't work in some circumstances. This lead to unreliable loading.

Loaders like this were used in a variety of games, not limited to Speccy Ports.

Two good loaders that appeared on both systems are Alkatraz and Speedlock. Both were reliable and fast.

The Amstrad's ROM loader was a bit better than the Spectrum's ROM loader because it had CRC error checking, compared to XOR, block based loading (so you could rewind and try a block again) compared to a single load.

Consequences for porting to CPC:

• If the loader was modified for CPC without good knowledge the loading would be unreliable. (e.g. errors are not detected, timings are bad, edge detection is dodgy).

• On the good side, the Spectrum utilised the border to indicate both the stage of loading (indicated by different colours used in the border) and the loading progress, so a modified loader for CPC would also indicate loading progress. If messages were turned off in the Amstrad ROM loader you didn't have any indication of loading progress.

Colours

The Spectrum palette (15 colours, bright at bottom):

The Amstrad palette (27 colours):

A comparison of the palettes:

From the comparison you can see that the Amstrad can reproduce the Spectrum's colours well, and then you can see with it's additional colours it can provide extra shades and some colours the Spectrum can't show (e.g. orange).

Consequences for porting to CPC:

• If the game was ported directly using only the Spectrum colours then the Amstrad version would have similar colours, when more appropiate colour's from it's palette could be used.

What they should do for CPC:

• Recolour the graphics using the Amstrad's palette to improve the look.

Colour Clash

The cell based colouring used on the Spectrum has its disadvantages.

When moving a sprite over a background, or a sprite over another sprite, and if both have colours you have to decide which colours take priority.

It is not possible to have all the colours together because of the colour limitation within each 8x8 cell.

This then means that the graphics with a lower priority then takes on the colour of the higher priority graphics.

If a sprite's colours takes priority, and it moves with pixel by pixel movement, as soon as it enters a new cell, the background will take on it's colours. The colour clash seems to extend furthur than the sprite. This is down to the 8x8 cell colouring.

Possible resolutions on Spectrum:

• Remove colour from the display so that background and sprites use the same colours, clash is eliminated.
• Move sprites in cell based movements. The colours still take priority but the clash is less of a problem.
• Add a black border around the sprites. Clash occurs, but because of the border it is not seen.

Consequences for porting to CPC:

• If colour priority, colour clash exists: CPC version has the colour clash simulated which is unnecessary.
• If 2 colours are used and colour clash eliminated: CPC version lacks colour, same as Spectrum
• If cell based movement is done, then CPC version has the same movement whereas it could be pixel perfect on CPC.
• If black border is used, CPC has the unnecessary black border.
• The CPC can't replicate the Spectrum's colour attribute system, this means a game converted to Amstrad's mode 1 has even less colours than the Spectrum version. The CPC version then has 4 colours, compared to up to 15 possible colours on the Spectrum.

What they should do for CPC:

• Recolour the graphics appropiately for the CPC in either mode 1 or mode 0.
• Use the Amstrad interrupts and change the colours multiple times each frame, this will give each region (between each interrupt) it's own colours increasing the number of colours on screen. Each region is 52 scanlines in height, and the whole screen in width. Note that the colours must be set for each region for each frame to maintain them, and that the pixels within each region are still limited to 4 colours in mode 1. The colour regions like this are ideal for having different colours for the HUD and for the main game area.

NOTE: The 6 raster interrupts on the CPC can be used to change the palette. However, while the screen displays 6 colours, the actual games window is still monocolour (2 colours... generally Black+one other ink...) or "almost monocolour (only background being monocolour and sprites having 3 inks... or some inks different from background's tiles...) typical examples are Strider (monocolour tiles and 3 inked sprrites), SuperWonderboy (Monocolour Background and monocolour sprites yet differently inked), PacMania or Black Tiger (monocolour game's window/playfield yet multicoloured HUD...) and so on (see later in this page for more examples).

Sound

There is 1 sound source on 48K spectrums: it's beeper, and 2 sources of sound on 128K spectrums: beeper and AY.

Beeper sound is simple. The spectrum has a speaker which you can turn on/off through a I/O port on the Spectrum's ULA. To make different sounds, you turn it on and off at different rates, all under control of the CPU. Speaker sound is CPU intenstive because the timing is all done through the CPU and delay loops. The consequence on the Spectrum is that not many games have beeper music during the game, and those that do are often staccato like (e.g. Manic Miner) (the game takes some time to update, then some time for sound, and this repeats). If the sound was made for the Spectrum beeper, this would need to be converted to AY sound for the CPC, the result would not be exactly the same.

Sound written for the AY in the Spectrum can't be ported directly because it would be out of tune, this is down to the difference in master clock given to the AY (1.7Mhz on Spectrum, 1.0Mhz on Amstrad). The music would need to be altered. When this is done, the music is almost the same.

It is worth noting that mostly the 128K version of Spectrum games had AY tunes, because the 128K model of the Spectrum is when the AY was introduced.

Consequences for porting to CPC:

• No sound (if beeper only sound and it's not translated)
• Sound out of tune on CPC (if AY sound without some conversion)
• Sound is beeper like and staccato when it could be AY "native"

What they should do for the CPC:

• Compose the tune for CPC
• For AY sounds, convert the music/effects to the CPC's AY master clock so that it is in tune (the tune may loose some of it's accuracy if this is done, especially regarding the hardware envelopes and noise, and this means the sound will not be exactly the same, but is much more acceptable).

Graphics

The Spectrum's graphics use 1 bit per pixel to define them. The colour is then defined by the attribute system.

Each byte therefore represent 8 pixels.

If shading is to be used, a mask is often stored with the pixels. The mask is used to remove or retain (depending on the mask type) pixels on the screen. The sprite is then combined with the screen to make the final result.

Consequences:

• The pixel data and colours are stored in a different way than the CPC, so some conversion must be done before the graphics can be used. Either the graphics are remade, or often converted through some automatic process.

Yet the common mask tecnique for sprites implies that another set of 1bpp sprites is needed for each sprites... totaling 2bpp (bit per pixels...) Amstrad could actually use one ink (colour) to mask sprites, hence the mundane 2bpp mode1 could getSprites masks with almost no extra DATA in RAM (just a few extra routines...).

Full masked games on Spectrum then have the same weight as Amstrad games concerning masked Graphical Data (often the case in monocoloured games or isometric games...)

As a result, games like Head over Heals or HeroQuest (isometric) or Shadow of the beast (2D but masked sprites, and parralax scrolling meaning even some masked background tiles...) could easily get the proper recode of Sprites/Tiles in 2bpp for close to no extra RAM used by DATAs..

Anyway due to "lazyness", some speccy Ported games still use 1bpp masks on CPC (the same as on speccy...) becauyse such ports had to be done in less than 2-3 weeks by a lone coder with no Grapician extras...

Techniques used for Graphics

Graphics with transparency

A common way to do this is to store 1 byte of mask, followed by 1 byte of pixel data, and to repeat this for the width of the sprite.

If we consider a sprite which is 16x16. Each byte contains 8 pixels. 2 bytes would be needed for pixel data and 2 bytes for mask. The total storage space required would be (2+2)*8 = 32 bytes.

Now, if the same representation was used on the Amstrad, and mode 1 was used, the Amstrad would need 2 times the ram space to store the data, because in mode 1 there is half the number of pixels per byte. So, each byte contains 4 pixels. 4 bytes would be needed for pixel data and 4 for mask: (4+4)*8 = 64 bytes.

However, if we sacrific 1 colour, so we have 1 pen for transparency and 3 for sprite colours, then we don't need the mask. The mask is common for all sprites. We still need 4 bytes for the pixel data but the result now is: 4*8 = 32 bytes. The same as the Spectrum.

Therefore, depending on the representation, this would determine how much ram is consumed on the Amstrad.

Real-Time Conversion of Spectrum graphics

A common way to get the Speccy game running on the CPC was to perform real-time conversion of Spectrum graphics.

• Graphics are stored on the Amstrad in the same format as on the Spectrum (2 colour, 1BPP)
• Amstrad's mode 1 is used to maintain the same pixel resolution.
• A routine converts the graphics on-demand, while the game is running, into the form that is displayed for the screen.

Needless to say, this enabled the port without the use of additional graphics artists, so it was cheaper.

Disadvantages:

• This process takes a lot more CPU power compared to the Spectrum version, because in addition to drawing and erasing the sprites, the pixel data must also be converted at the same time.
• This resulted in a slower game.
• Amstrad version had less colours (often as little as 2 colours)

Advantages:

• Pixel data took less RAM compared to storing it in Amstrad's mode 1 form.

Original consequences (under construction)

The Amstrad CPC was one of the best 8-bit computers of its time in terms of graphical capabilities. But those advanced capabilities had an impact on CPU resources. As so many games were ported from the Spectrum, a machine with decidedly lower visual specs, the Amstrad range could hardly benefit from its main advantage while lack of optimization meant that aspects as scroll or playing area fared even worse than the Spectrum versions. You have to remember that Spectrum had less resources taken by Video RAM, so could handle animation or scrolling more easily. It is also a misconception to believe the screen was downsized in those games to gain processor resources. It was only done to use the Speccy graphics more easily, and we can doubt the code was (re-)designed so such a screen reduction would even gain CPU resources.

Interestingly, games in Mode 1 could have been good despite the lack of colours, if only those colours were used properly more often.

Most of them got their graphic totally unchanged, displaying some kind of colour attributes "artifacts", a tell-tale sign of a Speccy port.

On the other hand, as mentioned before, those games weren't always bad. Games with no need of scrolling and with re-coded graphics could actually be good.

The killer-list of the infamous speccy ports

Note: these lists are by no means comprehensive, they just include the most high-profile releases.

Computer originals Hits

(most of them ended up being decent) :

• H.A.T.E
• Highway encounter
• Lotus turbo Esprit challenge
• Fighting Warrior
• Vendetta
• Hard Drivin'
• Way of the Tiger
• Last Ninja2
• Saboteur I
• Saboteur II

The numerous CodeMaster or Hewson games are not listed. Many of them were cheap budget Speccy games to begin with, and were quite well ported or remained good...

Well known franchises

• Scooby Doo
• Thundercats.
• MASK 3 : Venom Strike Back
• Airwolf 2
• Batman: The Caped Crusader

Adult games

• Sabrina
• Samantha fox strip poker.
• Strip poker II

Movie Franchises

• Indianna Jones 3 action game.
• Back to the future 2 (half parts were straight speccyporked)
• Big Trouble In Little China

Arcade hits

• R-Type
• Pac-Mania
• Salamander
• Dragon Breed
• Scramble spirit
• Black Tiger - Black Tiger CPC-Spectrum Comparison
• Strider
• Bionic Commando
• Super Wonderboy
• Double Dragon 3
• Super Hang-On
• Enduro Racer
• Toobin'
• Xybots
• Pit fighter
• Cabal
• Street Fighter
• Karnov

Special Category of Death

• Myth, history in the making (grrrrr).
• Gauntlet 3
• SWIV
• Shadow of the beast
• Midnight resistance

The top list of the speccy ports

All those games are frequently used in 8bit wars style videos and reviews, hence they have served as a counter-argument to the CPC's superior abilities. Those games were well known hits ported on pretty much all computers of their time and therefore constituted the very basis of comparison between most systems of the era.

• Shadow of the beast
• Myth, history in the making
• Gauntlet 3
• SWIV
• R-Type
• PacMania
• Salamander
• Dragon Breed
• Scramble spirit
• Black Tiger
• Strider
• Bionic Commando
• SuperWonderboy
• Double Dragon3
• Super Hang-On
• Enduro Racer
• Toobin
• Xybots
• Pit fighter
• Cabal
• Last Ninja2
• Thundercats.
• Hard Drivin'
• Sabrina
• Samantha fox strip poker.
• Strip Poker II
• Airwolf 2
• Indianna Jones 3 action game.
• Back to the future 2
• Vendetta

The 3 levels of Speccy porting

Of course the level of porting could greatly depend on whatever strategy the programmers/graphists used to port the original Spectrum game.

• A monochrome game could remain monochrome or be recolored for the CPC, or only parts of it (only sprites or Tiles but not both - mostly only sprites.)
• A colored game with design-wise graphics (character based design) could be the exact same yet with even less colours.
• Or Tiles/sprites could simply be completely well re-done/re-drawn, even in Mode 0 sometimes.

Rushed and Lazy

The game is exactly as on the Spectrum, even displaying graphical artifacts as Colour attributes and/or monochrome display for the game's window but not always the HUD, which may even often feature extra colours thanks to Raster colour changes, yet this doesn't really help to see what happens on the game's window.

Also sprites may display Transparency/translucency with background's colour, a typical Spectrum "feature".

Probably achieved by using almost the exact Spectrum code and emulating the Spectrum attributes on the CPC.

Examples :

• PacMania

Typical example, yet it managed to be a nice game despite this. The title screen and HUD shows the color attributes and were almost completely unchanged, yet with less colours on screen than the Speccy version.

Ironically, the game manages to display 6 colours in the 4 colours Mode1 - yet the game's area remains completely monochromatic (coded in 1 bit) and colour attributes artifacts are still present.

• Black Tiger: Same as PacMania
• Super Hang On : graphics Transparency/translucency
• Enduro Racer : same as Super Hang On, even more displayed as Sprites more often cross the different colored parts of the screen (while jumping)
• Bionic Commando : there are even inverted/negative colored sprites
• Sabrina : same as Bionic commando
• Gauntlet 3 : HUD is properly recolored (3 shades) but in-game window is monochrome (1bit coded sprites and tiles)
• R-type : Monochrome background while sprites still are "coloured" as with Colour attributes, hence even featuring less colours than original Spectrum game, while the entire screen still displays more than the only 4 Mode1 colours...(HUD raster trick). This game was done in 3 weeks by only one man, who simply emulated the speccy stuff on CPC. Given that the Spectrum game was a great release the CPC port is not too bad.

Semi-lazy

Well redone graphically, but not always as would actually be needed.

Examples :

• HeroQuest: still has monochrome feeling (2 blue shades being used) while actually being properly 2 bit re-coded. Ditherings use 3-colour gradients instead of the Spectrum's 2, and the grey adds a feeling of more colour.
• Strider has recoloured sprites, displaying no attributes, but Backgrounds remains monochrome, and the game is sluggish (because the CPU must still convert 1bpp graphics into 2bpp), yet the HUD+Raster trick enable a 6 colours displayed on screen and the HUD looks good.
• Shadow of the Beast: No real 3-4 coloured ditherings or even additional colours thanks to dithering the 2 medium colours together in many graphics (exteriors or for many sprites), yet the square Spectrum attributes are not displayed, while the Spectrum version remains monochrome (in game window, not HUD) in order to simply avoid Colour clashes. Would have needed more development time and a real CPC version.

Good Job

Those games are often more to be seen as proper Cross-Dev.

Graphics, despite sharing a common ancestry, are well redone, and take into account the Amstrad power. Sometimes those games are not that well ported, yet their concept and gameplay are such that this is not that important: the game is simply too good to be annoyed by such detail as the use of Mode1, and they were still sufficiently re-done.

• Head over heels

This one was the prime example of what every Spectrum port should have been. Even the C64 version was totally like the Speccy version (monochromatic game's area) while the Amstrad graphics were perfectly recoloured and colour clash was avoided. Also as this games didn't need scrolling the animation was almost as good as in other 8 bit versions, and colour palette often changed inks to actually get a colourful feeling all around.

• Deflektor : example of a good speccy "cross development", thanks to a clever concept. Could perhaps have been better yet the concept of the game makes it a clever port. Details like the Tape version loading parts or the good chiptunes enable a proper CPC experience.
• Switchblade: the GX4000 cartridge version displays extra features such as large vertical ditherings in a lot of Red shades (sky) or PLUS Hardware sprites "patches" as extra coloured tiles. This is more than enough to get a properly coloured feeling.

Some Speccy port "done right" may also use Mode 0 instead of Mode 1. Hence being graphically fully CPC (yet tiles or sprites are still comparable in dimensions). The result may vary from awful (the code is not optimised enough for CPC) great.This can be seen in Space Gun: Mode 0 and even PLUS features, yet the attribute-designed-unmasked sprites remain, in a sluggish game.

Techniques used

Mode1 and screen dimensions

The use of Mode1 enabled the CPC to keeps the same graphics as Spectrum, in appearance only. While the square pixels looks almost the same, the code was completely different. Also, the CPC being set for a 320x200 display instead of a 256x192 display, the pixels are in fact smaller on screen, hence a bigger border was needed for the exact same resolution.

This (the larger border) led to the false argument that this was the CPC resolution and therefore it was inferior to the Spectrum one, although the amount of pixels on the screen is the same.

While some Spanish companies reduced the screen in order to get the game better running in low-spec 464, the infamous speccy ports just ran a reduced screen so the ZX Spectrum's code and graphics could run almost "unchanged".

Monochromatic playfield and Sprite Masks

Having a monochrome playfield on ZX Spectrum is a common way to have no colour clashes - simply because there are no colours to clash! Also, most of those games then had masked sprites. This meant that each set of sprites had another "sprite set" for the mask, being actually 2x1bpp (bit per pixel) sets of data.

Some games coders actually used this to get the Sprites coded in 2bpp and used one of the 4 inks in mode1 to be the mask. This then took up more RAM used by data than the original. As a result some of those speccy ports have sprites in another colour than the background, which is actually better in terms of playability/look.

An example of this is Super wonder boy which could have even used one more colour for the sprites, but didn't.

Needless to say, the Background Tiles and Letter fonts were still in 1bpp converted in real time so the CPU had no rest and such games weren't faster nor that much better looking.

On the other hand, some games, despite having such Masked sprite totaling 2bpp had absolutely no sprite re-code at all (although this could have easily been prevented). Black Tiger is such a case.

Nevertheless, those games had one advantage : the smooth movement of sprites.

Examples :

• Batman: The Caped Crusader

Decently ported, As it use the 2bpp for the sprites in full potential. The sprites use 3 colours and the background 2 colours, including colour the unused by sprites, this make a poor background but the differently coloured sprites enable a better visibility.

• Strider : like Batman: The Caped Crusader... sprites use 3 colours and background 2... the difference in used inks give the sprites some extra visibility.

Strider also features some raster effect to get the HUD with extra colours, yet this certainly slow down the game a bit..

• Super wonderboy (wonderboy2) : poor port... the sprites use only 2 colours while they could actually use 3 with no extra effort but some graphical job.

Yet compaired to spectrum version, the CPC version manage to have the sprite more visible thanks to their different ink.

Masked Backgrounds

Some (rare) games actually used a mask for the Bakcground tiles too. This explains why they could be fully recoded with no notable additional weight for the data. Such games are often Isometric games and are considered among the good speccy ports (or actual Cross-Dev).

Examples :

• Heroquest: the Background tiles are also in 3 colours. Yet there is a really poor use of the mask colour.
• Head over Heels: yet the colours are better used than in Heroquest. If you look carefully, there are 2 kind of "background" elements.
  • Real non-masked Background (floor, walls) which use the full 4 colours,
  • and masked elements such as Sprites, Doors, Platforms... which are 3 colours only.

Unmasked games and CPC colour clashes

This category includes some of the worse examples, since actual Spectrum deficiencies were ported to the CPC.

• Bionic Commando
• Enduro Racer

Attribute based Sprites and Animation

The cell based colouring used on the Spectrum has it's disadvantages.

When moving a sprite over a background, or a sprite over another sprite, and if both have colours you have to decide which colours take priority.

It is not possible to have all the colours together because of the colour limitation within each 8x8 cell.

The problem then comes down to is that the graphics with a lower priority then takes the colour of the higher priority graphics.

Such games had no smooth movement of sprites. The sprite moved "character per character". As such the sprites are unmasked, being not really more than "tile-mapped". This meant the sprites had to actually fill the character tile or there would be artifacts introduced for the unmasked character's corner.

This was a "good" other way to get rid of Attributes Clashes and having actual "colours" on ZX Spectrum. But some speccy ports were then emulating the attribute system, which can be quite bad because CPC in Mode1 has half the colours the Speccy has.

• R-Type
• Space gun: this game was even released for Amstrad PLUS... Although coming very late in the CPC era is not really good and was probably rushed to the release. Yet the Character based engine enabled enormous sprites - but lacked smooth movement. Such a technique was actually used for quite a fair amount of Mode0 games. This is not "Speccy port" but it is good to to mention, as it was a common game design technique for both machines.
• AMC (Astro Marines corps)
• Satan

Rasters

A common cheat was to get some Raster interrupt colour change so you could argue that the game is actually displaying more than 4 colours on screen while being Mode1. This is only to mimic some sort or Raster based Colours attributes yet is actually not a clever move in some way as getting some raster interrupt may take lots of CPU cycles. Also, despite the game displaying more than the allowed colours on screen, the playing area was still monochrome. In the end, all this did was getting the game even slower.

On the other hand this could also be done right:

• Deflektor : Raster done right.
• Strider : Raster done right. (useless but good looking)
• Thundercats : (though there are more playing area colours)
• R-Type
• PacMania
• Black Tiger

Many (if not all) of those games can actually run faster just by getting rid of CPU-wasting rasters.

Providing a game had to deal with 1bpp to 2 bpp conversion, Software Sprites and Scrolling and complicated gameplay, adding some Raster interrupt to the equation is a really bad move and a good way to waste even more CPU time.

Partial code re-use for proper CPC games

Some CPC games are in mode0 yet the similarities with the speccy version are still obvious. Ocean was actually a lot into this, but thanks to a more professional graphic treatment (compared to many other British companies) and actually good porting tactics (though not always the case) this produced some of the finest CPC games.

Those games are examples of Cross-dev done right. They remain quite playable because the CPU doesn't waste time to decipher 1bpp graphics or get Rasters interrupts.

• Robocop
• Chase HQ

Some of the games below were Mode1 but fully supported the 2bpp re-coding of graphics done right (by a human, not by the CPU in real time) hence got properly coloured backgrounds.

• Shadow of the Beast: basically an almost playable Amiga Demo from the start this just turns into a quite good speccy port on CPC.
• Midnight Resistance : some elements such as the projectile sprites (bullets, explosions) are certainly far too big on the CPC to get it smooth and fast enough. Also some animations should have skipped a few frames to lighten the proceedings. But at least this is an example of Mode1 looking good...
• Wec le Mans: excellent CPC version, just a bit on the slow side. Burnin' Rubber is the Plus version of this game, sort of.