OS9 For Teensy 3.6/3.5

[BrendaEM]

I had this truly odd idea. I don't know how to present it, other than....

There is the source-code for a real-time microkernal unix-like multi-tasking, multi-user operating system, with multiple text and terminal window support--with a scalable graphic primitive system, which could easily fit and run on a Teensy 3.5/3.6. It would likely run with even less RAM, at 128k.

The operating system is old and needs updating, but it has a simply beautiful and efficient design*, which could be adapted to the modern Teensies. It may be one of the most compact forms of Unix.

[Background: OS9 was often used on old VME bus computers, and was later adapted and sold add-on for Tandy's TRS-80 Color Computer 3, which was hindered at that time as to not cross-compete with their PC's.]

AFAIK, a branch of source code as been adapted and updated for Hitachi processors. It is still maintained, after all of these years. The code on the Nitros9 page states that it is under GPLv2. Of course, an additional encumbrance check should be done.

I think it would be interesting to trace the original design and layout of the operating system, perhaps rewriting it in C, so it would be more portable. Obviously, this is not a one-person job.

Because the OS9 was specifically targeted for a particular processor, perhaps, instead the original processors could be hardware abstracted with a few specific memory addresses. Additionally, the old target system had a limitation whereas the operating system needed to interactively map memory blocks into a restrictive 64k block; the Teensy would likely not have this limitation.

Please flip through the technical reference, below, to better study where exactly where I am nuts : )
There's things that have to be changed and updated, but the foundation of possibilities you may find interesting.

*Technical Reference Manual
http://www.colorcomputerarchive.com... Systems/OS-9 Technical Reference (Tandy).pdf

User Manual, and Shell.
http://www.nitros9.org/Getting_Started_With_NitrOS-9.pdf

Source Code
https://sourceforge.net/projects/nitros9/

 

[tonton81]

FreeRTOS 9.0?

 

[BrendaEM]

FreeRTOS 9.0?

I've seen FreeRTOS some time ago. I don't want to jump to conclusions, but, from wikipedia, "FreeRTOS can be thought of as a 'thread library' rather than an 'operating system', although command line interface and POSIX-like I/O abstraction add-ons are available."

It appears that FreeRTOS has several chip implementations and networking support to it's credit. It also has quite a granular control over it's tasking.

Though, it seems like OS9 was a more complete operating system, with commands, a shell, MOTD, and everything. The user had commandline process control, including forking, send to background, I/O redirection, ect.

One unusual feature was that it had separate data and execution directories, such as:
chx /dd/cmds
chd /dd

Where the former would be the OS's extra files, and the later would be a data directory, so less path'ing is nessesary.

There was an optional default device, to avoid programs from being hardcoded to a particular drive, such as:
chd /dd
dir

There was a clear hierarchical structure to it's managers, drivers, and descriptors, as shown in the beginning of the technical reference. All the I/O is done though the operating system. The code was largely position independent and reeenterent.

I mentioned OS9 because it easily ran on 128k of RAM. Someone could even fork a shell into the terminal /t1 into a Teensy 3.6, load and save files to the microsd, /dd which would be mounted like a /h0 disk.

 

[GremlinWrangler]

Well have actually used OS9, and while the memories of the hardware involved are not fond (Kept running post 2010) the OS certainly worked. Not sure why you would want to run it on a Teensy though given the actual ability to run useful programs would be severly constrained, and not aware of any 'killer ap' that a command line OS9 system would sensibly execute? It's big draw that I'm aware of was it's multi user/multi process support that allowed it to run big complex systems with lots of moving parts with some degree of grace. While making cluster of T3.6s is interesting suspect the work to take 'single booting OS9 instance' to 'network of OS9 instances supporting all of OS9s process sharing capabilities' would be immense.

Also not sure if 'motd' is a feature or a bug. Almost all the uses of it I've meet could be summed up as 'trolling'.

 

[BrendaEM]

Okay, perhaps the MOTD could be used for evil, but...

A project such as this would make a Teensy 3.x the smallest autonomous computer.

For me, I think that part of the killer-ap thing would include commands to manipulate data on MicroSD drive--not only being limited to save data, but purge it, move it, rename it, delete it when it's not being used. You wouldn't be limited to a few basic flat FAT32 file operations, but almost everything a Unix system has.

If the Teensy has the hardware to read and write to MicroSD, with OS support, suddenly, your program could be 32GB is size, depending on the SD class.
Or if the MicroSD were relegated to data storage a robot it could better save the data from the rooms it scans.

If you made a weather logging and reporting device, or a healthcare device, you log into it to check its functioning without taking if offline. We can do that today with Raspberries but I find myself drawn to the Teensy over the Pi because of its compact size, and greater hardware interface provisions.

