Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Locomotive BASIC
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== A notable omission - memory bank switching == 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. Through an arrangement of the custom circuitry, switching pages into one of the four 16KB pages in the Z80 memory map ($0xxx, $4xxx, $8xxx, $Cxxx) is possible. For instance, the top page ($C000) is (usually) occupied by both the video RAM, the BASIC ROM and (on disc equipped machines) the AMSDOS ROM with the hardware and firmware providing the necessary control of access. The firmware ROM is bank-switched to the lower 16KB, extra RAM (that beyond the Z80 64KB e.g. the additional 64KB of the CPC6128) and sideways ROMs (containing user machine code or 3rd party software) are mapped to the top page ($C000) - RAM can actually be mapped to any bank. The CRT controller generally maps to the 16KB video RAM at $C000 in the main Z80 address space with the hardware ensuring the video picture is not interrupted when other banks were switched into the same page. All CPC models supported this fairly advanced (for the time) bank-switching to increase the potential memory storage - even an un-expanded CPC464 uses fully 96KB of ROM and RAM mapped into the Z80 64KB address space. Memory writes are always applied only to RAM in the main 64KB address space, regardless of switched state, e.g. if the lower ROM ($0-$3FFF) is switched into the memory map, <code>POKE &800,0</code> will write into RAM regardless. Several configurations of where the switched banks occur in the memory map are supported by the KERNEL. The CPC464/664 hardware can address up to 256KB including up to eight 16KB sideways ROMs, controlled by the large custom chip. One position is used by the BASIC ROM and both the CPC664 and CPC464 expanded with the FDI1, use a further slot for the AMSDOS ROM - leaving six slots. The CPC6128 hardware permits bank switching up to 4MB with increased space for 16 (32 with a PCB hack) 16KB sideways ROMs. Again, two positions are occupied with BASIC and AMSDOS leaving 14 available for user or 3rd parties. The KERNEL provides several methods of accessing banked memory; some involve a pseudo 24bit address via a vector or extending the HL register pair using the C register. For ROMs only the high or low ROM switching is controlled by the top two bits of a 16-bit address. Still others can retrieve data from a bank as if it were in the mainstream Z80 address map or directly from the main 64KB of RAM regardless of the state of the banks. Kernel routines to access banked memory include <code>KL_FAR_CALL, KL_FAR_JMP, KL_RAM_LAM</code> among others. Prior to "calling sideways", i.e. switching in a bank and jumping to execute machine code at an address there, the kernel assembles structures on the Z80 stack to ensure the safe capture of inbound <code>RET</code>urns from code in banked memory - restoring the state of the banks and ensuring code execution continues without issue. It is quite normal to have calls between banked ROMs, indeed this happens seamlessly every time BASIC uses AMSDOS (disc commands) as both ROMs occupy the same physical address space. Due to the heavily interrupt driven nature of the CPC range, it is wise to leave the Z80 Stack Pointer (SP) register alone as local use can result in crashes should it be diverted and an interrupt occur (it is quite common to set the stack to a local block so it can simply be abandoned after a routine has run). Such interrupts are likely to rely on the Kernel's structures on the stack. Despite BASIC not providing support for this kernel functionality, use of banked memory in a BASIC program was certainly possible but required the use of machine code routines to do the switch and take advantage of the result. Banked memory could not be used for BASIC program code. On the bundled CP/M 2.2 and CP/M+ (CPC6128) discs was a two-part program to add primitive-but-adequate bank-switching commands to BASIC. When run, <CODE>BANKMAN.BAS</CODE> reserves 1317 bytes of RAM into which; it loads <CODE>BANKMAN.BIN</CODE>, makes a call to that binary and then deletes itself. The latter file contains machine code to initialise a set of RSXs to enable RAM bank switching from BASIC programs. Functionality includes saving and loading screens from banks, copying between banks etc. 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. To add further hindrance, although not copyrighted, BANKMAN.BAS is saved in protected mode (SAVE"<my_prog>",p) and so is not listable - meaning that you cannot easily determine the method to load the RSXs and so use them in your own programs - to eliminate the two-stage start up. Besides using banked memory to store screen images and rapidly switch between them, some applications implement "RAM Discs" but these are not supported under the cassette/AMSDOS firmware, being quite proprietary.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)