Development was based on existing work recently undertaken writing Mallard BASIC for Acorn Computers Z80 addon for the BBC Micro.

The mix produced a comprehensive result with technical capabilities almost unheard of in any one contemporary platform - the tidy approach to firmware access with fixed jump blocks, the hypothecation of the firmware into modules, the clever hardware allowing expandability, with multiple pages of RAM and ROM all occupying the same address-space, simultaneously accessible, re-locatable display memory etc.

Fundamentally, the CPC platform consists of clever hardware with a rich firmware to exploit it; compartmentalised into sub-systems with standardised jump tables to access functionality.

At a machine level on the CPC platform, application software need not be concerned with code moving about in the actual firmware (e.g. for different versions and re-assembly) so long as it uses the documented jump block addresses.

Amstrad BASIC leveraged and exposed the platform being written to take full advantage of the machine, bundling up BASIC code into the requisite calls into the firmware,[2] providing specific commands for functionality rather than reliance on generic *FX or PEEK & POKE statements required to access features on competitor platforms.

Alternatively, saving with option "A" creates a fully text compatible ascii file e.g. SAVE "MYPROG",A Supplied with the Amstrad CPC464, it was a good release with only a single notable bug, being the DEC$() function (it provides PRINT USING style output but as a string rather than screen output).

This replaces the VARPTR() function found in other dialects of BASIC and is mostly used to pass a variable pointer to machine code routines allowing bi-directional data transfer.

This makes access to the subject variables very fast and considering their ubiquitous use, it is perhaps, surprising this mechanism was not used in Amstrad BASIC.

With Amstrad BASIC V1.1 (CPC664 onwards), the FILL command permitted painting complex-shaped, bounded areas of the screen and an eight bit mask could be applied DRAW enabling dotted lines etc.

A table giving the numeric codes for the 27 system colors was printed on the casing of the built-in 3" disk drive on the 664 and later machines.

The TEXT_VDU firmware pack allows for the creation of multiple text windows each with their own cursor, dimensions, content, colours etc.

The same chip was also used on late-model ZX Spectrums, as well as the Atari ST and MSX computers, but none of those had such a complete built-in SOUND command.

There was an easy method of allocating "safe" memory (see below) and once loaded either from disc or cassette or POKEd in, Z80 machine code could be executed with CALL .

Another method, leveraging the firmware, allowed for named sections of machine code using a feature known as Resident System eXtensions (RSX).

The code for the RSXs had a very specific header structure - the RSX names, their entry points and 4 bytes of scratchpad RAM for the firmware to link in and out of the list.

A major advantage of RSXs is not needing to know the address of a piece of machine code (like CALL which could only access the main 64KB address map, however configured) - the KERNEL returns the parameters necessary to execute the code in question no matter where it resides, in the entire memory map and in all ROM/RAM banks (see "bank switching" below).

Use of RSXs ensured that machine code in sideways ROMs was fully integrated with BASIC and the disc commands |DIR, |A, |TAPEIN, |ERA etc.

Notably the BBC Micro did not have garbage collect and manipulation of strings could result in "out of memory" errors simply because a requested block did not exist in one chunk.

In common with other dialects, Amstrad BASIC provides the FRE() function to return the amount of free heap.

Should an "Out of memory" error occur due to no free heap, Amstrad BASIC performs a garbage collection immediately prior to stopping the program, in an attempt to rescue the situation, so it was not really necessary for the programmer to concern themselves overly and FRE() is more informational than essential.

The MEMORY command can be used to adjust this address and through a combination of the two, space can be reserved easily and controllably - a primitive form of malloc().

Following on the ethos of exposing the platform capabilities in BASIC, it passed forward this functionality and the memory for UDG was allocated from the heap (i.e. the more characters, the lower HIMEM).

e.g. SYMBOL AFTER 32 would allow the entire printable ASCII character set to be redefined, with the corresponding reduction in available program space (1784 bytes).

If UDG were not required, memory could be returned to BASIC (resulting in fixed character matrices) with the command SYMBOL AFTER 256.

Although as a BASIC implementation, Amstrad BASIC is fairly complete and goes to great pains to support the CPC platform, one notable omission in all versions is native access to the memory bank switching mechanism used to expand the Z80 memory space; re-using address ranges by overlaying sections of physical ROM or RAM.

All CPC models supported this fairly advanced (for the time) bank-switching to increase the potential memory storage - even an un-expanded CPC464 fully used 96KB of ROM and RAM mapped into the Z80 64KB address space.

The latter file contains machine code to initialise a set of RSXs to enable RAM bank switching from BASIC programs.

It was not generally considered practical though as it is necessary to include both BANKMAN files with your own software products and run them at the command prompt before your own program can take advantage of bank switching RAM.

Besides using banked memory to store screen images and rapidly switch between them, some applications implemented "RAM Discs" but these were not supported under the cassette/AMSDOS firmware, being quite proprietary.

This was not unimportant, as some other machines of the era required programmers to use assembler in order to access the full sound and graphics capabilities of their system.