Computational clusters seem like fun, but when I think cluster, I instead think of controlling a device such as a robot with a series of localized processors. An arm processor, a leg processor, etc. connected like these this small video of two connected Arduinos.
https://www.youtube.com/watch?v=iOran8zx1yQ

I again became interested in this after writing a serial Arduino command-line stepper-motor control program. With only 28k of ram, it has 42 commands. I should have a new version out next week that accepts arguments. With even the additional space of Nano, it could the same thing with multiple motors. This project has warped how I think about microcontrollers.
https://www.youtube.com/watch?v=Lm8oprDhAnQ

 

[BrendaEM]

Just a namespace thought experiment.
Arduino's IDE doesn't like F$

void setup()
{

}

void loop()
{

}

// Common Definitions
// true
// false

// System Service Request Code Definitions ------------------------------

void F$Link ()
// Link to Module
{
// RMB 1
}

void F$Load ()
// Load Module from File
{
// RMB 1
}

void F$UnLink ()
// Unlink Module
{
// RMB 1
}

void F$Fork ()
// Start New Process
{
// RMB 1
}

void F$Wait ()
// Wait for Child Process to Die
{
// RMB 1
}

void F$Chain()
// Chain Process to New Module
{
// RMB 1
}

void F$Exit ()
// Terminate Process
{
// RMB 1
}

void F$Mem()
// Set Memory Size
{
// RMB 1
}

void F$Send ()
// Send Signal to Process
{
// RMB 1
}

void F$Icpt ()
// Set Signal Intercept
{
// RMB 1
}

void F$Sleep()
// Suspend Process
{
// RMB 1
}

void F$SSpd ()
// Suspend Process
{
// RMB 1
}

void F$ID ()
// Return Process ID
{
// RMB 1
}

void F$SPrior ()
// Set Process Priority
{
// RMB 1
}

void F$SSWI ()
// Set Software Interrupt
{
// RMB 1
}

void F$PErr ()
// Print Error
{
// RMB 1
}

void F$PrsNam ()
// Parse Pathlist Name
{
// RMB 1
}

void F$CmpNam ()
// Compare Two Names
{
// RMB 1
}

void F$SchBit ()
// Search Bit Map
{
// RMB 1
}

void F$AllBit ()
// Allocate in Bit Map
{
// RMB 1
}

void F$DelBit ()
// Deallocate in Bit Map
{
// RMB 1
}

void F$Time ()
// Get Current Time
{
// RMB 1
}

void F$STime()
// Set Current Time
{
// RMB 1
}

void F$CRC()
// Generate CRC
{
// RMB 1
}

// NitrOS-9 Level 2 system calls ------------------------------

void F$GPrDsc ()
// Get Process Descriptor copy
{
// RMB 1
}

void F$GBlkMp ()
// Get System Block Map copy
{
// RMB 1
}

void F$GModDr ()
// Get Module Directory
{
// RMB 1
}

void F$CpyMem ()
// Copy External Memory
{
// RMB 1
}

void F$SUser()
/ Set User ID number
{
// RMB 1
}

void F$UnLoad ()
// Unlink Module by name
{
// RMB 1
}

void F$Alarm()
// Color Computer 3 Alarm Call
{
// RMB 1
}

void F$NMLink ()
// Color Computer 3 Non-Mapping Link
{
// RMB 1
}

void F$NMLoad()
// Color Computer 3 Non-Mapping Load
{
// RMB 1
}

void F$Debug()
// Drop the system into the debugger
{
// RMB 1
}

void F$TPS ()
// Return System's Ticks Per Second
{
// RMB 1
}

void F$TimAlm ()
// CoCo individual process alarm call
{
// RMB 1
}

// NitrOS-9 common system calls ------------------------------

void F$VIRQ ()
// Install/Delete Virtual IRQ
{
// RMB 1
}

void F$SRqMem ()
// System Memory Request
{
// RMB 1
}

void F$SRtMem ()
// System Memory Return
{
// RMB 1
}

void F$IRQ()
// Enter IRQ Polling Table
{
// RMB 1
}

void F$IOQu ()
// Enter I/O Queue
{
// RMB 1
}

void F$AProc()
// Enter Active Process Queue
{
// RMB 1
}

void F$NProc()
// Start Next Process
{
// RMB 1
}

void F$VModul ()
// Validate Module
{
// RMB 1
}

void F$Find64 ()
// Find Process/Path Descriptor
{
// RMB 1
}

void F$All64()
// Allocate Process/Path Descriptor
{
// RMB 1
}

void F$Ret64()
// Return Process/Path Descriptor
{
// RMB 1
}

