That's my mega-commit you've all been waiting for.
The code for the shell share more routines with userspace apps than with kernel
units, because, well, its behavior is that of a userspace app, not a device
driver.
This created a weird situation with libraries and jump tables. Some routine
belonging to the `kernel/` directory felt weird there.
And then comes `apps/basic`, which will likely share even more code with the
shell. I was seeing myself creating huge jump tables to reuse code from the
shell. It didn't feel right.
Moreover, we'll probably want basic-like apps to optionnally replace the shell.
So here I am with this huge change in the project structure. I didn't test all
recipes on hardware yet, I will do later. I might have broken some...
But now, the structure feels better and the line between what belongs to
`kernel` and what belongs to `apps` feels clearer.
What used to be `tools/emul/user.h` was in fact specific to zasm, so I
moved it there.
To avoid name confusion, I renamed what used to be kernel.h and user.h
to kernel-bin.h and user-bin.h.
It was a bad idea to remove it. Now that I'm introducing the concept of
a per-app glue file, it becomes much easier to build emulated zasm as a
userspace app.
This shrinks the CFS size to 21k from nearly 64K. This will allow me to
kick the can down the road a bit with regards to supporting storage
seek/tell greater than 64K.
I'll get to it, but first, I want to assemble zasm with zasm!
On build, pack `parts/z80` into a CFS and embed it into the emulated
zasm executable as an fsdev. This will allow for the upcoming include
directive to have something to go to.
For now, this is useless except for inflating the emulated zasm's size.
With the help of the newly-introduced cfspack tool, we can mount a
filesystem in our emulated shell and play around. Read-only for now.
Unpacking incoming.
Virgil Dupras