Notes from the vault – 0x05 – RTX-51, an embedded scheduler

Part of group NOTES FROM THE VAULT. Theme from 1988, moved here 12Apr2022. Updated: 21Apr2022. IN WORK


This note in a wider context is about how I learned about the need for a task concept, and the necessary runtime system below it.

The thing that started this text was that I already had published a description of a small, “home written” real-time executive (rx or scheduler or runtime), the RTX-51 or RX51. I designed this in 1988. It was for the Intel MCS-51 8051- or 8052- type microcomputers. Up to 8 concurrent processes (or tasks) could be defined. A synchronising primitive consisting of a protected mailbox was also defined. These were part of a fire detection system from the company I worked for all my professional life: Autronica AS later Autronica Fire and Security.

My original entry chapter for this paper from 2011 is still: here. Don’t look this up yet: It references a technical paper about it: HTML and PDF (25 MB searchable). 34 years on I just now saw the spelling mistake. It’s of course “Real-time executive“:

Real-time excutive for 8051-type single-chip microcomputers (sic)
Author  : 0yvind Teig. 
Date    : 26.09.88 
Address : Autronica A/S
        : P.O.Box 3010, N 7001
        : Trondheim, Norway
        : Telephone: 47 7 918080

TODO: The source code in PL/M-51 will be added.

Getting there

1988: the world from my desk

Ten years to become readied for occam and transputer

In 1988 I had not yet heard about the transputer (by INMOS), and the accompanying occam language. Still it was no surprise that when these arrived it was me, at work, who asked my boss if I could attend a course in occam. This came to be in June 1989 and the location was at Inmos in Bristol, UK. But it taken some years to get to that point.

1978: MCS-48 and ASM (no tasks)

I started working for Autronica for real in 1976. In 1978 I coded our first microcontroller product containing an Intel MCS-48 type processor – the same type that was used in the first IBM PC’s keyboard. I literally “coded” in assembler, using a Prompt-48 box, where the hand compiled and relocated hex instructions had to be filled in, byte by byte. No task concept, the code was running its loop every some ms. It didn’t even use interrupt. But it surveilled the mains, and if it was lost then the radio link system was kept on batteries for some time (settable by pot-meters) and it then started a large emergency generator (max three trials) which then powered the radio link and charged the batteries. My code then shut down after some time when the mains came back. The voltage levels were also set by pot-meters with an output for a multimeter. No display. But it switched some really large high power contactors. All the described functionality in max 10 bytes less than one kilobytes of code. I never repeated that feat, and I never wanted to.

I recollect that this microcontroller only had 8 bits long conditional jumps. So, for the few jumps or calls across a 256 bytes page boundary I had to make a short landing table table at the end of each of them, for a JUMP or CALL instruction to get across the boundary. This was my first encounter on such boundary crossing “by hand”. There should be two more. A disclaimer is appropriate here. Much of this is re-collected from the brains of a soon to be 72 years old man (=me), and I was around 30-40 at the time. I have manuals here, the internet is there, and I do look at them – but I might still get some detail wrong.

1980ies: Intel and Texas and a dawning on tasking

My boss didn’t agree to purchase on an Intel Intellec blue box (the large one, with screen: the Intel MDS 80 – Microcomputer Development System running the ISIS operating system), before around 1980. We then had programmed in PL/M-51 and PL/M-80 for about a year. Around that time I was introduced to the Texas Instrument development system for the TMS9900 (or “990”) series microprocessors.  So we started to code in MPP Pascal (MicroProcessor Pascal) and I learned about tasks for the first time. The learning curve was steep. I think that this was based on ideas by Per Brinch Hansen, one of the great theoreticians of the time. And he had friends like Dijkstra and Hoare. All giants who influenced each other. The TI 990 system ran on the TX990 operating system, and also had a fantastic HW emulator called AMPL, controlled by its own control language. Yes, the learning curve was steep. All the stuff we had filled a small room with its own cooling system and air “absolute filter” for the huge disks. Also see [1].

So, when we in 1980 started with 8080 and PL/M-80 we bought a runtime system from NTH (Norges Tekniske Høgskole, later NTNU). It did have a task concept and it had semaphores and freepoolsemaphores I recollect. I think the latter was a semaphore pre-associated with some storage. Thank you, Trond Børsting, who designed that SW. It’s true, we never found any bugs in it, just as you had promised.

1983: MCS-48 and a simple scheduler in ASM

Fig.1 MCS-48 bank switching

Some times development isn’t linear. In 1983 we went back to coding in assembly code for one of the next products, but this time using an assembler sw. No hand generation of hex codes. But the processor family was the same: MCS-48. This was the fire detection system Autronica BS-30. We had now learned something about tasks. I therefore wrote a small runtime system, supporting a flavour of a task model. This product had one processor for the panel, and one for some extension boards. I remember that we had to set off a full year to fix and fix and rewrite the code for the extension board. The panel, with the task concept, had to make task code and interrupts in some kind of system – contrary to the solution in the extension board. Like interrupts, they have to push and pop all used registers, but which are actually used (now)? While the few error messages that did appear on the panel board appeared, the installations we had done were kept afloat until all was fine and we could update them all.

The MCS-48 8035 version could only address 4k bytes. But our program used almost 16 kB. This time there was no JUMP or CALL across, so I had to do the bank switching by hand. My second encounter. I used the extra three banks for subroutine calls only. I still have the diagram that tells how I did this with JMP across the banks and two extra pins set out to address more of the external EEPROM. I had to unsolder a ring in the ring binder to scan it. It’s in Norwegian but it looks rather international to me. Its heading is “Kryssing mellom 4k banker” = “Crossing between 4k banks”. The return also was through a JMP back again. CALL and RETR were used while not doing the crossing. This was one of the reasons why all my tasks ran on the primary 0-4k bank, and that there was no context switch while a subroutine was running. It was only to check the stack level to detect this. Since I have discovered that this isn’t far from the concurrency model of JavaScript – and I also used it in RTX-51, I’ll come back to this.

1982: More Texas and tasking in Pascal

Then over to MPP Pascal again, and lots of signal processing. We used the TMS99105 16 bits processor, and a double sided board I designed. I recollect that it also had a ground plane on every side, because we were talking about high speed. 24 MHz! We enjoyed MPP Pascal for all it was worth. This was for the Autronica GL-90 radar based fluid level measurement system. (In April 2022 I even found a GLL-90 board on eBay for about one thousand dollars! Yes, it’s from Kongsberg now, they bought that part of Autronica around year 2000.)

Then we did a MIP calculator (Mean Indicated Pressure) to calculate the delivered energy (in kW) and the condition of the rings on the pistons (plus plus), on very large diesel engines for ships. MPP Pascal again – and a TMS processor. This was Autronica NK-5.

1988: MCS-51 and a simple scheduler in PL/M-51

The next project I was set to work on was the loop controller BSU-50 for the Autronica BS-100 fire detection system. I think we started in 1986 of 87 – but we released it in 1988. Then a fix in 1990. These were PROM’ed MCS-51 microcontrollers. This is what this note started up with. We’ve come to the main theme.

Much about this is also described in Notes from the vault – 0x03 – Two early Autronica VLSI chips. These chips were used across both for BS-30 and BS-100.

More to come.



  1. 990 Computer Family Software by Texas Instruments, see – at the Computer History Museum (CHM, California) pages