void F$SSvc ()
// Service Request Table Initialization
{
// RMB 1
}

void F$IODel()
// Delete I/O Module
{
// RMB 1
}

// Level II System calls ------------------------------

void F$SLink()
// System Link
{
// RMB 1
}

void F$Boot ()
// Bootstrap System
{
// RMB 1
}

void F$BtMem()
// Bootstrap Memory Request
{
// RMB 1
}

void F$GProcP ()
// Get Process ptr
{
// RMB 1
}

void F$Move ()
// Move Data (low bound first)
{
// RMB 1
}

void F$AllRAM ()
// Allocate RAM blocks
{
// RMB 1
}

void F$AllImg ()
// Allocate Image RAM blocks
{
// RMB 1
}

void F$DelImg ()
// Deallocate Image RAM blocks
{ // RMB 1

}

void F$SetImg ()
// Set Process DAT Image
{ // RMB 1

}

void F$FreeLB ()
// Get Free Low Block
{ // RMB 1

}
void F$FreeHB ()
// Get Free High Block
{
// RMB 1
}

void F$AllTsk ()
// Allocate Process Task number
{
// RMB 1
}

void F$DelTsk ()
// Deallocate Process Task number
{
// RMB 1
}
void F$SetTsk ()
// Set Process Task DAT registers
{
// RMB 1
}

void F$ResTsk ()
// Reserve Task number
{
// RMB 1
}

void F$RelTsk ()
// Release Task number
{
// RMB 1
}

void F$DATLog ()
// Convert DAT Block/Offset to Logical
{
// RMB 1
}

void F$DATTmp ()
// Make temporary DAT image (Obsolete)
{
// RMB 1
}

void F$LDAXY()
// Load A [X,[Y]]
{
// RMB 1
}

void F$LDAXYP ()
// Load A [X+,[Y]]
{
// RMB 1
}

void F$LDDDXY ()
// Load D [D+X,[Y]]
{
// RMB 1
}

void F$LDABX()
// Load A from 0,X in task B
{
// RMB 1
}

void F$STABX()
// Store A at 0,X in task B
{
// RMB 1
}

void F$AllPrc ()
// Allocate Process Descriptor
{
// RMB 1
}

void F$DelPrc ()
// Deallocate Process Descriptor
{
// RMB 1
}

void F$ELink()
// Link using Module Directory Entry
{
// RMB 1
}

void F$FModul ()
// Find Module Directory Entry
{
// RMB 1
}

void F$MapBlk ()
// Map Specific Block
{
// RMB 1
}

void F$ClrBlk ()
// Clear Specific Block
{
// RMB 1
}

void F$DelRAM ()
// Deallocate RAM blocks
{
// RMB 1
}

void F$GCMDir ()
// Pack module directory
{
// RMB 1
}

void F$AlHRAM ()
// Allocate HIGH RAM Blocks
{
// RMB 1
}

// Alan DeKok additions ------------------------------

void F$ReBoot ()
// Reboot machine (reload OS9Boot) or drop to RSDOS
{
// RMB 1
}

void F$CRCMod ()
{ // RMB 1 // CRC mode, toggle or report current status

}
void F$XTime()
{ // RMB 1 // Get Extended time packet from RTC (fractions of second)

}
void F$VBlock ()
// Verify modules in a block of memory, add to module directory
{
// RMB 1
}

// Numbers $70 through $7F are reserved for user definitions

void F$RegDmp ()
// Ron Lammardo's debugging register dump
{
// RMB 1
}

void F$NVRAM ()
// Non Volatile RAM (RTC battery backed static) read / write
{
// RMB 1
}

 

[bryanc806]

+1 on OS9. Still my favorite OS.

 

[jwatte]

A project such as this would make a Teensy 3.x the smallest autonomous computer.

Of course not. People have put VAXen on chips before, and there are computers in watches that are autonomous.
It's interesting to note that the Teensy 3.5/3.6 have more RAM and ROM than the initial UNIX machines where TCP/IP was developed (like the PDP/11.)
You could run vim or emacs or shell or whatever on those. (Well, the older, smaller versions of those tools.)

But why would you want to, other than as a curiosity?
I think it's much better to use the available space of modern computers to make for a nice development environment, and then use the space on the microcontrollers so I don't have to worry so much about every single byte in whatever program I end up wanting to run on a microcontroller.
That, and the speed is nice, too

 

[delamination]

I had written a 6809 virtual machine on an ATMEGA128, and started booting NitrOS-9. It choked pretty quickly during initialization with only a few K of ram to work with, but it was exciting all the same.

I just discovered the ARM Cortex microcontrollers, and was considering what a port would take.