Certain aspects of the memory map are dictated by the processor. It requires Page One (&0100-&01FF) to be RAM for the provision of a stack, while the last six bytes of memory (&FFFA-&FFFF) are used to provide three vectored addresses for the hardware vectors.
While it is possible to locate the vectors in random access memory, because the RESET vector is one of these it is logical to place the firmware so that these final six bytes may be read out of the ROM, EPROM, FlashROM, etc...

Some systems, such as the Acorn FileStore E01S (Econet file server) copy the entire firmware into RAM and then switch the memory decoding so the ROM is invisible - all subsequent 'firmware' activity, including the hardware vectors, takes place in RAM. This degree of complexity is not provided within Amélie.

The basic memory map
The basic memory map is laid out as follows:

&FFFF		&FFFE IRQ vector
	EPROM	&FFFC RESET vector
		&FFFA NMI vector
	(BIOS area: 3Kb)
&F400	- - - - - - - - - - -	&F400 BIOS start
	(application area: 5Kb)
&E000	8192 bytes	&E000 EPROM base
&A700	Memory-mapped	EXP4SEL, EXP3SEL
&A400	Expansion hardware	EXP2SEL, EXP1SEL
&A300	Memory-mapped	&A300 Latch
	I/O hardware	&A100 ACIA (serial I/O)
&A000	devices	&A000 VIA (digital I/O)
&07FF		&0400-&07FF unallocated
	RAM	&0300-&03FF app. workspace
		&0200-&02FF serial buffer
	(2048 bytes)	&0100-&01FF processor stack
&0000		&0000-&00FF Page Zero

Each part is discussed in further detail within its respective sections.

 

Address decoding (first attempt)

The first attempt at address decoding is as follows. I drew it while having a break at my French course...

Click the image to view a larger version...

This, unfortunately, has a giant flaw. Can you spot it?

If not - consider that A14 and A15 both high mean the ROM is to be accessed; while A13 and A15 both high means an I/O device is being accessed.

However since the ROM is mapped in at &F000 , this in binary is %1111 0000 0000 0000; or in other words when accessing the ROM, A12, A13, A14, and A15 will always be high. Thus, the I/O device selections will always be active at the same time as the ROM selection. Aaargh!

 

The solution is pretty simple and would require only one more bit of logic to implement. But, it needs "NOT" so this would be another logic gate.

I know I can do the entire memory decode with three logic ICs (anything else is just messy).

 

Address decoding (second attempt)

What was necessary was not, in fact, a clever ploy to fit in another logic gate; but rather a complete rethink of the address selection logic.

I am not going to explain how I arrived at the current decision, since the diagram pretty-much explains itself.

Click the image to view a larger version...

If you have ProTel's CircuitMaker (or the Pro version), or ExpressPCB's ExpressSch and ExpressPCB (available from their website ), you can download schematics and circuit diagrams for a hypothetical daughter-board to perform address decodes.

This circuit will, however, be a part of the main motherboard and not a daughterboard... I just did it this way in order to aid breaking everything into small "easy to digest" chunks.

 

Effective address decoding

For reference purposes only... If you examine the memory decoding, you will see that the actual address ranges supported are:

            Address      Bytes  Purpose                        
         &0000 - &3FFF    16384   RAM (16K)
         &4000 - &9FFF   24576   Unaddressable (24K)
         &A000 - &A0FF      256   VIA
         &A100 - &A1FF      256   ACIA
         &A200 - &A2FF      256   Unallocated (options selector)
         &A300 - &A3FF      256   Latch
         &A400 - &BFFF     7168   Other I/O devices (7K)
         &C000 - &FFFF    16384   EPROM (16K)

This means that we could provide up to 16K of RAM, plus an equally large EPROM, if desired.