Changes
/* Screen dimensions */
On a more positive tone, those speccy ports had the merit to exist, or else Amstrad would have a smaller games catalogue.
It is worth noting that Spectrum ports also existed on [[MSX]], [[Enterprise]] 64/128,[[SAM Coupé]] and non-[[Z80]] [[Thomson]] MO/TO, [[SAM Coupé]] and [[Commodore 64|C64]].
==How these should have looked== This section shows games which were made specifically for the Amstrad's abilities or Spectrum ports that were done correctly. Here are some examples of Amstrad games done well, and how these games could have looked if more care was taken. The following list shows how a game can be done right using the cpc capabilities. These do not necessarily share any Spectrum code, and are not necessarily recoloured from the Spectrum: * Renegade* Gryzor* Xyphoes Fantasy* [[Head Over Heels]] Some CPC games share similarities with the Spectrum version, and probably share a lot of code, yet are in mode 0 (16 colours, lowest resolution). [[Ocean]] made a lot lilke and thanks to a more professional graphic treatment (compared to many other British companies) and actually good porting tactics this produced some of the finest CPC games. Those games are examples: *'''Robocop'''*'''Chase HQ''' Some of the games in the list below use mode 1 but fully supported the 2bpp re-coding of graphics done right (by a human, not by an automatic method) and hence got properly coloured backgrounds and sprites. *'''Shadow of the Beast'''*'''Midnight Resistance'''*'''Wec le Mans''' =Reasonsfor a Spectrum Port=
The [[ZX Spectrum]] shared similar hardware with the Amstrad CPC (see Machine comparisons).
*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.
====Input====
* Spectrum has multiple joystick standards. The common standards are Kempston, Sinclair and Cursor. Kempston was a common interface used on the Sinclair made Spectrum's. It plugged into the back of the machine and provided support for a single joystick. This type of joystick doesn't clash with the keyboard. The Sinclair standard is used on the Amstrad made Spectrums. These machines have two joystick ports. The Sinclair standard works by simulating keys pressed on the Spectrum keyboard. (Does the sinclair joystick cause keyboard clash?) All of these standard for the Spectrum supported the directions and 1 fire button. In comparison the Amstrad CPC models have a single joystick port which with a splitter cable can support two joysticks. The joysticks support the directions and up to 3 fire buttons on the CPC, but only 2 fire buttons on the later Plus machines. In addition using the joysticks and keyboard together on the Amstrad CPC causes keyboard clash where unwanted keys are pressed. Clash between joysticks and keys can be avoided with careful choice of keys. This clash was resolved on the Plus and can be resolved with diodes on the CPC joystick port. In general though, Amstrad games supported a single joystick, they didn't use key mappings that would avoid clash and many users didn't have these fixes so the games would suffer from keyboard clash. An example of this can be seen when playing two player Gauntlet where players could be fighting to move where they wanted to.
* The 48K spectrums had a rubber membrane keyboard, later versions had proper keys, and the Amstrad made Spectrum's have the best keyboards. The early Amstrad CPC464's and 664's had really good strong keyboards, comparable to those on the BBC Micro, whereas later ones were more flat and less good. Both Amstrad and Spectrum have a good selection of keys.
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.
===Disc drive=== The Spectrum didn't have an official floppy disc interface so there were different interfaces.In Russia the Betadisk interface is common, this used a WD1793 disc controller and 3.5" discs. This interface is incompatible with the Amstrad's. When Amstrad designed the +3, the used a similar disc interface to the Amstrad. The Amstrad designed Spectrum +3 has the following in common with the CPC6128:* same disc media (3")* same disc controller (NEC765 compatible)* the floppy controller is polled for data transfer* Similar disc format (CP/M based) However, the Spectrum+3 uses a different DOS than the Amstrad CPC6128. This means that the functions for reading/writing files are different on the Spectrum compared to the CPC. The Spectrum's DOS is more powerful than the CPC's. It can read CPC discs, Spectrum +3 and PCW discs easily. In order for the Amstrad to read Spectrum and PCW discs, it needs to have a special XDPB (Expanded Disc Parameter Block) configuration installed. The Spectrum +3's DOS is based on the disc functions in Locoscript the CPC's DOS is AMSDOS. The Spectrum's DOS was developed after the CPCs, so clearly they saw the weakness in the CPC's DOS design and improved it. The Spectrum Technical wiki can be found here. This describes the Spectrum hardware in more depth: http://scratchpad.wikia.com/wiki/ZX_Spectrum_technical_information ===Consequencesof a Spectrum Port=== ====Input==== The Spectrum has more joystick standards than the CPC, however reading the keyboard and joysticks and handling the input on the Spectrum is much simpler, takes less code and takes less CPU time than on the Amstrad. On the Amstrad it is best to read the keyboard and joystick in one pass and store the data into a buffer which can then be queried later. Then read from this buffer when you need to check the inputs. ====Disc Loading==== The Spectrum +3's disc interface had a design that was close to the Amstrad CPC6128's. This meant that disc loading software that used the disc interface directly could be modified easily to be used on the CPC. There are disc versions of the Alkatraz, Hexagon and Speedlock loaders common to both the CPC and Spectrum. However, the method for accessing the DOS is different. The good thing is that both shared good disc interfaces, so a disc loading system on the Spectrum, if ported to the CPC would not be a bad thing.
====Tape Loading====
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, based checksum and block based loading (so you could rewind and try a block again) compared to a single load.
Consequences for porting to CPC:
[[image:AmstradCPC_palette.png|Amstrad palette (from wikipedia)]]
A comparison of the palettesin CPC palette:
[[image:CPC_Speccy_palette_comparison.png|Comparison of the palettes ]]
* Recolour the graphics using the Amstrad's palette to improve the look.
====Colour Clashfrom the Cell based colouring====
The cell based colouring used on the Spectrum has its disadvantages. [[image:clash.png|right|thumb|Colour clashing in Knight Tyme. Observe the appearance of the character sprite as it merges with the background. (Background colours have priority here in this game.)]]
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.
The 6 raster interrupts on the CPC can be used to change the colours on the screen. You can redefine all the available colours, e.g. each interrupt you could re-program all the 4 available colours in mode 1. This can be done to increase the number of colours visible.
However, while there are more visible colours, each region is still limited to the number of available colours (e.g. limited to 4 colours in mode 1).
If a sprite passes between two raster interrupt regions it will suffer from a form of colour clash, where the part in the new region takes the colours from that region, and the part in the old region remains in the colours from that region.
Various ports use the raster interrupts, but how they chose to use them differs.
'''Possible resolutions on Spectrum:'''
* Peter Pack Rat
====Sound====
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.
* There is a trade off between mode 1, keeping the same resolution as the Spectrum but having only 4 colours, or using mode 0, with half the horizontal resolution but 16 colours. The choice depends on the detail required in the graphics.
The following sections describe possible ways to handle the graphics on the Amstrad.
=====Graphics with transparency=====
======Storage======
A common way to do this is on the Spectrum is to store 1 byte of mask, followed by 1 byte of pixel data, and to repeat this for the width of the sprite divided by 8. (Each byte representing a 8 pixel wide single line slice of the sprite).
If we consider a sprite which is 16x16. Each byte contains 8 pixels. For each line 2 bytes would be needed for pixel data and 2 bytes for mask. The total storage space required would be (2+2)*8 16 = 32 64 bytes.
If we consider mode 1 on the Amstrad, and we used the same representation, we could freely use 4 colours for the sprites. The Amstrad would also 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. For each line 4 bytes would be needed for pixel data and 4 for mask: (4+4)*8 16 = 64 128 bytes.
However, if we sacrifice 1 colour, so we have 1 pen which is fully transparent and 3 for opaque sprite colours then we don't need the mask to be stored this way. The mask is common for all sprites and we could store this as a single 256 byte array. We would still need 4 bytes for the pixel data but the result now is: 4*8 16 = 32 64 bytes. The same weight as the Spectrum.
Mode 2 is generally not used for games on the Amstrad because of it's lack of colour. The pixels in this mode are half as wide as the Spectrum's. If the Spectrum data was used directly, which it could be, then the sprites would be half the width of the Spectrum's. We would still be forced to store mask and pixels In this case the data storage is the same as on the Spectrum, and . If we wanted to maintain the same resolution we would need to double up each pixel, effectively magnifying it in the width by 2. The result would be twice the size of the Spectrum data.
If mode 0 is used, we could either store a mask and byte, as for the Spectrum, or more commonly we use pen 0 for full transparent and leave the other 15 pens to define the sprite. We could then use half the number of pixels horizontally and lower resolution too. Each byte now contains 2 pixels. The sprite is 8x16 now = (8/2)*16 = 64 bytes. So again twice This the same storage sizeas for mode 1. If the size of the sprites were too small, then we would need to increase the size and the storage space.
Therefore, depending on the representation, this would determine how much ram is consumed on the Amstrad.
The best it seems is choices are to go for mode 1, and use a common mask table, with 3 colours per sprite. Or use mode 0, use a common mask table, with 15 colours per sprite. In both cases we use 256 bytes more than the Spectrum equivalent graphics.
======Storage======
=====Real-Time Conversion of Spectrum graphics=====
A common way to get the Speccy game running on the CPC and using the same storage space for the graphics was to perform real-time conversion of from the Spectrum graphics.
* Graphics are stored on the Amstrad in the same format as on the Spectrum (2 colour, 1BPPwith sprites having masks)
* Amstrad's mode 1 is used to maintain the same pixel resolution.
* A routine function 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 . Therefore it was would be cheaperand easier if a programmer was tasked with making a conversion alone.
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 significantly slower game.
* Amstrad version had less colours (often as little as 2 colours)
Advantages:
* Pixel data took less RAM compared to storing than if it was stored in an Amstrad's mode 1 native form, so the game could run on a 64K Ram machine (CPC464 and CPC664, 464Plus).* If the colour attributes of the Spectrum were not simulated then the attribute data would not need to be stored for the CPC.
=====Mode 1 and screen dimensions=====
Amstrad's mode 1 is the closest mode which compares with the Spectrum's graphical abilities.
However, the CPC has a different "pixel clock" compared to the Spectrum. The CPC was designed for a 320x200 display instead of a 256x192 display and in fact the the pixels are smaller on the screen when you compare mode 1 (the closest equivalent on the CPC) to the Spectrum.
So when the screen is reprogrammed, you end up with a larger border on the CPC.
This (the larger border) led to the false argument that the CPC's resolution was inferior to the Spectrum one although the amount of pixels on the screen is EXACTLY the same.
=====Mode 0=====
When using mode 0, the screen can be reprogrammed to use the same sized screen as when using mode 1. However the resolution would be 128x192.
=====Screen dimensions=====
By setting CRTC register settings the Amstrad's screen dimensions can be reprogrammed to match the Spectrum's.
The normal values used are R1=32, R6=24.
There are advantages to reprogramming the screen dimension to match the Spectrum's.
* The gameplay is similar because the player sees the same amount of map and there are the same number of enemies and they move in the same way.* Graphics/levels would not need to be designed for a wider screen (e.g. in mode 1, 320 compared to 256)* For a smaller screen less memory is used for the Amstradscreen (16KB vs 12K). The memory used by the screen is the same regardless of CPC mode used. Unused areas can be used to store graphics, code and music. For a 320x200 CPC screen normally takes 16Kat &c000, but the unused areas are: c600-c7ff, ce00-cfff, d600-d7ff, de00-dfff, e600-e7ff, ee00-efff, f600-f7ff, fe00-ffff =====Random numbers===== Sometimes Spectrum games generated random numbers by reading from the Spectrum ROM which is always readable in the memory range &0000-&3fff. ''Consequences for CPC:''- There is not enough memory to store the Spectrum ROM in the Amstrad's memory therefore the same method can't be used. It may be possible to store a small part of the ROM depending on the memory range read by the program. It is possible to use the CPC's ROM when reduced paged in size but it takes 12K's contents will differ so the random numbers will also differ and therefore the gameplay will be different (although maybe not enough to be an issue). An alternative on the CPC is to use a function to generate a random number - which may result in more CPU instructions compared to the Spectrum random number generation method - or worse read the R register which is not really random enough. =====Double buffering===== TODO: =====Memory arrangement===== Spectrum game's often use the memory from &5500-&ffff. ''Consequences for CPC:''- If you are not using a custom disc or tape loader then during loading you will need to preserve the firmware memory regions. The easiest thing to do is start the game lower in memory (&0040), use the default screen at &c000-&ffff, and then once loaded copy data over these areas (provided you are not doing furthur loading/saving).
====Original consequences (under construction)====
*Pit fighter
*Cabal
*Street Fighter]
*Karnov
*Dynasty Wars
*'''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.
An special mention must go for '''Mevlut "Speccy" Dinc''', one of the worst offenders with nightmares as '''Big Trouble In Little China''', '''Enduro Racer''', '''Hammerfist''', '''Knightmare''', '''Last Ninja 2''', '''Last Ninja 2 Remix''', '''Prodigy''', '''Super Hang-On''' and '''Time Machine'''.
==Semi-lazy==
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'''[[File:Head Over Heels.png]] 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.
=Techniques used=
==Monochromatic playfield and Sprite Masks==
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''' : the background has a smooth scrolling while the sprites are fixed character grid based. The engine was keepted in R-Type128 modern remake.
*'''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.
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 gamesAmstrad interrupt positions==
[[Category: Games| ]][[Category:Programming]][[Category:Games Programming]][[Category:CrossDev]][[Category:CPC History]][[Category:Non CPC Computers]]