Unixoid VIC

[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.

[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:

[akator]

This looks really interesting.

[pixel]

It's been in the works for a while. 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!

[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.

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.

[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?

[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!

[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…

[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.

[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

[pixel]

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.

'cool-retro-terminal' https://github.com/Swordfish90/cool-retro-term – it takes a big boy to use it.

[pixel]

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.

[Mike]

Now for chasing zombies… how did printing decimals work again?

See the thread "Printing (unsigned) 16-bit numbers in Assembly, how?".

[pixel]

See the thread "Printing (unsigned) 16-bit numbers in Assembly, how?".

Thanks!

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.

[pixel]

First boot. Meaning userland C coding.