If you have any questions whatsoever, please get in touch !

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... (...after all, I do have to contribute towards the electricity bills!).
 
Please note that while the VeroDes software is associated with the Amélie project, it is distinct from it, therefore it is released under its own licence.

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 in the documentation
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).
I try to write all hex values in the "Courier New" font, however if I forget, here is the ampersand as it looks in this (Trebuchet) font - & - yucky isn't it? Looks more like a symbol for "etc", no?

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, neither is the VisualBasic-style '&H' prefix (i.e. &HFFFF).

Other hex numbers
These are written in accordance with the language in use - thus hex numbers in C are prefixed '0x', and in VisualBasic are prefixed '&H'. Note that in VisualBasic, values that fit into an integer range may be suffixed with an ampersand to denote that it is a "long". For example, &HE9 is an integer value while &HE9& is a long value. The suffix is not necessary for values out of integer range.
In general, it is essential to understand the Acorn and C conventions as I would write code like:
    something = &HFF ' initialise stack, starts at &FF and counts backwards

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! The feeling is mutual - I don't get the hokiness of segment addressing. :-)

Conventions - code

Opcodes and registers - 6502
Processor instructions are always written in upper case. Registers are normally written in upper case. Instructions are indented three places (column 4). Constants and registers are separated by two spaces (column 9). If there is a comment following, this should start on column 20.
For example:
   LDX  #64        ; Timer1 continuous, no SR, PA/PB unlatched
   STX  via_acr    ; Aux. Control Register

Opcodes and registers - ARM
Processor instructions are always written in upper case. Registers are normally written in upper case. Unless the code relates to APCS interfacing, you should not use APCS names (such as 'a1', 'v2', etc). Instructions are indented eight places (column 9). Parameters are written eight places further (column 17). Comments should begin around column 43.
For example:
        AND     R1, R0, #&FF              ; get low byte
        MOV     R0, R0, LSR #8            ; shift high byte low
        ORR     R0, R0, R1, LSL #8        ; merge in low byte high
It is recommended to alias the registers if it improves the readability of the code when applicable:
        MOV     R0, R0, LSR #8            ; discard low byte, we want A8-A15
        AND     A8, R0, #1                ; got A8
        MOV     R0, R0, LSR #1
        AND     A9, R0, #1                ; got A9
        MOV     R0, R0, LSR #5
        AND     A14, R0, #1               ; got A14
        MOV     R0, R0, LSR #1
        AND     A15, R0, #1               ; got A15
A9, A9, A14, A15 are R4, R5, R6, and R7 respectively.
 
In all functions, several assumptions may be made:
1. Functions should preserve and restore registers it corrupts.
2. It may be assumed that R0 to R3 may be freely corrupted. Therefore if a function relies upon the contents of the first four registers, it should preserve before calling another function.
3. R13 is the Stack Pointer. Fully descending. It is frequently aliased to "SP".
4. R14 is the Link Register. It is usually aliased to "LR".

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 (6502asm does not (currently) support 'local' labels).
For example:
   .lcl_innerloop

Definitions / constants
Definitions (not currently supported by 6502asm) are to be written in upper case, with an underscore as a prefix .
For example:
   LDX  #_START_VALUE

Assembler-provided labels (not currently supported by 6502asm ) are in upper case with two underscores prefixed and suffixed.
For example:
   EQUS __DATE__

Comments
<- to be written ->

Structure (in C code)
<- to be written ->

Hungarian Notation
HN is not used, anywhere, within the Amélie project. It appears that Microsoft recommends the use of such notation (if the VB stuff is anything to go by).
Let's put it like this, code submissions that use HN will probably not make it to be added to this website. There are many things wrong with HN, don't use it!

6502asm does not require the upper/lower case convention to be followed (if you prefer lower/mixed case code).

Such values may be inserted into the code by means of DCx or EQUx instructions:

• DCB / EQUB
  This inserts an 8 bit byte value.
   
• DCW / EQUW
  This inserts a 16 bit word value.
   
• EQUD
  This is an alias for me because I am so used to it from RISC OS. It inserts a 16 bit value. There is no DCx equivalent as the use of EQUD ('d' for doubleword') is totally wrong as it should insert a 32 bit 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.

Of bytes and words - RISC OS / x86 code
Typically, on an x86 system and integer is 16 bit and a long is 32 bit.

On a RISC OS system, both int and long are 32 bit.