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.