Initial 6502 experimentation for the tgl6502 - as an experimental target
to play with 6502isms easily

See:
http://thegaragelab.com/programming-the-tgl-6502/

Use a modern cc65 from https://github.com/cc65/cc65

Our memory mapping looks like this

	0x0000		ZP
	0x0100		6502 Stack (per proc) 
	0x0200		C stack (per proc)
	0x0400		I stack (per proc)
	0x0500		Udata actual data per proc
	0x0600+		Common copy and compiler runtime

	0x2000		Kernel data	(8K)
	0x4000		Kernel code	(48K)

This ensures we can do all our stack flips in one operation when we switch
process in switchin.




Lots not yet done:

signal checks are not being done on the syscall path (or irq path)

Checking on the 6502 stack. Probably we should just check for overflows and
kill, or perhaps copy stacks in/out IFF it would otherwise run out (as 
Apple ProDOS seems to)

Memory set up for now is banking, because we'll need swap and bank16k+swap
still needs significant work on the I/O side of things.

Lots of memory to save in kernel space by making the common and data copies
come from a bank we then switch out, along perhaps with the const data from
what would be discard areas on the Z80.


To build:
Set the platform/target
make clean
make
tools/tglsplice

and you'll get a 6502.rom

If you have a filesystem tgl_rootfs of 64K it will add this into the ROM
image at the top. (Note this may move in future as the top block may become
reserved for the tgl code).

If you have a monitor then put it in binary form in tgl_monitor and it'll
be merged with the image. The monitor will be mapped at 0xE000 and entered
at that address. It must fit in the 8K minus the vectors. On entry there
isn't really any RAM free as such but 1F00-1FFF is probably a fairly safe
place to store workspace without trashing the Fuzix image.

TODO
----
- Signal handling paths
- Fix brk() checking
- Interrupts
- Real I/O device
- Fix up all the C library stubs that use time_t. The kernel uses 64bits
  but the user code is packing them to 4 bytes. Needs some kind of define
  to pad up the structs that matter. 6809 will need the same but
  other-endian.

Fairly Essential Optimsations To Do For A Box This Slow on RAM
--------------------------------------------------------------

- Fast copy via spi buffer hack
- Use bank mode not 48K fixed so we can get more processes in (we don't
  have user overlapping common so swap can be done eventually too)
- Only copy the needed memory when forking, not 48K (in theory we are copying
  low->brk, sp->top, S->top of page, and Z)
- execve direct read to usermem (core change)
- vfork()
- usermem functions that use banking tricks
- map_save/restore copy/restore entries for kernel mode so we can take an
  interrupt when we are pulling banking tricks

General 650x Questions
---------------------- 

- What would it take to make ld65 generate banked binaries for 6502 boxes.
  The C argument stack is separate from the call/return stack so the usual
  horrible argument magic is avoided. It would just need stubs for inter
  bank calling added by the linker somehow, along with allowing multiple
  memory regions at the same address with different output files

- Would using a relocatable binary format make more sense given how varied
  6502 maps are. cc65 can already generate a quite usable format.

- Is it worth having standardised usermem_ helpers and entry/exit code for 6509