6502.org

I haven't studied OS9, but I do know about it. I have a CoCo2 in my closet upstairs.

My CoCo2 is in my living room in a drawer of the TV console. I have CoCoSDC floppy emulator with NitrOS-9 on it. It's an interesting system, but to fully experience NitrOS-9 you need a CoCo3 with extended memory.

However, a 65816 can address far more memory than a CoCo3 with a GIME chip. That's why I think it would be awesome for a Unix like OS project.

A nice feature of the CoCo2 ecosystem is that the modem and RS-232 cartridges both contain the same terminal program in ROM at the same address, making them ready to use out of the box as well as interchangeable. By contrast, the same cartridges for the C-64 plugged into the user port instead of the expansion port.

I had the good luck to take Doug Comer's final XINU class. One of the highlights of my time in college. It was a simple, non memory protected system that implemented some basic OS concepts without overly being complex.

One thing I'll suggest about your task switching code is that you don't have to copy all 256 bytes of the hardware stack during a task switch. If you just transfer the stack pointer into Y and copy from $100,Y up to $1FF you will save a great deal of needless data moving.
I wrote a preemptive thread scheduler for my 6502 Java VM but went with a much simpler cooperative fiber scheduler for PLASMA. Both have their places but I found the 6502 was better suited for a single thread/task. The 65816 does seem to be a better match to more sophisticated OS concepts.

Jonathan Halliday has a preemptive multitasking GUI OS for Atari 6502 computers.  I talked to him years ago and asked about this very thing, and IIRC, he said he divides the stack area up into a few portions, one for each task, and then when he switches tasks, he only copies out the one that ran longest ago to make room for the new one; and if you only have a few tasks running, you may not need any copying at all.  Look at the page, and you'll find it very impressive.

Gosh, you guys 'n gals, since I came back to the forum (a number of years ago now), I have sooo many times seen subjects that attracted my attention, firstly said something to myself along the lines of "I'm too old to go down that hole...", and finally taken the plunge :

• CPLD logic design and programming (with home-built HW)

• Choosing and adapting a new HL language (PLASMA), and finally writing a personal VM to use it

• Writing my own WDC 65C02 disassembler (twice!)

• Trying-out and adopting novel HW (the RP6502 'pico' computer using a Pi Pico(2) to provide a monitor and file I/O)

• Writing my own self-hosting WDC 65C02 assembler in PLASMA

• Currently consolidating documents and ideas to create my own text-editor

• Starting to play with the 65C816 using the same 'pico' architecture (WIP)

• ... and now the idea of a multi-tasking environment has started it's magnetic attraction...

A new folder under '6502' on my PC : "multi_task" This hobby already "keeps me off the streets" - but soon I think my neighbors will have forgotten who I am !
Thanks, for all of the above - and more, to Drogon, BDD, 8-Bit, resman, Garth and the many other contributors who keep my few remaining brain cells running at 110% !

"Dividing the stack space" is also the technique Andrè used for GeckOS, I believe. I have improved the scheduler a bit this week, but it does still copy the whole stack page. I think I put a comment in there that a future improvement should be to use the stack pointer to copy just the bytes actually used by the process.

This thread is giving me ideas and making me waste time.

First, I skimmed the Fuzix code and they have 6502 and 65816 ports, but it is for cc65. Last I looked at its code output it wasn't the best, especially for the 65816.

Second, I started reading the NitrOS-9 source. It's big and interesting but written in 6809 assembly language. Probably the most useful part of it is the kernel definition, data structures, and interface files.

Must go back to my main project...

In fact whether the stack is copied or divided is a build option.

If the stack is copied, it still is divided into kernel space stack an active task stack. The active task's stack is basically copied from stack pointer to upper bound, so only the used stack is copied.

That works well as usually only one task is active, except if you use pipes or background processing.

André

Here is a big update! I was on the road for about the last 10 days and didn't have access to my hardware. I think the most exciting thing is that, when I got homem, all the code I wrote while travelling assembled immediately, and when I put it on a ROM, all the stuff that was already working continue to work! YAY I didn't break anything! The code is not fully tested yet, and I have tracked down a few bugs already. But what's working right now is:

The RTC (NMIs are happening, system ticks is updating)
The scheduler (processes successfully switch back and forth)
The SLEEP system call (Calling SLEEP with 1 tick works as a sort of cooperative YIELD call)
The CREATE system call (new processes)
The VFS interface to the I/O (currently, only the WRITE call has been tested)
The GETMEM system call (memory allocator). FREEMEM hasn't been tested yet.

The code file is a little disorganized - I was adding syscalls to the bottom, and there are two or three separate places with lots of self-documentation. I should reorganize it eventually, but for now, / (or cmd+F) is my friend.

After a bit of testing, I rewrote the scheduler again. My "pseudopriority" worked great, and just how I thought it would - because I only thought about how it would work with 1, 2, or 3 processes! Of course, with a larger number of processes, it will always select the highest numbered ready PID that didn't just run, which means it will flip back and forth between those two processes and starve everyone else! I went back to simple round robin, but with a zero check so that the NULL process doesn't waste time every go-round.

Traditional UNIX has always used round-robin, but also looks at whether the waiting processes on the run queue are compute-bound or I/O bound, with the latter getting run preference.  The theory behind that is I/O is inherently expensive and limited to a single process at any given time.  Therefore an I/O-bound process should be the focus of MPU utilization to avoid slowing overall system performance to the speed of the I/O hardware.

Coming up with an efficient and fair scheduling algorithm is no simple matter and will naturally involve a variety of tradeoffs.  Ultimately, the goal is to achieve maximum MPU utilization, which means avoiding spin loops.  With a register-poor, eight-bit MPU that is saddled with blocking I/O, that goal may be elusive.

Slightly related - the scheduler in my OS (written in BCPL, runs on '816, ARM32, RV32I) has a strict round robin way of working too. Processes can voluntarily give up their slot if waiting on something (like coroutines), or are forced to give it up when waiting on a blocked channel or a timer or they've just exceeded their time slot. (100mS by default)

Each task has a fixed timeslot and I could start to fiddle with all that to give some tasks a higher or lower timeslot value but I've not needed to do that yet. Maybe in the future I'll write a "nice" command...

-Gordon

That sounds vaguely like the original windows 16 message handler, Gordon, except for the ability to force a switch if a task decided to hog the processor.

Neil

The DOS-based versions of Windows were text book examples of why the term “cooperative multitasking” is an oxymoron.  I can’t count how many times I cursed out Microsoft when one program hogged the machine and wouldn’t let go.