P65-Ophis Command Reference

Revision 3

Command Modes

These mostly follow the MOS Technology 6500 Microprocessor Familiy Programming Manual, except for the Accumulator mode. Accumulator instructions are written and interpreted identically to Implied mode instructions.

Basic arguments

Most arguments are just a number or label. The formats for these are below.

Numeric types

Label types

Normal labels are simply referred to by name. Anonymous labels may be referenced with strings of - or + signs (the label - refers to the immediate previous anonymous label, -- the one before that, etc., while + refers to the next anonymous label), and the special label ^ refers to the program counter at the start of the current instruction or pragma.

Normal labels are defined by prefixing a line with the label name and then a colon (e.g., label:). Anonymous labels are defined by prefixing a line with an asterisk (e.g., *).

Temporary labels are only reachable from inside the innermost enclosing .scope statement. They are identical to normal labels in every way, except that they start with an underscore.

String types

Strings are enclosed in double quotation marks. Backslashed characters (including backslashes and double quotes) are treated literally, so the string "The man said, \"The \\ character is the backslash.\"" produces the ASCII sequence for The man said, "The \ character is the backslash."

Strings are generally only used as arguments to assembler pragmas - usually for filenames (e.g., .include) but also for string data (in association with .byte).

Standards bizarreness note: Currently, attempting to pass a string to the .word or .dword statements produces a series of words/dwords where all bytes that aren't least-significant are zero. It's not at all clear that this is the right thing to do, but it's also not immediately clear what the right thing is.

Compound Arguments

Compound arguments may be built up from simple ones, using the standard +, -, *, and / operators, which carry the usual precedence. Also, the unary operators > and <, which bind more tightly than anything else, provide the high and low bytes of 16-bit values, respectively.

Use braces [ ] instead of parentheses ( ) when grouping arithmetic operations, as the parentheses are needed for the indirect addressing modes.

Examples:

Memory Model

In order to properly compute the locations of labels and the like, P65 must keep track of where assembled code will actually be sitting in memory, and it strives to do this in a way that is independent both of the target file and of the target machine.

Basic PC tracking

The primary technique P65 uses is "program counter tracking." As it assembles the code, it keeps track of a virtual program counter, and uses that to determine where the labels should go. (It's a little more complicated than this, thanks to some properties of the instruction set architecture, but that's beyond the scope of this document. See the implementation notes if you're morbidly curious.)

In the absence of an .org pragma, it assumes a starting PC of zero. .org is a simple pragma, setting the PC to the value that .org specifies. In the simplest case, one .org pragma appears at the beginning of the code and sets the location for the rest of the code, which is one contiguous block.

Basic Segmentation simulation

However, this isn't always practical. Often one wishes to have a region of memory reserved for data without actually mapping that memory to the file. On some systems (typically cartridge-based systems where ROM and RAM are seperate, and the target file only specifies the ROM image) this is mandatory. In order to access these variables symbolically, it's necessary to put the values into the label lookup table.

It is possible, but inconvenient, to do this with .alias, assigning a specific memory location to each variable. This requires careful coordination through your code, and makes creating reusable libraries all but impossible.

A better approach is to reserve a section at the beginning or end of your program, put an .org directive in, then use the .space directive to divide up the data area. This is still a bit inconvenient, though, because all variables must be assigned all at once. What we'd really like is to keep multiple PC counters, one for data and one for code.

The .text and .data directives do this. Each has its own PC that starts at zero, and you can switch between the two at any point without corrupting the other's counter. In this way each function can have a .data section (filled with .space commands) and a .text section (that contains the actual code). This lets our library routines be almost completely self-contained - we can have one source file that could be .included by multiple projects without getting in anything's way.

However, any given program may have its own ideas about where data and code go, and it's good to ensure with a .checkpc at the end of your code that you haven't accidentally overwritten code with data or vice versa. If your .data segment did start at zero, it's probably wise to make sure you aren't smashing the stack, too (which is sitting in the region from $0100 to $01FF).

If you write code with no segment-defining statements in it, the default segment is text.

The data segment is designed only for organizing labels. As such, errors will be flagged if you attempt to actually output information into a data segment.

General Segmentation Simulation

One text and data segment each is usually sufficient, but for the cases where it is not, P65 allows for user-defined segments. Putting a label after .text or .data produces a new segment with the specified name.

Say, for example, that we have access to the RAM at the low end of the address space, but want to reserve the zero page for truly critical variables, and use the rest of RAM for everything else. Let's also assume that this is a 6510 chip, and locations $00 and $01 are reserved for the I/O port. We could start our program off with:

.data
.org $200
.data zp
.org $2
.text
.org $800

And, to be safe, we would probably want to end our code with checks to make sure we aren't overwriting anything:

.data
.checkpc $800
.data zp
.checkpc $100

Assembler pragmas

Assembler pragmas are all instructions to the assembler that are not actual instructions. Currently implemented pragmas are:

The following pragmas are deprecated, added for compatibility with P65-Perl. Use the -d option to P65-Ophis to enable them.

The following pragmas haven't yet been implemented yet, but will be, in some form or other. Major omissions or glaring flaws with these should be reported...

Back to P65 Main Page