6502 assembler
Kragen Sitaker
subject. I see various places to look for example code; "The Fridge",
at http://www.ffd2.com/fridge/, has lots and lots of example code
(mostly for the C64), and www.6502.org. But I have no idea which of
this code is any good. What do other people recommend?
Again, I see lots of assemblers; I don't know if any of them are any
good. What do other people use?
I have an (unenhanced) //e. My overly-ambitious plan is to build a
native-code-compiling multitasking mini-Scheme on it and use it to do
interesting things. I'm thinking about using it as a windowing
terminal for my Linux box. Has anyone else tried something similar?
http://www.6502.org/crossdev/lang/index.htm is empty.
--
<kra...@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Sep 21 1999
48 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
Mike Westerfield
----------
In article <4iVF3.2276$QJ.8...@typ11.nn.bcandid.com>, kra...@dnaco.net
(Kragen Sitaker) wrote:
> Again, I see lots of assemblers; I don't know if any of them are any
> good. What do other people use?
There are two that are good and reasonably available. One even has an
existing customer support channel.
Merlin - This was the first assembler on the Apple II good enough to stand
the test of time. Its fast. Great for applications like games where you
will be tweeking and reassembling very rapidly. This assembler has a great
following to this day.
ORCA/M - This is the assembler Apple eventually picked as the standard
development environment for the Apple IIGS. It's powerful. Great for large
scale development where true subroutines and very powerful macros are a
plus. Also comes with a rather complete library, including integer math and
graphics, and an add-on for floating-point math. Still available and
supported at http://www.byteworks.org.
Mike Westerfield
Byte Works, Inc.
Date Doctor - the best y2k fix
> subject. I see various places to look for example code; "The Fridge",
> at http://www.ffd2.com/fridge/, has lots and lots of example code
> (mostly for the C64), and www.6502.org. But I have no idea which of
] call -151
* d000l
you can disassemble the ROM, so that's probably a good start, DOS is at
a000-bfff, c000-cfff is your extension cards like disk drives, so
careful round that.
zero page has your interrupt table, 200-2ff is your stack, 300-380 is
free space, but after that is more vectors,
400-7ff is your text page 1, 2000-3fff is hgr1, 4000-5fff is hgr2, 8000-
is a good place to write your own program.
basic is 800-1fff before you start running out - particularly if you
use hgr1.
if you have 128k ram, then
*d000:d000.1ffffm
(it's been a while, so forgive me if that is the wrong syntax)
will copy the ram so you can page switch - reading c083 will switch -
then you can seemingly modify them ROM - and it will affect how things
run.
Apple //e's are lots of fun
good luck, not sure how practical your ambition is, but sounds
interesting
later
--
Date Doctor is a new / proactive y2k fix
Ask for it by name...
It is the only fix that can apply to all PC's - all other fixes
are limited to only some/most PC's. It is totally software based.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Kragen Sitaker
Mike Westerfield <Mik...@aol.com> wrote:
>In article <4iVF3.2276$QJ.8...@typ11.nn.bcandid.com>, kra...@dnaco.net
>(Kragen Sitaker) wrote:
>> good. What do other people use?
>
>There are two that are good and reasonably available. One even has an
>existing customer support channel.
>
>Merlin - This was the first assembler on the Apple II good enough to stand
>the test of time. Its fast. Great for applications like games where you
>will be tweeking and reassembling very rapidly. This assembler has a great
>following to this day.
So its primary advantages are (a) it works; (b) it assembles really fast?
Where can I get it?
>ORCA/M - This is the assembler Apple eventually picked as the standard
>development environment for the Apple IIGS. It's powerful. Great for large
>scale development where true subroutines and very powerful macros are a
>plus. Also comes with a rather complete library, including integer math and
>graphics, and an add-on for floating-point math. Still available and
>supported at http://www.byteworks.org.
So its primary advantages are (a) it works; (b) it has true subroutines
(what are false subroutines?); (c) it has very powerful macros; (d) it
comes with a nice library?
It says on your page it costs $60, which is quite reasonable (although
it's twice what I've paid for the computer, so far). But I get a sick
feeling in my stomach reading software license agreements; would I get
source? Would I be allowed to modify and redistribute it?
If I can't find an assembler that comes with source and permission to
modify and redistribute, I'll just go ahead and write my own assembler
in Perl. It's not as if I've never written an assembler before. . .
--
<kra...@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Wed Sep 22 1999
47 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
Kragen Sitaker
Date Doctor - the best y2k fix <dated...@my-deja.com> wrote:
>] call -151
>
>* d000l
>
>you can disassemble the ROM, so that's probably a good start, DOS is at
>a000-bfff,
Thanks! Are they well-written?
>zero page has your interrupt table, 200-2ff is your stack,
Is that the BASIC stack you're talking about? I thought 100-1ff was
the hardware (i.e. PHA, PHP, PLA, PLP, JSR, RTS, BRK, RTI) stack.
(Maybe my book is wrong. I've seen a remarkable number of computer
books by people who didn't know what they were talking about.)
>if you have 128k ram, then
>
>*d000:d000.1ffffm
>
>(it's been a while, so forgive me if that is the wrong syntax)
>
>will copy the ram so you can page switch - reading c083 will switch -
>then you can seemingly modify them ROM - and it will affect how things
>run.
How does the bank switching work? What area of RAM is bank-switched,
and how many banks are there?
>good luck, not sure how practical your ambition is, but sounds
>interesting
Hey, if it turns out impractical, at least I'll have fun :)
Mike Westerfield
----------
In article <nBqG3.5395$QJ.3...@typ11.nn.bcandid.com>, kra...@dnaco.net
(Kragen Sitaker) wrote:
>>ORCA/M - This is the assembler Apple eventually picked as the standard
>>development environment for the Apple IIGS. It's powerful. Great for large
>>scale development where true subroutines and very powerful macros are a
>>plus. Also comes with a rather complete library, including integer math and
>>graphics, and an add-on for floating-point math. Still available and
>>supported at http://www.byteworks.org.
>
> So its primary advantages are (a) it works; (b) it has true subroutines
> (what are false subroutines?); (c) it has very powerful macros; (d) it
> comes with a nice library?
>
> It says on your page it costs $60, which is quite reasonable (although
> it's twice what I've paid for the computer, so far). But I get a sick
> feeling in my stomach reading software license agreements; would I get
> source? Would I be allowed to modify and redistribute it?
>
> If I can't find an assembler that comes with source and permission to
> modify and redistribute, I'll just go ahead and write my own assembler
> in Perl. It's not as if I've never written an assembler before. . .
If you're asking if $60 gets you the source to the assembler itself, no. If
you're asking if the source to the libraries are available, yes--and there
is no licensing fee or anything like that involved if you use the libraries,
of course. The same goes for the macros.
I have no idea what you've got in mind in terms of writing an assembler in
Perl. If your goal is a cross-assembler, none of the Apple II assemblers
will really help. All of them are written in 6502 assembly language and
depend heavily on the Apple II operating system. Even if the source were
available (and it isn't, not for a single one as far as I know) it wouldn't
be a good basis for a port.
As for writing your own assembler in Perl, I doubt if it will compare with
the native tools or even with a commercial cross-development package, but if
that's what tugs your chain, knock yourself out. Don't expect it to run on
an Apple II, though. As far as I am aware, Perl isn't available on the 8
bit Apple II, and even if it were, an assembler written in Perl would be so
slow you'd be begging me to take your $60 in mere hours--or the time for one
assembly, which would be about the same thing. :) Remember, the Apple II is
a 1 MHz, 8 bit machine with about 40K of memory that's useable by an
application, not a multi-hundred MHz 32 bit processor with scads of RAM like
most of us are used to these days. Something like an assembler written in
an interpreted high-level language would be really, really painful on an
Apple II!
Mike Westerfield
David Empson
> In article <4iVF3.2276$QJ.8...@typ11.nn.bcandid.com>,
> kra...@dnaco.net (Kragen Sitaker) wrote:
> > I've just started learning 6502 ASM; I have an ancient book on the
> > subject. I see various places to look for example code; "The Fridge",
> > at http://www.ffd2.com/fridge/, has lots and lots of example code
> > (mostly for the C64), and www.6502.org. But I have no idea which of
> > this code is any good. What do other people recommend?
>
> ] call -151
>
> * d000l
>
> you can disassemble the ROM, so that's probably a good start
But D000L won't give you any intelligent looking output from the
disassembly, since this area is the command vector table for Applesoft
BASIC. (It does contain code for Integer BASIC, assuming Programmer's
Aid #1 is present, which it would be for disk-based INTBASIC.)
> DOS is at a000-bfff
Try 9600-BFFF. Lots of tables in there, so finding useful entry points
to disassemble from is a little fiddly. Try disassembling from 3D0 to
get some JMP instructions into various parts of DOS, and disassemble the
destinations of these JMPs.
> zero page has your interrupt table
No it doesn't. The interrupt vectors on the 6502 are in ROM, at
FFFA-FFFF. On the Apple II, most of them are re-vectored through RAM at
03F0-03FF.
> 200-2ff is your stack
Try 100-1FF.
200-2FF is the input buffer.
> 300-380 is free space
Yes, but there is more than just that. 300-3CF is the generally
accepted "free space" in this area.
> but after that is more vectors,
3D0-3EC are used by DOS, the rest are for the monitor and other
firmware.
> if you have 128k ram, then
>
> *d000:d000.1ffffm
I'm assuming you meant "D000<D000.FFFFM". That will copy the ROM into
the language card, as long as the language card is write-enabled. This
has nothing to do with 128K RAM, however. The language card area
extends a 48K machine to 64K. (This area is officially called "bank
switched memory" in the IIe and later machines, which I have always
thought is a bad idea, since there are other memory areas which are also
bank switched.)
To do this properly:
1. Be very sure you are running under a standard version of DOS 3.3 (not
a version which has been moved into the language card). Do _not_ try
this under ProDOS, since you will overwrite the operating system. Note
also that this will probably not work very well for the IIgs.
2. Get into the monitor (CALL-151 from BASIC).
3. Type the following commands:
C082 C081 C081
D000<D000.FFFFM
C083
The first line read-enables the ROM, then write-enables the language
card RAM while leaving read access in the ROM.
The second line copies the ROM into the language card.
The third line read-enables the language card (write enable should be
retained).
For a simple patch to try, do a disassembly starting at FF69:
FF69L
This is the main loop of the monitor. The first few instructions should
be (on a IIe, II+ and probably IIc, but not IIgs):
FF69- A9 AA LDA #$AA
FF6B- 85 33 STA $33
FF6D- 20 67 FD JSR $FD67
If you patch the "AA" byte (at FF6A), you will change the prompt
character used by the monitor. Try the following:
FF6A:A5
This will change the prompt to a percent symbol.
> Apple //e's are lots of fun
No argument there.
--
David Empson
dem...@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand
Kragen Sitaker
Mike Westerfield <Mik...@aol.com> wrote:
>In article <nBqG3.5395$QJ.3...@typ11.nn.bcandid.com>, kra...@dnaco.net
>(Kragen Sitaker) wrote:
>> If I can't find an assembler that comes with source and permission to
>> modify and redistribute, I'll just go ahead and write my own assembler
>> in Perl. It's not as if I've never written an assembler before. . .
>
>Perl. If your goal is a cross-assembler, none of the Apple II assemblers
>will really help. All of them are written in 6502 assembly language and
>depend heavily on the Apple II operating system. Even if the source were
>available (and it isn't, not for a single one as far as I know) it wouldn't
>be a good basis for a port.
Actually, I'll be perfectly happy with either a cross-assembler or a
native assembler.
>As for writing your own assembler in Perl, I doubt if it will compare with
>the native tools or even with a commercial cross-development package, but if
>that's what tugs your chain, knock yourself out.
Well, I know I can write an assembler that works reliably, runs fast
enough for me, and has nice macros, without more than a few days' worth
of effort. It might even be more convenient -- we'll see.
> Don't expect it to run on an Apple II, though. As far as I am
> aware, Perl isn't available on the 8 bit Apple II,
No, it isn't, and almost certainly never will be.
> and even if it were, an assembler written in Perl would be so
>slow you'd be begging me to take your $60
Of course! :)
--
<kra...@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Thu Sep 23 1999
46 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
Tebo
>Actually, I'll be perfectly happy with either a cross-assembler or a
>native assembler.
>Well, I know I can write an assembler that works reliably, runs fast
>enough for me, and has nice macros, without more than a few days' worth
>of effort. It might even be more convenient -- we'll see.
I have some thoughts of writing an assembler (to be run
on the AppleII) myself, but haven't got time to do it...
(My "assembler" I plan to write is though somewhat different,
instead of writing INC X i want to write X++ and instead of
LDA #45 i want to write A=45) ...but if you write an assembler,
either cross-assembler or native, remember to tell us about
it and how to download it!
Stephen Judd
Kragen Sitaker <kra...@dnaco.net> wrote:
>I've just started learning 6502 ASM; I have an ancient book on the
>subject. I see various places to look for example code; "The Fridge",
>at http://www.ffd2.com/fridge/, has lots and lots of example code
>(mostly for the C64), and www.6502.org. But I have no idea which of
>this code is any good.
All of the code is good.
-S
Kragen Sitaker
Thank you for the recommendation.
I've been burned before by places that have lots and lots of example
code, none of which is any good. Macmillan Computer Publishing, in
particular. And I've seen a lot of other people get burned by Matt
Wright's CGI scripts.
I'm not really in any position to evaluate whether example 6502 code is
good or bad. :)
Sir Cain
it though, at the time they published it, I already had Ed Assem (it was
pre-GS days) and The Assembler & Macrosoft (also from Nibble). After the GS
came out, I bought Orca/M. The only thing it lacks is Macrosoft, but the
Macros that come with it are pretty close. Now if someone were really
enterprising, they would convert the Macrosoft macros to Orca/M!!!
--
Sir Cain The Silicon Knight
Mike Westerfield <Mik...@aol.com> wrote in message
news:7setvd$qci$1...@news.rt66.com...
>
>
> ----------
> In article <nBqG3.5395$QJ.3...@typ11.nn.bcandid.com>, kra...@dnaco.net
> (Kragen Sitaker) wrote:
>
>
> >>ORCA/M - This is the assembler Apple eventually picked as the standard
> >>development environment for the Apple IIGS. It's powerful. Great for
large
> >>scale development where true subroutines and very powerful macros are a
> >>plus. Also comes with a rather complete library, including integer math
and
> >>graphics, and an add-on for floating-point math. Still available and
> >>supported at http://www.byteworks.org.
> >
> > So its primary advantages are (a) it works; (b) it has true subroutines
> > (what are false subroutines?); (c) it has very powerful macros; (d) it
> > comes with a nice library?
> >
> > It says on your page it costs $60, which is quite reasonable (although
> > it's twice what I've paid for the computer, so far). But I get a sick
> > feeling in my stomach reading software license agreements; would I get
> > source? Would I be allowed to modify and redistribute it?
> >
> > If I can't find an assembler that comes with source and permission to
> > modify and redistribute, I'll just go ahead and write my own assembler
> > in Perl. It's not as if I've never written an assembler before. . .
>
> If you're asking if $60 gets you the source to the assembler itself, no.
If
> you're asking if the source to the libraries are available, yes--and there
> is no licensing fee or anything like that involved if you use the
libraries,
> of course. The same goes for the macros.
>
> I have no idea what you've got in mind in terms of writing an assembler in
> Perl. If your goal is a cross-assembler, none of the Apple II assemblers
> will really help. All of them are written in 6502 assembly language and
> depend heavily on the Apple II operating system. Even if the source were
> available (and it isn't, not for a single one as far as I know) it
wouldn't
> be a good basis for a port.
>
> As for writing your own assembler in Perl, I doubt if it will compare with
> the native tools or even with a commercial cross-development package, but
if
> that's what tugs your chain, knock yourself out. Don't expect it to run
on
> an Apple II, though. As far as I am aware, Perl isn't available on the 8
> bit Apple II, and even if it were, an assembler written in Perl would be
so
Jeff Brielmaier
Empson) wrote:
Hi David...
>Date Doctor - the best y2k fix <dated...@my-deja.com> wrote:
>
>> DOS is at a000-bfff
>
>Try 9600-BFFF. Lots of tables in there, so finding useful entry points
>to disassemble from is a little fiddly. Try disassembling from 3D0 to
>get some JMP instructions into various parts of DOS, and disassemble the
>destinations of these JMPs.
The best companion for looking at Apple DOS 3.3 is "Beneath Apple
DOS". Chapter 8 of this book has a running description of the entire
DOS kernel. Using the monitor's disassembly command along with the
book, you can have fun playing with DOS.
DOS actually only consumes $9D00-BFFF. $9600-9CFF is the file I/O
buffers and the amount of space that they actually consume can be
changed by use of the MAXFILES command (DOS defaults at startup with 3
file buffers).
The DOS kernel consists of tables and code intermixed. I'd highly
recommend 'Beneath Apple DOS' to be by your side as you disassemble
the DOS kernel.
Date Doctor - the best y2k fix
kra...@dnaco.net (Kragen Sitaker) wrote:
> In article <7scukv$sui$1...@nnrp1.deja.com>,> >] call -151
> >
> >* d000l
> >
> >you can disassemble the ROM, so that's probably a good start, DOS is
at
> >a000-bfff,
>
> Thanks! Are they well-written?
yes, they are easy to follow, and quite structured, so modifying things
is pretty easy, and the interrupt vectors are quite good practise if
you want to do anything on a PC later.
>
> >zero page has your interrupt table, 200-2ff is your stack,
>
> Is that the BASIC stack you're talking about? I thought 100-1ff was
> the hardware (i.e. PHA, PHP, PLA, PLP, JSR, RTS, BRK, RTI) stack.
> (Maybe my book is wrong. I've seen a remarkable number of computer
> books by people who didn't know what they were talking about.)
you could easily prove it either way I guess.
you might be right about 100-1ff, you will never want to access it
directly I expect, so just keep away from 100-2ff and you should be ok.
maybe 200-2ff is a disk buffer, it's been too long now.
>
> >if you have 128k ram, then
> >
> >*d000:d000.1ffffm
> >
> >(it's been a while, so forgive me if that is the wrong syntax)
> >
> >will copy the ram so you can page switch - reading c083 will switch -
> >then you can seemingly modify them ROM - and it will affect how
things
> >run.
>
> How does the bank switching work? What area of RAM is bank-switched,
> and how many banks are there?
ok, I remember now, the command d000<d000.1ffffM
as far as I know there is two banks, and you need to copy code into the
second bank before switching - as that command does for the ROM.
--
Date Doctor is a new / proactive y2k fix
Ask for it by name...
It is the only fix that can apply to all PC's - all other fixes
are limited to only some/most PC's. It is totally software based.
Sent via Deja.com http://www.deja.com/
Before you buy.
Date Doctor - the best y2k fix
dem...@actrix.gen.nz (David Empson) wrote:
>
> > zero page has your interrupt table
>
> No it doesn't. The interrupt vectors on the 6502 are in ROM, at
> FFFA-FFFF. On the Apple II, most of them are re-vectored through RAM
at
> 03F0-03FF.
software events like writing characters to screen, and getting input,
can all be intercepted via vectors in the zero page.
36-37 or 38-39. DOS does this after you boot up, - revectors to it's
own locations.
>
> > 200-2ff is your stack
>
> Try 100-1FF.
>
> 200-2FF is the input buffer.
>
> > 300-380 is free space
>
> Yes, but there is more than just that. 300-3CF is the generally
> accepted "free space" in this area.
>
> > but after that is more vectors,
>
> 3D0-3EC are used by DOS, the rest are for the monitor and other
> firmware.
what about 3f0-3f2 for the ctrl-reset vector.
I never had benefits of book learning for 2es, but we experimented and
found heaps of interesting things.
>
> > if you have 128k ram, then
> >
> > *d000:d000.1ffffm
>
--
Charles Richmond
bit-diddling to learn the 6502 assembly language, try the following
book:
As a start for Apple ]['s (not GS), you might try Compute! Books
_APPLE Machine Language for Beginners_, by Richard Mansfield,
ISBN: 0-87455-002-5. This book was published about 1985, but you
can get it from your local library or through inter-library loan.
This book contains the assembly source for the LADS assembler. It
also contains the hex for the machine code for the assembler that
you can type in. It has a small program that will checksum each
line of the hex, so you can have confidence that you typed it right.
This book has a description of all the 6502 instructions and
addressing modes. It also has some beginner assembly information,
like how to write multi-byte arithmetic routines.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Date Doctor - the best y2k fix
rich...@plano.net wrote:
> If you are looking to write a cross-assembler, or just do some
> bit-diddling to learn the 6502 assembly language, try the following
> book:
>
> As a start for Apple ]['s (not GS), you might try Compute! Books
> _APPLE Machine Language for Beginners_, by Richard Mansfield,
> ISBN: 0-87455-002-5. This book was published about 1985, but you
> can get it from your local library or through inter-library loan.
>
> This book contains the assembly source for the LADS assembler. It
> also contains the hex for the machine code for the assembler that
> you can type in. It has a small program that will checksum each
> line of the hex, so you can have confidence that you typed it right.
yep, I remember typing that in around 1986. the checksums were pretty
good, you couldn't transpose characters or otherwise fault it...
I think I preferred BIG MAC as an assembler though, but the instructions
were pretty easy.
three registers, A, X, Y
commands like LDA, LDX, LDY are loads
STA, STX, STY are stores
INX, INY DEX, DEY - are increment and decrement.
there is also INA, DEA, but they are undocumented and only on the newer
//e's - the ones with mouse characters I believe.
the addressing modes are eg. STA $00 or STA ($00) or STA $0000 or STA
($0000) or STA $0000,x or STA ($0000,x) or maybe even STA ($0000),x (x
or y in each case, examples are zero page, indirect zp, 16-bit, indirect
16-bit, 16bit with offset, indirect with offset,
then there is PHA, PHP, PLA, PLP, for pushing accumulator or program
counter onto the stack.
then things like ADC #04 to add 4 and carry to accumulator.
then TXA, TAX, TAY, TYA to transfer between accumulator and index
registers.
then SEC,CLC set clear carry,
then BNE, BEQ, BLT, BGT, BGE, BLE, BCS, --- branch if not eq, eq, less
than, grt, g or eq, less or eq, carry set, BZS (zero flag set), BMI
(minus), BPL (plus - < 128)
it's all coming back to me now!!
then theres some instruction to move the flags to a register - maybe you
PHF then PLA or something, then you can do bit operations
AND, ORA, XOR respectively.
also, most of the ADD ADC, SUB, SBC, and bitwise all have zero page and
16-bit at least for addressing modes.
addresses are stored low byte then high byte.
always 3 charactor opcodes, and always quite intuitive.
(SBC - subtract with carry)
(BZS - branch if zero flag set)
(XOR - exclusive OR)
etc.
good luck...
Date Doctor - the best y2k fix
David Empson
Date Doctor - the best y2k fix <dated...@my-deja.com> wrote:
> there is also INA, DEA, but they are undocumented and only on the newer
> //e's - the ones with mouse characters I believe.
They aren't "undocumented". They are documented completely in anything
which covers the 65C02 processor.
The 65C02 (as used in the IIc and enhanced IIe) adds about 26 new
opcodes. Some of these are outright new instructions (TRB/TSB), others
are new addressing modes (INC A, DEC A; aliased as INA and DEA).
> the addressing modes are eg. STA $00 or STA ($00) or STA $0000 or STA
> ($0000) or STA $0000,x or STA ($0000,x) or maybe even STA ($0000),x (x
> or y in each case, examples are zero page, indirect zp, 16-bit, indirect
> 16-bit, 16bit with offset, indirect with offset,
Some of those don't exist (for the STA instruction, anyway).
Here is a full list of the addressing modes for the LDA instruction, for
the 6502. These all apply to LDA, STA, ADC, SBC, AND, ORA, XOR and CMP,
with one exception: there is no STA immediate. :-)
LDA #$nn Immediate
LDA $nn Zero page
LDA $nnnn Absolute
LDA $nn,X Zero page indexed with X [Note: X only]
LDA $nnnn,X Absolute indexed with X
LDA $nnnn,Y Absolute indexed with Y
LDA ($nn,X) Zero page indexed indirect [Note: X only]
LDA ($nn),Y Zero page indirect indexed [Note: Y only]
The 65C02 adds one addressing mode:
LDA ($00) Zero page indirect
The 65816 adds six addressing modes:
LDA $nnnnnn Absolute long
LDA $nnnnnn,X Absolute long indexed with X [Note: X only]
LDA [$nn] Direct indirect long
LDA [$nn],Y Direct indirect indexed long
LDA $nn,S Stack relative
LDA ($nn,S),Y Stack relative indirect indexed
("Direct" is equivalent to "zero page" for the earlier processors. The
65816 has a D register which sets the base address of the direct page
anywhere in the first 64K bank.)
The 65816 immediate mode can be either 8-bit or 16-bit depending on a
flag setting.
Some other instructions have additional special addressing modes. Some
examples:
LDX $nn,Y Zero page indexed with Y
JMP ($nnnn) Absolute indirect
JMP ($nnnn,X) Absolute indexed indirect (65C02 and 65816 only)
> then there is PHA, PHP, PLA, PLP, for pushing accumulator or program
> counter onto the stack.
PHP/PLP deal with the processor flags. There is no way to directly push
or pull the program counter, except in a slightly modified form with the
JSR, RTS and RTI instructions (or with an interrupt).
> then BNE, BEQ, BLT, BGT, BGE, BLE, BCS, --- branch if not eq, eq, less
> than, grt, g or eq, less or eq, carry set, BZS (zero flag set), BMI
> (minus), BPL (plus - < 128)
Several of those don't exist. The set of branches are:
BNE Branch if not equal
BEQ Branch if equal
BPL Branch if plus
BMI Branch if minus
BCC Branch if carry clear
BCS Branch if carry set
BVC Branch if overflow clear
BVS Branch if overflow set
The 65C02 adds BRA (branch always), and the 65816 adds BRL (branch
long).
There are aliases for some of these instructions:
BLT Branch if less than (same as BCC)
BGE Branch if greater than or equal (same as BCS)
There is no single instruction to do a "branch if less than or equal",
or a "branch if greater than". These can be synthesised with two
consecutive branch instructions. Similarly there are no signed branch
instructions.
> then theres some instruction to move the flags to a register - maybe you
> PHF then PLA or something, then you can do bit operations
PHP, PLA.
> AND, ORA, XOR respectively.
EOR, actually. (Some assemblers accept XOR as an alias.)
> also, most of the ADD ADC, SUB, SBC, and bitwise all have zero page and
> 16-bit at least for addressing modes.
The 6502, 65C02 and 65816 do not have an ADD or SUB instruction. You
must always add or subtract with carry.
> (BZS - branch if zero flag set)
Never seen this one. BEQ is the correct name.
--
David Empson
dem...@actrix.gen.nz
Snail mail: P O Box 27-103, Wellington, New Zealand
Date Doctor - the best y2k fix
dem...@actrix.gen.nz (David Empson) wrote:
> Pardon the corrections. I'm in a pedantic mood this evening. :-)
your corrections are accepted gracefully. I haven't programmed the //e
seriously for 7 years, some things in my memory seem to have been
jumbled with some other assembly languages I see!!
ok I just tried it.
for those interested, call -151 then enter "!" to direct assemble code.
I must have got that on another chipset.
I tried SEZ and no joy either. oh well.
still SED, CLD, SEC, CLC, directly alter the flags. The Decimal one is
interesting - and really throws the system out if you set it without
clearing it later...
I was starting to wonder about all the opcodes and addressing modes I
was describing. There are only 256 machine opcodes, and each addressing
mode is represented by a different opcode pair, so I was sure I was
running out of room with the size of NUM_INSTRUCTIONS *
NUM_ADDRESSING_MODES....
regards
Lance Roberts
Snail mail: P O Box 68-261, Auckland, New Zealand
>
> --
> David Empson
> dem...@actrix.gen.nz
> Snail mail: P O Box 27-103, Wellington, New Zealand
>
--
Date Doctor - the best y2k fix
dem...@actrix.gen.nz (David Empson) wrote:
> The key point you are probably missing is that no instruction
implements
> every addressing mode, and most of them have only a small selection.
I am of course aware of this obvious fact...
> Some closely related instructions are STZ (4 opcodes), BIT (5
opcodes),
ah, that's where I remember Z from...
well anyway, heres a small piece of code for sound
if I remember rightly if you have a basic program with the following
10 CALL 768 : GOTO 10
it will play what you press on the keyboard
]CALL-151
*!
!300: LDY $C000
! TYA
! TAX
! INX
! BNE $0305
! STA $C030
! INY
! BNE $0303
! RTS
regards
Lance
David Empson
> I was starting to wonder about all the opcodes and addressing modes I
> was describing. There are only 256 machine opcodes, and each addressing
> mode is represented by a different opcode pair, so I was sure I was
> running out of room with the size of NUM_INSTRUCTIONS *
> NUM_ADDRESSING_MODES....
The 65816 almost manages to use all 256 opcodes. There is only one
unused one: $42. This is nominally "WDM" (the initials of William D
Mensch, the creator of the 65816). It was reserved for use as an opcode
prebyte for future processors.
The key point you are probably missing is that no instruction implements
every addressing mode, and most of them have only a small selection.
As I mentioned previously, the "big eight" accumulator instructions have
the most addressing modes:
LDA, STA, ORA, AND, EOR, ADC, SBC, CMP
In total, on the 65816, each of the instructions has 15 addressing modes
(except for the omission of "STA immediate", which is meaningless).
That accounts for 119 out of the 255 used opcodes. [136 left]
The next largest group looks like the read/modify/write operations:
ASL, LSR, ROL, ROR, INC, DEC
Each of these has five opcodes, for a total of 30. [106 left]
Some closely related instructions are STZ (4 opcodes), BIT (5 opcodes),
TSB and TRB (2 opcodes each). [93 left]
Now the index register group:
LDX, LDY (5 opcodes each); STX, STY, CPX, CPY (3 each). [71 left]
Now the jump group:
JMP (4 opcodes), JSR (2 opcodes). [65 left]
Everything else is a single opcode:
BCC, BCS, BEQ, BMI, BNE, BPL, BRA, BRK, BRL, BVC, BVS, CLC, CLD, CLI,
CLV, COP, DEX, DEY, INX, INY, JML, JSL, MVN, MVP, NOP, PEA, PEI, PER,
PHA, PHB, PHD, PHK, PHP, PHX, PHY, PLA, PLB, PLD, PLP, PLX, PLY, REP,
RTI, RTL, RTS, SEC, SED, SEI, SEP, STP, TAX, TAY, TCD, TCS, TDC, TSC,
TSX, TXA, TXS, TXY, TYA, TYX, WAI, XBA, XCE.
Jon Bettenct (formerly Mr.I'mAnOutOfControlLisaSimpsonFannnn)
> code, none of which is any good.
That happened to me once, too. I entered a program in an emulator that was
supposed to give me the number of free sectors on a DOS 3.3 disk, but
something went wrong and it damaged the disk image. The only way I could
get the data out was using Image2File.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
jonr...@napanet.net jrelay.cjb.net
An Apple II fanatic since 1998! S0.5 LIS+++! M1987
"I can't stand to see you so miserable, Lis. Unless it's from
a rubber spider down you dress. Hmm... that gives me an idea.
(Pulls out tape recorder) Note for later: put rubber spider down
Lisa's dress. He he he he he."
*_ Syntax Error: an error on a criminal's tax record.
| Bad Subscript: a criminal reading a book on a subway.
--- Unimplemented Trap: when a bear trap isn't set up
|' ,| properly and thus does not work.
--- Overflow: too many ice cubes. <Can't Restart>
Please remove capital letters from my e-mail address to respond.
Jon Bettenct (formerly Mr.I'mAnOutOfControlLisaSimpsonFannnn)
In article <1dyz220.yb...@dempson.actrix.gen.nz>,
dem...@actrix.gen.nz (David Empson) wrote:
I counted 63 of these. What about the remaining two?
Also, aren't the branch commands (BCC, BCS, BEQ, BMI, BNE, BPL, BRA, BVC,
BVS) three bytes? (One for the opcode and two for the operand [the address
to branch to])
>
> --
> David Empson
> dem...@actrix.gen.nz
> Snail mail: P O Box 27-103, Wellington, New Zealand
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Steve Judd
David Empson <dem...@actrix.gen.nz> wrote:
>Jon Bettenct (formerly Mr.I'mAnOutOfControlLisaSimpsonFannnn)
><jonINTERNE...@napaVALLEYnet.CLARInet> wrote:
>
>> Also, aren't the branch commands (BCC, BCS, BEQ, BMI, BNE, BPL, BRA, BVC,
>> BVS) three bytes? (One for the opcode and two for the operand [the address
>> to branch to])
>
To be pedantic, all except BRL.
-S
--
David Empson
<jonINTERNE...@napaVALLEYnet.CLARInet> wrote:
> In article <1dyz220.yb...@dempson.actrix.gen.nz>,
> dem...@actrix.gen.nz (David Empson) wrote:
>
> > Now the jump group:
> >
> > JMP (4 opcodes), JSR (2 opcodes). [65 left]
> >
> > Everything else is a single opcode:
> >
> > BCC, BCS, BEQ, BMI, BNE, BPL, BRA, BRK, BRL, BVC, BVS, CLC, CLD, CLI,
> > CLV, COP, DEX, DEY, INX, INY, JML, JSL, MVN, MVP, NOP, PEA, PEI, PER,
> > PHA, PHB, PHD, PHK, PHP, PHX, PHY, PLA, PLB, PLD, PLP, PLX, PLY, REP,
> > RTI, RTL, RTS, SEC, SED, SEI, SEP, STP, TAX, TAY, TCD, TCS, TDC, TSC,
> > TSX, TXA, TXS, TXY, TYA, TYX, WAI, XBA, XCE.
>
> I counted 63 of these. What about the remaining two?
Try again. I just counted again and it looks like 65 to me (14 on each
of the first four lines, for a subtotal of 56, plus 9 on the last line,
for a total of 65).
> Also, aren't the branch commands (BCC, BCS, BEQ, BMI, BNE, BPL, BRA, BVC,
> BVS) three bytes? (One for the opcode and two for the operand [the address
> to branch to])
No. All the branch instructions are two bytes, and use relative
addressing. The operand is a signed 8-bit number which is added to the
program counter (as at the start of the next instruction). This means
you can skip over 127 bytes for a forward branch, or 126 bytes for a
backward branch (not counting the branch instruction itself). An
infinite loop can be achieved by branching to the branch instruction
(assuming the condition is true), which uses a relative offset of -2
($FE).
Assemblers and disassemblers always display branch instructions as if
they used absolute addressing, i.e. with the address or label to which
they are branching. This is converted to a relative offset at assembly
time, and the assembly will fail if the destination address is out of
range.
Jon Bettenct (formerly Mr.I'mAnOutOfControlLisaSimpsonFannnn)
> > >
> > > BCC, BCS, BEQ, BMI, BNE, BPL, BRA, BRK, BRL, BVC, BVS, CLC, CLD, CLI,
> > > CLV, COP, DEX, DEY, INX, INY, JML, JSL, MVN, MVP, NOP, PEA, PEI, PER,
> > > PHA, PHB, PHD, PHK, PHP, PHX, PHY, PLA, PLB, PLD, PLP, PLX, PLY, REP,
> > > RTI, RTL, RTS, SEC, SED, SEI, SEP, STP, TAX, TAY, TCD, TCS, TDC, TSC,
> > > TSX, TXA, TXS, TXY, TYA, TYX, WAI, XBA, XCE.
> >
> > I counted 63 of these. What about the remaining two?
>
> Try again. I just counted again and it looks like 65 to me (14 on each
> of the first four lines, for a subtotal of 56, plus 9 on the last line,
> for a total of 65).
You're right. It's 65.
>
> > Also, aren't the branch commands (BCC, BCS, BEQ, BMI, BNE, BPL, BRA, BVC,
> > BVS) three bytes? (One for the opcode and two for the operand [the address
> > to branch to])
>
> No. All the branch instructions are two bytes, and use relative
> addressing. The operand is a signed 8-bit number which is added to the
> program counter (as at the start of the next instruction). This means
> you can skip over 127 bytes for a forward branch, or 126 bytes for a
> backward branch (not counting the branch instruction itself). An
> infinite loop can be achieved by branching to the branch instruction
> (assuming the condition is true), which uses a relative offset of -2
> ($FE).
Yeah, well, they're STILL not single-byte opcodes.
Date Doctor - the best y2k fix
26.napanet.net>,
jonINTERNE...@napaVALLEYnet.CLARInet (Jon Bettenct (formerly
no they are single opcodes in the context we were talking about.
he was referring to how in machine code there is 1 unique 8-bit pattern
per instruction, and that some mneumonics can have several different
opcodes for different addressing types - but the branch instructions
have only 1 opcode, and the addressing mode is always 1-byte relative.
I think you misenterpreted the discussion.
Jon Bettenct (formerly Mr.I'mAnOutOfControlLisaSimpsonFannnn)
>
> no they are single opcodes in the context we were talking about.
> he was referring to how in machine code there is 1 unique 8-bit pattern
> per instruction, and that some mneumonics can have several different
> opcodes for different addressing types - but the branch instructions
> have only 1 opcode, and the addressing mode is always 1-byte relative.
>
> I think you misenterpreted the discussion.
I did, now that I think about it. I was thinking about how many bytes were
in the complete instruction, not how many addressing modes there were.
Mike Westerfield
----------
In article <7u11l2$jdp$1...@kc.trail.com>, sj...@kc.trail.com (Steve Judd)
wrote:
>>No. All the branch instructions are two bytes, and use relative
>
> To be pedantic, all except BRL.
Well, to be even more so, this is a 6502 discussion--and BRL isn't a 6502
instruction. :)
Mike Westerfield
David Empson
> > > > Everything else is a single opcode:
> > > >
> > > > BCC, BCS, BEQ, BMI, BNE, BPL, BRA, BRK, BRL, BVC, BVS, CLC, CLD, CLI,
> > > > CLV, COP, DEX, DEY, INX, INY, JML, JSL, MVN, MVP, NOP, PEA, PEI, PER,
> > > > PHA, PHB, PHD, PHK, PHP, PHX, PHY, PLA, PLB, PLD, PLP, PLX, PLY, REP,
> > > > RTI, RTL, RTS, SEC, SED, SEI, SEP, STP, TAX, TAY, TCD, TCS, TDC, TSC,
> > > > TSX, TXA, TXS, TXY, TYA, TYX, WAI, XBA, XCE.
>
> > > Also, aren't the branch commands (BCC, BCS, BEQ, BMI, BNE, BPL, BRA, BVC,
> > > BVS) three bytes? (One for the opcode and two for the operand [the address
> > > to branch to])
> >
> > No. All the branch instructions are two bytes, and use relative
> > addressing.
[Well, except BRL, which is three bytes, as noted by Steve Judd. Jon
didn't mention that one so I didn't consider it when writing this
statement.]
> Yeah, well, they're STILL not single-byte opcodes.
I didn't say they were "single byte" opcodes. I said they were "single"
opcodes, i.e. there is only one 8-bit pattern used by the processor for
this instruction.
To take a couple of examples: BCC has a single addressing mode
(relative) and a single opcode, while JSR has two addressing modes
(absolute, and absolute pre-indexed with X on the 65C02), hence two
opcodes. (JSL is arguably a third addressing mode for JSR, but it is
usually written as a different mnemonic, so I'm classifying it as a
different instruction.)
A footnote: to be pedantic, they _are_ "single-byte opcodes". In fact,
every instruction on the 6502/65C02/65816 is a single-byte opcode. Most
of the instructions have operand bytes as well as the opcode itself, so
the instructions can be described as being a certain number of bytes,
but the opcode itself is always one byte.
The opcode is the part of the instruction which the processor decodes to
identify the action to be taken, and the addressing mode to be used.
The operand bytes are parameters which tell the processor the memory
location or data value to be used.
David Empson
> ----------
> In article <7u11l2$jdp$1...@kc.trail.com>, sj...@kc.trail.com (Steve Judd)
> wrote:
>
> >>No. All the branch instructions are two bytes, and use relative
> >
> > To be pedantic, all except BRL.
>
> Well, to be even more so, this is a 6502 discussion--and BRL isn't a 6502
> instruction. :)
Not exactly - I was describing the entire 65816 instruction set in this
sub-thread, so it was a relevant comment.