Page 1 of 2

Unixoid VIC

Posted: Thu Mar 14, 2024 6:02 am
by pixel
Talking UltiMem: For the latest revision of INGLE there's a new kernel design. cc65's code generation unfortunately does not allow to use C as a macro assembler without taking all the fun away. Macros to the rescue and the fun is back. Key ideas:

No assembly syscall table. Device #31 handles its dozen function calls. Example in pseudo-code:

Code: Select all

open (31,31, 0, "PF"); // Fork child process.
chkin (31);
pid = chrin ();
if (pid == 0) {
	// Do childish things.
}
Not even BASIC coders are left behind with that kind of API. The child process is a copy of the parent (sharing open files and allocated extended memory) ending up its very own address space. U no touch IO23 area.

Loadable drivers. Processes may assign a vector table to a device and become a driver (leaving BASIC coders behind), receiving LFNs translated to global LFNs that never collide with other processes as well as receiving copies of the file names to cross address spaces. Few extra syscalls help to allocate and release cozy homes (IO area pages) for interrupt handlers.

That's pretty much the last next VIC thing from my side, fitting nicely on two double-printed sheets of paper and being a thing of beauty.

Re: Unixoid VIC

Posted: Thu Mar 14, 2024 8:36 am
by pixel
Should you care about premature source code, it's to be found here: https://github.com/SvenMichaelKlose/ing ... x/main.asm

It even has a vanity comment at the top. I'm secretly expecting this one day:
2024-03-13 tunix in vicvi.png

Re: Unixoid VIC

Posted: Thu Mar 14, 2024 12:00 pm
by akator
This looks really interesting.

Re: Unixoid VIC

Posted: Thu Mar 14, 2024 8:03 pm
by pixel
It's been in the works for a while. :roll: So here's the plan if no deadline gets in the way (the literal one).

Code: Select all

# Planned system calls

Downcase letters denote byte values.

## General

* "SX" kill all processes and drivers and return to plain BASIC.
* "SN" stops multi-tasking.
* "SM" resumes multi-tasking.

## Processes

* "P" returns a list of process IDs, together with flags.
  (Running or sleeping,)
* "PI" returns ID of the current process.
* "PF" creates a copy of the current process, sharing all its open
  resources and returns its ID.  Returns 0 to the child.
* "PEpathname" replace current process by executable.
* "PXc" exits current process with a code (byte).
* "PWp" waits for a process to exit and returns its exit code.
* "PKp" kills a process (with exit code 255).
* "PSp" stops a process.
* "PRp" resumes a process.

Probably required at some point, at least to keep out background
processes as long as something else is running:
* "PPpl" Set priority level of process (0: highest, 255: lowest)

## Drivers

* "D" returns a list of devices and drivers.
* "DRdvv" register vectors for a particular device.
  Global to all processes.  Two additional vectors allow block-wise
  reads and writes.
* "DA" allocates per-process IO page (for low-level driver code).
* "DG" allocates global IO page (for interrupts).
* "DCx" commits global IO page to other process as they have them on
  different banks (per-process IO23 area).
* "DFx" frees IO page.

## Extended memory

* "MA" allocates a bank.
* "MFx" frees a bank.
Looks pretty portable across the 8-bit range of Commodore home computers, given the right memory expansion, doesn't it?
Test Driven Development is in order from here on. Some driver work is in ../ultifs/ and that's in C. Good night!

Re: Unixoid VIC

Posted: Fri Mar 15, 2024 6:36 pm
by pixel
This is so simple, one could actually do an entertaining 6502 programming book about it. (Am feeling elated.) TUNIX development is done tests first. The rest is only sketched code to get the big picture which is fun really with a brain-to-computer interface like VI (keyboard, not mouse).

Test-driven development might look like double work but it's actually half. Tests become the documentation and as long as they pass one can head back home in peace.

tunix-boot.png

It's testing the very straight-forward linked list with byte "pointers" (index into the array containing the list). It's super-fast, eating up only three instructions. And I'm 100% sure that basic resource allocation works.

Re: Unixoid VIC

Posted: Mon Mar 18, 2024 6:52 am
by pixel
Yeah! This should stay small.

The egg-laying wool-milk-pig with power outlet nose and peeing gasoline here is the deque (doubly-linked list) on a (256 byte page) with byte pointers to previous/next elements. Multiple lists can share a page and removal/insertion ist really fast and happens at constant speed. Ideal for something like a pool of processes that can be either be on a running, sleeping or zombie (waiting for its parent to exit) list. Other things just need a singly-linked list or plain array. Some tricks applied and some unnerving run-time assertions don't have to be.
Includes a speed code generator for memory copies.

Anyone with a neat idea on how to switch from one BASIC console to another comfortably? C=[+SHIFT]+F-key?

Re: Unixoid VIC

Posted: Thu Mar 21, 2024 7:46 pm
by pixel
%p A version written in C would be nice because TDD in assembly isn't…

