Multi-tasking OS in the '816 ...

[drogon]

I've been somewhat diverted from my Ruby816 project by things like moving house and doing some stuff for the Cerberus 2080 project (more on that here, soon!) but I thought I'd put up a sneak peek at my Ruby816 multi-tasking OS in operation.

The demo calculates Pi to 100 places in just over 6 seconds then I run up 12 clocks on the display and run the Pi calculation again - which then takes just over 8 seconds, so you don't get something for nothing here...

Note that the display is just a single graphical plane, so when it scrolls the clocks scroll and a new one gets drawn - it's a little confusing but I clear the screen once they're all running then run the Pi calculation again.

Video here: https://youtu.be/ZL1VI8ezgYc

Enjoy,

-Gordon

[MichaelM]

Gordon:

Very impressive. I didn't check the pi calculation, however.

[BigEd]

Very nice! Pi checks out - to the last displayed digit too, which is always a risky digit. (And then, should one round or truncate? In this case, truncate, and I think that feels right to me too.)

Remind me - is this cooperative or preemptive multitasking?

[drogon]

A quick follow-up in reply to a question asked off-line ...

The display is "RubyTerm" which is a "smart" terminal program that runs on my Linux desktop PC. The communication from that to the Ruby board is a 115200 baud serial line. The software on the Ruby sends standard Acorn MOS VDU commands down the serial line, so ASCII is just as it is, but to draw a line, you send the plot command code, then the line code then endpoints as 4 byes (2 for X, 2 for Y), so 6 bytes. A circle is similarly draw with the plot command code, circle code then the circle centre and radius.

So the '816 isn't dealing with the graphics directly but they're off-loaded to another system.

This is inspired by both the BBC Micro (c1981), which with a 2nd processor connected to a 2Mhz bus would have the original system as the host/IO processor and the 2nd processor doing the important stuff. Also the BLIT (c1982): http://doc.cat-v.org/bell_labs/blit/ which was, as far as I can tell, the forerunner to the X windowing system.

My plans are to ultimately have something like the BLIT running as an application on my desktop, or even a stand alone device using something like a Pi and high speed serial or even parallel line (6522) back to the Ruby board. This was all reassuringly expensive back then - almost pocket money now...

-Gordon

[drogon]

BigEd wrote:

Very nice! Pi checks out - to the last displayed digit too, which is always a risky digit. (And then, should one round or truncate? In this case, truncate, and I think that feels right to me too.)

Remind me - is this cooperative or preemptive multitasking?

It's preemptive.

So if a program sits in an infinite loop then it will all go slow, but other tasks will run.

Internally it works a bit like the transputer did which handled it all in it's microcode engine. Here the "microcode engine" is the Cintcode VM environment which takes the timer interrupt and switches tasks at the required time - currently in a strict round robin manner but I'm looking at the possibility of a concept of high priority for the one interactive task.

Those clocks work by simply sleeping for a period of time (semi-random to deliberately make sure the second hands don't sync. from 900 to 1100 ms) I'll "improve" it when I get a hardware RTC ... You don't have to do anything special in your code but being "nice" by calling delay() when the task has nothing else to do is... well, nice.

This does mean that if you run something outside the VM environment (say a large subroutine written entirely in '816 ASM), then the whole system will stall until that routine returns. Since I don't plan to write much more '816 ASM this is something I can live with.

-Gordon

[MichaelM]

Again Gordon, very nice. Certainly appreciate the use of the VM to provide an environment similar to that used by the Inmos Transputer, which to this day remains one of my all time favorites. Too bad I don't have the equipment to pull out my B004 transputer modules and use them 27+ years on since I last used them.

[drogon]

MichaelM wrote:

Again Gordon, very nice. Certainly appreciate the use of the VM to provide an environment similar to that used by the Inmos Transputer, which to this day remains one of my all time favorites. Too bad I don't have the equipment to pull out my B004 transputer modules and use them 27+ years on since I last used them.

This project may interest you:

https://retrocomputingforum.com/t/raspb ... lator/2068

code, etc. here:

https://github.com/blackjetrock/picoputer

I have working channels between processes on my system and extending these to a hardware link is relatively easy when I get the hardware...

Cheers,

-Gordon

[MichaelM]

Thanks for the links. It's truly amazing how some good ideas never really die, but are resurrected over and over again.