If you have any questions
whatsoever, please get in touch
!
Licence
This is a basic overview of the licence
terms. More detailed ones may exist within the documentation
of the individual parts, but will not be greatly
different from that stated below...
These plans, diagrams, object code,
and sources are free to use for
personal and non-commercial use (commercial
is hereby defined as
something for which the end-user must pay, either directly or
indirectly) and thus covers "shareware", magazine
publication, and so forth.
Any other use requires my
permission first, and profit participation may be
requested. I'm open to options.
You download materials from this website upon the
following conditions:
-
You report all corrections and
modifications back to me, it will be assumed that such
changes may be integrated into the main release (available
from this website).
-
If you make your own modified versions
available (i.e. on your website) then it must
clearly state on the website,
the documentation, and on-screen in the program itself
that the user is
not
using the original release. You must provide
Amélie's URL as follows:
http://www.heyrick.co.uk/amelie/
(I am happy to host modified
versions here, if preferred)
-
None of this
code is covered by the GPL, and furthermore
integration in any way that could make this code liable
for GPLisation is expressly forbidden. In case of such an
event, I remind you that the only person who can
legally change the licencing on this source to GPL is
myself, the legal copyright holder
. And, well,
d'you get the feeling that won't ever happen?
(before
the hate-mail rolls in, my problem is with the GPL itself
and with some of its proponents; if I didn't generally
agree with what it represented then I'd not be releasing
all the source code to this
project, would I?)
Please note that the FSF has the following to say on
the matter of this software being
available for "free":
If you want to say that a program
is free software, please don't say that it is available "for
free." That term specifically means "for zero price." Free
software is a matter of freedom, not
price.
Unfortunately, this is casting the issue
in their favour, which could be taken to be as
much as a misrepresentation as what they say you should
not write. You see, I could equally validly say "Free software
is a matter of price, not freedom", because in the English
language we have only the one word to describe the two
states.
Therefore to clarify, while you have certain
'freedoms' with the Amélie product code and plans,
there are rules that I expect you to play by. Provided you
don't intend making yourself money with Amélie (and
not sharing), then for you the whole thing is "gratuit". In the
FSF's eyes, I cannot call Amélie
"libre".
Additionally, the FSF suggest that one should
not use "commercial" to describe something that you pay for,
as commercial can be free (look at Linux boxed packs). This is
why I clarify "commercial" as anything for which the
end-user must pay. If the end user does not pay a penny, then
in my mind it is not "commercial" even if a business wrote it
(frankly, Martians could write it for all I care). By this
token, "MSIE" is not commercial software, "Word" is.
Microsoft wrote both.
Now this might, to you, read as a big
"don't rip me off" statement. You'd be entirely correct. Play
fair by me and I'll show you the same in return. I am not a
millionaire, I can't afford to be altuistic - no matter how
much I might like the ideology. I have taken time and effort
to make this, and I have done it from scratch. And you can
look at it all, right here. You can build it. You can enjoy
it. For all of this I ask only that you let me know of
improvements that you make. I do not see any commercial
purpose to Amélie as these days you can make a lot of
embedded hardware using only one device (microcontrollers such
as the PIC series). However if Amélie does what you
want (in your 'commercial' product), talk to
me about it...
Conventions
Within all
of Amélie, the following numerical
conventions exist:
Binary
numbers
Binary values are denoted by a
percent prefix, thus %1001 is 9 and
%1111 is
15...
In all cases, leading zeroes may be present or
absent as ćsthetics dictate. It doesn't matter.
The
rightmost bit is the least significant, and binary values
are always read right-to-left.
Hex (base 16)
numbers
Hex values are denoted by an
ampersand prefix, i.e. &F for 15, or
&0000-&FFFF for the
6502 addressing range.
Again, leading zeroes may or may
not be present.
The rightmost value is the least
significant byte, the leftmost being the most significant
byte. Thus &ABCD is 43,981 and
not 52,651 or 56,506 (etc).
Hex numbers in
6502asm
The assembler will accept
hex numbers prefixed by a dollar (i.e. $FFFF) as is the
Commadore/Pascal method. In addition the C-like '0x' prefix is also accepted (i.e.
0xFFFF).
The DOS-style
'h' suffix (i.e. FFFFh) is not
supported.
6502
addresses
Where addresses are written, the
logical address is always given. The BIOS code starts at
&F800, while that would be &00, &F8 in the 6502's
memory.
In general, this will be
understood by Acorn programmers and sort-of understood by
Commadore/AppleII/Oric/etc programmers. Those weaned on the
x86 platform might scratch their heads and think this is all
alien!
Opcodes and
registers
By convention, processor
instructions are always written in upper case.
Registers are normally written in upper case.
For
example:
LDA
#43
ROL A
Labels
Labels,
prefixed with a period (the BBC BASIC assembler way), are
always written in lower case and use no other
punctuation except for the underscore to split words.
For
example:
.irq_vector_exit
Local labels follow the same
pattern, though it is advisable to use the prefix ".lcl" to
denote the label as being 'local' to the defined
routine.
For example:
.lclinnerloop
Definitions
Definitions
are to be written in upper case, with an underscore as
a prefix.
For example:
LDX #_START_VALUE
Assembler-provided
labels are in upper case with two underscores prefixed
and suffixed.
For example:
EQUS
__DATE__
6502asm does not
require the upper/lower case convention to be followed (if you
prefer lower case code).
Of bytes and
words
It is
assumed that a byte value is 8bit and a word
value is 16bit. This isn't strictly correct as the 6502
is only an 8bit microprocessor with an 8bit data bus; but this
distinction makes life easier when talking about 16bit
addresses.
Such values may be inserted
into the code by means of DCx
or EQUx instructions:
-
DCB / EQUB
This inserts an
8bit byte value.
-
DCW / EQUW
This inserts a
16bit word value.
-
EQUD
This is an alias for me
because I am so used to it from RISC OS. It inserts a
16bit value. There is no DCx equivalent as the use of EQUD
('d' for doubleword') is totally wrong as it should insert
a 32bit value... but I was fed up of assembly errors
thanks to RISC OSisms leaking into my code!
8-0
Obviously, it is recommended that you not
use this. I'm just describing it in case you encounter
it.
-
DCS / EQUS
Insert a string
literal.
You can insert several C-like escape
codes:
-
\n Insert
an &0A
byte
-
\r Insert
an &0D
byte
-
\" Insert
a double quotes character
-
\' Insert
a single quote character
-
\0 Insert
a null byte
-
\\ Insert
a backslash character
-
\x## Insert a hex value
directly (must be two digits, pad with leading
zeroes if shorter)
-
\d###
Insert a (base 10) value directly (must
be three digits, pad if shorter)
-
DCZ / EQUZ
Inserts a null
terminated string literal.
Can contain escape codes as
described above.