Editing Locomotive BASIC (section)

== Memory allocation and management ==
Generally speaking, BASIC programmers do not have to concern themselves too much with the inner workings of their chosen platform to get decent results. Should a programmer wish to ignore them and stick only to BASIC, they are well catered-for with a speedy, rich dialect. For those who want to go beyond and want more control, they are likewise accommodated.

In many contemporary systems, allocating a block of memory seems an after-thought with no "proper" method of achieving it. Innovative methods were adopted by programmers which resulted in some, often, highly cryptic and fiddly methods, such as creating <code>REM</code> statements with the required length and then <code>POKE</code>ing the data into known addresses in the BASIC program line - the command <code>LET L=USR 16514</code> was famous in ZX81 circles, 16514 being the address of the first byte after the first token on the first program line (usually a REM statement on line 1) the only area of memory guaranteed not to move around or be corrupted with added program lines, garbage collect etc.

Amstrad BASIC program space occupies RAM from $170 extending to somewhere around $A6F0 (varies with BASIC version and other considerations), just under the BASIC system area, AMSDOS area and the high jump blocks - a little over 41KB. Numeric variables and functions etc. are located immediately above the program with the remaining, free memory in between termed "the [[Heap (data structure)|heap]]". The contents of string variables are stored in the heap near the very top, with just the string descriptors being stored in similar fashion to numerics in the variable table - just above the program (see Variables and functions above). BASIC program code grew up and strings grew down towards each other in RAM, gradually consuming the heap in between. Amstrad BASIC has a garbage collector which de-fragments the heap to maximise usable memory - as with most computer languages, as strings are created then sliced/deleted, chunks of un-used memory occur between used parts and the heap can become "porous". 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. The function has two forms: <CODE>FRE(numeric)</CODE>, e.g. PRINT FRE(0), returns the size, in bytes, of the largest single block in the heap. The second form, <CODE>FRE("")</CODE>, forces a garbage collect and so, returns a true count of free heap. Used areas (mainly strings and temporary structures) are aggregated at the top of the heap with no gaps - data is moved and pointers updated, leaving available heap as a single chunk of memory extending down to the program and variables. This latter form can take some time to run on badly fragmented systems. Should an "Out of memory" error be imminent due to no free heap, Amstrad BASIC performs a garbage collection immediately prior to stopping the program in an attempt to rescue the situation. Subsequently, it was not necessary for the programmer to concern themselves overly with heap management and FRE() is more informational than essential.

Amstrad BASIC provides the function, <code>HIMEM</code>, which returns the last address used by BASIC i.e. the very last address before the system areas. The <code>MEMORY</code> 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 <code>malloc()</code>. For example, suppose a block of 1KB was required, space could be reserved (with full consent/awareness of BASIC) using <code>MEMORY HIMEM-1024</code>  - adjusting down the maximum extent of BASIC memory use. Machine code, say, could then be safely loaded into and called at <code>HIMEM+1</code> (or elsewhere in that 1K), safe from other processes and accidental relocation/corruption.

The CPC range makes provision, through the SCREEN_PACK, for User Defined Graphics (UDG) whereby the 8x8 pixel matrix for a character can be redefined allowing for the creation of special characters. By default, the top 16 characters (128 bytes) are "soft" and if that is sufficient, no further adjustment is required. Following on the ethos of exposing the platform capabilities in BASIC, it passes forward this functionality and the memory for UDG is allocated from the heap (i.e. the more characters, the lower <code>HIMEM</code>). More characters (and thus more RAM) can be allocated with the <code>SYMBOL AFTER <char></code> command - where char represents the character code from which UDG is available. e.g. <code>SYMBOL AFTER 32</code> allows the entire printable ASCII character set to be redefined, with the corresponding reduction in available program space (1784 bytes). The firmware copies the default character matrices from ROM into the newly allocated space, thus defining the character matrix was not essential for clarity. If UDG are not required, memory can be returned to BASIC (resulting in fixed character matrices) with the command <code>SYMBOL AFTER 256</code>.

The simplified default CPC memory map as it appears to BASIC.
[[File:CPC MEM MAP.png|800px|frameless|center]]