z80pack, tricks: update bankfork

We now use all but 4K for base memory so we may need to copy more space.
Without this fix programs with large or no chmem crashes in fork()
usermem: fix error handling
usermem-z80: return 0
z80pack: put the kernel flag in common

As this is checked with the kernel not mapped it's important it lives somewhere
more suitable
process: kernel flag has moved to common
binman: memcpy the initialized data over

This accidentally got removed when I stripped it down from the full
featured kernel version.
6502test: flesh out a little of the 6502 init paths
execve: remove some debug noise
6502: Start fleshing out how the port would work

Very incomplete at this point
lowlevel-z80: di/ei handling

Handle both di/ei restore cases don't assume we are just stacking disables
dragon: continue fleshing out

At this point it's a fairly complete build minus I/O devices but with some
guesswork on how we will deal with irq and syscall handling given the odd
memory mappings.

It does at least suggest that we can put it in cartridge + single task in
memory mode.
lowlevel-z80: remove accidentally commited debugging code
ucp: chmod parameters order fixed
Merge pull request #14 from atsidaev/ucp

ucp: chmod parameters order fixed
From: William R Sowerbutts

Correct the inode type in a dirent.

We accidentally kept the 32bit type from ELKS
Merge branch 'master' of https://github.com/EtchedPixels/FUZIX

Merge with patches applied via github
pcw8256: Continued work

This fixes parts of the floppy logic and moves kernel_flag as per core
changes.

We now load the superblock correctly but things to castors up when we start
to load init. We appear to be asking for the right track/sector but more
debugging is needed.
bank32: make passive provision for awkward boxes with low 32K switching

This allows you to define them as a 32K paged system and use the provided
swap and page hooks, plus your switch functions to copy blocks between the
spare parts of the high 32K and the pages they are stashed in.

This means that with a typical usage model of a single large app performance
will basically be as good as a sensible layout, and only if you have two
larger apps actively running at once will it degrade much.

This will be pretty much essential to cover the uBee and the N8VEM-2.
unbanked: Update comments

Will pointed out the comments in unbanked about Z180 were bogus, and indeed
were also out of date.

Also turns out we can't have the kernel at physical 0 and banks for user
copy and for udata on the Z180 as the N8VEM-4 and probably others have ROM
at physical 0
crt0: Correct environment and argument parsing

From: Will Sowerbutts

kernel sets up the stack differently: argc, argv, environ[]