The .OR directive is used to set the starting address of a program, a part of the program, or a data block. All following bytes are stored in consecutive addresses, starting at the address specified by expression. It's equivalent to the ORG directive found in most other assemblers.
In Version 3 of the SB-Assembler this directive will perform a boundary sync.
The .OR directive sets both the program counter and target address to the value of the expression.
This effectively switches off a possible patch mode (see .PH directive). A possible dummy mode is also terminated (see .DU directive). In Version 3 of the SB-Assembler the .OR directive will also set the .TA address in sync with the program counter again.
The expression may not contain forward referenced labels otherwise a fatal Undefined label error will be reported.
One single assembly run may contain several .OR directives.
But some additional rules exist when sending the generated code to an unformatted target file like BIN or HEX.
The .OR directive will close an unformatted target file because these file formats do not support address information. Formatted files do support address information and those files will not be closed by the .OR directive. This implies that you have to use the .OR directive before creating an unformatted file, otherwise you'll end up with an empty target file.
If you do use more than one .OR directive together with unformatted files you'll have to open a new target file every time the .OR directive is used. Therefore you should better use the .NO directive when you're using unformatted target files.
The occurrence of the .OR directive while using formatted files will flush the current target line buffer to the target file and a new target line is started with the new address in the address field.
Due to several questions from users I decided to change (read: improve) the behaviour of the .OR directive in combination with unformatted files.
As from software version 2.07 it is now allowed to start an unformatted file before setting the .OR address, but only if the unformatted file is still empty when the .OR directive is encountered.
This means that if the .OR directive is used when the unformatted file is no longer empty it will still close the target file, there is no way to prevent that!
Version 3 of the SB-Assembler also behaves in this improved way with regard to unformatted files. Version 3 also gives the user a warning when an unformatted file is closed by the .OR directive. Version 2 closes unformatted files without a warning!
It goes without saying that the programmer is responsible to prevent overlapping of memory spaces when multiple .OR directives are used in one assembly run.
The SB-Assembler will not protest if you reset the target address to an already used location of memory.
When writing a program that has to run in bank switched memory you better use the .PH directive instead of using the .OR directive to reset the program counter every time you want to start again from the beginning of the bank switched memory area.
If you insist on using the .OR directive for bank switched memory applications you should store every overlay in a separate target file.
With Version 3 of the SB-Assembler you may also use the .OR directive in combination with the .TA directive to create programs for bank switched memory.
.OR $1000 Store program from $1000 upwards ; ; ; .OR $2000 Continue from address $2000 ; ; ; .OR $0000 You can also continue at lower addresses ; ; ;