msx2: initial bootstrap debugging

We get as far as enabling interrupts then curl up and die. The VDP
programming also doesn't set text80 but does produce some interesting
flashing blobs

Makefile/link: Update all the other link files to match the previous change

Merge pull request #4 from gmacd/master

Add condition to build z80pack on Mac

Add condition to build z80pack on Mac

msx2: Further random guesswork as we go - memory sizing

msx2: RAM fixup

Apparently RAM is added in the reverse order to tht expected - 3 is at 0x000
2 is at 0x4000 etc. Add them properly then add 0 so that init picks up the
initial 0xC000 bank for common and udata

msx2: Add an initial wild guess at what MSX2 will need

Hopefully that'll be a basis for someone who knows something about MSX2
to fill in the blanks. In particular my VDP code is a wild untested guess

Makefile: call the final result fuzix.bin not uzi.bin

Still need to rename all the temporaries

README: first take at instructions for building

No these are not sufficient yet

Merge pull request #3 from erkinalp/master

Converted all function definitions into prototype style in mkfs.c

Converted all function definitions into prototype style in mkfs.c

pcw8256,fdc765: not the architectural question around banking and swap

Basically the problem is this:

On a 16K banked machine we have 0x0000-0xBFFF holding user code and we can
switch between processes low 48K with gay abandon. However the top 16K holds
process memory, common, *and* our stacks.

What probably needs to happen is that either we bounce such buffers (slow) or
teach the swap device driver in the platform to do bank flipping.

The problem with this last one is that
- it has to be done per platform
- some machines have brain damaged banking where a given address in a bank
  cannot be remapped to a different virtual address

Unfortunately it's not obvious how to create a generic solution that doesn't
punish sensibly designed machines.

pcw8256,fdc765.s: Use outi not ini for writes, comment the code fully

This still doesn't explain why we misparse the status errors.

emulator: Add code for lseek() rather than the UZI v6 seek

Not yet tested, but this should be the basis to bootstrap CP/M emulation
code in the OS environment. At that point we can retarget the UZIX native
compiler setup for FUZIX and have a native compiler for userspace (yay!)

px4plus: update comments, remember to swap the uarea

swap: Fix silly bug

nc100/200: update notes, start adding NC200 support

px4 init: Remember to set the video base !

Makefile: introduce the _VIDEO segment, rebalance CODE and CODE2

Not that the linker can bank the things yet...

crt0.s: Prepare for _VIDEO

crt0: Prepare for _VIDEO area

px4plus: Add initial (untested) video, and adjust memory maps etc

Add an init.c for code we can discard.

vt: We are going to make this more bankable, add warnings

binman: Teach binman some new tricks

Allow for discard being low
Allow for initializer being low (indicating we are not doing common packing
and the classic 'copy up' image)
Spot data/const overlapping for cases we force data start (PX4Plus)
Smart end/start identification for complex images rather than the classic
image.

Hopefully classic images still work

start: move more discardables into _DISCARD

px4plus: note the state of play

font8x8: allow 1K font

We don't always want to blow 2K on fonts, so allow a 1K font option

platform-px4: Add the PX4Plus

The question was asked and its an interesting one as the PX4Plus is probably
right on the limit of what we can handle if we use the ROM pods.

This is untested but builds and also not very useful as it doesn't yet have
the vt driver, keyboard, font or floppy. It does seem to prove that if you
breathe in then you can fit the Z80 core into 32K of ROM with 8K for the
common/udata and put the video/floppy/fonts banked into the top of the RAM
area. That would still allow something like 48K binaries to run, and as the
PX4Plus has at best 128K of RAMdisc for swapping 32K is probably a saner
limit anyway.

And no.. I do not think swapping to a 38400 baud serial floppy would rock.

nc200: Initial pass at NC200 support as well as the NC100

Giving the floppy drive a miss as it seems to be completely undocumented
and will need research. May be easier to port CP/M 3 to it first for
investigation.

README.md: mutter mutter formatting crap, whats wrong with ASCII

pcw8256,devtty: Commit some of the shift keys that were missing

PORTING: Clarify map_save/restore

pcw8256: resync with the core updates

Makefile: remove some more bits of legacy uzi.com building

Makefile: remove reference to removed loader code

socz80: Add the SocZ80 platform README

socz80: Add the target

This code isn't yet complete. It's had a first pass conversion to the revised
kernel interfaces but the MMU logic has not yet been wired up to bank16 or
converted to the new format API.

execve: Correct cpm emulator loading

We moved to a real off_t and lseek behaviour but that didn't get propogated
into the CP/M emulator loading logic.

pcw8256: don't define un-needed UAREA bits

This avoids dragging in extra code we won't be using

Standalone: Add the standalone utilities

These are based off the UZI-WRS versions from Will Sowerbutts except for
chmem which is new code.

README.md: put the main notes here

README: remove notes leaving historical bits here

fuzix: Halloween Release

First cut of the development tree. Not terribly useful but hey its hackable
and boots.

Create README.md

Initial commit