Relocating RSXs is a toughie, but in Part 2 of his RSX tutorial, DAVID HOLMES reckons he has the answer... It can be difficult to arrange for RSX routines to be relocatable as the code involves several absolute addresses which will require alteration unless the code is run at the address to which it was originally assembled. It is not always easy to predict where in memory each user may wish to place the code as the presence of external ROMs or other RSX routines, for example, alter the value of HIMEM to a considerable degree. For this reason it is desirable to allow the code to be as flexible as possible. There are two ways of achieving this. One way is to use a machine code relocator program which is added to the RSX code. This can be quite complex, however, and may involve a considerable amount of effort which is not justified in a short routine. BASIC solution The method used here is to use the BASIC loader program Listing 1 to relocate the code as described below. When the program has been developed the code can be assembled to any reasonable position and then the bytes relating to any absolute address can be noted. It may be easiest to assemble to two different locations and then use the assembler to compare the two blocks of code. The addresses noted as different are those referring to absolute addresses. An absolute address is an address that is defined as a fixed point in the memory rather than a point relative to the start of the code. Such an address will be always at the same distance from the start of the code but its actual value will depend upon the code origin. It is this value which must be adjusted to allow the code to run at any specific load address. The problems occur in the first section of code which sets up the RSX. For example, the address of the command table defined in bytes two and three is an absolute address. The same applies to the address of the workspace defined in bytes five and six, the address of the name table defined in bytes &d and &e and the address of the label .fade defined in bytes &10 and &11. The remainder of the code contains no absolute addresses (other than Firmware calls) and is completely relocatable. LISTING 1: RSX RELOCATION (INCOMPLET) 10 REM SCREEN FADE
20 REM by D. Holmes
...
Only absolute addresses referring to locations within the code itself require relocation for different load addresses. Absolute addresses are used when registers are loaded from memory locations (either numbered or labelled), when memory locations are loaded from registers and when calls or jumps (not relative jumps) are made to labelled locations. For this reason relative jumps (jr instructions) should be used when possible to reduce the amount of relocation work to be done. Firmware calls cause no problem as they are not affected by the position of the RSX code in memory.
Defining terms In order to explain the principles of relocation clearly it is valuable to define some terms. The absolute address itself is defined within the code by the contents of an address which is at a fixed point from the start of the code. To use the example of the command table, its address is pointed to by bytes two and three. This is true for any start address. The addresses of these bytes may be described as the Definition Offset Address (DOA) and this is found at the Definition Offset (DO) from the start of the code. For the command table the low byte of the DOA is at. start+1 and the high byte is at start+2. Only one value is required to define the position of this address so I have chosen to use the offset of the high byte. Therefore the DO value used for the relocation of this address is two. As stated above the absolute address pointed to is also at a fixed distance from the start of the code. The command table label for example is found at start + &0d. This may be described as the Absolute Offset Address (AOA) and it identifies a location at the Absolute Offset (AO) from the start of the code. In this case the AOA equals start + &0d and the AO has a value of &0d. To relocate the code each DOA must be loaded with the value of the related AOA. The DO values can be noted by an examination of the assembler listing or by using a comparison of the code assembled to two different locations as suggested above. The AO values are the offsets from the code origin of the actual values contained in both bytes of the DOA. These bytes must be subtracted from the code origin to give the AO value. Most assemblers will allow assembly to a code origin of zero (although the code is stored elsewhere). If the listing of this is examined the AO values can be read off directly for each DOA as the contents of the two bytes of each DOA give the value of the AO. Do not forget that they are given in low byte, high byte order and must be reversed to give the AO value. In short routines as in this case, only the low byte will actually be used as the high byte will be zero. LISTING 2 (INCOMPLET) org &200
.start
...The length of the code can be worked out from the assembler listing so the BASIC loader can reserve the correct number of bytes as shown in lines 30 and 40 of Listing 1. It is important that HIMEM is not below (&3fff+code length) when the program is run or the workspace and command table may be loaded below &3fff. This is below the lower ROM and the RSX will not be initialised. The bulk of the code can then be poked in with a standard hex loader. To complete the program the relocator section reads in the pairs of DO and AO values from a DATA line. Table of values The table shows the DO and AO values for each address in the |FADE program as taken from listing 2 (see AA54). | Label defined | Definition Offset (High byte) | Absolute Offset | | command _table | &2 | &d | | space | &5 | &9 | | name_table | &e | &12 | | fade | &11 | &17 |
As BASIC now knows the start address, it is easy to find each AOA by adding the value of the AO to start. If this is calculated in hexadecimal, the low and high bytes can be separated using the RIGHTS and LEFT$ funtions.
The high byte of the DOA can be found by adding the value of the DO to start. The low byte can be found by subtracting one from this value. The low byte of the AOA is poked into the low byte of the DOA and the high byte of the AOA is poked into the high byte of the DOA. This procedure is performed for each DOA and the code is then CALLed. This installs the RSX and the loader program is deleted to prevent it from being run again. It is worth spending a little time adding a relocator to any RSX programs which are designed to store code just below HIMEM as this allows a library of routines to be built up. These can then be used when required with the minimum usage of memory as each routine can be added at the highest available location. AA#55 | ★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser... |
CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 197 millisecondes et consultée 1626 foisL'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko. |
|
| 
