mirror of
https://github.com/michaelcmartin/Ophis.git
synced 2024-12-08 18:49:40 +00:00
Remove spurious CRLFs
This commit is contained in:
parent
af50326e39
commit
57e663cf29
@ -1,451 +1,451 @@
|
||||
<appendix id="ref-link">
|
||||
<title>Ophis Command Reference</title>
|
||||
<section>
|
||||
<title>Command Modes</title>
|
||||
<para>
|
||||
These mostly follow the <emphasis>MOS Technology 6500
|
||||
Microprocessor Family Programming Manual</emphasis>, except
|
||||
for the Accumulator mode. Accumulator instructions are written
|
||||
and interpreted identically to Implied mode instructions.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Implied:</emphasis> <literal>RTS</literal></para></listitem>
|
||||
<listitem><para><emphasis>Accumulator:</emphasis> <literal>LSR</literal></para></listitem>
|
||||
<listitem><para><emphasis>Immediate:</emphasis> <literal>LDA #$06</literal></para></listitem>
|
||||
<listitem><para><emphasis>Zero Page:</emphasis> <literal>LDA $7C</literal></para></listitem>
|
||||
<listitem><para><emphasis>Zero Page, X:</emphasis> <literal>LDA $7C,X</literal></para></listitem>
|
||||
<listitem><para><emphasis>Zero Page, Y:</emphasis> <literal>LDA $7C,Y</literal></para></listitem>
|
||||
<listitem><para><emphasis>Absolute:</emphasis> <literal>LDA $D020</literal></para></listitem>
|
||||
<listitem><para><emphasis>Absolute, X:</emphasis> <literal>LDA $D000,X</literal></para></listitem>
|
||||
<listitem><para><emphasis>Absolute, Y:</emphasis> <literal>LDA $D000,Y</literal></para></listitem>
|
||||
<listitem><para><emphasis>(Zero Page Indirect, X):</emphasis> <literal>LDA ($80, X)</literal></para></listitem>
|
||||
<listitem><para><emphasis>(Zero Page Indirect), Y:</emphasis> <literal>LDA ($80), Y</literal></para></listitem>
|
||||
<listitem><para><emphasis>(Absolute Indirect):</emphasis> <literal>JMP ($A000)</literal></para></listitem>
|
||||
<listitem><para><emphasis>Relative:</emphasis> <literal>BNE loop</literal></para></listitem>
|
||||
<listitem><para><emphasis>(Absolute Indirect, X):</emphasis> <literal>JMP ($A000, X)</literal> — Only available with 65C02 extensions</para></listitem>
|
||||
<listitem><para><emphasis>(Zero Page Indirect):</emphasis> <literal>LDX ($80)</literal> — Only available with 65C02 extensions</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section>
|
||||
<title>Basic arguments</title>
|
||||
<para>
|
||||
Most arguments are just a number or label. The formats for
|
||||
these are below.
|
||||
</para>
|
||||
<section>
|
||||
<title>Numeric types</title>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Hex:</emphasis> <literal>$41</literal> (Prefixed with $)</para></listitem>
|
||||
<listitem><para><emphasis>Decimal:</emphasis> <literal>65</literal> (No markings)</para></listitem>
|
||||
<listitem><para><emphasis>Octal:</emphasis> <literal>0101</literal> (Prefixed with zero)</para></listitem>
|
||||
<listitem><para><emphasis>Binary:</emphasis> <literal>%01000001</literal> (Prefixed with %)</para></listitem>
|
||||
<listitem><para><emphasis>Character:</emphasis> <literal>'A</literal> (Prefixed with single quote)</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section>
|
||||
<title>Label types</title>
|
||||
<para>
|
||||
Normal labels are simply referred to by name. Anonymous
|
||||
labels may be referenced with strings of - or + signs (the
|
||||
label <literal>-</literal> refers to the immediate
|
||||
previous anonymous label, <literal>--</literal> the
|
||||
one before that, etc., while <literal>+</literal>
|
||||
refers to the next anonymous label), and the special
|
||||
label <literal>^</literal> refers to the program
|
||||
counter at the start of the current instruction or directive.
|
||||
</para>
|
||||
<para>
|
||||
Normal labels are <emphasis>defined</emphasis> by
|
||||
prefixing a line with the label name and then a colon
|
||||
(e.g., <literal>label:</literal>). Anonymous labels
|
||||
are defined by prefixing a line with an asterisk
|
||||
(e.g., <literal>*</literal>).
|
||||
</para>
|
||||
<para>
|
||||
Temporary labels are only reachable from inside the
|
||||
innermost enclosing <literal>.scope</literal>
|
||||
statement. They are identical to normal labels in every
|
||||
way, except that they start with an underscore.
|
||||
</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>String types</title>
|
||||
<para>
|
||||
Strings are enclosed in double quotation marks. Backslashed
|
||||
characters (including backslashes and double quotes) are
|
||||
treated literally, so the string <literal>"The man said,
|
||||
\"The \\ character is the backslash.\""</literal> produces
|
||||
the ASCII sequence for <literal>The man said, "The \
|
||||
character is the backslash."</literal>
|
||||
</para>
|
||||
<para>
|
||||
Strings are generally only used as arguments to assembler
|
||||
directives—usually for filenames
|
||||
(e.g., <literal>.include</literal>) but also for string
|
||||
data (in association with <literal>.byte</literal>).
|
||||
</para>
|
||||
<para>
|
||||
It is legal, though unusual, to attempt to pass a string to
|
||||
the other data statements. This will produces a series of
|
||||
words/dwords where all bytes that aren't least-significant
|
||||
are zero. Endianness and size will match what the directive
|
||||
itself indicated.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section>
|
||||
<title>Compound Arguments</title>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
Use brackets [ ] instead of parentheses ( ) when grouping
|
||||
arithmetic operations, as the parentheses are needed for the
|
||||
indirect addressing modes.
|
||||
</para>
|
||||
<para>
|
||||
Examples:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para><literal>$D000</literal> evaluates to $D000</para></listitem>
|
||||
<listitem><para><literal>$D000+32</literal> evaluates to $D020</para></listitem>
|
||||
<listitem><para><literal>$D000+$20</literal> also evaluates to $D020</para></listitem>
|
||||
<listitem><para><literal><$D000+32</literal> evaluates to $20</para></listitem>
|
||||
<listitem><para><literal>>$D000+32</literal> evaluates to $F0</para></listitem>
|
||||
<listitem><para><literal>>[$D000+32]</literal> evaluates to $D0</para></listitem>
|
||||
<listitem><para><literal>>$D000-275</literal> evaluates to $CE</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section>
|
||||
<title>Memory Model</title>
|
||||
<para>
|
||||
In order to properly compute the locations of labels and the
|
||||
like, Ophis 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.
|
||||
</para>
|
||||
<section>
|
||||
<title>Basic PC tracking</title>
|
||||
<para>
|
||||
The primary technique Ophis uses is <emphasis>program counter
|
||||
tracking</emphasis>. As it assembles the code, it keeps
|
||||
track of a virtual program counter, and uses that to
|
||||
determine where the labels should go.
|
||||
</para>
|
||||
<para>
|
||||
In the absence of an <literal>.org</literal> directive, it
|
||||
assumes a starting PC of zero. <literal>.org</literal>
|
||||
is a simple directive, setting the PC to the value
|
||||
that <literal>.org</literal> specifies. In the simplest
|
||||
case, one <literal>.org</literal> directive appears at the
|
||||
beginning of the code and sets the location for the rest of
|
||||
the code, which is one contiguous block.
|
||||
</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>Basic Segmentation simulation</title>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
It is possible, but inconvenient, to do this
|
||||
with <literal>.alias</literal>, assigning a specific
|
||||
memory location to each variable. This requires careful
|
||||
coordination through your code, and makes creating reusable
|
||||
libraries all but impossible.
|
||||
</para>
|
||||
<para>
|
||||
A better approach is to reserve a section at the beginning
|
||||
or end of your program, put an <literal>.org</literal>
|
||||
directive in, then use the <literal>.space</literal>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
The <literal>.text</literal>
|
||||
and <literal>.data</literal> 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 <literal>.data</literal> section (filled
|
||||
with <literal>.space</literal> commands) and
|
||||
a <literal>.text</literal> 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 <literal>.included</literal> by multiple
|
||||
projects without getting in anything's way.
|
||||
</para>
|
||||
<para>
|
||||
However, any given program may have its own ideas about
|
||||
where data and code go, and it's good to ensure with
|
||||
a <literal>.checkpc</literal> at the end of your code
|
||||
that you haven't accidentally overwritten code with data or
|
||||
vice versa. If your <literal>.data</literal>
|
||||
segment <emphasis>did</emphasis> 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).
|
||||
</para>
|
||||
<para>
|
||||
If you write code with no segment-defining statements in
|
||||
it, the default segment
|
||||
is <literal>text</literal>.
|
||||
</para>
|
||||
<para>
|
||||
The <literal>data</literal> segment is designed only
|
||||
for organizing labels. As such, errors will be flagged if
|
||||
you attempt to actually output information into
|
||||
a <literal>data</literal> segment.
|
||||
</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>General Segmentation Simulation</title>
|
||||
<para>
|
||||
One text and data segment each is usually sufficient, but
|
||||
for the cases where it is not, Ophis allows for user-defined
|
||||
segments. Putting a label
|
||||
after <literal>.text</literal>
|
||||
or <literal>.data</literal> produces a new segment with
|
||||
the specified name.
|
||||
</para>
|
||||
<para>
|
||||
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:
|
||||
</para>
|
||||
<programlisting>
|
||||
.data
|
||||
.org $200
|
||||
.data zp
|
||||
.org $2
|
||||
.text
|
||||
.org $800
|
||||
</programlisting>
|
||||
<para>
|
||||
And, to be safe, we would probably want to end our code
|
||||
with checks to make sure we aren't overwriting anything:
|
||||
</para>
|
||||
<programlisting>
|
||||
.data
|
||||
.checkpc $800
|
||||
.data zp
|
||||
.checkpc $100
|
||||
</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
<section>
|
||||
<title>Macros</title>
|
||||
<para>
|
||||
Assembly language is a powerful tool—however, there are
|
||||
many tasks that need to be done repeatedly, and with
|
||||
mind-numbing minor modifications. Ophis includes a facility
|
||||
for <emphasis>macros</emphasis> to allow this. Ophis macros
|
||||
are very similar in form to function calls in higher level
|
||||
languages.
|
||||
</para>
|
||||
<section>
|
||||
<title>Defining Macros</title>
|
||||
<para>
|
||||
Macros are defined with the <literal>.macro</literal>
|
||||
and <literal>.macend</literal> commands. Here's a
|
||||
simple one that will clear the screen on a Commodore
|
||||
64:
|
||||
</para>
|
||||
<programlisting>
|
||||
.macro clr'screen
|
||||
lda #147
|
||||
jsr $FFD2
|
||||
.macend
|
||||
</programlisting>
|
||||
</section>
|
||||
<section>
|
||||
<title>Invoking Macros</title>
|
||||
<para>
|
||||
To invoke a macro, either use
|
||||
the <literal>.invoke</literal> command or backquote the
|
||||
name of the routine. The previous macro may be expanded
|
||||
out in either of two ways, at any point in the
|
||||
source:
|
||||
</para>
|
||||
<programlisting>.invoke clr'screen</programlisting>
|
||||
<para>or</para>
|
||||
<programlisting>`clr'screen</programlisting>
|
||||
<para>will work equally well.</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>Passing Arguments to Macros</title>
|
||||
<para>
|
||||
Macros may take arguments. The arguments to a macro are
|
||||
all of the <quote>word</quote> type, though byte values may
|
||||
be passed and used as bytes as well. The first argument in
|
||||
an invocation is bound to the label
|
||||
<literal>_1</literal>, the second
|
||||
to <literal>_2</literal>, and so on. Here's a macro
|
||||
for storing a 16-bit value into a word pointer:
|
||||
</para>
|
||||
<programlisting>
|
||||
.macro store16 ; `store16 dest, src
|
||||
lda #<_2
|
||||
sta _1
|
||||
lda #>_2
|
||||
sta _1+1
|
||||
.macend
|
||||
</programlisting>
|
||||
<para>
|
||||
Macro arguments behave, for the most part, as if they were
|
||||
defined by <literal>.alias</literal>
|
||||
commands <emphasis>in the calling context</emphasis>.
|
||||
(They differ in that they will not produce duplicate-label
|
||||
errors if those names already exist in the calling scope,
|
||||
and in that they disappear after the call is
|
||||
completed.)
|
||||
</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>Features and Restrictions of the Ophis Macro Model</title>
|
||||
<para>
|
||||
Unlike most macro systems (which do textual replacement),
|
||||
Ophis macros evaluate their arguments and bind them into the
|
||||
symbol table as temporary labels. This produces some
|
||||
benefits, but it also puts some restrictions on what kinds of
|
||||
macros may be defined.
|
||||
</para>
|
||||
<para>
|
||||
The primary benefit of this <quote>expand-via-binding</quote>
|
||||
discipline is that there are no surprises in the semantics.
|
||||
The expression <literal>_1+1</literal> in the macro above
|
||||
will always evaluate to one more than the value that was
|
||||
passed as the first argument, even if that first argument is
|
||||
some immensely complex expression that an
|
||||
expand-via-substitution method may accidentally
|
||||
mangle.
|
||||
</para>
|
||||
<para>
|
||||
The primary disadvantage of the expand-via-binding
|
||||
discipline is that only fixed numbers of words and bytes
|
||||
may be passed. A substitution-based system could define a
|
||||
macro including the line <literal>LDA _1</literal> and
|
||||
accept as arguments both <literal>$C000</literal>
|
||||
(which would put the value of memory location $C000 into
|
||||
the accumulator) and <literal>#$40</literal> (which
|
||||
would put the immediate value $40 into the accumulator).
|
||||
If you <emphasis>really</emphasis> need this kind of
|
||||
behavior, a run a C preprocessor over your Ophis source,
|
||||
and use <literal>#define</literal> to your heart's
|
||||
content.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section>
|
||||
<title>Assembler directives</title>
|
||||
<para>
|
||||
Assembler directives are all instructions to the assembler
|
||||
that are not actual instructions. Ophis's set of directives
|
||||
follow.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para><literal>.advance</literal> <emphasis>address</emphasis>:
|
||||
Forces the program counter to
|
||||
be <emphasis>address</emphasis>. Unlike
|
||||
the <literal>.org</literal>
|
||||
directive, <literal>.advance</literal> outputs zeroes until the
|
||||
program counter reaches a specified address. Attempting
|
||||
to <literal>.advance</literal> to a point behind the current
|
||||
program counter is an assemble-time error.</para></listitem>
|
||||
<listitem><para><literal>.alias</literal> <emphasis>label</emphasis> <emphasis>value</emphasis>: The
|
||||
.alias directive assigns an arbitrary value to a label. This
|
||||
value may be an arbitrary argument, but cannot reference any
|
||||
label that has not already been defined (this prevents
|
||||
recursive label dependencies).</para></listitem>
|
||||
<listitem><para><literal>.byte</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ... ]:
|
||||
Specifies a series of arguments, which are evaluated, and
|
||||
strings, which are included as raw ASCII data. The final
|
||||
results of these arguments must be one byte in size. Seperate
|
||||
constants are seperated by comments.</para></listitem>
|
||||
<listitem><para><literal>.checkpc</literal> <emphasis>address</emphasis>: Ensures that the
|
||||
program counter is less than or equal to the address
|
||||
specified, and emits an assemble-time error if it is not.
|
||||
<emphasis>This produces no code in the final binary - it is there to
|
||||
ensure that linking a large amount of data together does not
|
||||
overstep memory boundaries.</emphasis></para></listitem>
|
||||
<listitem><para><literal>.data</literal> <emphasis>[label]</emphasis>: Sets the segment to
|
||||
the segment name specified and disallows output. If no label
|
||||
is given, switches to the default data segment.</para></listitem>
|
||||
<listitem><para><literal>.incbin</literal> <emphasis>filename</emphasis>: Inserts the
|
||||
contents of the file specified as binary data. Use it to
|
||||
include graphics information, precompiled code, or other
|
||||
non-assembler data.</para></listitem>
|
||||
<listitem><para><literal>.include</literal> <emphasis>filename</emphasis>: Includes the
|
||||
entirety of the file specified at that point in the program.
|
||||
Use this to order your final sources.</para></listitem>
|
||||
<listitem><para><literal>.org</literal> <emphasis>address</emphasis>: Sets the program
|
||||
counter to the address specified. <emphasis>This does not emit any
|
||||
code in and of itself, nor does it overwrite anything that
|
||||
previously existed.</emphasis> If you wish to jump ahead in memory,
|
||||
use <literal>.advance</literal>.</para></listitem>
|
||||
<listitem><para><literal>.require</literal> <emphasis>filename</emphasis>: Includes the entirety
|
||||
of the file specified at that point in the program. Unlike <literal>.include</literal>,
|
||||
however, code included with <literal>.require</literal> will only be inserted once.
|
||||
The <literal>.require</literal> directive is useful for ensuring that certain code libraries
|
||||
are somewhere in the final binary. They are also very useful for guaranteeing that
|
||||
macro libraries are available.</para></listitem>
|
||||
<listitem><para><literal>.space</literal> <emphasis>label</emphasis> <emphasis>size</emphasis>: This
|
||||
directive is used to organize global variables. It defines the
|
||||
label specified to be at the current location of the program
|
||||
counter, and then advances the program counter <emphasis>size</emphasis>
|
||||
steps ahead. No actual code is produced. This is equivalent
|
||||
to <literal>label: .org ^+size</literal>.</para></listitem>
|
||||
<listitem><para><literal>.text</literal> <emphasis>[label]</emphasis>: Sets the segment to
|
||||
the segment name specified and allows output. If no label is
|
||||
given, switches to the default text segment.</para></listitem>
|
||||
<listitem><para><literal>.word</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ... ]:
|
||||
Like <literal>.byte</literal>, but values are all treated as two-byte
|
||||
values and stored low-end first (as is the 6502's wont). Use
|
||||
this to create jump tables (an unadorned label will evaluate
|
||||
to that label's location) or otherwise store 16-bit
|
||||
data.</para></listitem>
|
||||
<listitem><para><literal>.dword</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ...]:
|
||||
Like <literal>.word</literal>, but for 32-bit values.</para></listitem>
|
||||
<listitem><para><literal>.wordbe</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ...]:
|
||||
Like <literal>.word</literal>, but stores the value in a big-endian format (high byte first).</para></listitem>
|
||||
<listitem><para><literal>.dwordbe</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ...]:
|
||||
Like <literal>.dword</literal>, but stores the value high byte first.</para></listitem>
|
||||
<listitem><para><literal>.scope</literal>: Starts a new scope block. Labels
|
||||
that begin with an underscore are only reachable from within
|
||||
their innermost enclosing <literal>.scope</literal> statement.</para></listitem>
|
||||
<listitem><para><literal>.scend</literal>: Ends a scope block. Makes the
|
||||
temporary labels defined since the last <literal>.scope</literal>
|
||||
statement unreachable, and permits them to be redefined in a
|
||||
new scope.</para></listitem>
|
||||
<listitem><para><literal>.macro</literal> <emphasis>name</emphasis>: Begins a macro
|
||||
definition block. This is a scope block that can be inlined
|
||||
at arbitrary points with <literal>.invoke</literal>. Arguments to the
|
||||
macro will be bound to temporary labels with names like
|
||||
<literal>_1</literal>, <literal>_2</literal>, etc.</para></listitem>
|
||||
<listitem><para><literal>.macend</literal>: Ends a macro definition
|
||||
block.</para></listitem>
|
||||
<listitem><para><literal>.invoke</literal> <emphasis>label</emphasis> [<emphasis>argument</emphasis> [,
|
||||
<emphasis>argument</emphasis> ...]]: invokes (inlines) the specified
|
||||
macro, binding the values of the arguments to the ones the
|
||||
macro definition intends to read. A shorthand for <literal>.invoke</literal>
|
||||
is the name of the macro to invoke, backquoted.</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</appendix>
|
||||
<appendix id="ref-link">
|
||||
<title>Ophis Command Reference</title>
|
||||
<section>
|
||||
<title>Command Modes</title>
|
||||
<para>
|
||||
These mostly follow the <emphasis>MOS Technology 6500
|
||||
Microprocessor Family Programming Manual</emphasis>, except
|
||||
for the Accumulator mode. Accumulator instructions are written
|
||||
and interpreted identically to Implied mode instructions.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Implied:</emphasis> <literal>RTS</literal></para></listitem>
|
||||
<listitem><para><emphasis>Accumulator:</emphasis> <literal>LSR</literal></para></listitem>
|
||||
<listitem><para><emphasis>Immediate:</emphasis> <literal>LDA #$06</literal></para></listitem>
|
||||
<listitem><para><emphasis>Zero Page:</emphasis> <literal>LDA $7C</literal></para></listitem>
|
||||
<listitem><para><emphasis>Zero Page, X:</emphasis> <literal>LDA $7C,X</literal></para></listitem>
|
||||
<listitem><para><emphasis>Zero Page, Y:</emphasis> <literal>LDA $7C,Y</literal></para></listitem>
|
||||
<listitem><para><emphasis>Absolute:</emphasis> <literal>LDA $D020</literal></para></listitem>
|
||||
<listitem><para><emphasis>Absolute, X:</emphasis> <literal>LDA $D000,X</literal></para></listitem>
|
||||
<listitem><para><emphasis>Absolute, Y:</emphasis> <literal>LDA $D000,Y</literal></para></listitem>
|
||||
<listitem><para><emphasis>(Zero Page Indirect, X):</emphasis> <literal>LDA ($80, X)</literal></para></listitem>
|
||||
<listitem><para><emphasis>(Zero Page Indirect), Y:</emphasis> <literal>LDA ($80), Y</literal></para></listitem>
|
||||
<listitem><para><emphasis>(Absolute Indirect):</emphasis> <literal>JMP ($A000)</literal></para></listitem>
|
||||
<listitem><para><emphasis>Relative:</emphasis> <literal>BNE loop</literal></para></listitem>
|
||||
<listitem><para><emphasis>(Absolute Indirect, X):</emphasis> <literal>JMP ($A000, X)</literal> — Only available with 65C02 extensions</para></listitem>
|
||||
<listitem><para><emphasis>(Zero Page Indirect):</emphasis> <literal>LDX ($80)</literal> — Only available with 65C02 extensions</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section>
|
||||
<title>Basic arguments</title>
|
||||
<para>
|
||||
Most arguments are just a number or label. The formats for
|
||||
these are below.
|
||||
</para>
|
||||
<section>
|
||||
<title>Numeric types</title>
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Hex:</emphasis> <literal>$41</literal> (Prefixed with $)</para></listitem>
|
||||
<listitem><para><emphasis>Decimal:</emphasis> <literal>65</literal> (No markings)</para></listitem>
|
||||
<listitem><para><emphasis>Octal:</emphasis> <literal>0101</literal> (Prefixed with zero)</para></listitem>
|
||||
<listitem><para><emphasis>Binary:</emphasis> <literal>%01000001</literal> (Prefixed with %)</para></listitem>
|
||||
<listitem><para><emphasis>Character:</emphasis> <literal>'A</literal> (Prefixed with single quote)</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section>
|
||||
<title>Label types</title>
|
||||
<para>
|
||||
Normal labels are simply referred to by name. Anonymous
|
||||
labels may be referenced with strings of - or + signs (the
|
||||
label <literal>-</literal> refers to the immediate
|
||||
previous anonymous label, <literal>--</literal> the
|
||||
one before that, etc., while <literal>+</literal>
|
||||
refers to the next anonymous label), and the special
|
||||
label <literal>^</literal> refers to the program
|
||||
counter at the start of the current instruction or directive.
|
||||
</para>
|
||||
<para>
|
||||
Normal labels are <emphasis>defined</emphasis> by
|
||||
prefixing a line with the label name and then a colon
|
||||
(e.g., <literal>label:</literal>). Anonymous labels
|
||||
are defined by prefixing a line with an asterisk
|
||||
(e.g., <literal>*</literal>).
|
||||
</para>
|
||||
<para>
|
||||
Temporary labels are only reachable from inside the
|
||||
innermost enclosing <literal>.scope</literal>
|
||||
statement. They are identical to normal labels in every
|
||||
way, except that they start with an underscore.
|
||||
</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>String types</title>
|
||||
<para>
|
||||
Strings are enclosed in double quotation marks. Backslashed
|
||||
characters (including backslashes and double quotes) are
|
||||
treated literally, so the string <literal>"The man said,
|
||||
\"The \\ character is the backslash.\""</literal> produces
|
||||
the ASCII sequence for <literal>The man said, "The \
|
||||
character is the backslash."</literal>
|
||||
</para>
|
||||
<para>
|
||||
Strings are generally only used as arguments to assembler
|
||||
directives—usually for filenames
|
||||
(e.g., <literal>.include</literal>) but also for string
|
||||
data (in association with <literal>.byte</literal>).
|
||||
</para>
|
||||
<para>
|
||||
It is legal, though unusual, to attempt to pass a string to
|
||||
the other data statements. This will produces a series of
|
||||
words/dwords where all bytes that aren't least-significant
|
||||
are zero. Endianness and size will match what the directive
|
||||
itself indicated.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section>
|
||||
<title>Compound Arguments</title>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
Use brackets [ ] instead of parentheses ( ) when grouping
|
||||
arithmetic operations, as the parentheses are needed for the
|
||||
indirect addressing modes.
|
||||
</para>
|
||||
<para>
|
||||
Examples:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para><literal>$D000</literal> evaluates to $D000</para></listitem>
|
||||
<listitem><para><literal>$D000+32</literal> evaluates to $D020</para></listitem>
|
||||
<listitem><para><literal>$D000+$20</literal> also evaluates to $D020</para></listitem>
|
||||
<listitem><para><literal><$D000+32</literal> evaluates to $20</para></listitem>
|
||||
<listitem><para><literal>>$D000+32</literal> evaluates to $F0</para></listitem>
|
||||
<listitem><para><literal>>[$D000+32]</literal> evaluates to $D0</para></listitem>
|
||||
<listitem><para><literal>>$D000-275</literal> evaluates to $CE</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section>
|
||||
<title>Memory Model</title>
|
||||
<para>
|
||||
In order to properly compute the locations of labels and the
|
||||
like, Ophis 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.
|
||||
</para>
|
||||
<section>
|
||||
<title>Basic PC tracking</title>
|
||||
<para>
|
||||
The primary technique Ophis uses is <emphasis>program counter
|
||||
tracking</emphasis>. As it assembles the code, it keeps
|
||||
track of a virtual program counter, and uses that to
|
||||
determine where the labels should go.
|
||||
</para>
|
||||
<para>
|
||||
In the absence of an <literal>.org</literal> directive, it
|
||||
assumes a starting PC of zero. <literal>.org</literal>
|
||||
is a simple directive, setting the PC to the value
|
||||
that <literal>.org</literal> specifies. In the simplest
|
||||
case, one <literal>.org</literal> directive appears at the
|
||||
beginning of the code and sets the location for the rest of
|
||||
the code, which is one contiguous block.
|
||||
</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>Basic Segmentation simulation</title>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
It is possible, but inconvenient, to do this
|
||||
with <literal>.alias</literal>, assigning a specific
|
||||
memory location to each variable. This requires careful
|
||||
coordination through your code, and makes creating reusable
|
||||
libraries all but impossible.
|
||||
</para>
|
||||
<para>
|
||||
A better approach is to reserve a section at the beginning
|
||||
or end of your program, put an <literal>.org</literal>
|
||||
directive in, then use the <literal>.space</literal>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
The <literal>.text</literal>
|
||||
and <literal>.data</literal> 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 <literal>.data</literal> section (filled
|
||||
with <literal>.space</literal> commands) and
|
||||
a <literal>.text</literal> 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 <literal>.included</literal> by multiple
|
||||
projects without getting in anything's way.
|
||||
</para>
|
||||
<para>
|
||||
However, any given program may have its own ideas about
|
||||
where data and code go, and it's good to ensure with
|
||||
a <literal>.checkpc</literal> at the end of your code
|
||||
that you haven't accidentally overwritten code with data or
|
||||
vice versa. If your <literal>.data</literal>
|
||||
segment <emphasis>did</emphasis> 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).
|
||||
</para>
|
||||
<para>
|
||||
If you write code with no segment-defining statements in
|
||||
it, the default segment
|
||||
is <literal>text</literal>.
|
||||
</para>
|
||||
<para>
|
||||
The <literal>data</literal> segment is designed only
|
||||
for organizing labels. As such, errors will be flagged if
|
||||
you attempt to actually output information into
|
||||
a <literal>data</literal> segment.
|
||||
</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>General Segmentation Simulation</title>
|
||||
<para>
|
||||
One text and data segment each is usually sufficient, but
|
||||
for the cases where it is not, Ophis allows for user-defined
|
||||
segments. Putting a label
|
||||
after <literal>.text</literal>
|
||||
or <literal>.data</literal> produces a new segment with
|
||||
the specified name.
|
||||
</para>
|
||||
<para>
|
||||
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:
|
||||
</para>
|
||||
<programlisting>
|
||||
.data
|
||||
.org $200
|
||||
.data zp
|
||||
.org $2
|
||||
.text
|
||||
.org $800
|
||||
</programlisting>
|
||||
<para>
|
||||
And, to be safe, we would probably want to end our code
|
||||
with checks to make sure we aren't overwriting anything:
|
||||
</para>
|
||||
<programlisting>
|
||||
.data
|
||||
.checkpc $800
|
||||
.data zp
|
||||
.checkpc $100
|
||||
</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
<section>
|
||||
<title>Macros</title>
|
||||
<para>
|
||||
Assembly language is a powerful tool—however, there are
|
||||
many tasks that need to be done repeatedly, and with
|
||||
mind-numbing minor modifications. Ophis includes a facility
|
||||
for <emphasis>macros</emphasis> to allow this. Ophis macros
|
||||
are very similar in form to function calls in higher level
|
||||
languages.
|
||||
</para>
|
||||
<section>
|
||||
<title>Defining Macros</title>
|
||||
<para>
|
||||
Macros are defined with the <literal>.macro</literal>
|
||||
and <literal>.macend</literal> commands. Here's a
|
||||
simple one that will clear the screen on a Commodore
|
||||
64:
|
||||
</para>
|
||||
<programlisting>
|
||||
.macro clr'screen
|
||||
lda #147
|
||||
jsr $FFD2
|
||||
.macend
|
||||
</programlisting>
|
||||
</section>
|
||||
<section>
|
||||
<title>Invoking Macros</title>
|
||||
<para>
|
||||
To invoke a macro, either use
|
||||
the <literal>.invoke</literal> command or backquote the
|
||||
name of the routine. The previous macro may be expanded
|
||||
out in either of two ways, at any point in the
|
||||
source:
|
||||
</para>
|
||||
<programlisting>.invoke clr'screen</programlisting>
|
||||
<para>or</para>
|
||||
<programlisting>`clr'screen</programlisting>
|
||||
<para>will work equally well.</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>Passing Arguments to Macros</title>
|
||||
<para>
|
||||
Macros may take arguments. The arguments to a macro are
|
||||
all of the <quote>word</quote> type, though byte values may
|
||||
be passed and used as bytes as well. The first argument in
|
||||
an invocation is bound to the label
|
||||
<literal>_1</literal>, the second
|
||||
to <literal>_2</literal>, and so on. Here's a macro
|
||||
for storing a 16-bit value into a word pointer:
|
||||
</para>
|
||||
<programlisting>
|
||||
.macro store16 ; `store16 dest, src
|
||||
lda #<_2
|
||||
sta _1
|
||||
lda #>_2
|
||||
sta _1+1
|
||||
.macend
|
||||
</programlisting>
|
||||
<para>
|
||||
Macro arguments behave, for the most part, as if they were
|
||||
defined by <literal>.alias</literal>
|
||||
commands <emphasis>in the calling context</emphasis>.
|
||||
(They differ in that they will not produce duplicate-label
|
||||
errors if those names already exist in the calling scope,
|
||||
and in that they disappear after the call is
|
||||
completed.)
|
||||
</para>
|
||||
</section>
|
||||
<section>
|
||||
<title>Features and Restrictions of the Ophis Macro Model</title>
|
||||
<para>
|
||||
Unlike most macro systems (which do textual replacement),
|
||||
Ophis macros evaluate their arguments and bind them into the
|
||||
symbol table as temporary labels. This produces some
|
||||
benefits, but it also puts some restrictions on what kinds of
|
||||
macros may be defined.
|
||||
</para>
|
||||
<para>
|
||||
The primary benefit of this <quote>expand-via-binding</quote>
|
||||
discipline is that there are no surprises in the semantics.
|
||||
The expression <literal>_1+1</literal> in the macro above
|
||||
will always evaluate to one more than the value that was
|
||||
passed as the first argument, even if that first argument is
|
||||
some immensely complex expression that an
|
||||
expand-via-substitution method may accidentally
|
||||
mangle.
|
||||
</para>
|
||||
<para>
|
||||
The primary disadvantage of the expand-via-binding
|
||||
discipline is that only fixed numbers of words and bytes
|
||||
may be passed. A substitution-based system could define a
|
||||
macro including the line <literal>LDA _1</literal> and
|
||||
accept as arguments both <literal>$C000</literal>
|
||||
(which would put the value of memory location $C000 into
|
||||
the accumulator) and <literal>#$40</literal> (which
|
||||
would put the immediate value $40 into the accumulator).
|
||||
If you <emphasis>really</emphasis> need this kind of
|
||||
behavior, a run a C preprocessor over your Ophis source,
|
||||
and use <literal>#define</literal> to your heart's
|
||||
content.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
<section>
|
||||
<title>Assembler directives</title>
|
||||
<para>
|
||||
Assembler directives are all instructions to the assembler
|
||||
that are not actual instructions. Ophis's set of directives
|
||||
follow.
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para><literal>.advance</literal> <emphasis>address</emphasis>:
|
||||
Forces the program counter to
|
||||
be <emphasis>address</emphasis>. Unlike
|
||||
the <literal>.org</literal>
|
||||
directive, <literal>.advance</literal> outputs zeroes until the
|
||||
program counter reaches a specified address. Attempting
|
||||
to <literal>.advance</literal> to a point behind the current
|
||||
program counter is an assemble-time error.</para></listitem>
|
||||
<listitem><para><literal>.alias</literal> <emphasis>label</emphasis> <emphasis>value</emphasis>: The
|
||||
.alias directive assigns an arbitrary value to a label. This
|
||||
value may be an arbitrary argument, but cannot reference any
|
||||
label that has not already been defined (this prevents
|
||||
recursive label dependencies).</para></listitem>
|
||||
<listitem><para><literal>.byte</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ... ]:
|
||||
Specifies a series of arguments, which are evaluated, and
|
||||
strings, which are included as raw ASCII data. The final
|
||||
results of these arguments must be one byte in size. Seperate
|
||||
constants are seperated by comments.</para></listitem>
|
||||
<listitem><para><literal>.checkpc</literal> <emphasis>address</emphasis>: Ensures that the
|
||||
program counter is less than or equal to the address
|
||||
specified, and emits an assemble-time error if it is not.
|
||||
<emphasis>This produces no code in the final binary - it is there to
|
||||
ensure that linking a large amount of data together does not
|
||||
overstep memory boundaries.</emphasis></para></listitem>
|
||||
<listitem><para><literal>.data</literal> <emphasis>[label]</emphasis>: Sets the segment to
|
||||
the segment name specified and disallows output. If no label
|
||||
is given, switches to the default data segment.</para></listitem>
|
||||
<listitem><para><literal>.incbin</literal> <emphasis>filename</emphasis>: Inserts the
|
||||
contents of the file specified as binary data. Use it to
|
||||
include graphics information, precompiled code, or other
|
||||
non-assembler data.</para></listitem>
|
||||
<listitem><para><literal>.include</literal> <emphasis>filename</emphasis>: Includes the
|
||||
entirety of the file specified at that point in the program.
|
||||
Use this to order your final sources.</para></listitem>
|
||||
<listitem><para><literal>.org</literal> <emphasis>address</emphasis>: Sets the program
|
||||
counter to the address specified. <emphasis>This does not emit any
|
||||
code in and of itself, nor does it overwrite anything that
|
||||
previously existed.</emphasis> If you wish to jump ahead in memory,
|
||||
use <literal>.advance</literal>.</para></listitem>
|
||||
<listitem><para><literal>.require</literal> <emphasis>filename</emphasis>: Includes the entirety
|
||||
of the file specified at that point in the program. Unlike <literal>.include</literal>,
|
||||
however, code included with <literal>.require</literal> will only be inserted once.
|
||||
The <literal>.require</literal> directive is useful for ensuring that certain code libraries
|
||||
are somewhere in the final binary. They are also very useful for guaranteeing that
|
||||
macro libraries are available.</para></listitem>
|
||||
<listitem><para><literal>.space</literal> <emphasis>label</emphasis> <emphasis>size</emphasis>: This
|
||||
directive is used to organize global variables. It defines the
|
||||
label specified to be at the current location of the program
|
||||
counter, and then advances the program counter <emphasis>size</emphasis>
|
||||
steps ahead. No actual code is produced. This is equivalent
|
||||
to <literal>label: .org ^+size</literal>.</para></listitem>
|
||||
<listitem><para><literal>.text</literal> <emphasis>[label]</emphasis>: Sets the segment to
|
||||
the segment name specified and allows output. If no label is
|
||||
given, switches to the default text segment.</para></listitem>
|
||||
<listitem><para><literal>.word</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ... ]:
|
||||
Like <literal>.byte</literal>, but values are all treated as two-byte
|
||||
values and stored low-end first (as is the 6502's wont). Use
|
||||
this to create jump tables (an unadorned label will evaluate
|
||||
to that label's location) or otherwise store 16-bit
|
||||
data.</para></listitem>
|
||||
<listitem><para><literal>.dword</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ...]:
|
||||
Like <literal>.word</literal>, but for 32-bit values.</para></listitem>
|
||||
<listitem><para><literal>.wordbe</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ...]:
|
||||
Like <literal>.word</literal>, but stores the value in a big-endian format (high byte first).</para></listitem>
|
||||
<listitem><para><literal>.dwordbe</literal> <emphasis>arg</emphasis> [ , <emphasis>arg</emphasis>, ...]:
|
||||
Like <literal>.dword</literal>, but stores the value high byte first.</para></listitem>
|
||||
<listitem><para><literal>.scope</literal>: Starts a new scope block. Labels
|
||||
that begin with an underscore are only reachable from within
|
||||
their innermost enclosing <literal>.scope</literal> statement.</para></listitem>
|
||||
<listitem><para><literal>.scend</literal>: Ends a scope block. Makes the
|
||||
temporary labels defined since the last <literal>.scope</literal>
|
||||
statement unreachable, and permits them to be redefined in a
|
||||
new scope.</para></listitem>
|
||||
<listitem><para><literal>.macro</literal> <emphasis>name</emphasis>: Begins a macro
|
||||
definition block. This is a scope block that can be inlined
|
||||
at arbitrary points with <literal>.invoke</literal>. Arguments to the
|
||||
macro will be bound to temporary labels with names like
|
||||
<literal>_1</literal>, <literal>_2</literal>, etc.</para></listitem>
|
||||
<listitem><para><literal>.macend</literal>: Ends a macro definition
|
||||
block.</para></listitem>
|
||||
<listitem><para><literal>.invoke</literal> <emphasis>label</emphasis> [<emphasis>argument</emphasis> [,
|
||||
<emphasis>argument</emphasis> ...]]: invokes (inlines) the specified
|
||||
macro, binding the values of the arguments to the ones the
|
||||
macro definition intends to read. A shorthand for <literal>.invoke</literal>
|
||||
is the name of the macro to invoke, backquoted.</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
</appendix>
|
||||
|
@ -1,74 +1,74 @@
|
||||
; Test file for 65C02 extended opcode compliance
|
||||
; This odd little source file uses every addressing mode
|
||||
; of every opcode, and uses the opcode itself as the argument
|
||||
; to each instruction that takes one. The resulting binary's
|
||||
; bytes are thus in strictly increasing numerical order.
|
||||
|
||||
; Some opcodes have multiple mnemonics; we provide both.
|
||||
|
||||
; This file also doesn't include the 65C02's opcodes that
|
||||
; are also available in stock 6502s - see testbase.oph for
|
||||
; those.
|
||||
TSB $04 ; 04: TSB - Zero Page
|
||||
RMB0 $07 ; 07: RMB0 - Zero Page
|
||||
TSB $0C0C ; 0C: TSB - Absolute
|
||||
BBR0 ^+$11 ; 0F: BBR0 - Relative
|
||||
ORA ($12) ; 12: ORA - (Zero Page)
|
||||
TRB $14 ; 14: TRB - Zero Page
|
||||
RMB1 $17 ; 17: RMB1 - Zero Page
|
||||
INA ; 1A: INA - Implied
|
||||
INC ; INC - Implied
|
||||
TRB $1C1C ; 1C: TRB - Absolute
|
||||
BBR1 ^+$21 ; 1F: BBR1 - Relative
|
||||
RMB2 $27 ; 27: RMB2 - Zero Page
|
||||
BBR2 ^+$31 ; 2F: BBR2 - Relative
|
||||
AND ($32) ; 32: AND - (Zero Page)
|
||||
BIT $34, X ; 34: BIT - Zero Page, X
|
||||
RMB3 $37 ; 37: RMB3 - Zero Page
|
||||
DEA ; 3A: DEA - Implied
|
||||
DEC ; 3A: DEC - Implied
|
||||
BIT $3C3C,X ; 3C: BIT - Absolute, X
|
||||
BBR3 ^+$41 ; 3F: BBR3 - Relative
|
||||
RMB4 $47 ; 47: RMB4 - Zero Page
|
||||
BBR4 ^+$51 ; 4F: BBR4 - Relative
|
||||
EOR ($52) ; 52: EOR - (Zero Page)
|
||||
RMB5 $57 ; 57: RMB5 - Zero Page
|
||||
PHY ; 5A: PHY - Implied
|
||||
BBR5 ^+$61 ; 5F: BBR5 - Relative
|
||||
STZ $64 ; 64: STZ - Zero Page
|
||||
RMB6 $67 ; 67: RMB6 - Zero Page
|
||||
BBR6 ^+$71 ; 6F: BBR6 - Relative
|
||||
ADC ($72) ; 72: ADC - (Zero Page)
|
||||
STZ $74, X ; 74: STZ - Zero Page, X
|
||||
RMB7 $77 ; 77: RMB7 - Zero Page
|
||||
PLY ; 7A: PLY - Implied
|
||||
JMP ($7C7C, X) ; 7C: JMP - (Absolute, X)
|
||||
BBR7 ^+$81 ; 7F: BBR7 - Relative
|
||||
BRA ^-$7E ; 80: BRA - Relative
|
||||
SMB0 $87 ; 87: SMB0 - Zero Page
|
||||
BIT #$89 ; 89: BIT - Immediate
|
||||
BBS0 ^-$6F ; 8F: BBS0 - Relative
|
||||
STA ($92) ; 92: STA - (Zero Page)
|
||||
SMB1 $97 ; 97: SMB1 - Zero Page
|
||||
STZ $9C9C ; 9C: STZ - Absolute
|
||||
STZ $9E9E, X ; 9E: STZ - Absolute, X
|
||||
BBS1 ^-$5F ; 9F: BBS1 - Relative
|
||||
SMB2 $A7 ; A7: SMB2 - Zero Page
|
||||
BBS2 ^-$4F ; AF: BBS2 - Relative
|
||||
LDA ($B2) ; B2: LDA - (Zero Page)
|
||||
SMB3 $B7 ; B7: SMB3 - Zero Page
|
||||
BBS3 ^-$3F ; BF: BBS3 - Relative
|
||||
SMB4 $C7 ; C7: SMB4 - Zero Page
|
||||
WAI ; CB: WAI - Implied
|
||||
BBS4 ^-$2F ; CF: BBS4 - Relative
|
||||
CMP ($D2) ; D2: CMP - (Zero Page)
|
||||
SMB5 $D7 ; D7: SMB5 - Zero Page
|
||||
PHX ; DA: PHX - Implied
|
||||
STP ; DB: STP - Implied
|
||||
BBS5 ^-$1F ; DF: BBS5 - Relative
|
||||
SMB6 $E7 ; E7: SMB6 - Zero Page
|
||||
BBS6 ^-$0F ; EF: BBS6 - Relative
|
||||
SBC ($F2) ; F2: SBC - (Zero Page)
|
||||
SMB7 $F7 ; F7: SMB7 - Zero Page
|
||||
PLX ; FA: PLX - Implied
|
||||
BBS7 ^+$01 ; FF: BBS7 - Relative
|
||||
; Test file for 65C02 extended opcode compliance
|
||||
; This odd little source file uses every addressing mode
|
||||
; of every opcode, and uses the opcode itself as the argument
|
||||
; to each instruction that takes one. The resulting binary's
|
||||
; bytes are thus in strictly increasing numerical order.
|
||||
|
||||
; Some opcodes have multiple mnemonics; we provide both.
|
||||
|
||||
; This file also doesn't include the 65C02's opcodes that
|
||||
; are also available in stock 6502s - see testbase.oph for
|
||||
; those.
|
||||
TSB $04 ; 04: TSB - Zero Page
|
||||
RMB0 $07 ; 07: RMB0 - Zero Page
|
||||
TSB $0C0C ; 0C: TSB - Absolute
|
||||
BBR0 ^+$11 ; 0F: BBR0 - Relative
|
||||
ORA ($12) ; 12: ORA - (Zero Page)
|
||||
TRB $14 ; 14: TRB - Zero Page
|
||||
RMB1 $17 ; 17: RMB1 - Zero Page
|
||||
INA ; 1A: INA - Implied
|
||||
INC ; INC - Implied
|
||||
TRB $1C1C ; 1C: TRB - Absolute
|
||||
BBR1 ^+$21 ; 1F: BBR1 - Relative
|
||||
RMB2 $27 ; 27: RMB2 - Zero Page
|
||||
BBR2 ^+$31 ; 2F: BBR2 - Relative
|
||||
AND ($32) ; 32: AND - (Zero Page)
|
||||
BIT $34, X ; 34: BIT - Zero Page, X
|
||||
RMB3 $37 ; 37: RMB3 - Zero Page
|
||||
DEA ; 3A: DEA - Implied
|
||||
DEC ; 3A: DEC - Implied
|
||||
BIT $3C3C,X ; 3C: BIT - Absolute, X
|
||||
BBR3 ^+$41 ; 3F: BBR3 - Relative
|
||||
RMB4 $47 ; 47: RMB4 - Zero Page
|
||||
BBR4 ^+$51 ; 4F: BBR4 - Relative
|
||||
EOR ($52) ; 52: EOR - (Zero Page)
|
||||
RMB5 $57 ; 57: RMB5 - Zero Page
|
||||
PHY ; 5A: PHY - Implied
|
||||
BBR5 ^+$61 ; 5F: BBR5 - Relative
|
||||
STZ $64 ; 64: STZ - Zero Page
|
||||
RMB6 $67 ; 67: RMB6 - Zero Page
|
||||
BBR6 ^+$71 ; 6F: BBR6 - Relative
|
||||
ADC ($72) ; 72: ADC - (Zero Page)
|
||||
STZ $74, X ; 74: STZ - Zero Page, X
|
||||
RMB7 $77 ; 77: RMB7 - Zero Page
|
||||
PLY ; 7A: PLY - Implied
|
||||
JMP ($7C7C, X) ; 7C: JMP - (Absolute, X)
|
||||
BBR7 ^+$81 ; 7F: BBR7 - Relative
|
||||
BRA ^-$7E ; 80: BRA - Relative
|
||||
SMB0 $87 ; 87: SMB0 - Zero Page
|
||||
BIT #$89 ; 89: BIT - Immediate
|
||||
BBS0 ^-$6F ; 8F: BBS0 - Relative
|
||||
STA ($92) ; 92: STA - (Zero Page)
|
||||
SMB1 $97 ; 97: SMB1 - Zero Page
|
||||
STZ $9C9C ; 9C: STZ - Absolute
|
||||
STZ $9E9E, X ; 9E: STZ - Absolute, X
|
||||
BBS1 ^-$5F ; 9F: BBS1 - Relative
|
||||
SMB2 $A7 ; A7: SMB2 - Zero Page
|
||||
BBS2 ^-$4F ; AF: BBS2 - Relative
|
||||
LDA ($B2) ; B2: LDA - (Zero Page)
|
||||
SMB3 $B7 ; B7: SMB3 - Zero Page
|
||||
BBS3 ^-$3F ; BF: BBS3 - Relative
|
||||
SMB4 $C7 ; C7: SMB4 - Zero Page
|
||||
WAI ; CB: WAI - Implied
|
||||
BBS4 ^-$2F ; CF: BBS4 - Relative
|
||||
CMP ($D2) ; D2: CMP - (Zero Page)
|
||||
SMB5 $D7 ; D7: SMB5 - Zero Page
|
||||
PHX ; DA: PHX - Implied
|
||||
STP ; DB: STP - Implied
|
||||
BBS5 ^-$1F ; DF: BBS5 - Relative
|
||||
SMB6 $E7 ; E7: SMB6 - Zero Page
|
||||
BBS6 ^-$0F ; EF: BBS6 - Relative
|
||||
SBC ($F2) ; F2: SBC - (Zero Page)
|
||||
SMB7 $F7 ; F7: SMB7 - Zero Page
|
||||
PLX ; FA: PLX - Implied
|
||||
BBS7 ^+$01 ; FF: BBS7 - Relative
|
||||
|
@ -1,7 +1,7 @@
|
||||
; This data file just dumps out $00-$0F repeatedly with different forms.
|
||||
|
||||
.byte 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
|
||||
.word 256, $0302, $0504, $0706, $0908, $0b0a, $0d0c, $0f0e
|
||||
.dword $03020100, $07060504, $0b0a0908, $0f0e0d0c
|
||||
.wordbe 1, $0203, $0405, $0607, $0809, $0a0b, $0c0d, $0e0f
|
||||
.dwordbe $010203, $04050607, $08090a0b, $0c0d0e0f
|
||||
; This data file just dumps out $00-$0F repeatedly with different forms.
|
||||
|
||||
.byte 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
|
||||
.word 256, $0302, $0504, $0706, $0908, $0b0a, $0d0c, $0f0e
|
||||
.dword $03020100, $07060504, $0b0a0908, $0f0e0d0c
|
||||
.wordbe 1, $0203, $0405, $0607, $0809, $0a0b, $0c0d, $0e0f
|
||||
.dwordbe $010203, $04050607, $08090a0b, $0c0d0e0f
|
||||
|
@ -1,256 +1,256 @@
|
||||
00: BRK - Implied
|
||||
01: ORA - (Zero Page, X)
|
||||
02:
|
||||
03:
|
||||
04:
|
||||
05: ORA - Zero Page
|
||||
06: ASL - Zero Page
|
||||
07:
|
||||
08: PHP - Implied
|
||||
09: ORA - Immediate
|
||||
0A: ASL - Implied
|
||||
0B:
|
||||
0C:
|
||||
0D: ORA - Absolute
|
||||
0E: ASL - Absolute
|
||||
0F:
|
||||
10: BPL - Relative
|
||||
11: ORA - (Zero Page), Y
|
||||
12:
|
||||
13:
|
||||
14:
|
||||
15: ORA - Zero Page, X
|
||||
16: ASL - Zero Page, X
|
||||
17:
|
||||
18: CLC - Implied
|
||||
19: ORA - Absolute, Y
|
||||
1A:
|
||||
1B:
|
||||
1C:
|
||||
1D: ORA - Absolute, X
|
||||
1E: ASL - Absolute, X
|
||||
1F:
|
||||
20: JSR - Absolute
|
||||
21: AND - (Zero Page, X)
|
||||
22:
|
||||
23:
|
||||
24: BIT - Zero Page
|
||||
25: AND - Zero Page
|
||||
26: ROL - Zero Page
|
||||
27:
|
||||
28: PLP - Implied
|
||||
29: AND - Immediate
|
||||
2A: ROL - Implied
|
||||
2B:
|
||||
2C: BIT - Absolute
|
||||
2D: AND - Absolute
|
||||
2E: ROL - Absolute
|
||||
2F:
|
||||
30: BMI - Relative
|
||||
31: AND - (Zero Page), Y
|
||||
32:
|
||||
33:
|
||||
34:
|
||||
35: AND - Zero Page, X
|
||||
36: ROL - Zero Page, X
|
||||
37:
|
||||
38: SEC - Implied
|
||||
39: AND - Absolute, Y
|
||||
3A:
|
||||
3B:
|
||||
3C:
|
||||
3D: AND - Absolute, X
|
||||
3E: ROL - Absolute, X
|
||||
3F:
|
||||
40: RTI - Implied
|
||||
41: EOR - (Zero Page, X)
|
||||
42:
|
||||
43:
|
||||
44:
|
||||
45: EOR - Zero Page
|
||||
46: LSR - Zero Page
|
||||
47:
|
||||
48: PHA - Implied
|
||||
49: EOR - Immediate
|
||||
4A: LSR - Implied
|
||||
4B:
|
||||
4C: JMP - Absolute
|
||||
4D: EOR - Absolute
|
||||
4E: LSR - Absolute
|
||||
4F:
|
||||
50: BVC - Relative
|
||||
51: EOR - (Zero Page), Y
|
||||
52:
|
||||
53:
|
||||
54:
|
||||
55: EOR - Zero Page, X
|
||||
56: LSR - Zero Page, X
|
||||
57:
|
||||
58: CLI - Implied
|
||||
59: EOR - Absolute, Y
|
||||
5A:
|
||||
5B:
|
||||
5C:
|
||||
5D: EOR - Absolute, X
|
||||
5E: LSR - Absolute, X
|
||||
5F:
|
||||
60: RTS - Implied
|
||||
61: ADC - (Zero Page, X)
|
||||
62:
|
||||
63:
|
||||
64:
|
||||
65: ADC - Zero Page
|
||||
66: ROR - Zero Page
|
||||
67:
|
||||
68: PLA - Implied
|
||||
69: ADC - Immediate
|
||||
6A: ROR - Implied
|
||||
6B:
|
||||
6C: JMP - (Absolute)
|
||||
6D: ADC - Absolute
|
||||
6E: ROR - Absolute
|
||||
6F:
|
||||
70: BVS - Relative
|
||||
71: ADC - (Zero Page), Y
|
||||
72:
|
||||
73:
|
||||
74:
|
||||
75: ADC - Zero Page, X
|
||||
76: ROR - Zero Page, X
|
||||
77:
|
||||
78: SEI - Implied
|
||||
79: ADC - Absolute, Y
|
||||
7A:
|
||||
7B:
|
||||
7C:
|
||||
7D: ADC - Absolute, X
|
||||
7E: ROR - Absolute, X
|
||||
7F:
|
||||
80:
|
||||
81: STA - (Zero Page, X)
|
||||
82:
|
||||
83:
|
||||
84: STY - Zero Page
|
||||
85: STA - Zero Page
|
||||
86: STX - Zero Page
|
||||
87:
|
||||
88: DEY - Implied
|
||||
89:
|
||||
8A: TXA - Implied
|
||||
8B:
|
||||
8C: STY - Absolute
|
||||
8D: STA - Absolute
|
||||
8E: STX - Absolute
|
||||
8F:
|
||||
90: BCC - Relative
|
||||
91: STA - (Zero Page), Y
|
||||
92:
|
||||
93:
|
||||
94: STY - Zero Page, X
|
||||
95: STA - Zero Page, X
|
||||
96: STX - Zero Page, Y
|
||||
97:
|
||||
98: TYA - Implied
|
||||
99: STA - Absolute, Y
|
||||
9A: TXS - Implied
|
||||
9B:
|
||||
9C:
|
||||
9D: STA - Absolute, X
|
||||
9E:
|
||||
9F:
|
||||
A0: LDY - Immediate
|
||||
A1: LDA - (Zero Page, X)
|
||||
A2: LDX - Immediate
|
||||
A3:
|
||||
A4: LDY - Zero Page
|
||||
A5: LDA - Zero Page
|
||||
A6: LDX - Zero Page
|
||||
A7:
|
||||
A8: TAY - Implied
|
||||
A9: LDA - Immediate
|
||||
AA: TAX - Implied
|
||||
AB:
|
||||
AC: LDY - Absolute
|
||||
AD: LDA - Absolute
|
||||
AE: LDX - Absolute
|
||||
AF:
|
||||
B0: BCS - Relative
|
||||
B1: LDA - (Zero Page), Y
|
||||
B2:
|
||||
B3:
|
||||
B4: LDY - Zero Page, X
|
||||
B5: LDA - Zero Page, X
|
||||
B6: LDX - Zero Page, Y
|
||||
B7:
|
||||
B8: CLV - Implied
|
||||
B9: LDA - Absolute, Y
|
||||
BA: TSX - Implied
|
||||
BB:
|
||||
BC: LDY - Absolute, X
|
||||
BD: LDA - Absolute, X
|
||||
BE: LDX - Absolute, Y
|
||||
BF:
|
||||
C0: CPY - Immediate
|
||||
C1: CMP - (Zero Page, X)
|
||||
C2:
|
||||
C3:
|
||||
C4: CPY - Zero Page
|
||||
C5: CMP - Zero Page
|
||||
C6: DEC - Zero Page
|
||||
C7:
|
||||
C8: INY - Implied
|
||||
C9: CMP - Immediate
|
||||
CA: DEX - Implied
|
||||
CB:
|
||||
CC: CPY - Absolute
|
||||
CD: CMP - Absolute
|
||||
CE: DEC - Absolute
|
||||
CF:
|
||||
D0: BNE - Relative
|
||||
D1: CMP - (Zero Page), Y
|
||||
D2:
|
||||
D3:
|
||||
D4:
|
||||
D5: CMP - Zero Page, X
|
||||
D6: DEC - Zero Page, X
|
||||
D7:
|
||||
D8: CLD - Implied
|
||||
D9: CMP - Absolute, Y
|
||||
DA:
|
||||
DB:
|
||||
DC:
|
||||
DD: CMP - Absolute, X
|
||||
DE: DEC - Absolute, X
|
||||
DF:
|
||||
E0: CPX - Immediate
|
||||
E1: SBC - (Zero Page, X)
|
||||
E2:
|
||||
E3:
|
||||
E4: CPX - Zero Page
|
||||
E5: SBC - Zero Page
|
||||
E6: INC - Zero Page
|
||||
E7:
|
||||
E8: INX - Implied
|
||||
E9: SBC - Immediate
|
||||
EA: NOP - Implied
|
||||
EB:
|
||||
EC: CPX - Absolute
|
||||
ED: SBC - Absolute
|
||||
EE: INC - Absolute
|
||||
EF:
|
||||
F0: BEQ - Relative
|
||||
F1: SBC - (Zero Page), Y
|
||||
F2:
|
||||
F3:
|
||||
F4:
|
||||
F5: SBC - Zero Page, X
|
||||
F6: INC - Zero Page, X
|
||||
F7:
|
||||
F8: SED - Implied
|
||||
F9: SBC - Absolute, Y
|
||||
FA:
|
||||
FB:
|
||||
FC:
|
||||
FD: SBC - Absolute, X
|
||||
FE: INC - Absolute, X
|
||||
FF:
|
||||
00: BRK - Implied
|
||||
01: ORA - (Zero Page, X)
|
||||
02:
|
||||
03:
|
||||
04:
|
||||
05: ORA - Zero Page
|
||||
06: ASL - Zero Page
|
||||
07:
|
||||
08: PHP - Implied
|
||||
09: ORA - Immediate
|
||||
0A: ASL - Implied
|
||||
0B:
|
||||
0C:
|
||||
0D: ORA - Absolute
|
||||
0E: ASL - Absolute
|
||||
0F:
|
||||
10: BPL - Relative
|
||||
11: ORA - (Zero Page), Y
|
||||
12:
|
||||
13:
|
||||
14:
|
||||
15: ORA - Zero Page, X
|
||||
16: ASL - Zero Page, X
|
||||
17:
|
||||
18: CLC - Implied
|
||||
19: ORA - Absolute, Y
|
||||
1A:
|
||||
1B:
|
||||
1C:
|
||||
1D: ORA - Absolute, X
|
||||
1E: ASL - Absolute, X
|
||||
1F:
|
||||
20: JSR - Absolute
|
||||
21: AND - (Zero Page, X)
|
||||
22:
|
||||
23:
|
||||
24: BIT - Zero Page
|
||||
25: AND - Zero Page
|
||||
26: ROL - Zero Page
|
||||
27:
|
||||
28: PLP - Implied
|
||||
29: AND - Immediate
|
||||
2A: ROL - Implied
|
||||
2B:
|
||||
2C: BIT - Absolute
|
||||
2D: AND - Absolute
|
||||
2E: ROL - Absolute
|
||||
2F:
|
||||
30: BMI - Relative
|
||||
31: AND - (Zero Page), Y
|
||||
32:
|
||||
33:
|
||||
34:
|
||||
35: AND - Zero Page, X
|
||||
36: ROL - Zero Page, X
|
||||
37:
|
||||
38: SEC - Implied
|
||||
39: AND - Absolute, Y
|
||||
3A:
|
||||
3B:
|
||||
3C:
|
||||
3D: AND - Absolute, X
|
||||
3E: ROL - Absolute, X
|
||||
3F:
|
||||
40: RTI - Implied
|
||||
41: EOR - (Zero Page, X)
|
||||
42:
|
||||
43:
|
||||
44:
|
||||
45: EOR - Zero Page
|
||||
46: LSR - Zero Page
|
||||
47:
|
||||
48: PHA - Implied
|
||||
49: EOR - Immediate
|
||||
4A: LSR - Implied
|
||||
4B:
|
||||
4C: JMP - Absolute
|
||||
4D: EOR - Absolute
|
||||
4E: LSR - Absolute
|
||||
4F:
|
||||
50: BVC - Relative
|
||||
51: EOR - (Zero Page), Y
|
||||
52:
|
||||
53:
|
||||
54:
|
||||
55: EOR - Zero Page, X
|
||||
56: LSR - Zero Page, X
|
||||
57:
|
||||
58: CLI - Implied
|
||||
59: EOR - Absolute, Y
|
||||
5A:
|
||||
5B:
|
||||
5C:
|
||||
5D: EOR - Absolute, X
|
||||
5E: LSR - Absolute, X
|
||||
5F:
|
||||
60: RTS - Implied
|
||||
61: ADC - (Zero Page, X)
|
||||
62:
|
||||
63:
|
||||
64:
|
||||
65: ADC - Zero Page
|
||||
66: ROR - Zero Page
|
||||
67:
|
||||
68: PLA - Implied
|
||||
69: ADC - Immediate
|
||||
6A: ROR - Implied
|
||||
6B:
|
||||
6C: JMP - (Absolute)
|
||||
6D: ADC - Absolute
|
||||
6E: ROR - Absolute
|
||||
6F:
|
||||
70: BVS - Relative
|
||||
71: ADC - (Zero Page), Y
|
||||
72:
|
||||
73:
|
||||
74:
|
||||
75: ADC - Zero Page, X
|
||||
76: ROR - Zero Page, X
|
||||
77:
|
||||
78: SEI - Implied
|
||||
79: ADC - Absolute, Y
|
||||
7A:
|
||||
7B:
|
||||
7C:
|
||||
7D: ADC - Absolute, X
|
||||
7E: ROR - Absolute, X
|
||||
7F:
|
||||
80:
|
||||
81: STA - (Zero Page, X)
|
||||
82:
|
||||
83:
|
||||
84: STY - Zero Page
|
||||
85: STA - Zero Page
|
||||
86: STX - Zero Page
|
||||
87:
|
||||
88: DEY - Implied
|
||||
89:
|
||||
8A: TXA - Implied
|
||||
8B:
|
||||
8C: STY - Absolute
|
||||
8D: STA - Absolute
|
||||
8E: STX - Absolute
|
||||
8F:
|
||||
90: BCC - Relative
|
||||
91: STA - (Zero Page), Y
|
||||
92:
|
||||
93:
|
||||
94: STY - Zero Page, X
|
||||
95: STA - Zero Page, X
|
||||
96: STX - Zero Page, Y
|
||||
97:
|
||||
98: TYA - Implied
|
||||
99: STA - Absolute, Y
|
||||
9A: TXS - Implied
|
||||
9B:
|
||||
9C:
|
||||
9D: STA - Absolute, X
|
||||
9E:
|
||||
9F:
|
||||
A0: LDY - Immediate
|
||||
A1: LDA - (Zero Page, X)
|
||||
A2: LDX - Immediate
|
||||
A3:
|
||||
A4: LDY - Zero Page
|
||||
A5: LDA - Zero Page
|
||||
A6: LDX - Zero Page
|
||||
A7:
|
||||
A8: TAY - Implied
|
||||
A9: LDA - Immediate
|
||||
AA: TAX - Implied
|
||||
AB:
|
||||
AC: LDY - Absolute
|
||||
AD: LDA - Absolute
|
||||
AE: LDX - Absolute
|
||||
AF:
|
||||
B0: BCS - Relative
|
||||
B1: LDA - (Zero Page), Y
|
||||
B2:
|
||||
B3:
|
||||
B4: LDY - Zero Page, X
|
||||
B5: LDA - Zero Page, X
|
||||
B6: LDX - Zero Page, Y
|
||||
B7:
|
||||
B8: CLV - Implied
|
||||
B9: LDA - Absolute, Y
|
||||
BA: TSX - Implied
|
||||
BB:
|
||||
BC: LDY - Absolute, X
|
||||
BD: LDA - Absolute, X
|
||||
BE: LDX - Absolute, Y
|
||||
BF:
|
||||
C0: CPY - Immediate
|
||||
C1: CMP - (Zero Page, X)
|
||||
C2:
|
||||
C3:
|
||||
C4: CPY - Zero Page
|
||||
C5: CMP - Zero Page
|
||||
C6: DEC - Zero Page
|
||||
C7:
|
||||
C8: INY - Implied
|
||||
C9: CMP - Immediate
|
||||
CA: DEX - Implied
|
||||
CB:
|
||||
CC: CPY - Absolute
|
||||
CD: CMP - Absolute
|
||||
CE: DEC - Absolute
|
||||
CF:
|
||||
D0: BNE - Relative
|
||||
D1: CMP - (Zero Page), Y
|
||||
D2:
|
||||
D3:
|
||||
D4:
|
||||
D5: CMP - Zero Page, X
|
||||
D6: DEC - Zero Page, X
|
||||
D7:
|
||||
D8: CLD - Implied
|
||||
D9: CMP - Absolute, Y
|
||||
DA:
|
||||
DB:
|
||||
DC:
|
||||
DD: CMP - Absolute, X
|
||||
DE: DEC - Absolute, X
|
||||
DF:
|
||||
E0: CPX - Immediate
|
||||
E1: SBC - (Zero Page, X)
|
||||
E2:
|
||||
E3:
|
||||
E4: CPX - Zero Page
|
||||
E5: SBC - Zero Page
|
||||
E6: INC - Zero Page
|
||||
E7:
|
||||
E8: INX - Implied
|
||||
E9: SBC - Immediate
|
||||
EA: NOP - Implied
|
||||
EB:
|
||||
EC: CPX - Absolute
|
||||
ED: SBC - Absolute
|
||||
EE: INC - Absolute
|
||||
EF:
|
||||
F0: BEQ - Relative
|
||||
F1: SBC - (Zero Page), Y
|
||||
F2:
|
||||
F3:
|
||||
F4:
|
||||
F5: SBC - Zero Page, X
|
||||
F6: INC - Zero Page, X
|
||||
F7:
|
||||
F8: SED - Implied
|
||||
F9: SBC - Absolute, Y
|
||||
FA:
|
||||
FB:
|
||||
FC:
|
||||
FD: SBC - Absolute, X
|
||||
FE: INC - Absolute, X
|
||||
FF:
|
||||
|
@ -1,256 +1,256 @@
|
||||
00: BRK - Implied
|
||||
01: ORA - (Zero Page, X)
|
||||
02:
|
||||
03:
|
||||
04: TSB - Zero Page
|
||||
05: ORA - Zero Page
|
||||
06: ASL - Zero Page
|
||||
07: RMB0 - Zero Page
|
||||
08: PHP - Implied
|
||||
09: ORA - Immediate
|
||||
0A: ASL - Implied
|
||||
0B:
|
||||
0C: TSB - Absolute
|
||||
0D: ORA - Absolute
|
||||
0E: ASL - Absolute
|
||||
0F: BBR0 - Relative
|
||||
10: BPL - Relative
|
||||
11: ORA - (Zero Page), Y
|
||||
12: ORA - (Zero Page)
|
||||
13:
|
||||
14: TRB - Zero Page
|
||||
15: ORA - Zero Page, X
|
||||
16: ASL - Zero Page, X
|
||||
17: RMB1 - Zero Page
|
||||
18: CLC - Implied
|
||||
19: ORA - Absolute, Y
|
||||
1A: INA - Implied; INC - Implied
|
||||
1B:
|
||||
1C: TRB - Absolute
|
||||
1D: ORA - Absolute, X
|
||||
1E: ASL - Absolute, X
|
||||
1F: BBR1 - Relative
|
||||
20: JSR - Absolute
|
||||
21: AND - (Zero Page, X)
|
||||
22:
|
||||
23:
|
||||
24: BIT - Zero Page
|
||||
25: AND - Zero Page
|
||||
26: ROL - Zero Page
|
||||
27: RMB2 - Zero Page
|
||||
28: PLP - Implied
|
||||
29: AND - Immediate
|
||||
2A: ROL - Implied
|
||||
2B:
|
||||
2C: BIT - Absolute
|
||||
2D: AND - Absolute
|
||||
2E: ROL - Absolute
|
||||
2F: BBR2 - Relative
|
||||
30: BMI - Relative
|
||||
31: AND - (Zero Page), Y
|
||||
32: AND - (Zero Page)
|
||||
33:
|
||||
34: BIT - Zero Page, X
|
||||
35: AND - Zero Page, X
|
||||
36: ROL - Zero Page, X
|
||||
37: RMB3 - Zero Page
|
||||
38: SEC - Implied
|
||||
39: AND - Absolute, Y
|
||||
3A: DEA - Implied; DEC - Implied
|
||||
3B:
|
||||
3C: BIT - Absolute, X
|
||||
3D: AND - Absolute, X
|
||||
3E: ROL - Absolute, X
|
||||
3F: BBR3 - Relative
|
||||
40: RTI - Implied
|
||||
41: EOR - (Zero Page, X)
|
||||
42:
|
||||
43:
|
||||
44:
|
||||
45: EOR - Zero Page
|
||||
46: LSR - Zero Page
|
||||
47: RMB4 - Zero Page
|
||||
48: PHA - Implied
|
||||
49: EOR - Immediate
|
||||
4A: LSR - Implied
|
||||
4B:
|
||||
4C: JMP - Absolute
|
||||
4D: EOR - Absolute
|
||||
4E: LSR - Absolute
|
||||
4F: BBR4 - Relative
|
||||
50: BVC - Relative
|
||||
51: EOR - (Zero Page), Y
|
||||
52: EOR - (Zero Page)
|
||||
53:
|
||||
54:
|
||||
55: EOR - Zero Page, X
|
||||
56: LSR - Zero Page, X
|
||||
57: RMB5 - Zero Page
|
||||
58: CLI - Implied
|
||||
59: EOR - Absolute, Y
|
||||
5A: PHY - Implied
|
||||
5B:
|
||||
5C:
|
||||
5D: EOR - Absolute, X
|
||||
5E: LSR - Absolute, X
|
||||
5F: BBR5 - Relative
|
||||
60: RTS - Implied
|
||||
61: ADC - (Zero Page, X)
|
||||
62:
|
||||
63:
|
||||
64: STZ - Zero Page
|
||||
65: ADC - Zero Page
|
||||
66: ROR - Zero Page
|
||||
67: RMB6 - Zero Page
|
||||
68: PLA - Implied
|
||||
69: ADC - Immediate
|
||||
6A: ROR - Implied
|
||||
6B:
|
||||
6C: JMP - (Absolute)
|
||||
6D: ADC - Absolute
|
||||
6E: ROR - Absolute
|
||||
6F: BBR6 - Relative
|
||||
70: BVS - Relative
|
||||
71: ADC - (Zero Page), Y
|
||||
72: ADC - (Zero Page)
|
||||
73:
|
||||
74: STZ - Zero Page, X
|
||||
75: ADC - Zero Page, X
|
||||
76: ROR - Zero Page, X
|
||||
77: RMB7 - Zero Page
|
||||
78: SEI - Implied
|
||||
79: ADC - Absolute, Y
|
||||
7A: PLY - Implied
|
||||
7B:
|
||||
7C: JMP - (Absolute, X)
|
||||
7D: ADC - Absolute, X
|
||||
7E: ROR - Absolute, X
|
||||
7F: BBR7 - Relative
|
||||
80: BRA - Relative
|
||||
81: STA - (Zero Page, X)
|
||||
82:
|
||||
83:
|
||||
84: STY - Zero Page
|
||||
85: STA - Zero Page
|
||||
86: STX - Zero Page
|
||||
87: SMB0 - Zero Page
|
||||
88: DEY - Implied
|
||||
89: BIT - Immediate
|
||||
8A: TXA - Implied
|
||||
8B:
|
||||
8C: STY - Absolute
|
||||
8D: STA - Absolute
|
||||
8E: STX - Absolute
|
||||
8F: BBS0 - Relative
|
||||
90: BCC - Relative
|
||||
91: STA - (Zero Page), Y
|
||||
92: STA - (Zero Page)
|
||||
93:
|
||||
94: STY - Zero Page, X
|
||||
95: STA - Zero Page, X
|
||||
96: STX - Zero Page, Y
|
||||
97: SMB1 - Zero Page
|
||||
98: TYA - Implied
|
||||
99: STA - Absolute, Y
|
||||
9A: TXS - Implied
|
||||
9B:
|
||||
9C: STZ - Absolute
|
||||
9D: STA - Absolute, X
|
||||
9E: STZ - Absolute, X
|
||||
9F: BBS1 - Relative
|
||||
A0: LDY - Immediate
|
||||
A1: LDA - (Zero Page, X)
|
||||
A2: LDX - Immediate
|
||||
A3:
|
||||
A4: LDY - Zero Page
|
||||
A5: LDA - Zero Page
|
||||
A6: LDX - Zero Page
|
||||
A7: SMB2 - Zero Page
|
||||
A8: TAY - Implied
|
||||
A9: LDA - Immediate
|
||||
AA: TAX - Implied
|
||||
AB:
|
||||
AC: LDY - Absolute
|
||||
AD: LDA - Absolute
|
||||
AE: LDX - Absolute
|
||||
AF: BBS2 - Relative
|
||||
B0: BCS - Relative
|
||||
B1: LDA - (Zero Page), Y
|
||||
B2: LDA - (Zero Page)
|
||||
B3:
|
||||
B4: LDY - Zero Page, X
|
||||
B5: LDA - Zero Page, X
|
||||
B6: LDX - Zero Page, Y
|
||||
B7: SMB3 - Zero Page
|
||||
B8: CLV - Implied
|
||||
B9: LDA - Absolute, Y
|
||||
BA: TSX - Implied
|
||||
BB:
|
||||
BC: LDY - Absolute, X
|
||||
BD: LDA - Absolute, X
|
||||
BE: LDX - Absolute, Y
|
||||
BF: BBS3 - Relative
|
||||
C0: CPY - Immediate
|
||||
C1: CMP - (Zero Page, X)
|
||||
C2:
|
||||
C3:
|
||||
C4: CPY - Zero Page
|
||||
C5: CMP - Zero Page
|
||||
C6: DEC - Zero Page
|
||||
C7: SMB4 - Zero Page
|
||||
C8: INY - Implied
|
||||
C9: CMP - Immediate
|
||||
CA: DEX - Implied
|
||||
CB: WAI - Implied
|
||||
CC: CPY - Absolute
|
||||
CD: CMP - Absolute
|
||||
CE: DEC - Absolute
|
||||
CF: BBS4 - Relative
|
||||
D0: BNE - Relative
|
||||
D1: CMP - (Zero Page), Y
|
||||
D2: CMP - (Zero Page)
|
||||
D3:
|
||||
D4:
|
||||
D5: CMP - Zero Page, X
|
||||
D6: DEC - Zero Page, X
|
||||
D7: SMB5 - Zero Page
|
||||
D8: CLD - Implied
|
||||
D9: CMP - Absolute, Y
|
||||
DA: PHX - Implied
|
||||
DB: STP - Implied
|
||||
DC:
|
||||
DD: CMP - Absolute, X
|
||||
DE: DEC - Absolute, X
|
||||
DF: BBS5 - Relative
|
||||
E0: CPX - Immediate
|
||||
E1: SBC - (Zero Page, X)
|
||||
E2:
|
||||
E3:
|
||||
E4: CPX - Zero Page
|
||||
E5: SBC - Zero Page
|