CPCWiki - THE Amstrad CPC encyclopedia! - User contributions [en]

KC Compact

2012-12-14T23:12:10Z

Db6128: We didn't revert this when I got it wrong before :P

''Note: Much of this article was originally written by [[Kevin Thacker]] and so any references in the first person ("I", "me", ''etc.'') are by him.

[[Image:Kcc top.jpg|right|thumb|250px|The East German KC Compact Computer]]

== Background ==

The KC compact is a [[Clones|clone]] of the Amstrad CPC and was developed by a East German company called RFT.

The computer was designed in 1989 and made to celebrate 40 years of the DDR/GDR (Deutsche Demokratische Republik/German Democratic Republic). A year later the Berlin wall came down and East and West Germany were joined together and the DDR/GDR came to an end. Production of the computer halted, and it was only available for a short time and is rare.

I read about the KC compact in the Amscene section of Amstrad Action magazine, a Future Publishing Ltd publication. From that point I was hooked and I eventually wanted to own one.

During this time I found Andreas Krueger, webmaster of the Robotron-Net website, who owned one of these computers. Andreas was very helpful and provided photocopies of a manual and the schematics, a dump of the roms, ran some tests for me and more. I want to send him a big thankyou for all the help he gave.

In the last few months (May 2001) I contacted Thomas Tratz who owns a KC Compact. Thomas Tratz runs a great website for QuickBASIC. He has given me many of the original manuals, original software, and I bought a real KC Compact from his cousin! A big thankyou to Thomas and his cousin!

The case of the KC compact is the same as the Robotron BIC A5105, but has different hardware inside. The KC Compact I have does not have a information sticker on the underside, but information for the A5105!

Many of the IC's inside are Russian and clones of other IC's. (The UA880 is a clone of the Zilog Z80, and the U82536 is a clone of the Zilog Z8536).

I know of only a few people who have a real KC Compact (Andreas Kruger, Thomas Tratz, Frank Salmon of Oldbits computer collection and myself), if there are others please contact me and I will make a list of KC Compact owners, and you will be members of an exclusive club! :)

This document will describe the hardware and software differences (that are known) between this system and the Amstrad CPC.

== Alternative power supply ==

With the help of Darren Jarvis I now have a new power supply for my KC Compact. He gave me a power pack from a PC laptop, and with a special lead, this works perfectly on the KC Compact.

PC laptop power pack details:

LISHIN INTERNATIONAL ENTERPRISE CORP. AC ADAPTOR.

MODEL: LSE9802A1960

INPUT: 100-240V A.C. 50/60Hz 1.5A

OUTPUT: 19V D.C. 3.16A. 60W MAX

The power pack has a 3.5mm power plug at the end.

I made a lead which has a 3.5mm power socket and a telefunktion socket.

== External power supply ==

The official external power modulator provides +20V,-20V DC (err... more probably +20V and 0V) with 500mA (believed to be un-smoothed), from a source of ~220V at 50Hz.

The external power modulator is connected to the computer's internal power modulator, which generates a smoothed 12V and 5V outputs and these provide the power for the IC's. Most or all runs at 5V. The 12V are used for the built-in TV modulator, and is also output to the Expansion Port and Scart connector (and, not sure, maybe used elsewhere, too)

The internal power supply is very tolerant and the computer will run with input voltages as low as 6V, but the colours in the palette are weak. If the voltage is increased, the colours become strong, and around 18V-20V, they are all correct. If a low input voltage is used, it is likely that the 12V power output on the expansion connector will not be correct.

The connector is believed to be a Telefunken Line socket (Maplins catalogue reference: FT99H). If you can't find this connector then you can make a suitable connector using a power lead and a sharp craft knife.

== Software differences ==

The base system has 32k of

* Locomotive BASIC v1.1 rom (identical to BASIC rom in English CPC6128) (16k)
* A modified operating system rom from an English CPC6128 (16k)

* Differences are:

:* Different start-up message
:* Computer names (Schneider, Awa, Solavox etc) removed.
:* Initialisation code for the CIO (see details below)
:* Test program transfer (see details below)

I believe most software will run, but I have not been able to test this, but programs that use the following may be broken:

* Programs that rely on exact Interrupt mechanism of the CPC6128
* Programs that call direct into the operating system rom (these may work, because the changes to the operating system rom are minor)
* Programs that rely on a unofficial hardware feature (I do not know of all hardware details, so I cannot say the level of compatibility)

The disc interface has a modified AMSDOS rom.

== Hardware differences ==

* The colour palette is not cleared to black on reset
* The Amstrad unofficial mode (bit 1=bit 0=1 of [[Gate Array]] mode register) does not exist. The clock to the shift registers is stopped. The last colour is output.
* The raster interrupt is generated in a different way by the CIO.

This section describes the known hardware differences. This information is not definitive. I do not know all differences,

== UA880 CPU (equivalent to Zilog Z80) ==

The KC compact uses a UA880 CPU, which is a Russian clone of the [[Z80]]. It is not confirmed whether there are any actual differences compared to a real Z80. In terms of documentation, the KC Compact System Handbook lists the opcodes SLL, INF [a.k.a. IN F,(C)], and OUTF [a.k.a. OUT (C),F], whereas these have remained undocumented by Zilog.

== Video ==

* The [[CRTC]] should be more or less same as those used in CPCs. The handbook and schematic say the CRTC is a CM 607, but the CRTC in mine [=Kevin's] is an HD6845P.
* The clocks for each mode (0,1 and 2) are derived from the main 16Mhz clock, these then drive the shift registers to output pixels to the display.
* Mode 3 is hardwired to 5V, so it doesn't have a clock. The shift registers are stopped and output the last colour they clocked in. Even if this mode was activated in way of connecting up the clock for Mode 0 it is not decoded the same as on the CPC: 8 colours are chosen from the 16 colour palette, instead of 4.
* There may be a bug whereby if the border colour is changed rapidly there could be 1 pixel of another colour output. When loading a game which changes the colour of the border, I have seen moving "snow" on the screen. I have seen this effect, but I need to confirm how it is generated.
* The video output doesn't generate luminance, so the KC Compact can't be used with a GT64 or MM14.

== Colour-ROM ==

The KC compact has a colour-rom. Each byte in the ROM defines the R,G and B of an output colour.

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Bit''||''Function''
|-
|7||not used''
|-
|6||not used''
|-
|5||Green''
|-
|4||Green''
|-
|3||Red''
|-
|2||Red''
|-
|1||Blue''
|-
|0||Blue''
|-
|}

The hardware colour index (defined by the I/O write: A15="0", A14="1", D7="0", D6="1" D3-D0 define hardware colour index), is used as a look-up into the ROM.

Each colour-element (R, G or B) is defined using 2 bits and has the potential to define a total palette of 64 colours. The colour-rom only uses 3 of the 4 possible settings for each colour-element. Looking at the schematic, the potential is not realised, the two signals for each colour use the same resistors before being combined. This means that the bit combinations 10 and 01 produce the same result. So this means only 27 colours are possible.

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Element Bit 1''||''Element Bit 0''||Intensity''
|-
|0||0||Zero''
|-
|0||1||Half (same as 10)''
|-
|1||0||Half (same as 01)''
|-
|1||1||Full''
|-
|}

The colour ROM can be downloaded from the KC-Klub homepage.

== External connectors ==

=== Built-in connectors: pinout ===

* [[Connector:Cassette recorder|Cassette recorder]] - other pinout as CPC, motor control is TTL (not a relay)
* [[Connector:Digital joystick|Digital joystick]] - exactly as CPC (all 9 pins are exactly same)
* [[Connector:Expansion port|Expansion port]] - almost same as CPC (plus some extra pins: additional voltages, TEST feature, FBAS output)
* [[Connector:Monitor|Monitor]] - 21pin Scart connector, and UHF modulator
* [[Connector:Printer port|Printer port]] - almost same as CPC Plus (25pin)
* [[Connector:Stereo sound|Stereo sound]] - 5pin DIN (not 3.5mm)

=== Cassette socket ===

The Cassette socket has different connection assignments compared to the CPC, so you can't use a CPC cassette lead directly with the KC Compact.

I made a second lead which converted between KC Compact assignments and CPC assignments, which was connected between KC Compact and the CPC cassette lead.

I have been successfully loaded some CPC software.

=== Expansion socket ===

The KC compact has a real connector compared to the P.C.B. edge connector of an English CPC6128. The connector appears to be a PC Card connector. This connector is not the same as the one on a German CPC6128.

The expansion connector has more pins; 58 compared to 50 on an English CPC6128.

I am in the process of making an adaptor so that I can test CPC hardware on the KC Compact.

=== Parallel ===

On the KC compact the parallel port is connected to Port A of the CIO.

It is a general purpose I/O port. All 8-bits can be used for input or output. The input/output of each bit can be programmed. With standard setup, bit 7 is assigned to /STROBE, and bits 0-6 are assigned to Printer DATA, making a 7-bit printer port. Additionally, the 8th printer bit is implemented via Bit5 of PIO Port C (see [[8bit Printer Ports]]).

* The Amstrad CPC has a single-direction, 7-bit port.
* The KC Compact has a bi-directional, 8-bit port.

The KC compact parallel port is more powerful and flexible compared to the Amstrad CPC parallel port!

=== Keyboard ===

* The keyboard matrix of the KC compact supports all the keys of the CPC, but the following keys are not on the keyboard: F5, F6,F7,F8,F9.
* The KC Compact has a power LED (near CLR key). There are also (unused) locations for two additional LEDs (near TAB/CAPS key), eventually these locations are used by the D005 keyboard for KC-85 computers, or by the Robotron A5105 computer (both D005 and A5105 use the same case & keyboard as the KC Compact, aside from that, they have nothing to do with it).

== KP580BB55 PIO (equivalent to 8255 PPI) ==

Used (almost) identically as the CPC's [[8255]]. PIO Port B is slightly different:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|7||Cassette data read (identical to CPC)
|-
|6||Centronics/Printer Busy (identical to CPC)
|-
|5||/EXP (identical to CPC)
|-
|4||1 (+5v) (would be LK4 screen refresh rate in CPC) (but isn't like so in KC Compact?)
|-
|3||1 (+5v) (would be LK3 manufacturer ID in CPC)
|-
|2||0 (0v) (would be LK2 manufacturer ID in CPC)
|-
|1||/TEST (would be LK1 manufacturer ID in CPC)
|-
|0||VSYNC (identical to CPC)
|-
|}

* Note: The KC System Handbook accidently calls the chip "KP580B55", however, the correct name is "KP580BB55" (with double "B").

== U82536 CIO (equivalent to Zilog Z8536 CIO) ==

* [[CIO Overview]]
* [[CIO Usage in KC Compact]]
* [[CIO Registers (Summary)]]
* [[CIO Registers (Detailed)]]

The CIO chip is a Counter and I/O chip. In the KC compact system it is used to generate interrupts, access to the parallel printer port, and possibly video control.

When A12 of the I/O address is "0", the CIO is selected. Bit A9 and A8 of the I/O address select the registers of the CIO,
to avoid conflict with other peripherals the CIO should be access using:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Port''||''A9''||''A8''||''Register''||''Usage in KC Compact''
|-
|&ECxx||0||0||Port B data register||setup as timer and is connected to the video hardware (?)
|-
|&EDxx||0||1||Port C data register||setup as timer and is connected to the Interrupt hardware
|-
|&EExx||1||0||Control register||control
|-
|&EFxx||1||1||Port A data register||setup as I/O and is connected to the parallel printer port
|-
|}

* Note: A8 is passed through an inverter, resulting in the above "B,C,Control,A" ordering - this is done to map Port A to the same address as the CPC Printer Port (without the inverter, CIO registers would have "C,B,A,Control" ordering).

On start-up, the KC compact programs the CIO to the following state:

* Port A: I/O mode: all bits are set to output, and bit 7 is inverted when writing. (bit 7 is /strobe signal to printer)
* Port B: Counter mode (port B is split into two counters, both are setup the same): continuous count, restarts when count is over, uses external trigger, uses external input to update count, pulse output (when count is over)

* Port C: Counter mode: same configuration as port B.

Port C is used to generate interrupts. The counter input is HSYNC (the counter counts counter-input transitions; low-high and high-low). The trigger input is VSYV (this signal is derived from VSYNC).

What this means:

* The CIO Port C counter is updated when HSYNC changes state
* The CIO Port C counter is reset when VSYV changes state

With the default settings, the CIO will count 26 HSYNC transitions (52 lines of the display covered in this time) and generate a interrupt. At VSYNC the counter is reset so that the interrupts are synchronised.

I do not know the exact function of the counter's of Port B.

CPC Interrupts:

* synchronised to 2 HSYNCs after VSYNC
* interrupts cannot be generated closer than 32 lines
* counter inside Gate Array counts up to 52 lines.
* interrupt can be cleared by writing to bit 4 of Mode/ROM register in Gate Array (counter is also reset at this time)

KC compact interrupts:

* interrupt can be cleared by writing to bit 4 of Mode/ROM register at 0x07fxx (counter is *not* reset at this time)
* interrupt system fully programmable: can count HSYNCS, or count internal CIO clocks!

Therefore, the KC compact interrupt system is more powerful than the CPC!

== TEST feature ==

When the KC compact is reset, the /TEST signal on the expansion port is checked.

If it is high (1), the operating system will startup and BASIC will be entered. If it is low (0), the KC compact will enter a data transfer sequence using DATA2, DATA1, /STROBE and DATA7 on the expansion connector.

Data transfer:

The data transfer is controlled by another computer, the KC compact is the "slave".

Using DATA2, DATA1, /STROBE and DATA7, a program of 256 bytes in size can be transfered into KC compact memory at &a880. When all bytes have been transfered, this program will be executed.

KCC Side:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Synchronisation stage (Data transfer begin)''||''/STROBE must read as "1"!! wait for DATA1 to change from "1" to "0"''
|-
|Synchronisation Acknowledge stage||write 0x0f: DATA2="1", DATA7="0"''
|-
|Data transfer stage (repeat for 256 bytes)||Data byte transfer||repeat 8 times (once for each data bit) * write 0x0ff: DATA2="1",DATA7="1", and wait for /STROBE to read as "1" * read inputs: DATA1=data bit
|-
|||Data byte acknowledge stage||write: 0x0f0: DATA2="0", DATA7="1", and wait for /STROBE to read as "1"
|-
|}

* /STROBE and DATA1 are inputs
* DATA2 and DATA7 are outputs

== Connecting a KC compact to a CPC+ monitor ==

These connections are known to work!

What you need:

* SCART plug
* 8-pin DIN socket

Lead connections:

* Connect the 8-pin DIN socket to the 8-pin DIN plug from the monitor
* Connect the SCART plug to the SCART socket on the back of the KC Compact

Signal connections:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''pin number on SCART plug''||''pin number on CPC+ monitor socket''
|-
|19 (Composite Video Output)||1 (Composite Sync)
|-
|17 (Video Ground)||8 (GND)
|-
|15 (Analogue Red)||4 (Red)
|-
|11 (Analogue Green)||2 (Green)
|-
|7 (Analogue Blue)||5 (Blue)
|-
|}

== Pictures ==

<gallery caption="KC Compact Pictures">
Image:Kcc top2.jpg|Top (with UHF cable)
Image:Kcc top.jpg|Top (Keyboard)
Image:Kcc open.jpg|Top (removed)
Image:Kcc pcb.jpg|Top (PCB)
Image:Kcc left.jpg|Left
Image:Kcc rigt.jpg|Right
Image:Kcc pjs.jpg|Right (Power, Joystick, Sound)
Image:Kcc labl.jpg|Sticker for Robotron K1505 computer (accidently badged on a KC computer)
Image:Kcc back.jpg|Rear
Image:Kcc pt.jpg|Rear (left: Power, Tape, UHF)
Image:Kcc asp.jpg|Rear (middle: UHF, Scart, Printer)
Image:Kcc exp.jpg|Rear (right: Expansion)
Image:Kcc lead.jpg|Aerial lead connector (UHF)
Image:KCC with power supply.jpg|Computer with Power Supply
Image:KCC boxed1.jpg|Boxed (closed)
Image:KCC boxed2.jpg|Boxed (open)
Image:Adcompa.jpg|KC Compact advert
Image:Kcc bright top.jpg|Top
Image:Kcc bright right.jpg|Right
Image:Kcc bright back.jpg|Rear
Image:Kcc base left.jpg|Base Left
Image:Kcc base right.jpg|Base Right
Image:Deepfb keyb size kcc.jpg|Dimensions
Image:KCCompact_PCB_Top.jpg|PCB Top
Image:KCCompact_PCB_Bottom.jpg|PCB Bottom
Image:KCCompact_Keyboard_Top.jpg|Keyboard Top
Image:KCCompact_Keyboard_Bottom.jpg|Keyboard bottom
</gallery>

== Datasheets ==

* [[Media:CIO-Z8536.pdf]] - Zilog Z8536 CIO Datasheet (equivalent to U82536)
* [[Media:PPI M5L8255AP-5.pdf]] - Mitsubishi 8255 PPI Datasheet (equivalent to KP580BB55)

== KC Compact Hardware Manuals (german) ==

* [[Media:Kcc Beschreibung.pdf]] - Technical Data and Pin-Outs
* [[Media:Kcc Basic Handbuch.pdf]] - Basic Handbook
* [[Media:Kcc Systemhandbuch.pdf]] - System Handbook
* [[Media:Kcc Floppy System Handbuch.pdf]] - Floppy Handbook

== KC Compact Cassette Manuals (german) ==

* [[Media:Kcc kassette CC4001 Demokcc.pdf]] - Demonstration (Demo1, Demo2)
* [[Media:Kcc kassette CC6001 Spielebox1.pdf]] - Gamebox 1 (Strolch, Roessel, Match)
* [[Media:Kcc kassette CC6002 Spielebox2.pdf]] - Gamebox 2 (Orgel, Konzert)
* [[Media:Kcc kassette CC6003 Spielebox3.pdf]] - Gamebox 3 (Fruity Frank, Memory)
* ... Gamebox 4 (?)
* [[Media:Kcc kassette CC6005 Spielebox5.pdf]] - Gamebox 5 (Cubit, Muehle, Pagode)
* [[Media:Kcc kassette CC7001 Komponist.pdf]] - Composer (Komponi.bas, Fughette.mus, Menuett.mus, Gedanken.mus, Muslink.bas)
* [[Media:Kcc kassette CC7002 Grafix1.pdf]] - Graphic (Grafik1, BspMode0.mal, BspMode1.mal)

== KC Compact Schematics ==

<gallery>
File:Kcc schematic cpu io.gif|CPU and I/O Schematic
File:Kcc schematic memory.gif|Memory Schematic
File:Kcc schematic modulator.gif|Modulator Schematic
File:Kcc schematic video power.gif|Video and Power Schematic
File:Kcc block diagram.gif|Block Diagram
File:Kcc component map mainboard.gif|Component Map (Mainboard)
File:Kcc component map modulator.gif|Component Map (Modulator)
</gallery>

For schematics at higher resolution, see
Schematic (Modulator):[[Media:Kcc schem1.png|hires]],
Block Diagram (Mainboard):[[Media:Kcc schem2.png|hires]],
Component Map (Modulator):[[Media:Kcc schem3.png|hires]],
Schematic (CPU and I/O):[[Media:Kcc schem4l.png|left]] and [[Media:Kcc schem4r.png|right]],
Schematic (Memory):[[Media:Kcc schem5l.png|left]] and [[Media:Kcc schem5r.png|right]],
Schematic (Video and Power):[[Media:Kcc schem6l.png|left]] and [[Media:Kcc schem6r.png|right]],
Component Map (Mainboard):[[Media:Kcc schem7l.png|left]] and [[Media:Kcc schem7r.png|right]].

== Operating systems ==