Got a little bit tangled up with the banking but that also went well. IO23 is always there (each process has its own copy) to catch KERNAL I/O calls and the rest is in BLK1. That's enough trouble if apps can use that too.

Am wondering how LOAD and SAVE could be implemented by drivers but there won't be any other driver first but one to switch BASIC screens. If you want to run your web server written in BASIC in the background, you'll have to move it up to $2000. Programs using the regular memory from $1000-$2000 just won't multi-task to another program also using that area unless they trigger a switch themselves or the console wants to. Programs that don't use the screen area can still run in the background.

In the end this'll run on a C64/C128 with REU as well. AFAIK no other Commodore 8-bit computers but these and the VIC can handle this kind of thing as the right memory expansions don't exist, or do they? Good night!

Re: Unixoid VIC

Posted: Fri Mar 22, 2024 8:49 am
by pixel
And there it is: the fork system call:

Code: Select all

    lda #31
    tax
    jsr SETLFN
    lda #2
    ldx #<cmd_fork
    ldy #>cmd_fork
    jsr SETNAM
    jsr OPEN
    …
cmd_fork: .byte "PF"
Enough for today…

Re: Unixoid VIC

Posted: Fri Mar 22, 2024 10:04 am
by pixel
And suddenly CLALL makes sense. There are no standard logical file numbers for console I/O. CLALL virtually does the necessary CHKIN/CKOUT as if there were local file numbers for keyboard and screen. That bit of explanation is missing in all docs I've seen so far.
Not a show stopper.

Re: Unixoid VIC

Posted: Sat Mar 23, 2024 3:20 am
by Mike
That is actually the job of CLRCHN. CLALL in addition only rudely purges the table of open files (by setting the number of open files to 0) and there is only one single instance in ROM where a JSR $FFE7 is used - by the BASIC interpreter to ensure there are no (pre-)allocated logical file numbers after program edits, CLR, RUN or NEW. Unfortunately, drives do not get notified by this action, which easily results in splat files. Here's how CLALL should have been implemented (see also here):

Code: Select all

.CLALL
 JSR $FFCC     ; CLRCHN
.CLALL_00
 LDX $98
 BEQ CLALL_01
 LDA $0258,X
 JSR $FFC3     ; CLOSE
 BCC CLALL_00
.CLALL_01
 RTS

Re: Unixoid VIC

Posted: Sat Mar 23, 2024 4:23 am
by pixel
Mike wrote: Sat Mar 23, 2024 3:20 am That is actually the job of CLRCHN.
Just the regular dumbing down before enlightenment hits. You're right. Thanks! The idea of just dropping the channels wasn't too appealing, so TUNIX closes every file with CLALL. I'm thinking maybe it's a good idea if processes get (and thus inherit) their own device-to-driver assignments but I don't know why really. Ommmh…

I was also wrong with the C64-REU – it's DMA-driven. :(

EDIT: Fork! I ran out of IO23 pages for drivers.
tunix-cool.png
'cool-retro-terminal' https://github.com/Swordfish90/cool-retro-term – it takes a big boy to use it.

Re: Unixoid VIC

Posted: Sun Mar 24, 2024 4:01 pm
by pixel
tunix-zombie.png
Now for chasing zombies… how did printing decimals work again?

In the operating system's choreography, a process doesn't simply terminate and vanish. Instead, it lingers due to a critical relationship with its creator: the parent process. The parent may opt to inspect the exit code of its offspring at some future moment, necessitating a mechanism to preserve this information without squandering system resources.

Upon completion, while the process relinquishes its resources to avoid unnecessary consumption, it remains listed in the system with its exit code intact. This state of limbo ensures that the system can reclaim these resources efficiently without losing crucial information. The process is finally purged from the list either when the parent retrieves its exit code or if the parent itself exits. This interim state, known as a 'zombie' process, represents a minimal footprint placeholder, ensuring that the system's bookkeeping remains accurate and resource-efficient.

Waking up parents (or other processes that wait for some reason) is another mechanism that needs to be designed for heavy use.

Re: Unixoid VIC

Posted: Sun Mar 24, 2024 4:06 pm
by Mike
pixel wrote:Now for chasing zombies… how did printing decimals work again?
See the thread "Printing (unsigned) 16-bit numbers in Assembly, how?". :wink:

Re: Unixoid VIC

Posted: Sun Mar 24, 2024 5:26 pm
by pixel
Mike wrote: Sun Mar 24, 2024 4:06 pm See the thread "Printing (unsigned) 16-bit numbers in Assembly, how?". :wink:
8) Thanks!
tnuix-with-numbers.png
Oh impatience...

This will take assigning LFNs to devices to make pipes. And a FIFO driver for inter-process communication perhaps. But sure as hell a RAM disk because sharing a c15xx via the regular KERNAL isn't my piece of cake.

Re: Unixoid VIC

Posted: Mon Mar 25, 2024 12:22 pm
by pixel
First boot. Meaning userland C coding. :mrgreen:
tunix-firstboot.png