Denial

This is fun, especially with the latest VICE monitor update (build from source): (I know your eyes are just having sex.)

Instead of doing waiting lists for zombies implementing signals isn't much more complicated and the signal mechanism is a lot more versatile too. This needs some more rounds in the monitor anyhow.

I have added some lines of C code in a separate file so one can see what I mean by saying "simple". That's why C was invented. What is also kinda simple is the banking – simple on paper. Some seemingly pointless doodling fixes a lot in advance.

Anyway, this is getting addictive. Am trying to fix the banking in a way that the kernel and drivers can use regular system calls as well. Looking good but I am glad to announce that I'll be pretty busy with regular work for a cool company again very soon. This was the quick 90% system 1 code. The remaining 10% system 2 will better be implemented in healthy doses.

Just in case you're wondering: this will bring you multiple instances of BASIC with full memory and drivers in their own "address space" and if you want you can write TUNIX apps with whatever programming language you're into and they'll amaze you with real multi-tasking. Nothing compared to any other attempt in that direction thanks to Jim Brain's UltiMem. I hope one can buy that again some time in the future.

Syscalls (via OPEN) can be nested. That's great news. Task switches work in BASIC but there's still no working LOAD but many solutions to the problem. The required boot loader won't kill any existing boot menus. As that's extra work I started the ROM in C (copies itself to RAM on startup) the Unix way: looking shite but doing it right. Lots of old code can be reused.
One can switch between BASIC instances using sequences of OPEN but that's a hassle. Am very unsure what the virtual console should look like. Will take VIC user manuals for a walk.

It LOADs but OPEN brings random BASIC errors out of nowhere (STATUS = 0). That's an inconvenience for BASIC coders.

Time for the console switcher unless you want to do switches like this:

Now for messing this up with an interrupt handler..

The virtual console is a thing of surprising simplicity but the kernel isn't ready for it as the tests aren't thorough enough. That's why TUNIX is now a C program which suddenly decides to become a kernel.

Jim Brain said that he'd bring on another stash of UltiMems, but to make them affordable about 100 orders should be lining up.

(VIC with switcheritis.)

Still not stable enough for the console switcher.

Happily crashing along while progressing. Found some pleasure in writing docs and am developing a habit of having BLOG files in projects instead of spoiling boards.

Found a book about "systems programming" last night, documenting some University lecture. Didn't know its there. But: there is no such thing like coincidence. Spending a Sunday on reading books instead of error messages is highly recommendable anyhow.

About to crash when out of memory with 16 processes (full address space allocated for all). It should complain and exit gracefully. Doesn't pass mixed stress tests either, so there must be an issue with memory allocation.
Up to 32 processes could get squeezed in before extended memory has to run out.
Still not ready for the console switcher.

I wanna grab TUNIX, Small-C/Bielefeld-DB and INGLE and pile it up to a BSD-style distribution. Somehow the name "INGLE" is getting to me like a missing shot of Vodka deep down where it's needed and stays missing.

How about "HilariOS"?

If oscar64 turns out to give reasonable results, the assembly version of the kernel will become history within the very same heartbeat.

Project moved to https://github.com/SvenMichaelKlose/tunix.

EOT