* [[AMSDOS#BASDOS|BASDOS]] - AMSDOS clone
* [[CP/M#MicroDOS|MicroDOS]] - CP/M clone

== KC Compact Computer Resources and Links ==

* [[KC Compact Advert]] - KC Compact Advertising (with english translation)
* [[Clones|CPC Clones]] - List of all known CPC clones
* http://www.robotrontechnik.de/ - Retro site for east-german computers
* http://www.robotron-net.de/ - Retro site for east-german computers
* http://www.iee.et.tu-dresden.de/~kc-club/index.html - Retro site for east-german computers
* http://www.sax.de/~zander/index2h.html - KC Compact is found in the "Hobby" section

[[Category:Non CPC Computers]][[Category:Clones]]

Programming:Filling memory with a byte

2012-12-14T17:52:11Z

Db6128: /* Using the stack */

==Using LDIR==

From the '''The Unofficial Amstrad WWW Resource'''

<pre>
;; This code snippet will show one method to fill a block
;; of memory with a single data byte using Z80 assembly
;; language.

;;--------------------------------------------------

;; HL = start address of block
ld hl,&4000

;; DE = HL + 1
ld e,l
ld d,h
inc de

;; initialise first byte of block
;; with data byte (&00)
ld (hl),&00

;; BC = length of block in bytes
;; HL+BC-1 = end address of block

ld bc,&4000

;; fill memory
ldir

;;--------------------------------------------------

;; For each iteration of the LDIR command:
;;
;; 1. This command will copy the byte from the memory
;; address pointed to by HL to the memory address pointed to by DE.
;; i.e. (DE) = (HL).
;; 2. Then HL and DE will be incremented. BC will be decremented.
;;
;;
;; For the first byte:
;;
;; HL = start
;; DE = start+1
;; BC = length
;; (HL)=0
;;
;; For the second byte:
;;
;; HL = start + 1 (initialised to 0 by the previous iteration)
;; DE = start + 2
;; BC = length - 1
;;
;; For the third byte:
;;
;; HL = start + 2 (initialised to 0 by the previous iteration)
;; DE = start + 3
;; BC = length - 2
;;
;; etc....
</pre>

==Using the stack==

This method write bytes at a considerably faster rate by exploiting the speed of the stack pointer (SP) moving through RAM and its 2-byte steps. It is especially good for very rapidly clearing the screen.--[[User:Db6128|Db6128]] ([[User talk:Db6128|talk]]) 06:29, 13 December 2012 (EET)

<pre>
; Save the stack pointer
ld (SAVE_SP),sp ; Only remove if you're sure you don't need the stack
ld sp,FINAL_ADDRESS+1 ; e.g. to fill from &C000 to &FFFF (&4000 bytes), set SP to &FFFF+1 = &0000

; Define the region of RAM to be filled
ld hl,YOUR_BYTE_1*&100 + YOUR_BYTE_2 ; Use HL or whichever 16-bit register you prefer
ld de,LENGTH_TO_FILL/2 ; divided by 2 because DE is 2 bytes wide and PUSH pushes both

; Set up a fast 16-bit loop counter
dec de ; This method takes advantage of the fact that DJNZ leaves B as 0, which subsequent DJNZs see as 256
ld b,e ; B = (length/2) MOD 256, so 0 = a 512-byte block
inc b ; D = the number of 512-byte blocks to write, or just = 1 if the length is <512
inc d ; Of course, if you know the length ahead of run-time, you can set B and D directly in your ASM

; Fill the memory
PUSHLOOP:
push hl ; Writes HL to (SP-2) and DECs SP by 2.
; For even more speed, use multiple PUSH HLs in a row (I like 8, = &10 bytes) and adjust counters to match
djnz PUSHLOOP
dec d
jr nz,PUSHLOOP

; Restore the stack pointer
SAVE_SP equ $+1
ld SP,&9999 ; &9999 will be replaced by the actual previous value
</pre>

[[Category:Programming]]

Programming:Filling memory with a byte

2012-12-14T01:02:03Z

Db6128: /* Using the stack */ DErp

==Using LDIR==

From the '''The Unofficial Amstrad WWW Resource'''

<pre>
;; This code snippet will show one method to fill a block
;; of memory with a single data byte using Z80 assembly
;; language.

;;--------------------------------------------------

;; HL = start address of block
ld hl,&4000

;; DE = HL + 1
ld e,l
ld d,h
inc de

;; initialise first byte of block
;; with data byte (&00)
ld (hl),&00

;; BC = length of block in bytes
;; HL+BC-1 = end address of block

ld bc,&4000

;; fill memory
ldir

;;--------------------------------------------------

;; For each iteration of the LDIR command:
;;
;; 1. This command will copy the byte from the memory
;; address pointed to by HL to the memory address pointed to by DE.
;; i.e. (DE) = (HL).
;; 2. Then HL and DE will be incremented. BC will be decremented.
;;
;;
;; For the first byte:
;;
;; HL = start
;; DE = start+1
;; BC = length
;; (HL)=0
;;
;; For the second byte:
;;
;; HL = start + 1 (initialised to 0 by the previous iteration)
;; DE = start + 2
;; BC = length - 1
;;
;; For the third byte:
;;
;; HL = start + 2 (initialised to 0 by the previous iteration)
;; DE = start + 3
;; BC = length - 2
;;
;; etc....
</pre>

==Using the stack==

This method write bytes at a considerably faster rate by exploiting the speed of the stack pointer (SP) moving through RAM and its 2-byte steps. It is especially good for very rapidly clearing the screen.--[[User:Db6128|Db6128]] ([[User talk:Db6128|talk]]) 06:29, 13 December 2012 (EET)

<pre>
; Save the stack pointer
ld (SAVE_SP),sp ; Only remove if you're sure you don't need the stack
ld sp,FINAL_ADDRESS+1 ; e.g. to fill from &C000 to &FFFF (&4000 bytes), set SP to &FFFF+1 = &0000

; Define the region of RAM to be filled
ld h,YOUR_BYTE ; Use HL or whichever 16-bit register you prefer
ld l,YOUR_BYTE ; For 0, you can save 1 byte of memory by instead using XOR A:LD H,A:LD L,A
ld de,LENGTH_TO_FILL/2 ; divided by 2 because DE is 2 bytes wide and PUSH pushes both

; Set up a fast 16-bit loop counter
dec de ; This method takes advantage of the fact that DJNZ leaves B as 0, which subsequent DJNZs see as 256
ld b,e ; B = (length/2) MOD 256, so 0 = a 512-byte block
inc b ; D = the number of 512-byte blocks to write, or just = 1 if the length is <512
inc d ; Of course, if you know the length ahead of run-time, you can set B and D directly in your ASM

; Fill the memory
PUSHLOOP:
push hl ; Writes HL to (SP-2) and DECs SP by 2.
; For even more speed, use multiple PUSH HLs in a row (I like 8, = &10 bytes) and adjust counters to match
djnz PUSHLOOP
dec d
jr nz,PUSHLOOP

; Restore the stack pointer
SAVE_SP equ $+1
ld SP,&9999 ; &9999 will be replaced by the actual previous value
</pre>

[[Category:Programming]]

Programming:Filling memory with a byte

2012-12-13T04:29:00Z

Db6128: adding SP-based method

==Using LDIR==

From the '''The Unofficial Amstrad WWW Resource'''

<pre>
;; This code snippet will show one method to fill a block
;; of memory with a single data byte using Z80 assembly
;; language.

;;--------------------------------------------------

;; HL = start address of block
ld hl,&4000

;; DE = HL + 1
ld e,l
ld d,h
inc de

;; initialise first byte of block
;; with data byte (&00)
ld (hl),&00

;; BC = length of block in bytes
;; HL+BC-1 = end address of block

ld bc,&4000

;; fill memory
ldir

;;--------------------------------------------------

;; For each iteration of the LDIR command:
;;
;; 1. This command will copy the byte from the memory
;; address pointed to by HL to the memory address pointed to by DE.
;; i.e. (DE) = (HL).
;; 2. Then HL and DE will be incremented. BC will be decremented.
;;
;;
;; For the first byte:
;;
;; HL = start
;; DE = start+1
;; BC = length
;; (HL)=0
;;
;; For the second byte:
;;
;; HL = start + 1 (initialised to 0 by the previous iteration)
;; DE = start + 2
;; BC = length - 1
;;
;; For the third byte:
;;
;; HL = start + 2 (initialised to 0 by the previous iteration)
;; DE = start + 3
;; BC = length - 2
;;
;; etc....
</pre>

==Using the stack==

This method write bytes at a considerably faster rate by exploiting the speed of the stack pointer (SP) moving through RAM and its 2-byte steps. It is especially good for very rapidly clearing the screen.--[[User:Db6128|Db6128]] ([[User talk:Db6128|talk]]) 06:29, 13 December 2012 (EET)

<pre>
; Save the stack pointer
ld (SAVE_SP),sp ; Only remove if you're sure you don't need the stack
ld sp,FINAL_ADDRESS+1 ; e.g. to fill from &C000 to &FFFF (&4000 bytes), set SP to &FFFF+1 = &0000

; Define the region of RAM to be filled
ld h,YOUR_BYTE ; Use HL or whichever 16-bit register you prefer
ld l,YOUR_BYTE ; For 0, you can save 1 byte of memory by instead using XOR A:LD H,A:LD L,A
ld de,LENGTH_TO_FILL/2 ; divided by 2 because DE is 2 bytes wide and PUSH pushes both

; Set up a fast 16-bit loop counter
dec de ; This method takes advantage of the fact that DJNZ leaves B as 0, which subsequent DJNZs see as 256
ld b,e ; B = (length/2) MOD 256, so 0 = a 512-byte block
inc b ; D = the number of 512-byte blocks to write, or just = 1 if the length is <512
inc d ; Of course, if you know the length ahead of run-time, you can set B and D directly in your ASM

; Fill the memory
PUSHLOOP:
push hl ; Writes DE to (SP-2) and DECs SP by 2.
; For even more speed, use multiple PUSH HLs in a row (I like 8, = &10 bytes) and adjust counters to match
djnz PUSHLOOP
dec d
jr nz,PUSHLOOP

; Restore the stack pointer
SAVE_SP equ $+1
ld SP,&9999 ; &9999 will be replaced by the actual previous value
</pre>

[[Category:Programming]]

Z80 - undocumented opcodes

2012-12-10T07:25:17Z

Db6128: /* CB prefix */ removing one bit I wrote as I'm pretty sure it's nonsense and SLA works fine

The [[Z80|Z80]] CPU contains several undocumented opcodes, which can be quite helpful sometimes. The most useful undocumented opcodes are probably these ones, which split up the 16bit index registers IX and IY in 8bit registers called IXL,IXH,IYL and IYH.

Please note, that many Z80 successors like the Z180 are NOT able to execute some of the following opcodes properly.

This is just an overview. Parts of this article have been copied from the [http://www.myquest.nl/z80undocumented/ "The Undocumented Z80 Documented"] originally by Sean Young and currently maintained by Jan Wilmans, which is one of the most comprehensive descriptions around.

== CB prefix ==

Of the 247 opcodes that use the prefix &CB, the block &CB &30 to &CB &37 is undocumented officially. These commands shift the operand register left and set its lowest bit to 1.

This is in contrast to SRL (Shift Right Logical), which shifts right and clears the highest bit. Some believe these opcodes were supposed to be Shift Left Logical but that the setting of the lowest bit represents a bug in the Z80, claiming this is why the opcodes are undocumented. Others call the opcodes SLIA, for Shift Left Inverted Arithmetic.

Regardless of the story behind this operation, its effective result is ''register'' = (''register'' * 2) + 1, something that does have its uses and has been employed in various programming contexts for that reason.

<pre>CB30 SLL B
CB31 SLL C
CB32 SLL D
CB33 SLL E
CB34 SLL H
CB35 SLL L
CB36 SLL (HL)
CB37 SLL A
</pre>

== DD and FD prefixes ==

The &DD or &FD prefixes are documented as causing operations using the 16-bit register HL to instead work with either of the 16-bit indexing registers IX or IY; if the operations access a memory location (''i.e.'' normally LD A,(HL), ''etc.''), the opcodes must additionally include an extra byte that specifies a signed displacement (-128 to +127) from IX/IY.

However, Zilog have not documented the fact that these prefixes also affect opcodes that usually refer to the 8-bit components of HL, ''i.e.'' H and L. Thus, one gains access to the additional registers IXH, IXL, IYH, and IYL, for almost all commands that normally use H or L. It is even possible to do things like LD IXH,IXL (although you cannot combine IX and IY in the same instruction, for obvious reasons). These registers can be useful in routines that must process and/or store a lot of numbers. Thankfully, they are not as slow as their 16-bit counterparts: whereas access to (IX+d) is usually slower by 3 NOPs than the equivalent operation upon (HL), using the 8-bit components is (like PUSH IX, ''etc.'') only 1 NOP slower, and this is only due to the need to parse the prefixing byte.

<pre>DB #DD:LD H,A -> LD IXH,A
DB #FD:LD B,L -> LD B,IYL
</pre>
Note: These registers are called LX, LY, HX, and HY by [[WinAPE]]'s debugger, although its assembler uses the names given above.

== ED prefix ==

There are a number of undocumented EDxx instructions, of which most are duplicates of documented instructions. Any instruction not listed has no effect (same behaviour as 2 NOP instructions).

The complete list except for the block instructions:
<pre>ED40 IN B,(C) ED60 IN H,(C)
ED41 OUT (C),B ED61 OUT (C),H
ED42 SBC HL,BC ED62 SBC HL,HL
ED43 LD (nn),BC ED63 LD (nn),HL
ED44 NEG ED64 NEG *
ED45 RETN ED65 RETN *
ED46 IM 0 ED66 IM 0 *
ED47 LD I,A ED67 RRD
ED48 IN C,(C) ED68 IN L,(C)
ED49 OUT (C),C ED69 OUT (C),L
ED4A ADC HL,BC ED6A ADC HL,HL
ED4B LD BC,(nn) ED6B LD HL,(nn)
ED4C NEG * ED6C NEG *
ED4D RETI ED6D RETN *
ED4E IM 0 * ED6E IM 0 *
ED4F LD R,A ED6F RLD
ED50 IN D,(C) ED70 IN (C) / IN F,(C) *
ED51 OUT (C),D ED71 OUT (C),0 *
ED52 SBC HL,DE ED72 SBC HL,SP
ED53 LD (nn),DE ED73 LD (nn),SP
ED54 NEG * ED74 NEG *
ED55 RETN * ED75 RETN *
ED56 IM 1 ED76 IM 1 *
ED57 LD A,I ED77 NOP *
ED58 IN E,(C) ED78 IN A,(C)
ED59 OUT (C),E ED79 OUT (C),A
ED5A ADC HL,DE ED7A ADC HL,SP
ED5B LD DE,(nn) ED7B LD SP,(nn)
ED5C NEG * ED7C NEG *
ED5D RETN * ED7D RETN *
ED5E IM 2 ED7E IM 2 *
ED5F LD A,R ED7F NOP *
* = undocumented opcodes
</pre>
== DDCB prefix ==

The undocumented DDCB instructions store the result (if any) of the operation in one of the seven all-purpose registers, which one depends on the lower 3 bits of the last byte of the opcode (not operand, so not the offset).
<pre>000 B
001 C
010 D
011 E
100 H
101 L
110 (none: documented opcode)
111 A
</pre>
The documented DDCB0106 is RLC (IX+01h). So, clear the lower three bits (DDCB0100) and something is done to register B. The result of the RLC (which is stored in (IX+01h)) is now also stored in register B. Effectively, it does the following:
<pre>LD B,(IX+01h)
RLC B
LD (IX+01h),B
</pre>
So you get double value for money. The result is stored in B and (IX+01h). The most common notation is: RLC (IX+01h),B

I’ve once seen this notation:
<pre>RLC (IX+01h)
LD B,(IX+01h)
</pre>
That’s not correct: B contains the rotated value, even if (IX+01h) points to ROM. The DDCB SET and RES instructions do the same thing as the shift/rotate instructions:
<pre>DDCB10C0 SET 0,(IX+10h),B
DDCB10C1 SET 0,(IX+10h),C
DDCB10C2 SET 0,(IX+10h),D
DDCB10C3 SET 0,(IX+10h),E
DDCB10C4 SET 0,(IX+10h),H
DDCB10C5 SET 0,(IX+10h),L
DDCB10C6 SET 0,(IX+10h) - documented instruction
DDCB10C7 SET 0,(IX+10h),A
</pre>
So for example with the last instruction, the value of (IX+10h) with bit 0 set is also stored in register A.

The DDCB BIT instructions do not store any value; they merely test a bit. That’s why the undocumented DDCB BIT instructions are no different from the official ones:
<pre>DDCB d 78 BIT 7,(IX+d)
DDCB d 79 BIT 7,(IX+d)
DDCB d 7A BIT 7,(IX+d)
DDCB d 7B BIT 7,(IX+d)
DDCB d 7C BIT 7,(IX+d)
DDCB d 7D BIT 7,(IX+d)
DDCB d 7E BIT 7,(IX+d) - documented instruction
DDCB d 7F BIT 7,(IX+d)
</pre>
== FDCB prefix ==

Same as for the DDCB prefix, though IY is used instead of IX.

== Web links ==

*[http://www.robsy.net/z80undoc.pdf "The Undocumented Z80 Documented" by Sean Young at Jan Wilmans' Website]
*[http://www.raww.org/index.php?name=News&file=article&sid=2226 Short information about the internal "MEMPTR" 16bit register of the Z80 and its influence on the F-Register]

[[Category:Programming]]

6 MHz CPC

2012-12-10T02:30:10Z

Db6128: /* Disadvantages */ ...although the effects on the FDC are probably even worse

The 6 MHz CPC is a DIY hardware modification which allows to run the [[CPC6128]] with a CPU speed of 6 MHz instead of the usual 4 MHz.

== Technic ==
The 16 MHz crystal of the CPC is replaced by a 24 MHz crystal. Both crystals should kept on the main board, but a switch (2 lines at least, better 3) selects between them. You have to select the CPU and bus speed before you switch on the CPC. Switching the speed while the system is switched on is not advised.
None of the authors of this article is responsible for danger on your CPC, in case you try to use this DIY.

== Advantages ==
* Z80 runs with 6 MHz
* Bus runs with 6 MHz
* FDC is 50% faster
* Disc formats with 50% more sectors can be used
* Sound can be better, since the PSG runs more quickly
* Games run more fluid

== Disadvantages ==
* FDC can't read old disc formats any longer
* The horizontal timing of the CRTC is affected. In order to get a stable image, you need to program register 0 at 95 (96 characters line) and Register 2 at 61 (centering for 40 characters default)
* Pixels pitch is 66.7% of their original pitch.Theses pictures show this fact (320×200 mode 1 pixels with black border)
<gallery>
Image:12062011055.JPG|Original CPC @16Mhz
Image:12062011054.JPG|Overclocked CPC @24Mhz
</gallery>
* Not every hardware expansion is able to work with the 6 MHz bus speed
* Sound must be reprogrammed

== Software ==
* A lot of games run well with 6 MHz. For example: Nebulus, StarFox, Starstrike and others.
* There is a 6 MHz version of FutureOS

== Measurement of speed ==

* This speed improvement is 16.66667%.This has been tested with this simple program :

10 i = 0
20 after 500 goto 100
25 cls
30 i = i +1
40 ? i
50 goto 30
100 end

Score is 258 on normal CPC versus 301 on 24 MHz CPC.

(Theses results can be subject to discussion as we are not sure interrupts timing is not affected)

[[Category:DIY]][[Category:Hardware]]

6 MHz CPC

2012-12-10T02:29:22Z

Db6128: The squashed screen is a major disadvantage, so I've moved it there. Also, there was a constradiction: Is sound better or must it "be reprogrammed"? I have changed it to "can be better" to disambiguate slightly.

The 6 MHz CPC is a DIY hardware modification which allows to run the [[CPC6128]] with a CPU speed of 6 MHz instead of the usual 4 MHz.

== Technic ==
The 16 MHz crystal of the CPC is replaced by a 24 MHz crystal. Both crystals should kept on the main board, but a switch (2 lines at least, better 3) selects between them. You have to select the CPU and bus speed before you switch on the CPC. Switching the speed while the system is switched on is not advised.
None of the authors of this article is responsible for danger on your CPC, in case you try to use this DIY.

== Advantages ==
* Z80 runs with 6 MHz
* Bus runs with 6 MHz
* FDC is 50% faster
* Disc formats with 50% more sectors can be used
* Sound can be better, since the PSG runs more quickly
* Games run more fluid

== Disadvantages ==
* The horizontal timing of the CRTC is affected. In order to get a stable image, you need to program register 0 at 95 (96 characters line) and Register 2 at 61 (centering for 40 characters default)
* Pixels pitch is 66.7% of their original pitch.Theses pictures show this fact (320×200 mode 1 pixels with black border)
<gallery>
Image:12062011055.JPG|Original CPC @16Mhz
Image:12062011054.JPG|Overclocked CPC @24Mhz
</gallery>
* Not every hardware expansion is able to work with the 6 MHz bus speed
* FDC can't read old disc formats any longer
* Sound must be reprogrammed

== Software ==
* A lot of games run well with 6 MHz. For example: Nebulus, StarFox, Starstrike and others.
* There is a 6 MHz version of FutureOS

== Measurement of speed ==

* This speed improvement is 16.66667%.This has been tested with this simple program :

10 i = 0
20 after 500 goto 100
25 cls
30 i = i +1
40 ? i
50 goto 30
100 end

Score is 258 on normal CPC versus 301 on 24 MHz CPC.

(Theses results can be subject to discussion as we are not sure interrupts timing is not affected)

[[Category:DIY]][[Category:Hardware]]

Z80 - undocumented opcodes

2012-12-10T02:24:16Z

Db6128: /* DD and FD prefixes */

The [[Z80|Z80]] CPU contains several undocumented opcodes, which can be quite helpful sometimes. The most useful undocumented opcodes are probably these ones, which split up the 16bit index registers IX and IY in 8bit registers called IXL,IXH,IYL and IYH.

Please note, that many Z80 successors like the Z180 are NOT able to execute some of the following opcodes properly.

This is just an overview. Parts of this article have been copied from the [http://www.myquest.nl/z80undocumented/ "The Undocumented Z80 Documented"] originally by Sean Young and currently maintained by Jan Wilmans, which is one of the most comprehensive descriptions around.

== CB prefix ==

Of the 247 opcodes that use the prefix &CB, the block &CB &30 to &CB &37 is undocumented officially. These commands shift the operand register left and set its lowest bit to 1.

This is in contrast to SRL (Shift Right Logical), which shifts right and clears the highest bit. Some believe that this difference indicates why these opcodes are undocumented, feeling that this result represents a bug in the Z80 and that the operation was supposed to be Shift Left Logical, which would thus ''clear'' the lowest bit after shifting. Others call the opcodes SLIA, for Shift Left Inverted Arithmetic.

Regardless of the story behind this operation, its effective result is ''register'' = (''register'' * 2) + 1, something that does have its uses and has been employed in various programming contexts for that reason.

If you want a way to do an actual Shift Left Logical, ''i.e.'' ''register'' = ''register'' * 2, first ensure the carry is clear, inserting an OR A or AND A to achieve this if necessary, and then do an RL ''register''.

<pre>CB30 SLL B
CB31 SLL C
CB32 SLL D
CB33 SLL E
CB34 SLL H
CB35 SLL L
CB36 SLL (HL)
CB37 SLL A
</pre>

== DD and FD prefixes ==

The &DD or &FD prefixes are documented as causing operations using the 16-bit register HL to instead work with either of the 16-bit indexing registers IX or IY; if the operations access a memory location (''i.e.'' normally LD A,(HL), ''etc.''), the opcodes must additionally include an extra byte that specifies a signed displacement (-128 to +127) from IX/IY.

However, Zilog have not documented the fact that these prefixes also affect opcodes that usually refer to the 8-bit components of HL, ''i.e.'' H and L. Thus, one gains access to the additional registers IXH, IXL, IYH, and IYL, for almost all commands that normally use H or L. It is even possible to do things like LD IXH,IXL (although you cannot combine IX and IY in the same instruction, for obvious reasons). These registers can be useful in routines that must process and/or store a lot of numbers. Thankfully, they are not as slow as their 16-bit counterparts: whereas access to (IX+d) is usually slower by 3 NOPs than the equivalent operation upon (HL), using the 8-bit components is (like PUSH IX, ''etc.'') only 1 NOP slower, and this is only due to the need to parse the prefixing byte.

<pre>DB #DD:LD H,A -> LD IXH,A
DB #FD:LD B,L -> LD B,IYL
</pre>
Note: These registers are called LX, LY, HX, and HY by [[WinAPE]]'s debugger, although its assembler uses the names given above.

== ED prefix ==

There are a number of undocumented EDxx instructions, of which most are duplicates of documented instructions. Any instruction not listed has no effect (same behaviour as 2 NOP instructions).

The complete list except for the block instructions:
<pre>ED40 IN B,(C) ED60 IN H,(C)
ED41 OUT (C),B ED61 OUT (C),H
ED42 SBC HL,BC ED62 SBC HL,HL
ED43 LD (nn),BC ED63 LD (nn),HL
ED44 NEG ED64 NEG *
ED45 RETN ED65 RETN *
ED46 IM 0 ED66 IM 0 *
ED47 LD I,A ED67 RRD
ED48 IN C,(C) ED68 IN L,(C)
ED49 OUT (C),C ED69 OUT (C),L
ED4A ADC HL,BC ED6A ADC HL,HL
ED4B LD BC,(nn) ED6B LD HL,(nn)
ED4C NEG * ED6C NEG *
ED4D RETI ED6D RETN *
ED4E IM 0 * ED6E IM 0 *
ED4F LD R,A ED6F RLD
ED50 IN D,(C) ED70 IN (C) / IN F,(C) *
ED51 OUT (C),D ED71 OUT (C),0 *
ED52 SBC HL,DE ED72 SBC HL,SP
ED53 LD (nn),DE ED73 LD (nn),SP
ED54 NEG * ED74 NEG *
ED55 RETN * ED75 RETN *
ED56 IM 1 ED76 IM 1 *
ED57 LD A,I ED77 NOP *
ED58 IN E,(C) ED78 IN A,(C)
ED59 OUT (C),E ED79 OUT (C),A
ED5A ADC HL,DE ED7A ADC HL,SP
ED5B LD DE,(nn) ED7B LD SP,(nn)
ED5C NEG * ED7C NEG *
ED5D RETN * ED7D RETN *
ED5E IM 2 ED7E IM 2 *
ED5F LD A,R ED7F NOP *
* = undocumented opcodes
</pre>
== DDCB prefix ==

The undocumented DDCB instructions store the result (if any) of the operation in one of the seven all-purpose registers, which one depends on the lower 3 bits of the last byte of the opcode (not operand, so not the offset).
<pre>000 B
001 C
010 D
011 E
100 H
101 L
110 (none: documented opcode)
111 A
</pre>
The documented DDCB0106 is RLC (IX+01h). So, clear the lower three bits (DDCB0100) and something is done to register B. The result of the RLC (which is stored in (IX+01h)) is now also stored in register B. Effectively, it does the following:
<pre>LD B,(IX+01h)
RLC B
LD (IX+01h),B
</pre>
So you get double value for money. The result is stored in B and (IX+01h). The most common notation is: RLC (IX+01h),B

I’ve once seen this notation:
<pre>RLC (IX+01h)
LD B,(IX+01h)
</pre>
That’s not correct: B contains the rotated value, even if (IX+01h) points to ROM. The DDCB SET and RES instructions do the same thing as the shift/rotate instructions:
<pre>DDCB10C0 SET 0,(IX+10h),B
DDCB10C1 SET 0,(IX+10h),C
DDCB10C2 SET 0,(IX+10h),D
DDCB10C3 SET 0,(IX+10h),E
DDCB10C4 SET 0,(IX+10h),H
DDCB10C5 SET 0,(IX+10h),L
DDCB10C6 SET 0,(IX+10h) - documented instruction
DDCB10C7 SET 0,(IX+10h),A
</pre>
So for example with the last instruction, the value of (IX+10h) with bit 0 set is also stored in register A.

The DDCB BIT instructions do not store any value; they merely test a bit. That’s why the undocumented DDCB BIT instructions are no different from the official ones:
<pre>DDCB d 78 BIT 7,(IX+d)
DDCB d 79 BIT 7,(IX+d)
DDCB d 7A BIT 7,(IX+d)
DDCB d 7B BIT 7,(IX+d)
DDCB d 7C BIT 7,(IX+d)
DDCB d 7D BIT 7,(IX+d)
DDCB d 7E BIT 7,(IX+d) - documented instruction
DDCB d 7F BIT 7,(IX+d)
</pre>
== FDCB prefix ==

Same as for the DDCB prefix, though IY is used instead of IX.

== Web links ==

*[http://www.robsy.net/z80undoc.pdf "The Undocumented Z80 Documented" by Sean Young at Jan Wilmans' Website]
*[http://www.raww.org/index.php?name=News&file=article&sid=2226 Short information about the internal "MEMPTR" 16bit register of the Z80 and its influence on the F-Register]

[[Category:Programming]]

Z80 - undocumented opcodes

2012-12-10T02:23:17Z

Db6128: /* DD and FD prefixes */

The [[Z80|Z80]] CPU contains several undocumented opcodes, which can be quite helpful sometimes. The most useful undocumented opcodes are probably these ones, which split up the 16bit index registers IX and IY in 8bit registers called IXL,IXH,IYL and IYH.

Please note, that many Z80 successors like the Z180 are NOT able to execute some of the following opcodes properly.

This is just an overview. Parts of this article have been copied from the [http://www.myquest.nl/z80undocumented/ "The Undocumented Z80 Documented"] originally by Sean Young and currently maintained by Jan Wilmans, which is one of the most comprehensive descriptions around.

== CB prefix ==

Of the 247 opcodes that use the prefix &CB, the block &CB &30 to &CB &37 is undocumented officially. These commands shift the operand register left and set its lowest bit to 1.

This is in contrast to SRL (Shift Right Logical), which shifts right and clears the highest bit. Some believe that this difference indicates why these opcodes are undocumented, feeling that this result represents a bug in the Z80 and that the operation was supposed to be Shift Left Logical, which would thus ''clear'' the lowest bit after shifting. Others call the opcodes SLIA, for Shift Left Inverted Arithmetic.

Regardless of the story behind this operation, its effective result is ''register'' = (''register'' * 2) + 1, something that does have its uses and has been employed in various programming contexts for that reason.

If you want a way to do an actual Shift Left Logical, ''i.e.'' ''register'' = ''register'' * 2, first ensure the carry is clear, inserting an OR A or AND A to achieve this if necessary, and then do an RL ''register''.

<pre>CB30 SLL B
CB31 SLL C
CB32 SLL D
CB33 SLL E
CB34 SLL H
CB35 SLL L
CB36 SLL (HL)
CB37 SLL A
</pre>

== DD and FD prefixes ==

The &DD or &FD prefixes are documented as causing operations using the 16-bit register HL to instead work with either of the 16-bit indexing registers IX or IY; if the operations access a memory location (''i.e.'' normally LD A,(HL), ''etc.''), the opcodes must additionally include an extra byte that specifies a signed displacement (-128 to +127) from IX/IY.

However, Zilog have not documented the fact that these prefixes also affect opcodes that usually refer to the 8-bit components of HL, ''i.e.'' H and L. Thus, one gains access to the additional registers IXH, IXL, IYH, and IYL, for almost all commands that normally use H or L. It is even possible to do things like LD IXH,IXL. These registers can be useful in routines that must process and/or store a lot of numbers. Thankfully, they are not as slow as their 16-bit counterparts: whereas access to (IX+d) is usually slower by 3 NOPs than the equivalent operation upon (HL), using the 8-bit components is (like PUSH IX, ''etc.'') only 1 NOP slower, and this is only due to the need to parse the prefixing byte.

<pre>DB #DD:LD H,A -> LD IXH,A
DB #FD:LD B,L -> LD B,IYL
</pre>
Note: These registers are called LX, LY, HX, and HY by [[WinAPE]]'s debugger, although its assembler uses the names given above.

== ED prefix ==

There are a number of undocumented EDxx instructions, of which most are duplicates of documented instructions. Any instruction not listed has no effect (same behaviour as 2 NOP instructions).

The complete list except for the block instructions:
<pre>ED40 IN B,(C) ED60 IN H,(C)
ED41 OUT (C),B ED61 OUT (C),H
ED42 SBC HL,BC ED62 SBC HL,HL
ED43 LD (nn),BC ED63 LD (nn),HL
ED44 NEG ED64 NEG *
ED45 RETN ED65 RETN *
ED46 IM 0 ED66 IM 0 *
ED47 LD I,A ED67 RRD
ED48 IN C,(C) ED68 IN L,(C)
ED49 OUT (C),C ED69 OUT (C),L
ED4A ADC HL,BC ED6A ADC HL,HL
ED4B LD BC,(nn) ED6B LD HL,(nn)
ED4C NEG * ED6C NEG *
ED4D RETI ED6D RETN *
ED4E IM 0 * ED6E IM 0 *
ED4F LD R,A ED6F RLD
ED50 IN D,(C) ED70 IN (C) / IN F,(C) *
ED51 OUT (C),D ED71 OUT (C),0 *
ED52 SBC HL,DE ED72 SBC HL,SP
ED53 LD (nn),DE ED73 LD (nn),SP
ED54 NEG * ED74 NEG *
ED55 RETN * ED75 RETN *
ED56 IM 1 ED76 IM 1 *
ED57 LD A,I ED77 NOP *
ED58 IN E,(C) ED78 IN A,(C)
ED59 OUT (C),E ED79 OUT (C),A
ED5A ADC HL,DE ED7A ADC HL,SP
ED5B LD DE,(nn) ED7B LD SP,(nn)
ED5C NEG * ED7C NEG *
ED5D RETN * ED7D RETN *
ED5E IM 2 ED7E IM 2 *
ED5F LD A,R ED7F NOP *
* = undocumented opcodes
</pre>
== DDCB prefix ==

The undocumented DDCB instructions store the result (if any) of the operation in one of the seven all-purpose registers, which one depends on the lower 3 bits of the last byte of the opcode (not operand, so not the offset).
<pre>000 B
001 C
010 D
011 E
100 H
101 L
110 (none: documented opcode)
111 A
</pre>
The documented DDCB0106 is RLC (IX+01h). So, clear the lower three bits (DDCB0100) and something is done to register B. The result of the RLC (which is stored in (IX+01h)) is now also stored in register B. Effectively, it does the following:
<pre>LD B,(IX+01h)
RLC B
LD (IX+01h),B
</pre>
So you get double value for money. The result is stored in B and (IX+01h). The most common notation is: RLC (IX+01h),B

I’ve once seen this notation:
<pre>RLC (IX+01h)
LD B,(IX+01h)
</pre>
That’s not correct: B contains the rotated value, even if (IX+01h) points to ROM. The DDCB SET and RES instructions do the same thing as the shift/rotate instructions:
<pre>DDCB10C0 SET 0,(IX+10h),B
DDCB10C1 SET 0,(IX+10h),C
DDCB10C2 SET 0,(IX+10h),D
DDCB10C3 SET 0,(IX+10h),E
DDCB10C4 SET 0,(IX+10h),H
DDCB10C5 SET 0,(IX+10h),L
DDCB10C6 SET 0,(IX+10h) - documented instruction
DDCB10C7 SET 0,(IX+10h),A
</pre>
So for example with the last instruction, the value of (IX+10h) with bit 0 set is also stored in register A.

The DDCB BIT instructions do not store any value; they merely test a bit. That’s why the undocumented DDCB BIT instructions are no different from the official ones:
<pre>DDCB d 78 BIT 7,(IX+d)
DDCB d 79 BIT 7,(IX+d)
DDCB d 7A BIT 7,(IX+d)
DDCB d 7B BIT 7,(IX+d)
DDCB d 7C BIT 7,(IX+d)
DDCB d 7D BIT 7,(IX+d)
DDCB d 7E BIT 7,(IX+d) - documented instruction
DDCB d 7F BIT 7,(IX+d)
</pre>
== FDCB prefix ==

Same as for the DDCB prefix, though IY is used instead of IX.

== Web links ==

*[http://www.robsy.net/z80undoc.pdf "The Undocumented Z80 Documented" by Sean Young at Jan Wilmans' Website]
*[http://www.raww.org/index.php?name=News&file=article&sid=2226 Short information about the internal "MEMPTR" 16bit register of the Z80 and its influence on the F-Register]

[[Category:Programming]]

Z80 - undocumented opcodes

2012-12-10T02:13:56Z

Db6128: /* CB prefix */

The [[Z80|Z80]] CPU contains several undocumented opcodes, which can be quite helpful sometimes. The most useful undocumented opcodes are probably these ones, which split up the 16bit index registers IX and IY in 8bit registers called IXL,IXH,IYL and IYH.

Please note, that many Z80 successors like the Z180 are NOT able to execute some of the following opcodes properly.

This is just an overview. Parts of this article have been copied from the [http://www.myquest.nl/z80undocumented/ "The Undocumented Z80 Documented"] originally by Sean Young and currently maintained by Jan Wilmans, which is one of the most comprehensive descriptions around.

== CB prefix ==

Of the 247 opcodes that use the prefix &CB, the block &CB &30 to &CB &37 is undocumented officially. These commands shift the operand register left and set its lowest bit to 1.

This is in contrast to SRL (Shift Right Logical), which shifts right and clears the highest bit. Some believe that this difference indicates why these opcodes are undocumented, feeling that this result represents a bug in the Z80 and that the operation was supposed to be Shift Left Logical, which would thus ''clear'' the lowest bit after shifting. Others call the opcodes SLIA, for Shift Left Inverted Arithmetic.

Regardless of the story behind this operation, its effective result is ''register'' = (''register'' * 2) + 1, something that does have its uses and has been employed in various programming contexts for that reason.

If you want a way to do an actual Shift Left Logical, ''i.e.'' ''register'' = ''register'' * 2, first ensure the carry is clear, inserting an OR A or AND A to achieve this if necessary, and then do an RL ''register''.

<pre>CB30 SLL B
CB31 SLL C
CB32 SLL D
CB33 SLL E
CB34 SLL H
CB35 SLL L
CB36 SLL (HL)
CB37 SLL A
</pre>

== DD and FD prefixes ==

The DD/FD prefixes replace the registers L, H or HL with IXL/IYL, IXH/IYH or IX/IY.
<pre>DB #DD:LD H,A -> LD IXH,A
DB #FD:LD B,L -> LD B,IYL
</pre>
Note: These registers are called LX, LY, HX and HY in the WinAPE assembler.

== ED prefix ==

There are a number of undocumented EDxx instructions, of which most are duplicates of documented instructions. Any instruction not listed has no effect (same behaviour as 2 NOP instructions).

The complete list except for the block instructions:
<pre>ED40 IN B,(C) ED60 IN H,(C)
ED41 OUT (C),B ED61 OUT (C),H
ED42 SBC HL,BC ED62 SBC HL,HL
ED43 LD (nn),BC ED63 LD (nn),HL
ED44 NEG ED64 NEG *
ED45 RETN ED65 RETN *
ED46 IM 0 ED66 IM 0 *
ED47 LD I,A ED67 RRD
ED48 IN C,(C) ED68 IN L,(C)
ED49 OUT (C),C ED69 OUT (C),L
ED4A ADC HL,BC ED6A ADC HL,HL
ED4B LD BC,(nn) ED6B LD HL,(nn)
ED4C NEG * ED6C NEG *
ED4D RETI ED6D RETN *
ED4E IM 0 * ED6E IM 0 *
ED4F LD R,A ED6F RLD
ED50 IN D,(C) ED70 IN (C) / IN F,(C) *
ED51 OUT (C),D ED71 OUT (C),0 *
ED52 SBC HL,DE ED72 SBC HL,SP
ED53 LD (nn),DE ED73 LD (nn),SP
ED54 NEG * ED74 NEG *
ED55 RETN * ED75 RETN *
ED56 IM 1 ED76 IM 1 *
ED57 LD A,I ED77 NOP *
ED58 IN E,(C) ED78 IN A,(C)
ED59 OUT (C),E ED79 OUT (C),A
ED5A ADC HL,DE ED7A ADC HL,SP
ED5B LD DE,(nn) ED7B LD SP,(nn)
ED5C NEG * ED7C NEG *
ED5D RETN * ED7D RETN *
ED5E IM 2 ED7E IM 2 *
ED5F LD A,R ED7F NOP *
* = undocumented opcodes
</pre>
== DDCB prefix ==

The undocumented DDCB instructions store the result (if any) of the operation in one of the seven all-purpose registers, which one depends on the lower 3 bits of the last byte of the opcode (not operand, so not the offset).
<pre>000 B
001 C
010 D
011 E
100 H
101 L
110 (none: documented opcode)
111 A
</pre>
The documented DDCB0106 is RLC (IX+01h). So, clear the lower three bits (DDCB0100) and something is done to register B. The result of the RLC (which is stored in (IX+01h)) is now also stored in register B. Effectively, it does the following:
<pre>LD B,(IX+01h)
RLC B
LD (IX+01h),B
</pre>
So you get double value for money. The result is stored in B and (IX+01h). The most common notation is: RLC (IX+01h),B

I’ve once seen this notation:
<pre>RLC (IX+01h)
LD B,(IX+01h)
</pre>
That’s not correct: B contains the rotated value, even if (IX+01h) points to ROM. The DDCB SET and RES instructions do the same thing as the shift/rotate instructions:
<pre>DDCB10C0 SET 0,(IX+10h),B
DDCB10C1 SET 0,(IX+10h),C
DDCB10C2 SET 0,(IX+10h),D
DDCB10C3 SET 0,(IX+10h),E
DDCB10C4 SET 0,(IX+10h),H
DDCB10C5 SET 0,(IX+10h),L
DDCB10C6 SET 0,(IX+10h) - documented instruction
DDCB10C7 SET 0,(IX+10h),A
</pre>
So for example with the last instruction, the value of (IX+10h) with bit 0 set is also stored in register A.

The DDCB BIT instructions do not store any value; they merely test a bit. That’s why the undocumented DDCB BIT instructions are no different from the official ones:
<pre>DDCB d 78 BIT 7,(IX+d)
DDCB d 79 BIT 7,(IX+d)
DDCB d 7A BIT 7,(IX+d)
DDCB d 7B BIT 7,(IX+d)
DDCB d 7C BIT 7,(IX+d)
DDCB d 7D BIT 7,(IX+d)
DDCB d 7E BIT 7,(IX+d) - documented instruction
DDCB d 7F BIT 7,(IX+d)
</pre>
== FDCB prefix ==

Same as for the DDCB prefix, though IY is used instead of IX.

== Web links ==

*[http://www.robsy.net/z80undoc.pdf "The Undocumented Z80 Documented" by Sean Young at Jan Wilmans' Website]
*[http://www.raww.org/index.php?name=News&file=article&sid=2226 Short information about the internal "MEMPTR" 16bit register of the Z80 and its influence on the F-Register]

[[Category:Programming]]

Z80 - undocumented opcodes

2012-12-10T02:13:29Z

Db6128: /* CB prefix */

The [[Z80|Z80]] CPU contains several undocumented opcodes, which can be quite helpful sometimes. The most useful undocumented opcodes are probably these ones, which split up the 16bit index registers IX and IY in 8bit registers called IXL,IXH,IYL and IYH.

Please note, that many Z80 successors like the Z180 are NOT able to execute some of the following opcodes properly.

This is just an overview. Parts of this article have been copied from the [http://www.myquest.nl/z80undocumented/ "The Undocumented Z80 Documented"] originally by Sean Young and currently maintained by Jan Wilmans, which is one of the most comprehensive descriptions around.

== CB prefix ==

Of the 247 opcodes that use the prefix &CB, the block &CB &30 to &CB &37 is undocumented officially. These commands shift the operand register left and set its lowest bit to 1.

This is in contrast to SRL (Shift Right Logical), which shifts right and clears the highest bit. Some believe that this difference indicates why these opcodes are undocumented, feeling that this result represent a bug in the Z80 and that the operation was supposed to be Shift Left Logical, which would thus ''clear'' the lowest bit after shifting. Others call the opcodes SLIA, for Shift Left Inverted Arithmetic.

Regardless of the story behind this operation, its effective result of the operation is ''register'' = (''register'' * 2) + 1, something that does have its uses and has been employed in various programming contexts for that reason.

If you want a way to do an actual Shift Left Logical, ''i.e.'' ''register'' = ''register'' * 2, first ensure the carry is clear, inserting an OR A or AND A to achieve this if necessary, and then do an RL ''register''.

<pre>CB30 SLL B
CB31 SLL C
CB32 SLL D
CB33 SLL E
CB34 SLL H
CB35 SLL L
CB36 SLL (HL)
CB37 SLL A
</pre>

== DD and FD prefixes ==

The DD/FD prefixes replace the registers L, H or HL with IXL/IYL, IXH/IYH or IX/IY.
<pre>DB #DD:LD H,A -> LD IXH,A
DB #FD:LD B,L -> LD B,IYL
</pre>
Note: These registers are called LX, LY, HX and HY in the WinAPE assembler.

== ED prefix ==

There are a number of undocumented EDxx instructions, of which most are duplicates of documented instructions. Any instruction not listed has no effect (same behaviour as 2 NOP instructions).

The complete list except for the block instructions:
<pre>ED40 IN B,(C) ED60 IN H,(C)
ED41 OUT (C),B ED61 OUT (C),H
ED42 SBC HL,BC ED62 SBC HL,HL
ED43 LD (nn),BC ED63 LD (nn),HL
ED44 NEG ED64 NEG *
ED45 RETN ED65 RETN *
ED46 IM 0 ED66 IM 0 *
ED47 LD I,A ED67 RRD
ED48 IN C,(C) ED68 IN L,(C)
ED49 OUT (C),C ED69 OUT (C),L
ED4A ADC HL,BC ED6A ADC HL,HL
ED4B LD BC,(nn) ED6B LD HL,(nn)
ED4C NEG * ED6C NEG *
ED4D RETI ED6D RETN *
ED4E IM 0 * ED6E IM 0 *
ED4F LD R,A ED6F RLD
ED50 IN D,(C) ED70 IN (C) / IN F,(C) *
ED51 OUT (C),D ED71 OUT (C),0 *
ED52 SBC HL,DE ED72 SBC HL,SP
ED53 LD (nn),DE ED73 LD (nn),SP
ED54 NEG * ED74 NEG *
ED55 RETN * ED75 RETN *
ED56 IM 1 ED76 IM 1 *
ED57 LD A,I ED77 NOP *
ED58 IN E,(C) ED78 IN A,(C)
ED59 OUT (C),E ED79 OUT (C),A
ED5A ADC HL,DE ED7A ADC HL,SP
ED5B LD DE,(nn) ED7B LD SP,(nn)
ED5C NEG * ED7C NEG *
ED5D RETN * ED7D RETN *
ED5E IM 2 ED7E IM 2 *
ED5F LD A,R ED7F NOP *
* = undocumented opcodes
</pre>
== DDCB prefix ==

The undocumented DDCB instructions store the result (if any) of the operation in one of the seven all-purpose registers, which one depends on the lower 3 bits of the last byte of the opcode (not operand, so not the offset).
<pre>000 B
001 C
010 D
011 E
100 H
101 L
110 (none: documented opcode)
111 A
</pre>
The documented DDCB0106 is RLC (IX+01h). So, clear the lower three bits (DDCB0100) and something is done to register B. The result of the RLC (which is stored in (IX+01h)) is now also stored in register B. Effectively, it does the following:
<pre>LD B,(IX+01h)
RLC B
LD (IX+01h),B
</pre>
So you get double value for money. The result is stored in B and (IX+01h). The most common notation is: RLC (IX+01h),B

I’ve once seen this notation:
<pre>RLC (IX+01h)
LD B,(IX+01h)
</pre>
That’s not correct: B contains the rotated value, even if (IX+01h) points to ROM. The DDCB SET and RES instructions do the same thing as the shift/rotate instructions:
<pre>DDCB10C0 SET 0,(IX+10h),B
DDCB10C1 SET 0,(IX+10h),C
DDCB10C2 SET 0,(IX+10h),D
DDCB10C3 SET 0,(IX+10h),E
DDCB10C4 SET 0,(IX+10h),H
DDCB10C5 SET 0,(IX+10h),L
DDCB10C6 SET 0,(IX+10h) - documented instruction
DDCB10C7 SET 0,(IX+10h),A
</pre>
So for example with the last instruction, the value of (IX+10h) with bit 0 set is also stored in register A.

The DDCB BIT instructions do not store any value; they merely test a bit. That’s why the undocumented DDCB BIT instructions are no different from the official ones:
<pre>DDCB d 78 BIT 7,(IX+d)
DDCB d 79 BIT 7,(IX+d)
DDCB d 7A BIT 7,(IX+d)
DDCB d 7B BIT 7,(IX+d)
DDCB d 7C BIT 7,(IX+d)
DDCB d 7D BIT 7,(IX+d)
DDCB d 7E BIT 7,(IX+d) - documented instruction
DDCB d 7F BIT 7,(IX+d)
</pre>
== FDCB prefix ==

Same as for the DDCB prefix, though IY is used instead of IX.

== Web links ==

*[http://www.robsy.net/z80undoc.pdf "The Undocumented Z80 Documented" by Sean Young at Jan Wilmans' Website]
*[http://www.raww.org/index.php?name=News&file=article&sid=2226 Short information about the internal "MEMPTR" 16bit register of the Z80 and its influence on the F-Register]

[[Category:Programming]]

Mission Genocide

2012-12-03T18:09:36Z

Db6128: Adding info on Shirley's alias being Rotovision and on the port to the C64. Now, how do we get that info-box to actually align to the right?

{|align="right" valign="top"
|{{Infobox Game
|Image = [[Image:Mission genocide (K7) (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case) - (Front).jpg|center|300px|Titlescreen of the game]]
|Company = [[Firebird]]
|Developer = [http://www.dadgum.com/halcyon/BOOK/SHIRLEY.HTM Paul Shirley] a.k.a. Rotovision
|Publisher = [[Firebird]]
|Musician = Unknown
|Release = [[:Category:Games 1987|1987]]
|Platform = [[Amstrad CPC|CPC]], [[Commodore 64]]
|Genre = Shoot'Em Up
|GameModes = Unknown
|Controls = {{Keyboard}} {{Joystick}}
|Media = {{Disk}} {{Tape}}
|Language = {{EN}}
|Info = Unknown
}}
|}

'''''Mission Genocide''''', originally titled '''''ZTB''''' (for ''Zap the Bastards'' and later ''Badstars'' [http://www.dadgum.com/halcyon/BOOK/SHIRLEY.HTM]) and still named thusly on the loading screen and elsewhere, is a game by Paul Shirley (a.k.a. Rotovision) for the old generation of CPCs, released on both tape and disc and compatible with all models.

The game is mentioned fairly often for its smooth and pixel-perfect vertical scrolling, which is done in hardware using the [[CRTC]]. It is also notable in using a very fast method of plotting sprites, which takes advantage of the 16 colours of graphical Mode 0 by using 3 for sprites, Ink 0 for transparency, and the remaining 12 as 3 duplicate sets of 4 colours for the background: the roles of these Inks are arranged according to binary logic so that sprites can be ORd onto the background and ANDed to remove them, a method that is much faster and more memory-efficient than storing a sprite and a masking table and then performing all the relevant masking operations between these and the background. The name Rotovision has been used to refer to either of these techniques, but this seems actually to be an alias of the game’s programmer Paul Shirley: different ROMs of the game display one of these two names.

Shirley later ported ''Mission Genocide'' from the CPC to the [[Commodore 64]], although he says that version is “not worth the tape it's saved on”, unlike the “technically impressive” original version.

== Covertapes ==

<gallery caption="Mission Genocide">

Image:Mission genocide (K7) (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case) - (Back).jpg|Back Covertape
Image:Mission genocide (K7) (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case) - (Front).jpg|Front Covertape

</gallery>

== Tape ==

<gallery caption="Mission Genocide">

Image:Mission genocide (K7) (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case) - (Media).jpg|Tape

</gallery>

== Download ==

* [[Media:Mission genocide (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case).cdt.zip|Mission genocide (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case).cdt.zip]] (CDT for Emulators)

== Reviews ==

* [[Amstrad Computer User]] July of 1987:
<gallery>
image:MissionGenocide ACU July1987 p1.jpg|page 40
image:MissionGenocide ACU July1987 p2.jpg|page 41
</gallery>

== Links ==

* [http://www.cpc-power.com/index.php?page=detail&num=99 CPC game base from CPC Power]
* [http://tacgr.emuunlim.com/downloads/filedetail.php?recid=580 The Amstrad CPC Games Resource]
* [http://www.dadgum.com/halcyon/BOOK/SHIRLEY.HTM Interview with coder Paul Shirley], in which he discusses the alternative titles, his lack of faith in his conversion of the game to the Commodore 64, and topics about other projects.

[[Category:Games]] [[Category:Games 1987]]

Mission Genocide

2012-12-03T17:49:34Z

Db6128: Adding programmer, link to interview, alternative title, info on relatively famous graphical tricks, etc.

{| align="right" valign="top"
|{{Infobox Game
|Image = [[Image:Mission genocide (K7) (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case) - (Front).jpg|center|300px|Titlescreen of the game]]
|Company = [[Firebird]]
|Developer = [http://www.dadgum.com/halcyon/BOOK/SHIRLEY.HTM Paul Shirley]
|Publisher = [[Firebird]]
|Musician = Unknown
|Release = [[:Category:Games 1987|1987]]
|Platform = [[Amstrad CPC|CPC]]
|Genre = Shoot'Em Up
|GameModes = Unknown
|Controls = {{Keyboard}} {{Joystick}}
|Media = {{Disk}} {{Tape}}
|Language = {{EN}}
|Info = Unknown
}}
|}

'''''Mission Genocide''''', alternatively titled '''''ZTB''''' (for ''Zap the Bastards'' and later ''Badstars'' [http://www.dadgum.com/halcyon/BOOK/SHIRLEY.HTM]) on the loading screen and elsewhere, is a game for the old generation of CPCs, released on both tape and disc and compatible with all models.

The game is mentioned fairly often for its smooth and pixel-perfect vertical scrolling, which is done in hardware using the [[CRTC]]. It is also notable in using a very fast method of plotting sprites, which takes advantage of the 16 colours of graphical Mode 0 by using 3 for sprites, Ink 0 for transparency, and the remaining 12 as 3 duplicate sets of 4 colours for the background: the roles of these Inks are arranged according to binary logic so that sprites can be ORd onto the background and ANDed to remove them, a method that is much faster and more memory-efficient than storing a sprite and a masking table and then performing all the relevant masking operations between these and the background.

== Covertapes ==

<gallery caption="Mission Genocide">

Image:Mission genocide (K7) (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case) - (Back).jpg|Back Covertape
Image:Mission genocide (K7) (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case) - (Front).jpg|Front Covertape

</gallery>

== Tape ==

<gallery caption="Mission Genocide">

Image:Mission genocide (K7) (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case) - (Media).jpg|Tape

</gallery>

== Download ==

* [[Media:Mission genocide (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case).cdt.zip|Mission genocide (Firebird Software) (199 Silver Range) (1987) (Standard Jewel Case).cdt.zip]] (CDT for Emulators)

== Reviews ==

* [[Amstrad Computer User]] July of 1987:
<gallery>
image:MissionGenocide ACU July1987 p1.jpg|page 40
image:MissionGenocide ACU July1987 p2.jpg|page 41
</gallery>

== Links ==

* [http://www.cpc-power.com/index.php?page=detail&num=99 CPC game base from CPC Power]
* [http://tacgr.emuunlim.com/downloads/filedetail.php?recid=580 The Amstrad CPC Games Resource]
* [http://www.dadgum.com/halcyon/BOOK/SHIRLEY.HTM Interview with coder Paul Shirley], in which he discusses the alternative title, his lack of faith in his conversion of the game to the Commodore 64, and topics about other projects.

[[Category:Games]] [[Category:Games 1987]]

User:Db6128

2012-12-03T17:29:56Z

Db6128:

Already have an account on the forums, just saw on YouTube how much effort evidently went into porting Cybernoid from the Spectrum and thought it'd be a good one to add to the in-progress "Speccy ports" page

[Some time later…] Still going to get around to that some time when I can collect pics, ''etc.'' for comparison--[[User:Db6128|Db6128]] ([[User talk:Db6128|talk]]) 19:29, 3 December 2012 (EET)

Talk:KC Compact

2012-12-03T17:28:51Z

Db6128:

== Original author ==
Sorry Kev - I tried to follow the trail of previous renames/moves far enough to get the real author but evidently didn't do very well. :D
--[[User:Db6128|Db6128]] ([[User talk:Db6128|talk]]) 19:28, 3 December 2012 (EET)

Talk:KC Compact

2012-12-03T17:28:40Z

Db6128: /* Original author */ new section

== Original author ==

Sorry Kev - I tried to follow the trail of previous renames/moves far enough to get the real author but evidently didn't do very well. :D

Cassette data information

2012-12-03T05:47:55Z

Db6128: /* Recording a sound */ numbers :P

'''Translation note :'''
Cassette = Tape.

== Recording a sound ==

A sound is recorded by making a measurement of the amplitude of the sound at regular intervals which are defined by the ''sampling rate'' and to a vertical resolution (between the lowest and highest points on the wave) that is called the ''bit-depth''. The act of taking the measurement is often called ''sampling'' and each measurement unit is called a ''sample''. A file which contains samples is often called a waveform, sound sample, audio sample, ''etc.''

The sampling rate defines the rate/frequency at which the measurements are taken. The higher the sampling rate, the faster/more frequently the measurements are taken, and the higher the maximal frequency that can be represented by the signal. Conversely, the lower the sampling rate, the slower the measurements are taken, and the maximal frequency that can be stored is lower. The sample rate is described by the "Hz" unit of measurement. The "Hz" unit of measurement means "per second". Therefore, a sampling rate of 44100 Hz, a.k.a. 44.1 kHz, means that 44100 measurements are taken each second (in other words, one measurement every 1/44100 th of a second).

If the sampling is too low, then changes in the sound which occur between each measurement will not be measured. Because higher audio frequencies are defined by oscillating more rapidly, this means that lower sampling rates can store only lower frequencies. Therefore, the faster the measurements are taken, the more accurate the recording will be, and thus the higher the quality of sound that can be recorded. Of course, at high sample rates, because there are many more measurements taken, the resulting size of the file (containing the audio data) can be large.

As should be familiar to CPC users with a little technical knowledge, a sample that uses 8-bits for storage can represent 256 distinct amplitude levels, and a sample which uses 16-bits for storage can describe 65536 distinct amplitude levels. The higher the number of bits used by each sample for storage, the larger the range of distinct amplitude levels that can be represented. Therefore, the higher the number of bits used by each sample for storage, the higher the quality of sound that can be recorded. Moreover, the number of bits is directly related to the dynamic range of the resulting signal; that is, how much of a difference there is between the quietest and loudest sounds that it can represent. 16-bit signals provide a nominal 96 dB of dynamic range.

===What settings should you use?===

All modern sound cards should support 8-bit and 16-bit samples and sample rates of 22050 Hz and 44100 Hz. Some sound cards will support a greater range of recording rates which can be lower and higher than these values. The familiar format of CD audio uses a sampling rate of 44100 Hz and a bit-depth of 16-bits. These values are more than adequate to represent almost all real-world signals for listening by humans - and also, conveniently, are fine for Amstrad tapes, too! In fact, in theory, because the standard Amstrad tape routines have a maximal frequency of 2500 Hz, settings as low as 8000 Hz and 8 bits would probably be fine. However, you will probably want to use higher settings, just in case and/or to keep in line with more common formats such as CD audio, especially if you intend to archive your recordings.

For samp2cdt, you should save the file as "PCM" ("Pulse Code Modulation"). This is a uncompressed, unencoded storage representation. Each sample is a single measurement of the amplitude of the sound taken at a measurement point in time. Other representations such as "ADPCM" ("Amplitude Delta Pulse Code Modulation"), encode or compress the data to reduce the size of the audio file. Samp2cdt can't understand these representations, so please use "PCM" only.

===Illustrations and explanations of digital audio===

[[Image:wave1.gif]]

''Fig 1. An amplitude/time graph showing the waveform of the original sound''

[[Image:wave2.gif]]

''Fig 2. An amplitude/time graph showing the waveform of the original sound. The crosses indicate the amplitude measured at each sample time and the dotted lines indicate the the time of each measurement. The duration of time between each dotted line, defined by the sample rate, is equal to the duration of a sample. From this it can be seen that each sample has a finite and equal duration.''

[[Image:wave3.gif]]

''Fig 3. An amplitude/time graph showing the waveform of the original sound. As in Fig 2, the crosses indicate the amplitude measured at each sample time. The dotted line shows the waveform generated by sampling. The final value of each sample is defined to be the amplitude measured at the time of measurement.''

[[Image:wave4.gif]]

''Fig 4. An amplitude/time graph showing the sampled waveform. This waveform was generated at a high sample rate, and therefore the resulting waveform has a shape which is similar to the original. This waveform is the type you can see in a audio recording program like Goldwave. '''Note''', however, that this distinctively square signal is not what would be output by any barely decent sound-card! Audio hardware has built-in filters to smooth waveforms as they are converted from digital to analogue.''

[[Image:wave5.gif]]

''Fig 5. An amplitude/time graph showing the waveform of the original sound. As in Fig 2, this graph shows the amplitude of each measurement, and the dotted line indicates the time of measurement. This graph was created using a low sample rate. Notice that the time between each measurement is longer compared to Fig 2.''

[[Image:wave6.gif]]

''Fig 6. An amplitude/time graph showing the waveform of the original sound. As in Fig 3, the crosses indicate the amplitude measured at each sample time, and the dotted line shows the waveform generated by sampling. This graph shows the resulting waveform generated using a low sample rate.''

[[Image:wave7.gif]]

''Fig 7. An amplitude/time graph showing the sampled waveform. As explained in the note for Figure 4, this is only a visual representation of the digitally stored audio, '''not''' of the signal that would be output by any competent audio card. However, it does illustrate how low sampling rates reduce the bandwidth of frequencies: This waveform was generated at a low sample rate, and therefore the resulting waveform is much more coarse compared to Fig 4. Notice that although the general shape is similar to the original waveform, much of the smoothness is is lost between the time of each measurement. The loss of smoothness also means loss of information: the lower the sampling rate, the more information is lost; in other words, the maximal frequency that the signal can represent is lower. Similarly, lower bit-depths mean that the signal is less accurate, and in extreme cases can generate audible noise. Therefore, to record a sound, it is best to use relatively high sampling rate and bit-depth; CD audio's 44.1 kHz and 16 bits should be more than adequate for most uses, especially storage of CPC cassettes.''

Notes:

1. The "Nyquist theory" states that in order to accuratly record a sound of a known frequency, you must use a recording frequency which is more than twice that frequency (note "more than", not equal to). Example: to record a sound of 3000 Hz, you must record using >6000 Hz. If you use a lower sampling rate (e.g. 5000 Hz), frequencies less than or equal to half of the sampling rate cannot be properly represented and will be altered into lower-sounding frequencies.
Most Amstrad loaders are between 300 to 2500 Hz, therefore you should use a recording sample rate of >5000 Hz. It is recommended to use one of the common sample rates. e.g. 22050 Hz (22.05 Khz) or 44100 Hz (44.1 Khz).

2. There are two different representations to store the amplitude of the sample in a PCM audio file: unsigned or signed.
* A 8-bit unsigned sample has values between 0 and 255. In this range, 0 represents a low amplitudes, 255 a high amplitude, and the amplitudes increase linearly from 0 to 255.
* A 8-bit signed sample has values between -128 and 127. In this range, -128 represents a low amplitude, and 127 high amplitude, and the amplitudes increase linearly from -128 to 127.
Both methods can represent the same data, just in different ways (techies will be able to compare this to their knowledge of Z80 assembly), so there is no advantage to using either. The original reason for the two methods is due to the original method to playback the sound. Modern sound cards can play audio stored in both ways.
Note that both (albeit more obvious in the latter) share a feature typical of binary-encoded numbers: there is no exact 'centre' value, because the total number of possible values is even. In the context of audio, this means that, if the signal spanned the entire range, its centre (average) would be slightly off-zero (in this case, below), which is known as a DC offset. However, even if this did occur, it would be negligible and certainly not audible by humans!

== Duplication of cassettes ==

When the writing of a program is completed a "master" cassette is created. This cassette contains a audio representation of the computer data.

The master cassette is then duplicated, using a machine, onto many blank cassettes. These cassettes are packaged with instructions and distributed.

It is also easy to make a copy of a cassette if you have a twin cassette system, where one cassette unit will play the sound and the other will record. A first generation copy taken from a original cassette could be considered a copy of a copy of the master cassette.

Each time a cassette is copied however, additional noise may be introduced into the copied version. This noise is a mixture of noise from the original, and noise created by the machine making the copy. Therefore the sound on any cassette contains a mixture of noise and the sound of the computer data.

A loader on the computer must therefore be able to identify the actual sound of the data from other sounds that are on the cassette. If it can't do this, then there will be loading errors.

If you are transfering a cassette using samp2cdt, then you are advised to use an original (i.e. a cassette created directly from a master cassette), or a first generation copy (i.e. a cassette copied from an original).

== Loader ==

A "loader" is the name given to a program that reads data from cassette into the computer memory.

There is a "system" loader which is built into the Amstrad CPC ROM. This loader is activated when the computer is in cassette mode (note 1), and it can only understand one specific computer audio sound, the audio sound of the Amstrad CPC system data-blocks.

To read other loading systems (e.g. a fast-loader), there must be a program on the cassette (a "pre-loader" or "boot loader" or sometimes refered to as "loader"), stored using the Amstrad CPC system loader, which when executed will be able to understand and load fast-loader data.

This loader program is usually stored immediatly before any fast-loader blocks, and takes over from the system loader to load the remaining fast-loader blocks.

|program for fast-loader| |fast-loader block(s)|

So when a cassette is loaded the following occurs:

1. system loader recognises and loads "program for fast-loader".
2. "program for fast loader" takes control and loads the data from the fast-loader block(s) into computer memory
3. when loading has completed, the program is executed.

Notes:

1. a CPC without a disc interface (e.g. a CPC464, CPC464+ or KC Compact) will start-up in cassette mode. For a CPC with a disc interface attached (or internal), you must type |TAPE to enter cassette mode.

You can test if the computer is operating in cassette mode by typing RUN". If you see "Press PLAY then any key", then the computer is operating in cassette mode. If there is an error, then the computer is not operating in cassette mode.

== Amstrad cassette hardware ==

=== Reading ===

The audio from the cassette is read from a cassette player through the Amstrad's cassette electronics.

The Amstrad's cassette electronics converts the amplitude of the sound (a analogue signal) into a "0" or "1" measurement (a digital signal). This measurement can then be read from bit 7 of port B of the PPI 8255 IC.

[[Image:conv.gif]]

''Fig 8. This image shows the conversion of the audio waveform from the cassette into the digital representation by the Amstrad's cassette electronics. i.e. audio waveform (on cassette) -> Amstrad's cassette electronics -> 0 and 1 measurements''

The resulting measurements can be read using the following Z80 instructions:

<pre>
ld b,&f5 ;; I/O port address for PPI 8255 port B
;; (PPI 8255 port B is operating as input.)
in a,(c) ;; read port B inputs
and %10000000 ;; isolate bit 7 which contains the measurement.
</pre>

This measurement is *not* the actual state of a data-bit, but represents a low ("0") or high amplitude ("1"). In this document, the value of this measurement will be refered to as a "high" ("1") or "low" ("0") level.

Notes:

1. The CPC464 and CPC464+ have a cassette player built in. To connect a cassette player to the CPC664, CPC6128 or KC Compact then you must use a lead.
2. It is not known exactly how the amplitude of the sound from the cassette corresponds to the final "0" or "1" measurement.

samp2cdt uses a crude method to perform this conversion.

For a 8-bit signed sample:

* if the amplitude is 0..127, then the final measurement will be "1".
* if the amplitude is -128..0 then the final measurement will be "0".

=== Writing ===

A waveform is written to cassette using bit 5 of port C of the 8255 PPI IC. The waveform can only be defined by a high or low level, defined by the state of bit 5, which is then converted by the Amstrad's cassette electronics into a final output amplitude which is recorded onto cassette.

A high level can be written using the following Z80 instructions:

<pre>
ld b,&f6 ;; I/O port address for PPI 8255 port C
;; (PPI 8255 port C is operating as output.)

set 5,a ;; set cassette write output to high level
out (c),a ;; output level
</pre>

A low level can be written using the following Z80 instructions:

<pre>
ld b,&f6 ;; I/O port address for PPI 8255 port C
;; (PPI 8255 port C is operating as output.)

res 5,a ;; set cassette write output to low level
out (c),a ;; output level
</pre>

The amplitude of the output waveform is not amplified, therefore if you wish to record the cassette audio direct from an Amstrad you will need to amplify the waveform.

If the state of bit 5 is changed at a fixed frequency, then the graph of the state of bit 5 over time will be a square wave. However, the resulting audio written on the cassette will not be a perfect square wave because nature will attempt to convert the waveform into a sine wave.
Loading system audio waveform

Every loading system on the Amstrad uses a serial bit-stream. i.e. a single bit of information is read at a time.

This serial bit-stream is grouped into blocks of audio sound.

Every loading system uses a basic structure to describe each audio block in the following order:

|pilot|sync|data|trailer|

'''pilot'''

This is also refered to as "leader" by some documents.

This is constructed from a repeated waveform often with a fixed number of repetitions defined by the loading system.

The shape of the waveform is known by the loader program and this is used to identify the pilot waveform from other waveforms that may be present (e.g. noise).

The pilot is often long, so that the loader doesn't need to see the start of the pilot waveform in order to load the block.

The loader program will test the incoming waveform, checking it against the parameters defined for the pilot, before the waveform is accepted as the pilot waveform. (e.g. the number of repetitions must be some defined minimum value). The incoming waveform must fall within these specifications otherwise the waveform is not accepted as a pilot waveform.

'''sync ("synchronisation")'''

The sync is a waveform which is different to the pilot, and this defines the end of the pilot and the start of the data. When this sync has been detected, the loader knows that there is data following, and that the loader is always at the same point in the data stream. i.e. the loader program is synchronised to a specific point in the data waveform.

'''data'''

This is the actual data which is composed of waveforms defining "0" and "1" data bits.

The first element of the data may be a marker or id which may, for example, indicate the type of data in the block or the number of the block.

The remaining bits will define the data and zero or more checksums.

The whole data may consist of a single block with a single location and length (e.g. one block for a screen another for data), or multiple blocks each with their own location and length. (e.g. one block for screen and data)

The location and lengths of the blocks may be in the data stream itself, or they may be in a preceeding block, or may be hard-coded into the loader program.

'''trailer'''

The trailer always follows the data. Some loaders may not have a trailer. The two main purposes of the trailer are to ensure that the waveform of the last data bit in the data is constructed correctly and to provide some time in which the loader can prepare for the next block.

The exact definition of the loading systems's audio waveform is defined by the loader program.

samp2cdt has a number of decoder algorithms which recognises the audio waveform of various loading systems. These decoders read the waveform using a similar method to the loader program itself. These decoders have been created by examining the instructions of each loader program and the graph of the waveform in a sound recording package.

== Example of a typical loading system ==

The data on cassette actually consists of changing 0 and 1 levels. (a "level" is a magnitude of a value). The loader measures the time between each "level transition" where a "level transition" is the change from a "0" to a "1" level or the change from a "1" to a "0" level. The level can be timed using the following Z80 instructions:

<pre>
;; - keep testing the state of bit 7 of PPI 8255 port B
;; - update the counter to record the number of tests done
;; - when bit 7 of PPI 8255 port B changes state, stop testing.
;; counter will hold the total number of tests made.
;;
;; B = &F5 (I/O address of PPI 8255 input port B)
;; C = previous data read from PPI port B
ld d,0 ;; initialise count to 0
.loop inc d ;; increment count
in a,(c) ;; read input to PPI 8255 port B
xor c ;; exclusive-or with previous data read from PPI 8255 port B
and %10000000 ;; isolate bit 7
;; if result is 0, then the state of bit 7 that has
;; been read is the same as the previous state. i.e. bit 7 has not changed state.
;; if result is not 0, then the state of bit 7 has changed.
;; e.g. if bit 7 was previously 1, it is now 0. if bit 7 was previously 0, it is now 1.
jr z,loop
;; when execution reaches here we know that bit 7 has changed state and D
;; contains the number of tests.
</pre>

== Loader operation==

The loader generally operates in this way:

1. Time a wave. Is the duration of the wave within the minimum and maximum duration required for the pilot. If yes, go to 2, else go to 1.

2. We might have seen a wave from the pilot signal. time a wave. Is the duration of this wave within the minimum and maximum duration required for the pilot. If yes, increment number of waves seen, go to 2, else go to 1.

3. Have we seen the minimum number of pilot waves? Yes, go to 4, else go to 2. 4. time a wave. Is the duration of the wave within the minimum and maximum duration required for the sync? 2. Each Z80 instruction takes a finite time to execute. The execution time depends on the computer. If the timing of the Z80 instructions used by the test algorithm is known and predictable, then the time for each test can be calculated. Now, since the count represents the number of tests made before the condition is true (i.e. bit 7 changes state), the total time for the condition to be true, is the sum of the time for each test made. If each test always takes the same time, then the total time is the number of tests multiplied by the time for one test. In the Amstrad computer, all Z80 instructions execute in multiples of 1us (microsecond) regardless of their location in RAM. This fact simplifies this calculation.
Checksum

A "Checksum" is used to verify the loaded data.

A Checksum is the result of the "checksum calculation" made on a block of data. The actual calculation can be different depending on the method chosen.

There are two "Checksum"s.

1. a stored "Checksum".

This is the result of the "checksum calculation" calculated from the correct data. This is then stored with the data (e.g. before or after the data) when the master cassette is created.
2. a calculated "Checksum".

This is the result of the "checksum calculation" calculated from the data read from the cassette. After the calculation is complete it is compared against the stored checksum.

The stored and calculated "Checksums" are initialised with the same initial value and calculated using the same algorithm. Therefore, if the stored checksum matches the calculated checksum, it is assumed that the loaded data is identical to the original data. The data is verified to be correct.

If the stored checksum doesn't match the calculated checksum, then there has been a error. One or more bit's of data is incorrect. The checksum is designed to detect errors only, and often it is not possible to know which bit or bits of data is incorrect and in this case it is not often possible to correct the errors to reproduce the correct data.

A loader which has a checksum therefore is better than a loader that doesn't have a checksum, because the checksum will verify that the data is correct or incorrect.

With a loader which doesn't have a checksum, you have no way to verify the data, and therefore you can't guarantee that the data is identical to the original.

In this case, the only way to test that the data is correct is to make multiple transfers of the program and test each thoroughly (e.g. if the program is a game, you would play the game to the end), checking for graphic corruption and bugs. If all of the transfers operate the same, then you can assume that the data is correct.

== Various Audio file formats ==

There are numerous Audio file formats, each of which can store audio, but each has it's own structures and representation for the data.

The "format" of a file describes the internal structure, order and encoding of the data within the file.

Here is a list of the audio file formats supported by samp2cdt:

* Windows Wave file (a file which has the ".wav" file extension) is the common file format used for audio sounds on computers running "Windows".
* A Voice Wave file (a file which has the ".voc" file extension) was created by Creative for the original Soundblaster ISA sound card. This file format is used by the original voc2tzx utility which samp2cdt was developed from.
* A Audio Interchange file (a file which has the ".aiff" or ".aif" file extension) is the common file format used for audio sounds on the Mac computer.
* A file which has the ".iff" file extension is the common file format used for audio sounds by the Amiga computer.

==Links==
[[Converting a tape-image into a audio file]]

[[Category:Hardware]][[Category:DATA Storage|*]][[Category:Music and sound]][[Category:CPC Internal Components]]

Cassette data information

2012-12-03T05:44:44Z

Db6128: /* Example of a typical loading system */ formatting was borked

'''Translation note :'''
Cassette = Tape.

== Recording a sound ==

A sound is recorded by making a measurement of the amplitude of the sound at regular intervals which are defined by the ''sampling rate'' and to a vertical resolution (between the lowest and highest points on the wave) that is called the ''bit-depth''. The act of taking the measurement is often called ''sampling'' and each measurement unit is called a ''sample''. A file which contains samples is often called a waveform, sound sample, audio sample, ''etc.''

The sampling rate defines the rate/frequency at which the measurements are taken. The higher the sampling rate, the faster/more frequently the measurements are taken, and the higher the maximal frequency that can be represented by the signal. Conversely, the lower the sampling rate, the slower the measurements are taken, and the maximal frequency that can be stored is lower. The sample rate is described by the "Hz" unit of measurement. The "Hz" unit of measurement means "per second". Therefore, a sampling rate of 44010 Hz means 44010 measurements are taken each second (in other words, one measurement every 1/44010 th of a second).

If the sampling is too low, then changes in the sound which occur between each measurement will not be measured. Because higher audio frequencies are defined by oscillating more rapidly, this means that lower sampling rates can store only lower frequencies. Therefore, the faster the measurements are taken, the more accurate the recording will be, and thus the higher the quality of sound that can be recorded. Of course, at high sample rates, because there are many more measurements taken, the resulting size of the file (containing the audio data) can be large.

As should be familiar to CPC users with a little technical knowledge, a sample that uses 8-bits for storage can represent 256 distinct amplitude levels, and a sample which uses 16-bits for storage can describe 65536 distinct amplitude levels. The higher the number of bits used by each sample for storage, the larger the range of distinct amplitude levels that can be represented. Therefore, the higher the number of bits used by each sample for storage, the higher the quality of sound that can be recorded. Moreover, the number of bits is directly related to the dynamic range of the resulting signal; that is, how much of a difference there is between the quietest and loudest sounds that it can represent. 16-bit signals provide a nominal 96 dB of dynamic range.

===What settings should you use?===

All modern sound cards should support 8-bit and 16-bit samples and sample rates of 22050 Hz and 44100 Hz. Some sound cards will support a greater range of recording rates which can be lower and higher than these values. The familiar format of CD audio uses a sampling rate of 44100 Hz and a bit-depth of 16-bits. These values are more than adequate to represent almost all real-world signals for listening by humans - and also, conveniently, are fine for Amstrad tapes, too! In fact, in theory, because the standard Amstrad tape routines have a maximal frequency of 2500 Hz, settings as low as 8000 Hz and 8 bits would probably be fine. However, you will probably want to use higher settings, just in case and/or to keep in line with more common formats such as CD audio, especially if you intend to archive your recordings.

For samp2cdt, you should save the file as "PCM" ("Pulse Code Modulation"). This is a uncompressed, unencoded storage representation. Each sample is a single measurement of the amplitude of the sound taken at a measurement point in time. Other representations such as "ADPCM" ("Amplitude Delta Pulse Code Modulation"), encode or compress the data to reduce the size of the audio file. Samp2cdt can't understand these representations, so please use "PCM" only.

===Illustrations and explanations of digital audio===

[[Image:wave1.gif]]

''Fig 1. An amplitude/time graph showing the waveform of the original sound''

[[Image:wave2.gif]]

''Fig 2. An amplitude/time graph showing the waveform of the original sound. The crosses indicate the amplitude measured at each sample time and the dotted lines indicate the the time of each measurement. The duration of time between each dotted line, defined by the sample rate, is equal to the duration of a sample. From this it can be seen that each sample has a finite and equal duration.''

[[Image:wave3.gif]]

''Fig 3. An amplitude/time graph showing the waveform of the original sound. As in Fig 2, the crosses indicate the amplitude measured at each sample time. The dotted line shows the waveform generated by sampling. The final value of each sample is defined to be the amplitude measured at the time of measurement.''

[[Image:wave4.gif]]

''Fig 4. An amplitude/time graph showing the sampled waveform. This waveform was generated at a high sample rate, and therefore the resulting waveform has a shape which is similar to the original. This waveform is the type you can see in a audio recording program like Goldwave. '''Note''', however, that this distinctively square signal is not what would be output by any barely decent sound-card! Audio hardware has built-in filters to smooth waveforms as they are converted from digital to analogue.''

[[Image:wave5.gif]]

''Fig 5. An amplitude/time graph showing the waveform of the original sound. As in Fig 2, this graph shows the amplitude of each measurement, and the dotted line indicates the time of measurement. This graph was created using a low sample rate. Notice that the time between each measurement is longer compared to Fig 2.''

[[Image:wave6.gif]]

''Fig 6. An amplitude/time graph showing the waveform of the original sound. As in Fig 3, the crosses indicate the amplitude measured at each sample time, and the dotted line shows the waveform generated by sampling. This graph shows the resulting waveform generated using a low sample rate.''

[[Image:wave7.gif]]

''Fig 7. An amplitude/time graph showing the sampled waveform. As explained in the note for Figure 4, this is only a visual representation of the digitally stored audio, '''not''' of the signal that would be output by any competent audio card. However, it does illustrate how low sampling rates reduce the bandwidth of frequencies: This waveform was generated at a low sample rate, and therefore the resulting waveform is much more coarse compared to Fig 4. Notice that although the general shape is similar to the original waveform, much of the smoothness is is lost between the time of each measurement. The loss of smoothness also means loss of information: the lower the sample rating, the more information is lost; in other words, the maximal frequencies that the signal can represent is lower. Similarly, lower bit-depths mean that the signal is less accurate, and in extreme cases can generate audible noise, Therefore, to record a sound, it is best to use relatively high sampling rate and bit-depth.''

Notes:

1. The "Nyquist theory" states that in order to accuratly record a sound of a known frequency, you must use a recording frequency which is more than twice that frequency (note "more than", not equal to). Example: to record a sound of 3000 Hz, you must record using >6000 Hz. If you use a lower sampling rate (e.g. 5000 Hz), frequencies less than or equal to half of the sampling rate cannot be properly represented and will be altered into lower-sounding frequencies.
Most Amstrad loaders are between 300 to 2500 Hz, therefore you should use a recording sample rate of >5000 Hz. It is recommended to use one of the common sample rates. e.g. 22050 Hz (22.05 Khz) or 44100 Hz (44.1 Khz).

2. There are two different representations to store the amplitude of the sample in a PCM audio file: unsigned or signed.
* A 8-bit unsigned sample has values between 0 and 255. In this range, 0 represents a low amplitudes, 255 a high amplitude, and the amplitudes increase linearly from 0 to 255.
* A 8-bit signed sample has values between -128 and 127. In this range, -128 represents a low amplitude, and 127 high amplitude, and the amplitudes increase linearly from -128 to 127.
Both methods can represent the same data, just in different ways (techies will be able to compare this to their knowledge of Z80 assembly), so there is no advantage to using either. The original reason for the two methods is due to the original method to playback the sound. Modern sound cards can play audio stored in both ways.
Note that both (albeit more obvious in the latter) share a feature typical of binary-encoded numbers: there is no exact 'centre' value, because the total number of possible values is even. In the context of audio, this means that, if the signal spanned the entire range, its centre (average) would be slightly off-zero (in this case, below), which is known as a DC offset. However, even if this did occur, it would be negligible and certainly not audible by humans!

== Duplication of cassettes ==

When the writing of a program is completed a "master" cassette is created. This cassette contains a audio representation of the computer data.

The master cassette is then duplicated, using a machine, onto many blank cassettes. These cassettes are packaged with instructions and distributed.

It is also easy to make a copy of a cassette if you have a twin cassette system, where one cassette unit will play the sound and the other will record. A first generation copy taken from a original cassette could be considered a copy of a copy of the master cassette.

Each time a cassette is copied however, additional noise may be introduced into the copied version. This noise is a mixture of noise from the original, and noise created by the machine making the copy. Therefore the sound on any cassette contains a mixture of noise and the sound of the computer data.

A loader on the computer must therefore be able to identify the actual sound of the data from other sounds that are on the cassette. If it can't do this, then there will be loading errors.

If you are transfering a cassette using samp2cdt, then you are advised to use an original (i.e. a cassette created directly from a master cassette), or a first generation copy (i.e. a cassette copied from an original).

== Loader ==

A "loader" is the name given to a program that reads data from cassette into the computer memory.

There is a "system" loader which is built into the Amstrad CPC ROM. This loader is activated when the computer is in cassette mode (note 1), and it can only understand one specific computer audio sound, the audio sound of the Amstrad CPC system data-blocks.

To read other loading systems (e.g. a fast-loader), there must be a program on the cassette (a "pre-loader" or "boot loader" or sometimes refered to as "loader"), stored using the Amstrad CPC system loader, which when executed will be able to understand and load fast-loader data.

This loader program is usually stored immediatly before any fast-loader blocks, and takes over from the system loader to load the remaining fast-loader blocks.

|program for fast-loader| |fast-loader block(s)|

So when a cassette is loaded the following occurs:

1. system loader recognises and loads "program for fast-loader".
2. "program for fast loader" takes control and loads the data from the fast-loader block(s) into computer memory
3. when loading has completed, the program is executed.

Notes:

1. a CPC without a disc interface (e.g. a CPC464, CPC464+ or KC Compact) will start-up in cassette mode. For a CPC with a disc interface attached (or internal), you must type |TAPE to enter cassette mode.

You can test if the computer is operating in cassette mode by typing RUN". If you see "Press PLAY then any key", then the computer is operating in cassette mode. If there is an error, then the computer is not operating in cassette mode.

== Amstrad cassette hardware ==

=== Reading ===

The audio from the cassette is read from a cassette player through the Amstrad's cassette electronics.

The Amstrad's cassette electronics converts the amplitude of the sound (a analogue signal) into a "0" or "1" measurement (a digital signal). This measurement can then be read from bit 7 of port B of the PPI 8255 IC.

[[Image:conv.gif]]

''Fig 8. This image shows the conversion of the audio waveform from the cassette into the digital representation by the Amstrad's cassette electronics. i.e. audio waveform (on cassette) -> Amstrad's cassette electronics -> 0 and 1 measurements''

The resulting measurements can be read using the following Z80 instructions:

<pre>
ld b,&f5 ;; I/O port address for PPI 8255 port B
;; (PPI 8255 port B is operating as input.)
in a,(c) ;; read port B inputs
and %10000000 ;; isolate bit 7 which contains the measurement.
</pre>

This measurement is *not* the actual state of a data-bit, but represents a low ("0") or high amplitude ("1"). In this document, the value of this measurement will be refered to as a "high" ("1") or "low" ("0") level.

Notes:

1. The CPC464 and CPC464+ have a cassette player built in. To connect a cassette player to the CPC664, CPC6128 or KC Compact then you must use a lead.
2. It is not known exactly how the amplitude of the sound from the cassette corresponds to the final "0" or "1" measurement.

samp2cdt uses a crude method to perform this conversion.

For a 8-bit signed sample:

* if the amplitude is 0..127, then the final measurement will be "1".
* if the amplitude is -128..0 then the final measurement will be "0".

=== Writing ===

A waveform is written to cassette using bit 5 of port C of the 8255 PPI IC. The waveform can only be defined by a high or low level, defined by the state of bit 5, which is then converted by the Amstrad's cassette electronics into a final output amplitude which is recorded onto cassette.

A high level can be written using the following Z80 instructions:

<pre>
ld b,&f6 ;; I/O port address for PPI 8255 port C
;; (PPI 8255 port C is operating as output.)

set 5,a ;; set cassette write output to high level
out (c),a ;; output level
</pre>

A low level can be written using the following Z80 instructions:

<pre>
ld b,&f6 ;; I/O port address for PPI 8255 port C
;; (PPI 8255 port C is operating as output.)

res 5,a ;; set cassette write output to low level
out (c),a ;; output level
</pre>

The amplitude of the output waveform is not amplified, therefore if you wish to record the cassette audio direct from an Amstrad you will need to amplify the waveform.

If the state of bit 5 is changed at a fixed frequency, then the graph of the state of bit 5 over time will be a square wave. However, the resulting audio written on the cassette will not be a perfect square wave because nature will attempt to convert the waveform into a sine wave.
Loading system audio waveform

Every loading system on the Amstrad uses a serial bit-stream. i.e. a single bit of information is read at a time.

This serial bit-stream is grouped into blocks of audio sound.

Every loading system uses a basic structure to describe each audio block in the following order:

|pilot|sync|data|trailer|

'''pilot'''

This is also refered to as "leader" by some documents.

This is constructed from a repeated waveform often with a fixed number of repetitions defined by the loading system.

The shape of the waveform is known by the loader program and this is used to identify the pilot waveform from other waveforms that may be present (e.g. noise).

The pilot is often long, so that the loader doesn't need to see the start of the pilot waveform in order to load the block.

The loader program will test the incoming waveform, checking it against the parameters defined for the pilot, before the waveform is accepted as the pilot waveform. (e.g. the number of repetitions must be some defined minimum value). The incoming waveform must fall within these specifications otherwise the waveform is not accepted as a pilot waveform.

'''sync ("synchronisation")'''

The sync is a waveform which is different to the pilot, and this defines the end of the pilot and the start of the data. When this sync has been detected, the loader knows that there is data following, and that the loader is always at the same point in the data stream. i.e. the loader program is synchronised to a specific point in the data waveform.

'''data'''

This is the actual data which is composed of waveforms defining "0" and "1" data bits.

The first element of the data may be a marker or id which may, for example, indicate the type of data in the block or the number of the block.

The remaining bits will define the data and zero or more checksums.

The whole data may consist of a single block with a single location and length (e.g. one block for a screen another for data), or multiple blocks each with their own location and length. (e.g. one block for screen and data)

The location and lengths of the blocks may be in the data stream itself, or they may be in a preceeding block, or may be hard-coded into the loader program.

'''trailer'''

The trailer always follows the data. Some loaders may not have a trailer. The two main purposes of the trailer are to ensure that the waveform of the last data bit in the data is constructed correctly and to provide some time in which the loader can prepare for the next block.

The exact definition of the loading systems's audio waveform is defined by the loader program.

samp2cdt has a number of decoder algorithms which recognises the audio waveform of various loading systems. These decoders read the waveform using a similar method to the loader program itself. These decoders have been created by examining the instructions of each loader program and the graph of the waveform in a sound recording package.

== Example of a typical loading system ==

The data on cassette actually consists of changing 0 and 1 levels. (a "level" is a magnitude of a value). The loader measures the time between each "level transition" where a "level transition" is the change from a "0" to a "1" level or the change from a "1" to a "0" level. The level can be timed using the following Z80 instructions:

<pre>
;; - keep testing the state of bit 7 of PPI 8255 port B
;; - update the counter to record the number of tests done
;; - when bit 7 of PPI 8255 port B changes state, stop testing.
;; counter will hold the total number of tests made.
;;
;; B = &F5 (I/O address of PPI 8255 input port B)
;; C = previous data read from PPI port B
ld d,0 ;; initialise count to 0
.loop inc d ;; increment count
in a,(c) ;; read input to PPI 8255 port B
xor c ;; exclusive-or with previous data read from PPI 8255 port B
and %10000000 ;; isolate bit 7
;; if result is 0, then the state of bit 7 that has
;; been read is the same as the previous state. i.e. bit 7 has not changed state.
;; if result is not 0, then the state of bit 7 has changed.
;; e.g. if bit 7 was previously 1, it is now 0. if bit 7 was previously 0, it is now 1.
jr z,loop
;; when execution reaches here we know that bit 7 has changed state and D
;; contains the number of tests.
</pre>

== Loader operation==

The loader generally operates in this way:

1. Time a wave. Is the duration of the wave within the minimum and maximum duration required for the pilot. If yes, go to 2, else go to 1.

2. We might have seen a wave from the pilot signal. time a wave. Is the duration of this wave within the minimum and maximum duration required for the pilot. If yes, increment number of waves seen, go to 2, else go to 1.

3. Have we seen the minimum number of pilot waves? Yes, go to 4, else go to 2. 4. time a wave. Is the duration of the wave within the minimum and maximum duration required for the sync? 2. Each Z80 instruction takes a finite time to execute. The execution time depends on the computer. If the timing of the Z80 instructions used by the test algorithm is known and predictable, then the time for each test can be calculated. Now, since the count represents the number of tests made before the condition is true (i.e. bit 7 changes state), the total time for the condition to be true, is the sum of the time for each test made. If each test always takes the same time, then the total time is the number of tests multiplied by the time for one test. In the Amstrad computer, all Z80 instructions execute in multiples of 1us (microsecond) regardless of their location in RAM. This fact simplifies this calculation.
Checksum

A "Checksum" is used to verify the loaded data.

A Checksum is the result of the "checksum calculation" made on a block of data. The actual calculation can be different depending on the method chosen.

There are two "Checksum"s.

1. a stored "Checksum".

This is the result of the "checksum calculation" calculated from the correct data. This is then stored with the data (e.g. before or after the data) when the master cassette is created.
2. a calculated "Checksum".

This is the result of the "checksum calculation" calculated from the data read from the cassette. After the calculation is complete it is compared against the stored checksum.

The stored and calculated "Checksums" are initialised with the same initial value and calculated using the same algorithm. Therefore, if the stored checksum matches the calculated checksum, it is assumed that the loaded data is identical to the original data. The data is verified to be correct.

If the stored checksum doesn't match the calculated checksum, then there has been a error. One or more bit's of data is incorrect. The checksum is designed to detect errors only, and often it is not possible to know which bit or bits of data is incorrect and in this case it is not often possible to correct the errors to reproduce the correct data.

A loader which has a checksum therefore is better than a loader that doesn't have a checksum, because the checksum will verify that the data is correct or incorrect.

With a loader which doesn't have a checksum, you have no way to verify the data, and therefore you can't guarantee that the data is identical to the original.

In this case, the only way to test that the data is correct is to make multiple transfers of the program and test each thoroughly (e.g. if the program is a game, you would play the game to the end), checking for graphic corruption and bugs. If all of the transfers operate the same, then you can assume that the data is correct.

== Various Audio file formats ==

There are numerous Audio file formats, each of which can store audio, but each has it's own structures and representation for the data.

The "format" of a file describes the internal structure, order and encoding of the data within the file.

Here is a list of the audio file formats supported by samp2cdt:

* Windows Wave file (a file which has the ".wav" file extension) is the common file format used for audio sounds on computers running "Windows".
* A Voice Wave file (a file which has the ".voc" file extension) was created by Creative for the original Soundblaster ISA sound card. This file format is used by the original voc2tzx utility which samp2cdt was developed from.
* A Audio Interchange file (a file which has the ".aiff" or ".aif" file extension) is the common file format used for audio sounds on the Mac computer.
* A file which has the ".iff" file extension is the common file format used for audio sounds by the Amiga computer.

==Links==
[[Converting a tape-image into a audio file]]

[[Category:Hardware]][[Category:DATA Storage|*]][[Category:Music and sound]][[Category:CPC Internal Components]]

Cassette data information

2012-12-03T05:41:28Z

Db6128: /* Reading */ 8-bit signed numbers cannot represent both -128 and +128... unless you've hacked the universe

'''Translation note :'''
Cassette = Tape.

== Recording a sound ==

A sound is recorded by making a measurement of the amplitude of the sound at regular intervals which are defined by the ''sampling rate'' and to a vertical resolution (between the lowest and highest points on the wave) that is called the ''bit-depth''. The act of taking the measurement is often called ''sampling'' and each measurement unit is called a ''sample''. A file which contains samples is often called a waveform, sound sample, audio sample, ''etc.''

The sampling rate defines the rate/frequency at which the measurements are taken. The higher the sampling rate, the faster/more frequently the measurements are taken, and the higher the maximal frequency that can be represented by the signal. Conversely, the lower the sampling rate, the slower the measurements are taken, and the maximal frequency that can be stored is lower. The sample rate is described by the "Hz" unit of measurement. The "Hz" unit of measurement means "per second". Therefore, a sampling rate of 44010 Hz means 44010 measurements are taken each second (in other words, one measurement every 1/44010 th of a second).

If the sampling is too low, then changes in the sound which occur between each measurement will not be measured. Because higher audio frequencies are defined by oscillating more rapidly, this means that lower sampling rates can store only lower frequencies. Therefore, the faster the measurements are taken, the more accurate the recording will be, and thus the higher the quality of sound that can be recorded. Of course, at high sample rates, because there are many more measurements taken, the resulting size of the file (containing the audio data) can be large.

As should be familiar to CPC users with a little technical knowledge, a sample that uses 8-bits for storage can represent 256 distinct amplitude levels, and a sample which uses 16-bits for storage can describe 65536 distinct amplitude levels. The higher the number of bits used by each sample for storage, the larger the range of distinct amplitude levels that can be represented. Therefore, the higher the number of bits used by each sample for storage, the higher the quality of sound that can be recorded. Moreover, the number of bits is directly related to the dynamic range of the resulting signal; that is, how much of a difference there is between the quietest and loudest sounds that it can represent. 16-bit signals provide a nominal 96 dB of dynamic range.

===What settings should you use?===

All modern sound cards should support 8-bit and 16-bit samples and sample rates of 22050 Hz and 44100 Hz. Some sound cards will support a greater range of recording rates which can be lower and higher than these values. The familiar format of CD audio uses a sampling rate of 44100 Hz and a bit-depth of 16-bits. These values are more than adequate to represent almost all real-world signals for listening by humans - and also, conveniently, are fine for Amstrad tapes, too! In fact, in theory, because the standard Amstrad tape routines have a maximal frequency of 2500 Hz, settings as low as 8000 Hz and 8 bits would probably be fine. However, you will probably want to use higher settings, just in case and/or to keep in line with more common formats such as CD audio, especially if you intend to archive your recordings.

For samp2cdt, you should save the file as "PCM" ("Pulse Code Modulation"). This is a uncompressed, unencoded storage representation. Each sample is a single measurement of the amplitude of the sound taken at a measurement point in time. Other representations such as "ADPCM" ("Amplitude Delta Pulse Code Modulation"), encode or compress the data to reduce the size of the audio file. Samp2cdt can't understand these representations, so please use "PCM" only.

===Illustrations and explanations of digital audio===

[[Image:wave1.gif]]

''Fig 1. An amplitude/time graph showing the waveform of the original sound''

[[Image:wave2.gif]]

''Fig 2. An amplitude/time graph showing the waveform of the original sound. The crosses indicate the amplitude measured at each sample time and the dotted lines indicate the the time of each measurement. The duration of time between each dotted line, defined by the sample rate, is equal to the duration of a sample. From this it can be seen that each sample has a finite and equal duration.''

[[Image:wave3.gif]]

''Fig 3. An amplitude/time graph showing the waveform of the original sound. As in Fig 2, the crosses indicate the amplitude measured at each sample time. The dotted line shows the waveform generated by sampling. The final value of each sample is defined to be the amplitude measured at the time of measurement.''

[[Image:wave4.gif]]

''Fig 4. An amplitude/time graph showing the sampled waveform. This waveform was generated at a high sample rate, and therefore the resulting waveform has a shape which is similar to the original. This waveform is the type you can see in a audio recording program like Goldwave. '''Note''', however, that this distinctively square signal is not what would be output by any barely decent sound-card! Audio hardware has built-in filters to smooth waveforms as they are converted from digital to analogue.''

[[Image:wave5.gif]]

''Fig 5. An amplitude/time graph showing the waveform of the original sound. As in Fig 2, this graph shows the amplitude of each measurement, and the dotted line indicates the time of measurement. This graph was created using a low sample rate. Notice that the time between each measurement is longer compared to Fig 2.''

[[Image:wave6.gif]]

''Fig 6. An amplitude/time graph showing the waveform of the original sound. As in Fig 3, the crosses indicate the amplitude measured at each sample time, and the dotted line shows the waveform generated by sampling. This graph shows the resulting waveform generated using a low sample rate.''

[[Image:wave7.gif]]

''Fig 7. An amplitude/time graph showing the sampled waveform. As explained in the note for Figure 4, this is only a visual representation of the digitally stored audio, '''not''' of the signal that would be output by any competent audio card. However, it does illustrate how low sampling rates reduce the bandwidth of frequencies: This waveform was generated at a low sample rate, and therefore the resulting waveform is much more coarse compared to Fig 4. Notice that although the general shape is similar to the original waveform, much of the smoothness is is lost between the time of each measurement. The loss of smoothness also means loss of information: the lower the sample rating, the more information is lost; in other words, the maximal frequencies that the signal can represent is lower. Similarly, lower bit-depths mean that the signal is less accurate, and in extreme cases can generate audible noise, Therefore, to record a sound, it is best to use relatively high sampling rate and bit-depth.''

Notes:

1. The "Nyquist theory" states that in order to accuratly record a sound of a known frequency, you must use a recording frequency which is more than twice that frequency (note "more than", not equal to). Example: to record a sound of 3000 Hz, you must record using >6000 Hz. If you use a lower sampling rate (e.g. 5000 Hz), frequencies less than or equal to half of the sampling rate cannot be properly represented and will be altered into lower-sounding frequencies.
Most Amstrad loaders are between 300 to 2500 Hz, therefore you should use a recording sample rate of >5000 Hz. It is recommended to use one of the common sample rates. e.g. 22050 Hz (22.05 Khz) or 44100 Hz (44.1 Khz).

2. There are two different representations to store the amplitude of the sample in a PCM audio file: unsigned or signed.
* A 8-bit unsigned sample has values between 0 and 255. In this range, 0 represents a low amplitudes, 255 a high amplitude, and the amplitudes increase linearly from 0 to 255.
* A 8-bit signed sample has values between -128 and 127. In this range, -128 represents a low amplitude, and 127 high amplitude, and the amplitudes increase linearly from -128 to 127.
Both methods can represent the same data, just in different ways (techies will be able to compare this to their knowledge of Z80 assembly), so there is no advantage to using either. The original reason for the two methods is due to the original method to playback the sound. Modern sound cards can play audio stored in both ways.
Note that both (albeit more obvious in the latter) share a feature typical of binary-encoded numbers: there is no exact 'centre' value, because the total number of possible values is even. In the context of audio, this means that, if the signal spanned the entire range, its centre (average) would be slightly off-zero (in this case, below), which is known as a DC offset. However, even if this did occur, it would be negligible and certainly not audible by humans!

== Duplication of cassettes ==

When the writing of a program is completed a "master" cassette is created. This cassette contains a audio representation of the computer data.

The master cassette is then duplicated, using a machine, onto many blank cassettes. These cassettes are packaged with instructions and distributed.

It is also easy to make a copy of a cassette if you have a twin cassette system, where one cassette unit will play the sound and the other will record. A first generation copy taken from a original cassette could be considered a copy of a copy of the master cassette.

Each time a cassette is copied however, additional noise may be introduced into the copied version. This noise is a mixture of noise from the original, and noise created by the machine making the copy. Therefore the sound on any cassette contains a mixture of noise and the sound of the computer data.

A loader on the computer must therefore be able to identify the actual sound of the data from other sounds that are on the cassette. If it can't do this, then there will be loading errors.

If you are transfering a cassette using samp2cdt, then you are advised to use an original (i.e. a cassette created directly from a master cassette), or a first generation copy (i.e. a cassette copied from an original).

== Loader ==

A "loader" is the name given to a program that reads data from cassette into the computer memory.

There is a "system" loader which is built into the Amstrad CPC ROM. This loader is activated when the computer is in cassette mode (note 1), and it can only understand one specific computer audio sound, the audio sound of the Amstrad CPC system data-blocks.

To read other loading systems (e.g. a fast-loader), there must be a program on the cassette (a "pre-loader" or "boot loader" or sometimes refered to as "loader"), stored using the Amstrad CPC system loader, which when executed will be able to understand and load fast-loader data.

This loader program is usually stored immediatly before any fast-loader blocks, and takes over from the system loader to load the remaining fast-loader blocks.

|program for fast-loader| |fast-loader block(s)|

So when a cassette is loaded the following occurs:

1. system loader recognises and loads "program for fast-loader".
2. "program for fast loader" takes control and loads the data from the fast-loader block(s) into computer memory
3. when loading has completed, the program is executed.

Notes:

1. a CPC without a disc interface (e.g. a CPC464, CPC464+ or KC Compact) will start-up in cassette mode. For a CPC with a disc interface attached (or internal), you must type |TAPE to enter cassette mode.

You can test if the computer is operating in cassette mode by typing RUN". If you see "Press PLAY then any key", then the computer is operating in cassette mode. If there is an error, then the computer is not operating in cassette mode.

== Amstrad cassette hardware ==

=== Reading ===

The audio from the cassette is read from a cassette player through the Amstrad's cassette electronics.

The Amstrad's cassette electronics converts the amplitude of the sound (a analogue signal) into a "0" or "1" measurement (a digital signal). This measurement can then be read from bit 7 of port B of the PPI 8255 IC.

[[Image:conv.gif]]

''Fig 8. This image shows the conversion of the audio waveform from the cassette into the digital representation by the Amstrad's cassette electronics. i.e. audio waveform (on cassette) -> Amstrad's cassette electronics -> 0 and 1 measurements''

The resulting measurements can be read using the following Z80 instructions:

<pre>
ld b,&f5 ;; I/O port address for PPI 8255 port B
;; (PPI 8255 port B is operating as input.)
in a,(c) ;; read port B inputs
and %10000000 ;; isolate bit 7 which contains the measurement.
</pre>

This measurement is *not* the actual state of a data-bit, but represents a low ("0") or high amplitude ("1"). In this document, the value of this measurement will be refered to as a "high" ("1") or "low" ("0") level.

Notes:

1. The CPC464 and CPC464+ have a cassette player built in. To connect a cassette player to the CPC664, CPC6128 or KC Compact then you must use a lead.
2. It is not known exactly how the amplitude of the sound from the cassette corresponds to the final "0" or "1" measurement.

samp2cdt uses a crude method to perform this conversion.

For a 8-bit signed sample:

* if the amplitude is 0..127, then the final measurement will be "1".
* if the amplitude is -128..0 then the final measurement will be "0".

=== Writing ===

A waveform is written to cassette using bit 5 of port C of the 8255 PPI IC. The waveform can only be defined by a high or low level, defined by the state of bit 5, which is then converted by the Amstrad's cassette electronics into a final output amplitude which is recorded onto cassette.

A high level can be written using the following Z80 instructions:

<pre>
ld b,&f6 ;; I/O port address for PPI 8255 port C
;; (PPI 8255 port C is operating as output.)

set 5,a ;; set cassette write output to high level
out (c),a ;; output level
</pre>

A low level can be written using the following Z80 instructions:

<pre>
ld b,&f6 ;; I/O port address for PPI 8255 port C
;; (PPI 8255 port C is operating as output.)

res 5,a ;; set cassette write output to low level
out (c),a ;; output level
</pre>

The amplitude of the output waveform is not amplified, therefore if you wish to record the cassette audio direct from an Amstrad you will need to amplify the waveform.

If the state of bit 5 is changed at a fixed frequency, then the graph of the state of bit 5 over time will be a square wave. However, the resulting audio written on the cassette will not be a perfect square wave because nature will attempt to convert the waveform into a sine wave.
Loading system audio waveform

Every loading system on the Amstrad uses a serial bit-stream. i.e. a single bit of information is read at a time.

This serial bit-stream is grouped into blocks of audio sound.

Every loading system uses a basic structure to describe each audio block in the following order:

|pilot|sync|data|trailer|

'''pilot'''

This is also refered to as "leader" by some documents.

This is constructed from a repeated waveform often with a fixed number of repetitions defined by the loading system.

The shape of the waveform is known by the loader program and this is used to identify the pilot waveform from other waveforms that may be present (e.g. noise).

The pilot is often long, so that the loader doesn't need to see the start of the pilot waveform in order to load the block.

The loader program will test the incoming waveform, checking it against the parameters defined for the pilot, before the waveform is accepted as the pilot waveform. (e.g. the number of repetitions must be some defined minimum value). The incoming waveform must fall within these specifications otherwise the waveform is not accepted as a pilot waveform.

'''sync ("synchronisation")'''

The sync is a waveform which is different to the pilot, and this defines the end of the pilot and the start of the data. When this sync has been detected, the loader knows that there is data following, and that the loader is always at the same point in the data stream. i.e. the loader program is synchronised to a specific point in the data waveform.

'''data'''

This is the actual data which is composed of waveforms defining "0" and "1" data bits.

The first element of the data may be a marker or id which may, for example, indicate the type of data in the block or the number of the block.

The remaining bits will define the data and zero or more checksums.

The whole data may consist of a single block with a single location and length (e.g. one block for a screen another for data), or multiple blocks each with their own location and length. (e.g. one block for screen and data)

The location and lengths of the blocks may be in the data stream itself, or they may be in a preceeding block, or may be hard-coded into the loader program.

'''trailer'''

The trailer always follows the data. Some loaders may not have a trailer. The two main purposes of the trailer are to ensure that the waveform of the last data bit in the data is constructed correctly and to provide some time in which the loader can prepare for the next block.

The exact definition of the loading systems's audio waveform is defined by the loader program.

samp2cdt has a number of decoder algorithms which recognises the audio waveform of various loading systems. These decoders read the waveform using a similar method to the loader program itself. These decoders have been created by examining the instructions of each loader program and the graph of the waveform in a sound recording package.

== Example of a typical loading system ==

The data on cassette actually consists of changing 0 and 1 levels. (a "level" is a magnitude of a value). The loader measures the time between each "level transition" where a "level transition" is the change from a "0" to a "1" level or the change from a "1" to a "0" level. The level can be timed using the following Z80 instructions:

<pre>
;; - keep testing the state of bit 7 of PPI 8255 port B
;; - update the counter to record the number of tests done
;; - when bit 7 of PPI 8255 port B changes state, stop testing.
;; counter will hold the total number of tests made.
;;
;; B = &F5 (I/O address of PPI 8255 input port B)
;; C = previous data read from PPI port B ld d,0
;; initialise count to 0 .loop inc d
;; increment count in a,(c)
;; read input to PPI 8255 port B xor c
;; exclusive-or with previous data read from PPI 8255 port B and %10000000
;; isolate bit 7
;; if result is 0, then the state of bit 7 that has
;; been read is the same as the previous state. i.e. bit 7 has not changed state.
;; if result is not 0, then the state of bit 7 has changed.
;; e.g. if bit 7 was previously 1, it is now 0. if bit 7 was previously 0, it is now 1. jr z,loop
;; when execution reaches here we know that bit 7 has changed state and D
;; contains the number of tests.
</pre>

== Loader operation==

The loader generally operates in this way:

1. Time a wave. Is the duration of the wave within the minimum and maximum duration required for the pilot. If yes, go to 2, else go to 1.

2. We might have seen a wave from the pilot signal. time a wave. Is the duration of this wave within the minimum and maximum duration required for the pilot. If yes, increment number of waves seen, go to 2, else go to 1.

3. Have we seen the minimum number of pilot waves? Yes, go to 4, else go to 2. 4. time a wave. Is the duration of the wave within the minimum and maximum duration required for the sync? 2. Each Z80 instruction takes a finite time to execute. The execution time depends on the computer. If the timing of the Z80 instructions used by the test algorithm is known and predictable, then the time for each test can be calculated. Now, since the count represents the number of tests made before the condition is true (i.e. bit 7 changes state), the total time for the condition to be true, is the sum of the time for each test made. If each test always takes the same time, then the total time is the number of tests multiplied by the time for one test. In the Amstrad computer, all Z80 instructions execute in multiples of 1us (microsecond) regardless of their location in RAM. This fact simplifies this calculation.
Checksum

A "Checksum" is used to verify the loaded data.

A Checksum is the result of the "checksum calculation" made on a block of data. The actual calculation can be different depending on the method chosen.

There are two "Checksum"s.

1. a stored "Checksum".

This is the result of the "checksum calculation" calculated from the correct data. This is then stored with the data (e.g. before or after the data) when the master cassette is created.
2. a calculated "Checksum".

This is the result of the "checksum calculation" calculated from the data read from the cassette. After the calculation is complete it is compared against the stored checksum.

The stored and calculated "Checksums" are initialised with the same initial value and calculated using the same algorithm. Therefore, if the stored checksum matches the calculated checksum, it is assumed that the loaded data is identical to the original data. The data is verified to be correct.

If the stored checksum doesn't match the calculated checksum, then there has been a error. One or more bit's of data is incorrect. The checksum is designed to detect errors only, and often it is not possible to know which bit or bits of data is incorrect and in this case it is not often possible to correct the errors to reproduce the correct data.

A loader which has a checksum therefore is better than a loader that doesn't have a checksum, because the checksum will verify that the data is correct or incorrect.

With a loader which doesn't have a checksum, you have no way to verify the data, and therefore you can't guarantee that the data is identical to the original.

In this case, the only way to test that the data is correct is to make multiple transfers of the program and test each thoroughly (e.g. if the program is a game, you would play the game to the end), checking for graphic corruption and bugs. If all of the transfers operate the same, then you can assume that the data is correct.

== Various Audio file formats ==

There are numerous Audio file formats, each of which can store audio, but each has it's own structures and representation for the data.

The "format" of a file describes the internal structure, order and encoding of the data within the file.

Here is a list of the audio file formats supported by samp2cdt:

* Windows Wave file (a file which has the ".wav" file extension) is the common file format used for audio sounds on computers running "Windows".
* A Voice Wave file (a file which has the ".voc" file extension) was created by Creative for the original Soundblaster ISA sound card. This file format is used by the original voc2tzx utility which samp2cdt was developed from.
* A Audio Interchange file (a file which has the ".aiff" or ".aif" file extension) is the common file format used for audio sounds on the Mac computer.
* A file which has the ".iff" file extension is the common file format used for audio sounds by the Amiga computer.

==Links==
[[Converting a tape-image into a audio file]]

[[Category:Hardware]][[Category:DATA Storage|*]][[Category:Music and sound]][[Category:CPC Internal Components]]

Cassette data information

2012-12-03T05:40:31Z

Db6128: /* Recording a sound */ intended to clarify a few things, mostly ended up rambling :S

'''Translation note :'''
Cassette = Tape.

== Recording a sound ==

A sound is recorded by making a measurement of the amplitude of the sound at regular intervals which are defined by the ''sampling rate'' and to a vertical resolution (between the lowest and highest points on the wave) that is called the ''bit-depth''. The act of taking the measurement is often called ''sampling'' and each measurement unit is called a ''sample''. A file which contains samples is often called a waveform, sound sample, audio sample, ''etc.''

The sampling rate defines the rate/frequency at which the measurements are taken. The higher the sampling rate, the faster/more frequently the measurements are taken, and the higher the maximal frequency that can be represented by the signal. Conversely, the lower the sampling rate, the slower the measurements are taken, and the maximal frequency that can be stored is lower. The sample rate is described by the "Hz" unit of measurement. The "Hz" unit of measurement means "per second". Therefore, a sampling rate of 44010 Hz means 44010 measurements are taken each second (in other words, one measurement every 1/44010 th of a second).

If the sampling is too low, then changes in the sound which occur between each measurement will not be measured. Because higher audio frequencies are defined by oscillating more rapidly, this means that lower sampling rates can store only lower frequencies. Therefore, the faster the measurements are taken, the more accurate the recording will be, and thus the higher the quality of sound that can be recorded. Of course, at high sample rates, because there are many more measurements taken, the resulting size of the file (containing the audio data) can be large.

As should be familiar to CPC users with a little technical knowledge, a sample that uses 8-bits for storage can represent 256 distinct amplitude levels, and a sample which uses 16-bits for storage can describe 65536 distinct amplitude levels. The higher the number of bits used by each sample for storage, the larger the range of distinct amplitude levels that can be represented. Therefore, the higher the number of bits used by each sample for storage, the higher the quality of sound that can be recorded. Moreover, the number of bits is directly related to the dynamic range of the resulting signal; that is, how much of a difference there is between the quietest and loudest sounds that it can represent. 16-bit signals provide a nominal 96 dB of dynamic range.

===What settings should you use?===

All modern sound cards should support 8-bit and 16-bit samples and sample rates of 22050 Hz and 44100 Hz. Some sound cards will support a greater range of recording rates which can be lower and higher than these values. The familiar format of CD audio uses a sampling rate of 44100 Hz and a bit-depth of 16-bits. These values are more than adequate to represent almost all real-world signals for listening by humans - and also, conveniently, are fine for Amstrad tapes, too! In fact, in theory, because the standard Amstrad tape routines have a maximal frequency of 2500 Hz, settings as low as 8000 Hz and 8 bits would probably be fine. However, you will probably want to use higher settings, just in case and/or to keep in line with more common formats such as CD audio, especially if you intend to archive your recordings.

For samp2cdt, you should save the file as "PCM" ("Pulse Code Modulation"). This is a uncompressed, unencoded storage representation. Each sample is a single measurement of the amplitude of the sound taken at a measurement point in time. Other representations such as "ADPCM" ("Amplitude Delta Pulse Code Modulation"), encode or compress the data to reduce the size of the audio file. Samp2cdt can't understand these representations, so please use "PCM" only.

===Illustrations and explanations of digital audio===

[[Image:wave1.gif]]

''Fig 1. An amplitude/time graph showing the waveform of the original sound''

[[Image:wave2.gif]]

''Fig 2. An amplitude/time graph showing the waveform of the original sound. The crosses indicate the amplitude measured at each sample time and the dotted lines indicate the the time of each measurement. The duration of time between each dotted line, defined by the sample rate, is equal to the duration of a sample. From this it can be seen that each sample has a finite and equal duration.''

[[Image:wave3.gif]]

''Fig 3. An amplitude/time graph showing the waveform of the original sound. As in Fig 2, the crosses indicate the amplitude measured at each sample time. The dotted line shows the waveform generated by sampling. The final value of each sample is defined to be the amplitude measured at the time of measurement.''

[[Image:wave4.gif]]

''Fig 4. An amplitude/time graph showing the sampled waveform. This waveform was generated at a high sample rate, and therefore the resulting waveform has a shape which is similar to the original. This waveform is the type you can see in a audio recording program like Goldwave. '''Note''', however, that this distinctively square signal is not what would be output by any barely decent sound-card! Audio hardware has built-in filters to smooth waveforms as they are converted from digital to analogue.''

[[Image:wave5.gif]]

''Fig 5. An amplitude/time graph showing the waveform of the original sound. As in Fig 2, this graph shows the amplitude of each measurement, and the dotted line indicates the time of measurement. This graph was created using a low sample rate. Notice that the time between each measurement is longer compared to Fig 2.''

[[Image:wave6.gif]]

''Fig 6. An amplitude/time graph showing the waveform of the original sound. As in Fig 3, the crosses indicate the amplitude measured at each sample time, and the dotted line shows the waveform generated by sampling. This graph shows the resulting waveform generated using a low sample rate.''

[[Image:wave7.gif]]

''Fig 7. An amplitude/time graph showing the sampled waveform. As explained in the note for Figure 4, this is only a visual representation of the digitally stored audio, '''not''' of the signal that would be output by any competent audio card. However, it does illustrate how low sampling rates reduce the bandwidth of frequencies: This waveform was generated at a low sample rate, and therefore the resulting waveform is much more coarse compared to Fig 4. Notice that although the general shape is similar to the original waveform, much of the smoothness is is lost between the time of each measurement. The loss of smoothness also means loss of information: the lower the sample rating, the more information is lost; in other words, the maximal frequencies that the signal can represent is lower. Similarly, lower bit-depths mean that the signal is less accurate, and in extreme cases can generate audible noise, Therefore, to record a sound, it is best to use relatively high sampling rate and bit-depth.''

Notes:

1. The "Nyquist theory" states that in order to accuratly record a sound of a known frequency, you must use a recording frequency which is more than twice that frequency (note "more than", not equal to). Example: to record a sound of 3000 Hz, you must record using >6000 Hz. If you use a lower sampling rate (e.g. 5000 Hz), frequencies less than or equal to half of the sampling rate cannot be properly represented and will be altered into lower-sounding frequencies.
Most Amstrad loaders are between 300 to 2500 Hz, therefore you should use a recording sample rate of >5000 Hz. It is recommended to use one of the common sample rates. e.g. 22050 Hz (22.05 Khz) or 44100 Hz (44.1 Khz).

2. There are two different representations to store the amplitude of the sample in a PCM audio file: unsigned or signed.
* A 8-bit unsigned sample has values between 0 and 255. In this range, 0 represents a low amplitudes, 255 a high amplitude, and the amplitudes increase linearly from 0 to 255.
* A 8-bit signed sample has values between -128 and 127. In this range, -128 represents a low amplitude, and 127 high amplitude, and the amplitudes increase linearly from -128 to 127.
Both methods can represent the same data, just in different ways (techies will be able to compare this to their knowledge of Z80 assembly), so there is no advantage to using either. The original reason for the two methods is due to the original method to playback the sound. Modern sound cards can play audio stored in both ways.
Note that both (albeit more obvious in the latter) share a feature typical of binary-encoded numbers: there is no exact 'centre' value, because the total number of possible values is even. In the context of audio, this means that, if the signal spanned the entire range, its centre (average) would be slightly off-zero (in this case, below), which is known as a DC offset. However, even if this did occur, it would be negligible and certainly not audible by humans!

== Duplication of cassettes ==

When the writing of a program is completed a "master" cassette is created. This cassette contains a audio representation of the computer data.

The master cassette is then duplicated, using a machine, onto many blank cassettes. These cassettes are packaged with instructions and distributed.

It is also easy to make a copy of a cassette if you have a twin cassette system, where one cassette unit will play the sound and the other will record. A first generation copy taken from a original cassette could be considered a copy of a copy of the master cassette.

Each time a cassette is copied however, additional noise may be introduced into the copied version. This noise is a mixture of noise from the original, and noise created by the machine making the copy. Therefore the sound on any cassette contains a mixture of noise and the sound of the computer data.

A loader on the computer must therefore be able to identify the actual sound of the data from other sounds that are on the cassette. If it can't do this, then there will be loading errors.

If you are transfering a cassette using samp2cdt, then you are advised to use an original (i.e. a cassette created directly from a master cassette), or a first generation copy (i.e. a cassette copied from an original).

== Loader ==

A "loader" is the name given to a program that reads data from cassette into the computer memory.

There is a "system" loader which is built into the Amstrad CPC ROM. This loader is activated when the computer is in cassette mode (note 1), and it can only understand one specific computer audio sound, the audio sound of the Amstrad CPC system data-blocks.

To read other loading systems (e.g. a fast-loader), there must be a program on the cassette (a "pre-loader" or "boot loader" or sometimes refered to as "loader"), stored using the Amstrad CPC system loader, which when executed will be able to understand and load fast-loader data.

This loader program is usually stored immediatly before any fast-loader blocks, and takes over from the system loader to load the remaining fast-loader blocks.

|program for fast-loader| |fast-loader block(s)|

So when a cassette is loaded the following occurs:

1. system loader recognises and loads "program for fast-loader".
2. "program for fast loader" takes control and loads the data from the fast-loader block(s) into computer memory
3. when loading has completed, the program is executed.

Notes:

1. a CPC without a disc interface (e.g. a CPC464, CPC464+ or KC Compact) will start-up in cassette mode. For a CPC with a disc interface attached (or internal), you must type |TAPE to enter cassette mode.

You can test if the computer is operating in cassette mode by typing RUN". If you see "Press PLAY then any key", then the computer is operating in cassette mode. If there is an error, then the computer is not operating in cassette mode.

== Amstrad cassette hardware ==

=== Reading ===

The audio from the cassette is read from a cassette player through the Amstrad's cassette electronics.

The Amstrad's cassette electronics converts the amplitude of the sound (a analogue signal) into a "0" or "1" measurement (a digital signal). This measurement can then be read from bit 7 of port B of the PPI 8255 IC.

[[Image:conv.gif]]

''Fig 8. This image shows the conversion of the audio waveform from the cassette into the digital representation by the Amstrad's cassette electronics. i.e. audio waveform (on cassette) -> Amstrad's cassette electronics -> 0 and 1 measurements''

The resulting measurements can be read using the following Z80 instructions:

<pre>
ld b,&f5 ;; I/O port address for PPI 8255 port B
;; (PPI 8255 port B is operating as input.)
in a,(c) ;; read port B inputs
and %10000000 ;; isolate bit 7 which contains the measurement.
</pre>

This measurement is *not* the actual state of a data-bit, but represents a low ("0") or high amplitude ("1"). In this document, the value of this measurement will be refered to as a "high" ("1") or "low" ("0") level.

Notes:

1. The CPC464 and CPC464+ have a cassette player built in. To connect a cassette player to the CPC664, CPC6128 or KC Compact then you must use a lead.
2. It is not known exactly how the amplitude of the sound from the cassette corresponds to the final "0" or "1" measurement.

samp2cdt uses a crude method to perform this conversion.

For a 8-bit signed sample:

* if the amplitude is 0..128, then the final measurement will be "1".
* if the amplitude is -128..0 then the final measurement will be "0".

=== Writing ===

A waveform is written to cassette using bit 5 of port C of the 8255 PPI IC. The waveform can only be defined by a high or low level, defined by the state of bit 5, which is then converted by the Amstrad's cassette electronics into a final output amplitude which is recorded onto cassette.

A high level can be written using the following Z80 instructions:

<pre>
ld b,&f6 ;; I/O port address for PPI 8255 port C
;; (PPI 8255 port C is operating as output.)

set 5,a ;; set cassette write output to high level
out (c),a ;; output level
</pre>

A low level can be written using the following Z80 instructions:

<pre>
ld b,&f6 ;; I/O port address for PPI 8255 port C
;; (PPI 8255 port C is operating as output.)

res 5,a ;; set cassette write output to low level
out (c),a ;; output level
</pre>

The amplitude of the output waveform is not amplified, therefore if you wish to record the cassette audio direct from an Amstrad you will need to amplify the waveform.

If the state of bit 5 is changed at a fixed frequency, then the graph of the state of bit 5 over time will be a square wave. However, the resulting audio written on the cassette will not be a perfect square wave because nature will attempt to convert the waveform into a sine wave.
Loading system audio waveform

Every loading system on the Amstrad uses a serial bit-stream. i.e. a single bit of information is read at a time.

This serial bit-stream is grouped into blocks of audio sound.

Every loading system uses a basic structure to describe each audio block in the following order:

|pilot|sync|data|trailer|

'''pilot'''

This is also refered to as "leader" by some documents.

This is constructed from a repeated waveform often with a fixed number of repetitions defined by the loading system.

The shape of the waveform is known by the loader program and this is used to identify the pilot waveform from other waveforms that may be present (e.g. noise).

The pilot is often long, so that the loader doesn't need to see the start of the pilot waveform in order to load the block.

The loader program will test the incoming waveform, checking it against the parameters defined for the pilot, before the waveform is accepted as the pilot waveform. (e.g. the number of repetitions must be some defined minimum value). The incoming waveform must fall within these specifications otherwise the waveform is not accepted as a pilot waveform.

'''sync ("synchronisation")'''

The sync is a waveform which is different to the pilot, and this defines the end of the pilot and the start of the data. When this sync has been detected, the loader knows that there is data following, and that the loader is always at the same point in the data stream. i.e. the loader program is synchronised to a specific point in the data waveform.

'''data'''

This is the actual data which is composed of waveforms defining "0" and "1" data bits.

The first element of the data may be a marker or id which may, for example, indicate the type of data in the block or the number of the block.

The remaining bits will define the data and zero or more checksums.

The whole data may consist of a single block with a single location and length (e.g. one block for a screen another for data), or multiple blocks each with their own location and length. (e.g. one block for screen and data)

The location and lengths of the blocks may be in the data stream itself, or they may be in a preceeding block, or may be hard-coded into the loader program.

'''trailer'''

The trailer always follows the data. Some loaders may not have a trailer. The two main purposes of the trailer are to ensure that the waveform of the last data bit in the data is constructed correctly and to provide some time in which the loader can prepare for the next block.

The exact definition of the loading systems's audio waveform is defined by the loader program.

samp2cdt has a number of decoder algorithms which recognises the audio waveform of various loading systems. These decoders read the waveform using a similar method to the loader program itself. These decoders have been created by examining the instructions of each loader program and the graph of the waveform in a sound recording package.

== Example of a typical loading system ==

The data on cassette actually consists of changing 0 and 1 levels. (a "level" is a magnitude of a value). The loader measures the time between each "level transition" where a "level transition" is the change from a "0" to a "1" level or the change from a "1" to a "0" level. The level can be timed using the following Z80 instructions:

<pre>
;; - keep testing the state of bit 7 of PPI 8255 port B
;; - update the counter to record the number of tests done
;; - when bit 7 of PPI 8255 port B changes state, stop testing.
;; counter will hold the total number of tests made.
;;
;; B = &F5 (I/O address of PPI 8255 input port B)
;; C = previous data read from PPI port B ld d,0
;; initialise count to 0 .loop inc d
;; increment count in a,(c)
;; read input to PPI 8255 port B xor c
;; exclusive-or with previous data read from PPI 8255 port B and %10000000
;; isolate bit 7
;; if result is 0, then the state of bit 7 that has
;; been read is the same as the previous state. i.e. bit 7 has not changed state.
;; if result is not 0, then the state of bit 7 has changed.
;; e.g. if bit 7 was previously 1, it is now 0. if bit 7 was previously 0, it is now 1. jr z,loop
;; when execution reaches here we know that bit 7 has changed state and D
;; contains the number of tests.
</pre>

== Loader operation==

The loader generally operates in this way:

1. Time a wave. Is the duration of the wave within the minimum and maximum duration required for the pilot. If yes, go to 2, else go to 1.

2. We might have seen a wave from the pilot signal. time a wave. Is the duration of this wave within the minimum and maximum duration required for the pilot. If yes, increment number of waves seen, go to 2, else go to 1.

3. Have we seen the minimum number of pilot waves? Yes, go to 4, else go to 2. 4. time a wave. Is the duration of the wave within the minimum and maximum duration required for the sync? 2. Each Z80 instruction takes a finite time to execute. The execution time depends on the computer. If the timing of the Z80 instructions used by the test algorithm is known and predictable, then the time for each test can be calculated. Now, since the count represents the number of tests made before the condition is true (i.e. bit 7 changes state), the total time for the condition to be true, is the sum of the time for each test made. If each test always takes the same time, then the total time is the number of tests multiplied by the time for one test. In the Amstrad computer, all Z80 instructions execute in multiples of 1us (microsecond) regardless of their location in RAM. This fact simplifies this calculation.
Checksum

A "Checksum" is used to verify the loaded data.

A Checksum is the result of the "checksum calculation" made on a block of data. The actual calculation can be different depending on the method chosen.

There are two "Checksum"s.

1. a stored "Checksum".

This is the result of the "checksum calculation" calculated from the correct data. This is then stored with the data (e.g. before or after the data) when the master cassette is created.
2. a calculated "Checksum".

This is the result of the "checksum calculation" calculated from the data read from the cassette. After the calculation is complete it is compared against the stored checksum.

The stored and calculated "Checksums" are initialised with the same initial value and calculated using the same algorithm. Therefore, if the stored checksum matches the calculated checksum, it is assumed that the loaded data is identical to the original data. The data is verified to be correct.

If the stored checksum doesn't match the calculated checksum, then there has been a error. One or more bit's of data is incorrect. The checksum is designed to detect errors only, and often it is not possible to know which bit or bits of data is incorrect and in this case it is not often possible to correct the errors to reproduce the correct data.

A loader which has a checksum therefore is better than a loader that doesn't have a checksum, because the checksum will verify that the data is correct or incorrect.

With a loader which doesn't have a checksum, you have no way to verify the data, and therefore you can't guarantee that the data is identical to the original.

In this case, the only way to test that the data is correct is to make multiple transfers of the program and test each thoroughly (e.g. if the program is a game, you would play the game to the end), checking for graphic corruption and bugs. If all of the transfers operate the same, then you can assume that the data is correct.

== Various Audio file formats ==

There are numerous Audio file formats, each of which can store audio, but each has it's own structures and representation for the data.

The "format" of a file describes the internal structure, order and encoding of the data within the file.

Here is a list of the audio file formats supported by samp2cdt:

* Windows Wave file (a file which has the ".wav" file extension) is the common file format used for audio sounds on computers running "Windows".
* A Voice Wave file (a file which has the ".voc" file extension) was created by Creative for the original Soundblaster ISA sound card. This file format is used by the original voc2tzx utility which samp2cdt was developed from.
* A Audio Interchange file (a file which has the ".aiff" or ".aif" file extension) is the common file format used for audio sounds on the Mac computer.
* A file which has the ".iff" file extension is the common file format used for audio sounds by the Amiga computer.

==Links==
[[Converting a tape-image into a audio file]]

[[Category:Hardware]][[Category:DATA Storage|*]][[Category:Music and sound]][[Category:CPC Internal Components]]

KC Compact

2012-12-02T22:06:11Z

Db6128: correct user link

''Note: Much of this article was originally written by [[User:CPCLER|CPCLER]], and so any references in the first person ("I", "me", ''etc.'') are probably by him.

[[Image:Kcc top.jpg|right|thumb|250px|The East German KC Compact Computer]]

== Background ==

The KC compact is a [[Clones|clone]] of the Amstrad CPC and was developed by a East German company called RFT.

The computer was designed in 1989 and made to celebrate 40 years of the DDR/GDR (Deutsche Demokratische Republik/German Democratic Republic). A year later the Berlin wall came down and East and West Germany were joined together and the DDR/GDR came to an end. Production of the computer halted, and it was only available for a short time and is rare.

I read about the KC compact in the Amscene section of Amstrad Action magazine, a Future Publishing Ltd publication. From that point I was hooked and I eventually wanted to own one.

During this time I found Andreas Krueger, webmaster of the Robotron-Net website, who owned one of these computers. Andreas was very helpful and provided photocopies of a manual and the schematics, a dump of the roms, ran some tests for me and more. I want to send him a big thankyou for all the help he gave.

In the last few months (May 2001) I contacted Thomas Tratz who owns a KC Compact. Thomas Tratz runs a great website for QuickBASIC. He has given me many of the original manuals, original software, and I bought a real KC Compact from his cousin! A big thankyou to Thomas and his cousin!

The case of the KC compact is the same as the Robotron BIC A5105, but has different hardware inside. The KC Compact I have does not have a information sticker on the underside, but information for the A5105!

Many of the IC's inside are Russian and clones of other IC's. (The UA880 is a clone of the Zilog Z80, and the U82536 is a clone of the Zilog Z8536).

I know of only a few people who have a real KC Compact (Andreas Kruger, Thomas Tratz, Frank Salmon of Oldbits computer collection and myself), if there are others please contact me and I will make a list of KC Compact owners, and you will be members of an exclusive club! :)

This document will describe the hardware and software differences (that are known) between this system and the Amstrad CPC.

== Alternative power supply ==

With the help of Darren Jarvis I now have a new power supply for my KC Compact. He gave me a power pack from a PC laptop, and with a special lead, this works perfectly on the KC Compact.

PC laptop power pack details:

LISHIN INTERNATIONAL ENTERPRISE CORP. AC ADAPTOR.

MODEL: LSE9802A1960

INPUT: 100-240V A.C. 50/60Hz 1.5A

OUTPUT: 19V D.C. 3.16A. 60W MAX

The power pack has a 3.5mm power plug at the end.

I made a lead which has a 3.5mm power socket and a telefunktion socket.

== External power supply ==

The official external power modulator provides +20V,-20V DC (err... more probably +20V and 0V) with 500mA (believed to be un-smoothed), from a source of ~220V at 50Hz.

The external power modulator is connected to the computer's internal power modulator, which generates a smoothed 12V and 5V outputs and these provide the power for the IC's. Most or all runs at 5V. The 12V are used for the built-in TV modulator, and is also output to the Expansion Port and Scart connector (and, not sure, maybe used elsewhere, too)

The internal power supply is very tolerant and the computer will run with input voltages as low as 6V, but the colours in the palette are weak. If the voltage is increased, the colours become strong, and around 18V-20V, they are all correct. If a low input voltage is used, it is likely that the 12V power output on the expansion connector will not be correct.

The connector is believed to be a Telefunken Line socket (Maplins catalogue reference: FT99H). If you can't find this connector then you can make a suitable connector using a power lead and a sharp craft knife.

== Software differences ==

The base system has 32k of

* Locomotive BASIC v1.1 rom (identical to BASIC rom in English CPC6128) (16k)
* A modified operating system rom from an English CPC6128 (16k)

* Differences are:

:* Different start-up message
:* Computer names (Schneider, Awa, Solavox etc) removed.
:* Initialisation code for the CIO (see details below)
:* Test program transfer (see details below)

I believe most software will run, but I have not been able to test this, but programs that use the following may be broken:

* Programs that rely on exact Interrupt mechanism of the CPC6128
* Programs that call direct into the operating system rom (these may work, because the changes to the operating system rom are minor)
* Programs that rely on a unofficial hardware feature (I do not know of all hardware details, so I cannot say the level of compatibility)

The disc interface has a modified AMSDOS rom.

== Hardware differences ==

* The colour palette is not cleared to black on reset
* The Amstrad unofficial mode (bit 1=bit 0=1 of [[Gate Array]] mode register) does not exist. The clock to the shift registers is stopped. The last colour is output.
* The raster interrupt is generated in a different way by the CIO.

This section describes the known hardware differences. This information is not definitive. I do not know all differences,

== UA880 CPU (equivalent to Zilog Z80) ==

The KC compact uses a UA880 CPU, which is a Russian clone of the [[Z80]]. It is not confirmed whether there are any actual differences compared to a real Z80. In terms of documentation, the KC Compact System Handbook lists the opcodes SLL, INF [a.k.a. IN F,(C)], and OUTF [a.k.a. OUT (C),F], whereas these have remained undocumented by Zilog.

== Video ==

* The [[CRTC]] should be more or less same as those used in CPCs. The handbook and schematic say the CRTC is a CM 607, but the CRTC in CPCLER's an HD6845P.
* The clocks for each mode (0,1 and 2) are derived from the main 16Mhz clock, these then drive the shift registers to output pixels to the display.
* Mode 3 is hardwired to 5V, so it doesn't have a clock. The shift registers are stopped and output the last colour they clocked in. Even if this mode was activated in way of connecting up the clock for Mode 0 it is not decoded the same as on the CPC: 8 colours are chosen from the 16 colour palette, instead of 4.
* There may be a bug whereby if the border colour is changed rapidly there could be 1 pixel of another colour output. When loading a game which changes the colour of the border, I have seen moving "snow" on the screen. I have seen this effect, but I need to confirm how it is generated.
* The video output doesn't generate luminance, so the KC Compact can't be used with a GT64 or MM14.

== Colour-ROM ==

The KC compact has a colour-rom. Each byte in the ROM defines the R,G and B of an output colour.

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Bit''||''Function''
|-
|7||not used''
|-
|6||not used''
|-
|5||Green''
|-
|4||Green''
|-
|3||Red''
|-
|2||Red''
|-
|1||Blue''
|-
|0||Blue''
|-
|}

The hardware colour index (defined by the I/O write: A15="0", A14="1", D7="0", D6="1" D3-D0 define hardware colour index), is used as a look-up into the ROM.

Each colour-element (R, G or B) is defined using 2 bits and has the potential to define a total palette of 64 colours. The colour-rom only uses 3 of the 4 possible settings for each colour-element. Looking at the schematic, the potential is not realised, the two signals for each colour use the same resistors before being combined. This means that the bit combinations 10 and 01 produce the same result. So this means only 27 colours are possible.

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Element Bit 1''||''Element Bit 0''||Intensity''
|-
|0||0||Zero''
|-
|0||1||Half (same as 10)''
|-
|1||0||Half (same as 01)''
|-
|1||1||Full''
|-
|}

The colour ROM can be downloaded from the KC-Klub homepage.

== External connectors ==

=== Built-in connectors: pinout ===

* [[Connector:Cassette recorder|Cassette recorder]] - other pinout as CPC, motor control is TTL (not a relay)
* [[Connector:Digital joystick|Digital joystick]] - exactly as CPC (all 9 pins are exactly same)
* [[Connector:Expansion port|Expansion port]] - almost same as CPC (plus some extra pins: additional voltages, TEST feature, FBAS output)
* [[Connector:Monitor|Monitor]] - 21pin Scart connector, and UHF modulator
* [[Connector:Printer port|Printer port]] - almost same as CPC Plus (25pin)
* [[Connector:Stereo sound|Stereo sound]] - 5pin DIN (not 3.5mm)

=== Cassette socket ===

The Cassette socket has different connection assignments compared to the CPC, so you can't use a CPC cassette lead directly with the KC Compact.

I made a second lead which converted between KC Compact assignments and CPC assignments, which was connected between KC Compact and the CPC cassette lead.

I have been successfully loaded some CPC software.

=== Expansion socket ===

The KC compact has a real connector compared to the P.C.B. edge connector of an English CPC6128. The connector appears to be a PC Card connector. This connector is not the same as the one on a German CPC6128.

The expansion connector has more pins; 58 compared to 50 on an English CPC6128.

I am in the process of making an adaptor so that I can test CPC hardware on the KC Compact.

=== Parallel ===

On the KC compact the parallel port is connected to Port A of the CIO.

It is a general purpose I/O port. All 8-bits can be used for input or output. The input/output of each bit can be programmed. With standard setup, bit 7 is assigned to /STROBE, and bits 0-6 are assigned to Printer DATA, making a 7-bit printer port. Additionally, the 8th printer bit is implemented via Bit5 of PIO Port C (see [[8bit Printer Ports]]).

* The Amstrad CPC has a single-direction, 7-bit port.
* The KC Compact has a bi-directional, 8-bit port.

The KC compact parallel port is more powerful and flexible compared to the Amstrad CPC parallel port!

=== Keyboard ===

* The keyboard matrix of the KC compact supports all the keys of the CPC, but the following keys are not on the keyboard: F5, F6,F7,F8,F9.
* The KC Compact has a power LED (near CLR key). There are also (unused) locations for two additional LEDs (near TAB/CAPS key), eventually these locations are used by the D005 keyboard for KC-85 computers, or by the Robotron A5105 computer (both D005 and A5105 use the same case & keyboard as the KC Compact, aside from that, they have nothing to do with it).

== KP580BB55 PIO (equivalent to 8255 PPI) ==

Used (almost) identically as the CPC's [[8255]]. PIO Port B is slightly different:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|7||Cassette data read (identical to CPC)
|-
|6||Centronics/Printer Busy (identical to CPC)
|-
|5||/EXP (identical to CPC)
|-
|4||1 (+5v) (would be LK4 screen refresh rate in CPC) (but isn't like so in KC Compact?)
|-
|3||1 (+5v) (would be LK3 manufacturer ID in CPC)
|-
|2||0 (0v) (would be LK2 manufacturer ID in CPC)
|-
|1||/TEST (would be LK1 manufacturer ID in CPC)
|-
|0||VSYNC (identical to CPC)
|-
|}

* Note: The KC System Handbook accidently calls the chip "KP580B55", however, the correct name is "KP580BB55" (with double "B").

== U82536 CIO (equivalent to Zilog Z8536 CIO) ==

* [[CIO Overview]]
* [[CIO Usage in KC Compact]]
* [[CIO Registers (Summary)]]
* [[CIO Registers (Detailed)]]

The CIO chip is a Counter and I/O chip. In the KC compact system it is used to generate interrupts, access to the parallel printer port, and possibly video control.

When A12 of the I/O address is "0", the CIO is selected. Bit A9 and A8 of the I/O address select the registers of the CIO,
to avoid conflict with other peripherals the CIO should be access using:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Port''||''A9''||''A8''||''Register''||''Usage in KC Compact''
|-
|&ECxx||0||0||Port B data register||setup as timer and is connected to the video hardware (?)
|-
|&EDxx||0||1||Port C data register||setup as timer and is connected to the Interrupt hardware
|-
|&EExx||1||0||Control register||control
|-
|&EFxx||1||1||Port A data register||setup as I/O and is connected to the parallel printer port
|-
|}

* Note: A8 is passed through an inverter, resulting in the above "B,C,Control,A" ordering - this is done to map Port A to the same address as the CPC Printer Port (without the inverter, CIO registers would have "C,B,A,Control" ordering).

On start-up, the KC compact programs the CIO to the following state:

* Port A: I/O mode: all bits are set to output, and bit 7 is inverted when writing. (bit 7 is /strobe signal to printer)
* Port B: Counter mode (port B is split into two counters, both are setup the same): continuous count, restarts when count is over, uses external trigger, uses external input to update count, pulse output (when count is over)

* Port C: Counter mode: same configuration as port B.

Port C is used to generate interrupts. The counter input is HSYNC (the counter counts counter-input transitions; low-high and high-low). The trigger input is VSYV (this signal is derived from VSYNC).

What this means:

* The CIO Port C counter is updated when HSYNC changes state
* The CIO Port C counter is reset when VSYV changes state

With the default settings, the CIO will count 26 HSYNC transitions (52 lines of the display covered in this time) and generate a interrupt. At VSYNC the counter is reset so that the interrupts are synchronised.

I do not know the exact function of the counter's of Port B.

CPC Interrupts:

* synchronised to 2 HSYNCs after VSYNC
* interrupts cannot be generated closer than 32 lines
* counter inside Gate Array counts up to 52 lines.
* interrupt can be cleared by writing to bit 4 of Mode/ROM register in Gate Array (counter is also reset at this time)

KC compact interrupts:

* interrupt can be cleared by writing to bit 4 of Mode/ROM register at 0x07fxx (counter is *not* reset at this time)
* interrupt system fully programmable: can count HSYNCS, or count internal CIO clocks!

Therefore, the KC compact interrupt system is more powerful than the CPC!

== TEST feature ==

When the KC compact is reset, the /TEST signal on the expansion port is checked.

If it is high (1), the operating system will startup and BASIC will be entered. If it is low (0), the KC compact will enter a data transfer sequence using DATA2, DATA1, /STROBE and DATA7 on the expansion connector.

Data transfer:

The data transfer is controlled by another computer, the KC compact is the "slave".

Using DATA2, DATA1, /STROBE and DATA7, a program of 256 bytes in size can be transfered into KC compact memory at &a880. When all bytes have been transfered, this program will be executed.

KCC Side:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Synchronisation stage (Data transfer begin)''||''/STROBE must read as "1"!! wait for DATA1 to change from "1" to "0"''
|-
|Synchronisation Acknowledge stage||write 0x0f: DATA2="1", DATA7="0"''
|-
|Data transfer stage (repeat for 256 bytes)||Data byte transfer||repeat 8 times (once for each data bit) * write 0x0ff: DATA2="1",DATA7="1", and wait for /STROBE to read as "1" * read inputs: DATA1=data bit
|-
|||Data byte acknowledge stage||write: 0x0f0: DATA2="0", DATA7="1", and wait for /STROBE to read as "1"
|-
|}

* /STROBE and DATA1 are inputs
* DATA2 and DATA7 are outputs

== Connecting a KC compact to a CPC+ monitor ==

These connections are known to work!

What you need:

* SCART plug
* 8-pin DIN socket

Lead connections:

* Connect the 8-pin DIN socket to the 8-pin DIN plug from the monitor
* Connect the SCART plug to the SCART socket on the back of the KC Compact

Signal connections:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''pin number on SCART plug''||''pin number on CPC+ monitor socket''
|-
|19 (Composite Video Output)||1 (Composite Sync)
|-
|17 (Video Ground)||8 (GND)
|-
|15 (Analogue Red)||4 (Red)
|-
|11 (Analogue Green)||2 (Green)
|-
|7 (Analogue Blue)||5 (Blue)
|-
|}

== Pictures ==

<gallery caption="KC Compact Pictures">
Image:Kcc top2.jpg|Top (with UHF cable)
Image:Kcc top.jpg|Top (Keyboard)
Image:Kcc open.jpg|Top (removed)
Image:Kcc pcb.jpg|Top (PCB)
Image:Kcc left.jpg|Left
Image:Kcc rigt.jpg|Right
Image:Kcc pjs.jpg|Right (Power, Joystick, Sound)
Image:Kcc labl.jpg|Sticker for Robotron K1505 computer (accidently badged on a KC computer)
Image:Kcc back.jpg|Rear
Image:Kcc pt.jpg|Rear (left: Power, Tape, UHF)
Image:Kcc asp.jpg|Rear (middle: UHF, Scart, Printer)
Image:Kcc exp.jpg|Rear (right: Expansion)
Image:Kcc lead.jpg|Aerial lead connector (UHF)
Image:KCC with power supply.jpg|Computer with Power Supply
Image:KCC boxed1.jpg|Boxed (closed)
Image:KCC boxed2.jpg|Boxed (open)
Image:Adcompa.jpg|KC Compact advert
Image:Kcc bright top.jpg|Top
Image:Kcc bright right.jpg|Right
Image:Kcc bright back.jpg|Rear
Image:Kcc base left.jpg|Base Left
Image:Kcc base right.jpg|Base Right
Image:Deepfb keyb size kcc.jpg|Dimensions
Image:KCCompact_PCB_Top.jpg|PCB Top
Image:KCCompact_PCB_Bottom.jpg|PCB Bottom
Image:KCCompact_Keyboard_Top.jpg|Keyboard Top
Image:KCCompact_Keyboard_Bottom.jpg|Keyboard bottom
</gallery>

== Datasheets ==

* [[Media:CIO-Z8536.pdf]] - Zilog Z8536 CIO Datasheet (equivalent to U82536)
* [[Media:PPI M5L8255AP-5.pdf]] - Mitsubishi 8255 PPI Datasheet (equivalent to KP580BB55)

== KC Compact Hardware Manuals (german) ==

* [[Media:Kcc Beschreibung.pdf]] - Technical Data and Pin-Outs
* [[Media:Kcc Basic Handbuch.pdf]] - Basic Handbook
* [[Media:Kcc Systemhandbuch.pdf]] - System Handbook
* [[Media:Kcc Floppy System Handbuch.pdf]] - Floppy Handbook

== KC Compact Cassette Manuals (german) ==

* [[Media:Kcc kassette CC4001 Demokcc.pdf]] - Demonstration (Demo1, Demo2)
* [[Media:Kcc kassette CC6001 Spielebox1.pdf]] - Gamebox 1 (Strolch, Roessel, Match)
* [[Media:Kcc kassette CC6002 Spielebox2.pdf]] - Gamebox 2 (Orgel, Konzert)
* [[Media:Kcc kassette CC6003 Spielebox3.pdf]] - Gamebox 3 (Fruity Frank, Memory)
* ... Gamebox 4 (?)
* [[Media:Kcc kassette CC6005 Spielebox5.pdf]] - Gamebox 5 (Cubit, Muehle, Pagode)
* [[Media:Kcc kassette CC7001 Komponist.pdf]] - Composer (Komponi.bas, Fughette.mus, Menuett.mus, Gedanken.mus, Muslink.bas)
* [[Media:Kcc kassette CC7002 Grafix1.pdf]] - Graphic (Grafik1, BspMode0.mal, BspMode1.mal)

== KC Compact Schematics ==

<gallery>
File:Kcc schematic cpu io.gif|CPU and I/O Schematic
File:Kcc schematic memory.gif|Memory Schematic
File:Kcc schematic modulator.gif|Modulator Schematic
File:Kcc schematic video power.gif|Video and Power Schematic
File:Kcc block diagram.gif|Block Diagram
File:Kcc component map mainboard.gif|Component Map (Mainboard)
File:Kcc component map modulator.gif|Component Map (Modulator)
</gallery>

For schematics at higher resolution, see
Schematic (Modulator):[[Media:Kcc schem1.png|hires]],
Block Diagram (Mainboard):[[Media:Kcc schem2.png|hires]],
Component Map (Modulator):[[Media:Kcc schem3.png|hires]],
Schematic (CPU and I/O):[[Media:Kcc schem4l.png|left]] and [[Media:Kcc schem4r.png|right]],
Schematic (Memory):[[Media:Kcc schem5l.png|left]] and [[Media:Kcc schem5r.png|right]],
Schematic (Video and Power):[[Media:Kcc schem6l.png|left]] and [[Media:Kcc schem6r.png|right]],
Component Map (Mainboard):[[Media:Kcc schem7l.png|left]] and [[Media:Kcc schem7r.png|right]].

== Operating systems ==

* [[AMSDOS#BASDOS|BASDOS]] - AMSDOS clone
* [[CP/M#MicroDOS|MicroDOS]] - CP/M clone

== KC Compact Computer Resources and Links ==

* [[KC Compact Advert]] - KC Compact Advertising (with english translation)
* [[Clones|CPC Clones]] - List of all known CPC clones
* http://www.robotrontechnik.de/ - Retro site for east-german computers
* http://www.robotron-net.de/ - Retro site for east-german computers
* http://www.iee.et.tu-dresden.de/~kc-club/index.html - Retro site for east-german computers
* http://www.sax.de/~zander/index2h.html - KC Compact is found in the "Hobby" section

[[Category:Non CPC Computers]][[Category:Clones]]

KC Compact

2012-12-02T22:05:24Z

Db6128: I didn't know who the "I"/"me" was, so after hunting it down in the history, I've noted it for others. :) Also, Z80 does have IN/OUT F (however useful they might be), so I removed the question.

''Note: Much of this article was originally written by [[CPCLER]], and so any references in the first person ("I", "me", ''etc.'') are probably by him.

[[Image:Kcc top.jpg|right|thumb|250px|The East German KC Compact Computer]]

== Background ==

The KC compact is a [[Clones|clone]] of the Amstrad CPC and was developed by a East German company called RFT.

The computer was designed in 1989 and made to celebrate 40 years of the DDR/GDR (Deutsche Demokratische Republik/German Democratic Republic). A year later the Berlin wall came down and East and West Germany were joined together and the DDR/GDR came to an end. Production of the computer halted, and it was only available for a short time and is rare.

I read about the KC compact in the Amscene section of Amstrad Action magazine, a Future Publishing Ltd publication. From that point I was hooked and I eventually wanted to own one.

During this time I found Andreas Krueger, webmaster of the Robotron-Net website, who owned one of these computers. Andreas was very helpful and provided photocopies of a manual and the schematics, a dump of the roms, ran some tests for me and more. I want to send him a big thankyou for all the help he gave.

In the last few months (May 2001) I contacted Thomas Tratz who owns a KC Compact. Thomas Tratz runs a great website for QuickBASIC. He has given me many of the original manuals, original software, and I bought a real KC Compact from his cousin! A big thankyou to Thomas and his cousin!

The case of the KC compact is the same as the Robotron BIC A5105, but has different hardware inside. The KC Compact I have does not have a information sticker on the underside, but information for the A5105!

Many of the IC's inside are Russian and clones of other IC's. (The UA880 is a clone of the Zilog Z80, and the U82536 is a clone of the Zilog Z8536).

I know of only a few people who have a real KC Compact (Andreas Kruger, Thomas Tratz, Frank Salmon of Oldbits computer collection and myself), if there are others please contact me and I will make a list of KC Compact owners, and you will be members of an exclusive club! :)

This document will describe the hardware and software differences (that are known) between this system and the Amstrad CPC.

== Alternative power supply ==

With the help of Darren Jarvis I now have a new power supply for my KC Compact. He gave me a power pack from a PC laptop, and with a special lead, this works perfectly on the KC Compact.

PC laptop power pack details:

LISHIN INTERNATIONAL ENTERPRISE CORP. AC ADAPTOR.

MODEL: LSE9802A1960

INPUT: 100-240V A.C. 50/60Hz 1.5A

OUTPUT: 19V D.C. 3.16A. 60W MAX

The power pack has a 3.5mm power plug at the end.

I made a lead which has a 3.5mm power socket and a telefunktion socket.

== External power supply ==

The official external power modulator provides +20V,-20V DC (err... more probably +20V and 0V) with 500mA (believed to be un-smoothed), from a source of ~220V at 50Hz.

The external power modulator is connected to the computer's internal power modulator, which generates a smoothed 12V and 5V outputs and these provide the power for the IC's. Most or all runs at 5V. The 12V are used for the built-in TV modulator, and is also output to the Expansion Port and Scart connector (and, not sure, maybe used elsewhere, too)

The internal power supply is very tolerant and the computer will run with input voltages as low as 6V, but the colours in the palette are weak. If the voltage is increased, the colours become strong, and around 18V-20V, they are all correct. If a low input voltage is used, it is likely that the 12V power output on the expansion connector will not be correct.

The connector is believed to be a Telefunken Line socket (Maplins catalogue reference: FT99H). If you can't find this connector then you can make a suitable connector using a power lead and a sharp craft knife.

== Software differences ==

The base system has 32k of

* Locomotive BASIC v1.1 rom (identical to BASIC rom in English CPC6128) (16k)
* A modified operating system rom from an English CPC6128 (16k)

* Differences are:

:* Different start-up message
:* Computer names (Schneider, Awa, Solavox etc) removed.
:* Initialisation code for the CIO (see details below)
:* Test program transfer (see details below)

I believe most software will run, but I have not been able to test this, but programs that use the following may be broken:

* Programs that rely on exact Interrupt mechanism of the CPC6128
* Programs that call direct into the operating system rom (these may work, because the changes to the operating system rom are minor)
* Programs that rely on a unofficial hardware feature (I do not know of all hardware details, so I cannot say the level of compatibility)

The disc interface has a modified AMSDOS rom.

== Hardware differences ==

* The colour palette is not cleared to black on reset
* The Amstrad unofficial mode (bit 1=bit 0=1 of [[Gate Array]] mode register) does not exist. The clock to the shift registers is stopped. The last colour is output.
* The raster interrupt is generated in a different way by the CIO.

This section describes the known hardware differences. This information is not definitive. I do not know all differences,

== UA880 CPU (equivalent to Zilog Z80) ==

The KC compact uses a UA880 CPU, which is a Russian clone of the [[Z80]]. It is not confirmed whether there are any actual differences compared to a real Z80. In terms of documentation, the KC Compact System Handbook lists the opcodes SLL, INF [a.k.a. IN F,(C)], and OUTF [a.k.a. OUT (C),F], whereas these have remained undocumented by Zilog.

== Video ==

* The [[CRTC]] should be more or less same as those used in CPCs. The handbook and schematic say the CRTC is a CM 607, but the CRTC in CPCLER's an HD6845P.
* The clocks for each mode (0,1 and 2) are derived from the main 16Mhz clock, these then drive the shift registers to output pixels to the display.
* Mode 3 is hardwired to 5V, so it doesn't have a clock. The shift registers are stopped and output the last colour they clocked in. Even if this mode was activated in way of connecting up the clock for Mode 0 it is not decoded the same as on the CPC: 8 colours are chosen from the 16 colour palette, instead of 4.
* There may be a bug whereby if the border colour is changed rapidly there could be 1 pixel of another colour output. When loading a game which changes the colour of the border, I have seen moving "snow" on the screen. I have seen this effect, but I need to confirm how it is generated.
* The video output doesn't generate luminance, so the KC Compact can't be used with a GT64 or MM14.

== Colour-ROM ==

The KC compact has a colour-rom. Each byte in the ROM defines the R,G and B of an output colour.

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Bit''||''Function''
|-
|7||not used''
|-
|6||not used''
|-
|5||Green''
|-
|4||Green''
|-
|3||Red''
|-
|2||Red''
|-
|1||Blue''
|-
|0||Blue''
|-
|}

The hardware colour index (defined by the I/O write: A15="0", A14="1", D7="0", D6="1" D3-D0 define hardware colour index), is used as a look-up into the ROM.

Each colour-element (R, G or B) is defined using 2 bits and has the potential to define a total palette of 64 colours. The colour-rom only uses 3 of the 4 possible settings for each colour-element. Looking at the schematic, the potential is not realised, the two signals for each colour use the same resistors before being combined. This means that the bit combinations 10 and 01 produce the same result. So this means only 27 colours are possible.

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Element Bit 1''||''Element Bit 0''||Intensity''
|-
|0||0||Zero''
|-
|0||1||Half (same as 10)''
|-
|1||0||Half (same as 01)''
|-
|1||1||Full''
|-
|}

The colour ROM can be downloaded from the KC-Klub homepage.

== External connectors ==

=== Built-in connectors: pinout ===

* [[Connector:Cassette recorder|Cassette recorder]] - other pinout as CPC, motor control is TTL (not a relay)
* [[Connector:Digital joystick|Digital joystick]] - exactly as CPC (all 9 pins are exactly same)
* [[Connector:Expansion port|Expansion port]] - almost same as CPC (plus some extra pins: additional voltages, TEST feature, FBAS output)
* [[Connector:Monitor|Monitor]] - 21pin Scart connector, and UHF modulator
* [[Connector:Printer port|Printer port]] - almost same as CPC Plus (25pin)
* [[Connector:Stereo sound|Stereo sound]] - 5pin DIN (not 3.5mm)

=== Cassette socket ===

The Cassette socket has different connection assignments compared to the CPC, so you can't use a CPC cassette lead directly with the KC Compact.

I made a second lead which converted between KC Compact assignments and CPC assignments, which was connected between KC Compact and the CPC cassette lead.

I have been successfully loaded some CPC software.

=== Expansion socket ===

The KC compact has a real connector compared to the P.C.B. edge connector of an English CPC6128. The connector appears to be a PC Card connector. This connector is not the same as the one on a German CPC6128.

The expansion connector has more pins; 58 compared to 50 on an English CPC6128.

I am in the process of making an adaptor so that I can test CPC hardware on the KC Compact.

=== Parallel ===

On the KC compact the parallel port is connected to Port A of the CIO.

It is a general purpose I/O port. All 8-bits can be used for input or output. The input/output of each bit can be programmed. With standard setup, bit 7 is assigned to /STROBE, and bits 0-6 are assigned to Printer DATA, making a 7-bit printer port. Additionally, the 8th printer bit is implemented via Bit5 of PIO Port C (see [[8bit Printer Ports]]).

* The Amstrad CPC has a single-direction, 7-bit port.
* The KC Compact has a bi-directional, 8-bit port.

The KC compact parallel port is more powerful and flexible compared to the Amstrad CPC parallel port!

=== Keyboard ===

* The keyboard matrix of the KC compact supports all the keys of the CPC, but the following keys are not on the keyboard: F5, F6,F7,F8,F9.
* The KC Compact has a power LED (near CLR key). There are also (unused) locations for two additional LEDs (near TAB/CAPS key), eventually these locations are used by the D005 keyboard for KC-85 computers, or by the Robotron A5105 computer (both D005 and A5105 use the same case & keyboard as the KC Compact, aside from that, they have nothing to do with it).

== KP580BB55 PIO (equivalent to 8255 PPI) ==

Used (almost) identically as the CPC's [[8255]]. PIO Port B is slightly different:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|7||Cassette data read (identical to CPC)
|-
|6||Centronics/Printer Busy (identical to CPC)
|-
|5||/EXP (identical to CPC)
|-
|4||1 (+5v) (would be LK4 screen refresh rate in CPC) (but isn't like so in KC Compact?)
|-
|3||1 (+5v) (would be LK3 manufacturer ID in CPC)
|-
|2||0 (0v) (would be LK2 manufacturer ID in CPC)
|-
|1||/TEST (would be LK1 manufacturer ID in CPC)
|-
|0||VSYNC (identical to CPC)
|-
|}

* Note: The KC System Handbook accidently calls the chip "KP580B55", however, the correct name is "KP580BB55" (with double "B").

== U82536 CIO (equivalent to Zilog Z8536 CIO) ==

* [[CIO Overview]]
* [[CIO Usage in KC Compact]]
* [[CIO Registers (Summary)]]
* [[CIO Registers (Detailed)]]

The CIO chip is a Counter and I/O chip. In the KC compact system it is used to generate interrupts, access to the parallel printer port, and possibly video control.

When A12 of the I/O address is "0", the CIO is selected. Bit A9 and A8 of the I/O address select the registers of the CIO,
to avoid conflict with other peripherals the CIO should be access using:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Port''||''A9''||''A8''||''Register''||''Usage in KC Compact''
|-
|&ECxx||0||0||Port B data register||setup as timer and is connected to the video hardware (?)
|-
|&EDxx||0||1||Port C data register||setup as timer and is connected to the Interrupt hardware
|-
|&EExx||1||0||Control register||control
|-
|&EFxx||1||1||Port A data register||setup as I/O and is connected to the parallel printer port
|-
|}

* Note: A8 is passed through an inverter, resulting in the above "B,C,Control,A" ordering - this is done to map Port A to the same address as the CPC Printer Port (without the inverter, CIO registers would have "C,B,A,Control" ordering).

On start-up, the KC compact programs the CIO to the following state:

* Port A: I/O mode: all bits are set to output, and bit 7 is inverted when writing. (bit 7 is /strobe signal to printer)
* Port B: Counter mode (port B is split into two counters, both are setup the same): continuous count, restarts when count is over, uses external trigger, uses external input to update count, pulse output (when count is over)

* Port C: Counter mode: same configuration as port B.

Port C is used to generate interrupts. The counter input is HSYNC (the counter counts counter-input transitions; low-high and high-low). The trigger input is VSYV (this signal is derived from VSYNC).

What this means:

* The CIO Port C counter is updated when HSYNC changes state
* The CIO Port C counter is reset when VSYV changes state

With the default settings, the CIO will count 26 HSYNC transitions (52 lines of the display covered in this time) and generate a interrupt. At VSYNC the counter is reset so that the interrupts are synchronised.

I do not know the exact function of the counter's of Port B.

CPC Interrupts:

* synchronised to 2 HSYNCs after VSYNC
* interrupts cannot be generated closer than 32 lines
* counter inside Gate Array counts up to 52 lines.
* interrupt can be cleared by writing to bit 4 of Mode/ROM register in Gate Array (counter is also reset at this time)

KC compact interrupts:

* interrupt can be cleared by writing to bit 4 of Mode/ROM register at 0x07fxx (counter is *not* reset at this time)
* interrupt system fully programmable: can count HSYNCS, or count internal CIO clocks!

Therefore, the KC compact interrupt system is more powerful than the CPC!

== TEST feature ==

When the KC compact is reset, the /TEST signal on the expansion port is checked.

If it is high (1), the operating system will startup and BASIC will be entered. If it is low (0), the KC compact will enter a data transfer sequence using DATA2, DATA1, /STROBE and DATA7 on the expansion connector.

Data transfer:

The data transfer is controlled by another computer, the KC compact is the "slave".

Using DATA2, DATA1, /STROBE and DATA7, a program of 256 bytes in size can be transfered into KC compact memory at &a880. When all bytes have been transfered, this program will be executed.

KCC Side:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''Synchronisation stage (Data transfer begin)''||''/STROBE must read as "1"!! wait for DATA1 to change from "1" to "0"''
|-
|Synchronisation Acknowledge stage||write 0x0f: DATA2="1", DATA7="0"''
|-
|Data transfer stage (repeat for 256 bytes)||Data byte transfer||repeat 8 times (once for each data bit) * write 0x0ff: DATA2="1",DATA7="1", and wait for /STROBE to read as "1" * read inputs: DATA1=data bit
|-
|||Data byte acknowledge stage||write: 0x0f0: DATA2="0", DATA7="1", and wait for /STROBE to read as "1"
|-
|}

* /STROBE and DATA1 are inputs
* DATA2 and DATA7 are outputs

== Connecting a KC compact to a CPC+ monitor ==

These connections are known to work!

What you need:

* SCART plug
* 8-pin DIN socket

Lead connections:

* Connect the 8-pin DIN socket to the 8-pin DIN plug from the monitor
* Connect the SCART plug to the SCART socket on the back of the KC Compact

Signal connections:

{|{{Prettytable|width: 700px; font-size: 2em;}}
|''pin number on SCART plug''||''pin number on CPC+ monitor socket''
|-
|19 (Composite Video Output)||1 (Composite Sync)
|-
|17 (Video Ground)||8 (GND)
|-
|15 (Analogue Red)||4 (Red)
|-
|11 (Analogue Green)||2 (Green)
|-
|7 (Analogue Blue)||5 (Blue)
|-
|}

== Pictures ==

<gallery caption="KC Compact Pictures">
Image:Kcc top2.jpg|Top (with UHF cable)
Image:Kcc top.jpg|Top (Keyboard)
Image:Kcc open.jpg|Top (removed)
Image:Kcc pcb.jpg|Top (PCB)
Image:Kcc left.jpg|Left
Image:Kcc rigt.jpg|Right
Image:Kcc pjs.jpg|Right (Power, Joystick, Sound)
Image:Kcc labl.jpg|Sticker for Robotron K1505 computer (accidently badged on a KC computer)
Image:Kcc back.jpg|Rear
Image:Kcc pt.jpg|Rear (left: Power, Tape, UHF)
Image:Kcc asp.jpg|Rear (middle: UHF, Scart, Printer)
Image:Kcc exp.jpg|Rear (right: Expansion)
Image:Kcc lead.jpg|Aerial lead connector (UHF)
Image:KCC with power supply.jpg|Computer with Power Supply
Image:KCC boxed1.jpg|Boxed (closed)
Image:KCC boxed2.jpg|Boxed (open)
Image:Adcompa.jpg|KC Compact advert
Image:Kcc bright top.jpg|Top
Image:Kcc bright right.jpg|Right
Image:Kcc bright back.jpg|Rear
Image:Kcc base left.jpg|Base Left
Image:Kcc base right.jpg|Base Right
Image:Deepfb keyb size kcc.jpg|Dimensions
Image:KCCompact_PCB_Top.jpg|PCB Top
Image:KCCompact_PCB_Bottom.jpg|PCB Bottom
Image:KCCompact_Keyboard_Top.jpg|Keyboard Top
Image:KCCompact_Keyboard_Bottom.jpg|Keyboard bottom
</gallery>

== Datasheets ==

* [[Media:CIO-Z8536.pdf]] - Zilog Z8536 CIO Datasheet (equivalent to U82536)
* [[Media:PPI M5L8255AP-5.pdf]] - Mitsubishi 8255 PPI Datasheet (equivalent to KP580BB55)

== KC Compact Hardware Manuals (german) ==

* [[Media:Kcc Beschreibung.pdf]] - Technical Data and Pin-Outs
* [[Media:Kcc Basic Handbuch.pdf]] - Basic Handbook
* [[Media:Kcc Systemhandbuch.pdf]] - System Handbook
* [[Media:Kcc Floppy System Handbuch.pdf]] - Floppy Handbook

== KC Compact Cassette Manuals (german) ==

* [[Media:Kcc kassette CC4001 Demokcc.pdf]] - Demonstration (Demo1, Demo2)
* [[Media:Kcc kassette CC6001 Spielebox1.pdf]] - Gamebox 1 (Strolch, Roessel, Match)
* [[Media:Kcc kassette CC6002 Spielebox2.pdf]] - Gamebox 2 (Orgel, Konzert)
* [[Media:Kcc kassette CC6003 Spielebox3.pdf]] - Gamebox 3 (Fruity Frank, Memory)
* ... Gamebox 4 (?)
* [[Media:Kcc kassette CC6005 Spielebox5.pdf]] - Gamebox 5 (Cubit, Muehle, Pagode)
* [[Media:Kcc kassette CC7001 Komponist.pdf]] - Composer (Komponi.bas, Fughette.mus, Menuett.mus, Gedanken.mus, Muslink.bas)
* [[Media:Kcc kassette CC7002 Grafix1.pdf]] - Graphic (Grafik1, BspMode0.mal, BspMode1.mal)

== KC Compact Schematics ==

<gallery>
File:Kcc schematic cpu io.gif|CPU and I/O Schematic
File:Kcc schematic memory.gif|Memory Schematic
File:Kcc schematic modulator.gif|Modulator Schematic
File:Kcc schematic video power.gif|Video and Power Schematic
File:Kcc block diagram.gif|Block Diagram
File:Kcc component map mainboard.gif|Component Map (Mainboard)
File:Kcc component map modulator.gif|Component Map (Modulator)
</gallery>

For schematics at higher resolution, see
Schematic (Modulator):[[Media:Kcc schem1.png|hires]],
Block Diagram (Mainboard):[[Media:Kcc schem2.png|hires]],
Component Map (Modulator):[[Media:Kcc schem3.png|hires]],
Schematic (CPU and I/O):[[Media:Kcc schem4l.png|left]] and [[Media:Kcc schem4r.png|right]],
Schematic (Memory):[[Media:Kcc schem5l.png|left]] and [[Media:Kcc schem5r.png|right]],
Schematic (Video and Power):[[Media:Kcc schem6l.png|left]] and [[Media:Kcc schem6r.png|right]],
Component Map (Mainboard):[[Media:Kcc schem7l.png|left]] and [[Media:Kcc schem7r.png|right]].

== Operating systems ==

* [[AMSDOS#BASDOS|BASDOS]] - AMSDOS clone
* [[CP/M#MicroDOS|MicroDOS]] - CP/M clone

== KC Compact Computer Resources and Links ==

* [[KC Compact Advert]] - KC Compact Advertising (with english translation)
* [[Clones|CPC Clones]] - List of all known CPC clones
* http://www.robotrontechnik.de/ - Retro site for east-german computers
* http://www.robotron-net.de/ - Retro site for east-german computers
* http://www.iee.et.tu-dresden.de/~kc-club/index.html - Retro site for east-german computers
* http://www.sax.de/~zander/index2h.html - KC Compact is found in the "Hobby" section

[[Category:Non CPC Computers]][[Category:Clones]]

CPC old generation

2012-12-02T21:54:32Z

Db6128: /* Similarities to the BBC Micro */ Replacing the self-confused bit about BBC BASIC for the CPC with a version that makes sense :P + a (necessarily) brief comparison of the two BASICs

[[Category:Hardware|*]][[Category:CPC Internal Components| ]][[Category:CPC History|*]][[Category:Amstrad Products| ]]

[[Image:464.png|thumb|CPC 464 with Colour monitor]]
[[Image:Schneider 664 en.jpg|thumb|German CPC 664]]

''The following text was copied in part from the [http://en.wikipedia.org/wiki/Amstrad_CPC English Wikipedia article].''

==Hardware description==
All CPC models were based on a Zilog Z80 processor clocked at 4 MHz. Because a common pool of RAM is shared with the video circuits, the Z80 may only make a memory access once every four cycles, which has the effect of rounding all instruction cycle lengths up to the next multiple of four.

The system came with 64 KB or 128 KB of RAM depending on the model (capable of being expanded to 576k). The machines also featured a standard 9-pin Atari-style joystick socket which was able to take two joysticks via a splitter.

The machines' dimensions are:
*'''CPC464''' : 17 x 57.5 x 7.5
*'''CPC6128''' : 17.5 x 51.1 x 5

===Video (graphics): modes, outputs===
Underlying the CPC's video output was the [[CRTC|Motorola 6845]] address generator. This chip was connected to a pixel generator that supported 4 bpp, 2 bpp and 1 bpp output (bits per pixel). The address generator was clocked at a constant rate so the 4 bpp display generated half as many pixels as the 2 bpp and a quarter as many as the 1 bpp.

The ROM featured three built-in display resolutions but many others could be achieved by reprogramming the 6845.

The standard [[video modes]] were:
*'''Mode 0''': '''160×200''' pixels with 16 colours (4 bpp)
*'''Mode 1''': '''320×200''' pixels with 4 colours (2 bpp)
*'''Mode 2''': '''640×200''' pixels with 2 colours (1 bpp)
*'''Mode 3''': '''160×200''' pixels with 4 colours (2 bpp) (this is not an official mode, but rather a side-effect of the hardware)

A colour palette of 27 colours was supported, derived from RGB colour space with each component assigned as either off, half on or on. The later '''Plus''' models extended this to 4096 colours and added support for hardware sprites.

This hardware compares well with the other 8-bit computers. In particular the CPC lacks the colour clash of the ZX Spectrum, and clever programming of the 6845 could produce overscan, different resolutions (although with the same pixel density) and smooth pixel scrolling.

The machine lacked either a RF TV or composite video output and instead shipped with a proprietary 5-pin DIN connector intended for use solely with the supplied Amstrad monitor. An external adapter for RF TV was available to be bought separately.

The five-pin DIN connector is capable of driving a television with a correctly wired SCART lead.

===Audio (sound)===
The CPC used the General Instrument AY-3-8912 sound chip, providing three channels, each configurable to generate square waves, white noise or both. A small array of hardware volume envelopes are available.

Output was provided in mono by a small (4 cm) built-in loudspeaker with volume control, driven by an unusually powerful amplifier. Stereo output was provided through a 3.5mm headphone jack, not present on some early CPC464 models. In those models, what looked like a standard 3.5" headphone jack was actually used for connecting an external tape recorder, although later models used a five-pin DIN connector for the same purpose.

Playback of digital sound samples at a resolution of a little better than 5-bit, as heard on the title screen of the game ''RoboCop'', was possible through clever programming of the sound chip. This trick was very processor intensive and hard to combine with any other processing.

===The 3" floppy disk drives===
Amstrad's idiosyncratic choice of Hitachi's 3" floppy disk drive, when the rest of the PC industry was moving to Sony's 3.5" format, is often claimed to be due to Amstrad bulk-buying a large consignment of 3" drive units in Asia. The cheapest drive (built-in in later models) was a single-sided 40-track unit that required the user to physically remove and flip the disk to access both sides. Each side had its own independent write-protect switch. The sides were termed "A" and "B", with each one holding 180KB (178KB in AMSDOS format) for a total of 360KB per disc.

The disk drive interface was a NEC 765 FDC, used for the same purpose in the IBM PC/XT, PC/AT and PS/2 machines. Many of its features were unused in order to cut costs, namely DMA transfers and support for single density disks. Disks were formatted as double density using Modified Frequency Modulation.

Disks were shipped in a paper sleeve or a hard plastic case resembling a compact disc "jewel" case. The casing is thicker and more rigid than that of 3.5" diskettes and the sliding metal cover to protect the media surface is internal to the casing and latched, unlike the simple external sliding cover of Sony's version (some reviews at the time reported driving over them with no problems). Because of this they were significantly more expensive than both the 5.25" and 3.5" alternatives. This, combined with their low nominal capacities and their essentially proprietary nature, lead to the format being discontinued when the CPC itself was discontinued.

Apart from Amstrad's other 3" machine, the PCW, and the ZX Spectrum +3 (produced by Sinclair), the only other computer systems to use them were the Sega SF-7000 and mostly obscure and exotic CP/M systems such as the Tatung Einstein and Osborne machines. It should be noted that some of these machines used drives with different pinouts and care should be taken when replacing drives.

The data formatting of 3" disks was very similar to that of 5¼" disks, and the Amstrad CPC machines were able to use 5¼" drives through their "external drive" port - either one specially designed for use by the CPC or an adapted IBM-PC drive.

A more popular alternative was to attach an adapted IBM-PC 3½" drive for operation in either single-sided 180 KB or double-sided 360 KB mode, although with the later availability of the PARADOS Disc Operating System, 720k per disc became available. (It was possible to patch CP/M Plus so that it recognised 80 track double sided disk formats, too.)

===Serial port adaptor===
An official RS-232-C D25 serial port adaptor was produced that attached to the expansion connector at the rear of the machine, and had a through-connector for the CPC464 disk drive or other peripherals. The adaptor came with a "''Book of Spells''" for facilitating data transfer between other systems using a proprietary protocol in the device's own ROM, as well as terminal software to connect to British Telecom's Prestel service. A separate version of the ROM was created for the U.S. market due to the use of the commands "SUCK" and "BLOW", which were considered unacceptable there.

===Similarities to the BBC Micro===
The CPC has been termed an "improved Z80 implementation of the (earlier) BBC Micro" due to similarities in firmware and hardware. Both used the Motorola 6845 video address generator and the two have very similar sound output chips - the General Instrument AY-3-8912 in the CPC provided three tone channels each optionally with added noise and the Texas Instruments SN76489 in the BBC offered three tone channels and one exclusive noise channel.

The BBC Micro used an Intel 8271 floppy disc controller. The CPC used the Intel 8272, which is similar to the 8271 but contains the addition of a double density (MFM) mode.

The "two cursor" BASIC editing system seen on the Amstrad CPC (whereby holding Shift and using the cursor keys moves a shadow text cursor allowing text to be copied from another area of the screen to the normal cursor) was a lift from BBC BASIC, albeit substantially improved by allowing free movement of the normal cursor.

Both systems provided similar systems of full hardware abstraction through Operating System calls. This saves programs which don't require time critical hardware access from having to touch the underlying machine and provides a level of machine portability for those programs.

As the CPC had its own dialect of [[BASIC]], namely [[Locomotive BASIC]], so the BBC Micro has its own version named [[BBC BASIC]]. BBC BASIC evolved with subsequent models of BBC computers and with Acorn's next system, the Archimedes. Both had their own sets of advantages: Locomotive BASIC was faster in many contexts, had native support for text windows, had more comprehensive commands for manipulating sound, ''etc.''; BBC BASIC had support for procedures (rather than just arithmetic functions), an inline assembler, and others. Of note is the fact that among the numerous [http://www.bbcbasic.co.uk/bbcbasic.html ports of BBC Basic] produced by the company [http://www.rtrussell.co.uk/ R.T. Russell] is a version especially adapted for the Amstrad CPC, including support for its specific graphics and sound capabilities; there is also a generic version for [[CP/M]].

==Software==
===Built-in BASIC and operating system===
Like most home computers at the time, the CPC had its OS and a BASIC interpreter built in as ROM. It used Locomotive BASIC - a variant specifically written for the CPC hardware which as a result was faster, more comfortable and more powerful than the generic but common Microsoft BASIC used by the Commodore 64 and MSX amongst others. It was particularly notable for providing easy access to the machine's video and audio resources in contrast to the arcane POKE commands required on some Microsoft implementations (the MSX implementation of Microsoft Basic being an exception, which even allowed for hardware sprite manipulation and collision detection).

===Other languages===
Although it was possible to obtain compilers for Locomotive BASIC, BCPL, C, Forth, and Turbo Pascal the majority of the CPC's software was written in native Z80 assembly language.

An interpreter for the educational language LOGO was also supplied with the 664 and 6128 (and available for the 464 with purchase of an external disc drive).

==What was in the box?==

=== CPC464 ===

* The computer itself, including built-in [[Datacorder]]
* [[Demostration tape or disc|Demonstration tape]] in local language (UK, Germany, France, Spain)
* [[User Manual]]
* Either an [[Amstrad GT64/GT65 Green Monitor|Amstrad GT64 (Later: GT65) green monitor]] or an [[Amstrad CTM640/CTM644 Color Monitor|Amstrad CTM640 (Later: CTM644) Colour Monitor]]
* Optional: [[Amstrad MP1/MP2 modulator|Amstrad MP-1 (Later: MP-2) TV modulator and power supply]]
* A Gamepack consisting of 12 Amsoft Titles on Tape.

<gallery>
Image:CPC464_pcb_r1.jpg|CPC464 PCB revision 0 (original)
Image:CPC464_pcb_r3.jpg|CPC464 PCB revision 3 (costdown)
Image:CPC464_new_amstrad_logo.jpg|CPC464 (new Amstrad logo - photo from costdown model)
</gallery>

=== CPC472 ===

* [[472]]

=== CPC664 ===

* The computer itself, including built-in 3" disk drive
* [[System Disk]]: CP/M 2.2 disk with demo in local language (UK, Germany, France, Spain)
* [[User Manual]]
* Either an [[Amstrad GT64/GT65 Green Monitor|Amstrad GT65 green monitor]] or an [[Amstrad CTM640/CTM644 Color Monitor|Amstrad CTM644 Colour Monitor]]
* Optional: [[Amstrad MP1/MP2 modulator|Amstrad MP-2 TV modulator and power supply]]

<gallery>
Image:664.jpg|The 664 in high-res
Image:CPC664_Top.jpg|CPC 664 Top
Image:CPC664_PCB_Top.jpg|CPC 664 Motherboard Top
Image:CPC664_PCB_Bottom.jpg|CPC 664 Motherboard Bottom
</gallery>

=== CPC6128 ===

* The computer itself, including built-in 3" disk drive
* [[System Disk]]s with CP/M Plus, CP/M 2.2 and a demo in local language (UK, Germany, France, Spain)
* [[User Manual]]
* Either an [[Amstrad GT64/GT65 Green Monitor|Amstrad GT65 green monitor]] or an [[Amstrad CTM640/CTM644 Color Monitor|Amstrad CTM644 Colour Monitor]]
* Optional: [[Amstrad MP1/MP2 modulator|Amstrad MP-2 TV modulator and power supply]]
* Later models came with the [[Amstrad PP8 Promotional Pack]]

<gallery>
Image:CPC6128_Top.jpg|CPC 6128 Top
Image:CPC6128_PCB_Top_(Z70290_MC0020B).jpg|CPC 6128 Motherboard Top
Image:CPC6128_PCB_Bottom_(Z70290_MC0020B).jpg|CPC 6128 Motherboard Bottom
</gallery>

=== DDI-1 ===

* Controller DDI-1
* 3" disk drive FD-1
* [[System Disk]]: CP/M 2.2 disk with demo
* [[User Manual]]

==Others==

* [[Keyboard Versions]]
* [[Mainboard Versions]]
* [[CPC6128_Keyboard_Disassembled]]

==Clones==

See [[Clones]] for a list of classic and modern clones.

CNGSoft

2012-12-02T21:39:51Z

Db6128: /* Links */ Whoops, getting rusty with my wikimarkup, evidently

'''CNGSoft''' (César Nicolás González) is the Spanish programmer who has been writing and releasing versions of the emulator [[CPCE]] since August 1st 1997.

His other especially notable project is ''[[BB4CPC]]''[http://www.cpcwiki.eu/forum/games/bubble-bobble-remake-(bb4cpc)/msg36311/#msg36311], an enhanced remake of ''[[Bubble Bobble]]'' for the CPC. The system already had a CPC version released during its official heyday, but many players felt that it was not as good a port as it could have been; CNGSoft, being a big fan of the ''Bubble Bobble''/''[[Rainbow Islands]]'' franchise, wanted to release a version that took more advantage of the Amstrad's hardware and provided the best experience possible.

He has made a very interesting tool for the CPC, LZ2PACKER, a [http://en.wikipedia.org/wiki/Self-extracting_archive self-extracting archive], as seen in the binary [ftp://ftp.nvg.ntnu.no/pub/cpc/games/arcade/jetsetff.zip JSW2]. The compression method is based on [http://genesis8.free.fr/frontend/misc/demopack.zip Demoniak's packer] and fully compatible with it.

His most quoted ''excusatio non petita'' is "English isn't my first language, I apologize for using it so poorly."

==Releases==

===Games===
* ''[[Justin]]''
* ''[[BB4CPC]]''

===Emulator===
* [[CPCE]]

===Tools===
* LZ2PACKER (see above)

==Links==
* [http://cngsoft.no-ip.org/ Homepage]
* [http://cngsoft.no-ip.org/cng_bb4cpc.htm Home of ''BB4CPC'']
* [http://www.cpcwiki.eu/forum/games/bubble-bobble-remake-(bb4cpc)/msg36311/#msg36311 Topic on the CPC Wiki's forum about the release of ''BB4CPC'']

[[Category:CPC scene members]]

CNGSoft

2012-12-02T21:38:52Z

Db6128: Adding info on BB4CPC; it's about time :P I guess we will need a dedicated page for that, too

'''CNGSoft''' (César Nicolás González) is the Spanish programmer who has been writing and releasing versions of the emulator [[CPCE]] since August 1st 1997.

His other especially notable project is ''[[BB4CPC]]''[http://www.cpcwiki.eu/forum/games/bubble-bobble-remake-(bb4cpc)/msg36311/#msg36311], an enhanced remake of ''[[Bubble Bobble]]'' for the CPC. The system already had a CPC version released during its official heyday, but many players felt that it was not as good a port as it could have been; CNGSoft, being a big fan of the ''Bubble Bobble''/''[[Rainbow Islands]]'' franchise, wanted to release a version that took more advantage of the Amstrad's hardware and provided the best experience possible.

He has made a very interesting tool for the CPC, LZ2PACKER, a [http://en.wikipedia.org/wiki/Self-extracting_archive self-extracting archive], as seen in the binary [ftp://ftp.nvg.ntnu.no/pub/cpc/games/arcade/jetsetff.zip JSW2]. The compression method is based on [http://genesis8.free.fr/frontend/misc/demopack.zip Demoniak's packer] and fully compatible with it.

His most quoted ''excusatio non petita'' is "English isn't my first language, I apologize for using it so poorly."

==Releases==

===Games===
* ''[[Justin]]''
* ''[[BB4CPC]]''

===Emulator===
* [[CPCE]]

===Tools===
* LZ2PACKER (see above)

==Links==
* [http://cngsoft.no-ip.org/] Homepage
* [http://cngsoft.no-ip.org/cng_bb4cpc.htm] Home of ''BB4CPC''

[[Category:CPC scene members]]