How about Moon-nux for the Owl 75, with free computer time 2:30 to 6:30 am... Note No PIZZA or COLA after 3:00 AM.

The real news is I filled up the order code, to get 4 extra scratch registers, or base registers like a frame or i/o pointers.
They don't do to much, but they were a easy upgrade. This is about as far as I can go with my design and not need
hardware changes.
Ben
PS. Updated the hardware for BCC/BSR but not the software.

Minix seems like quite a heavy OS for a retro 16-bit computer. I recall Bill Buzbee spent quite a bit of effort getting it to run on Magic-1.

It wouldn't take much to make that compiler run bare metal. It kind of depends what you are using for storage though. For solid state storage it's super easy. When I was bootstrapping a z80 my file allocation table was pencil and paper. On power up the CPU is halted and a hex based keypad programmer / bus monitor was used to program a JMP <to some address in ROM> instruction into RAM. No USART or keyboard, output was to one of those little Hitachi LCDs.

The rest of the BIOS will be routines for terminal IO.

Minux was a mini-unix, so it is kinda bigger than other os's. I also was looking at ELKS as well. This was from a time when
K&R was the C standard, so porting seemed reasonable,and still 16 bit code. Floppy disks was still the norm so developing
software was left to some big machine with large drives and fast printers. Sadly by the time Open Source came around you needed
24 bit addressing for any kind of code, and that is too big for what I consider a Small text based computer.

My bios will also have floating point in rom, but I need to get a basic shell written. Most of the stuff is now tweaking the system
to see what works best. IRQ service needs to be revised and other logic needs to be cleaned up. By then I will have version 1
implemented, with the newer ideas left version 2 and perhaps a simple mmu.

Ouch, ELKS requires 512k. All the modern minimal Unix OSs seem to require quite a bit of RAM, even FUZIX was something like 128k.

Would Unix V6 be an option? 1975, open source and 16-bit. It did use an MMU. But porting the kernel is much easier because of the J. Lions book "A commentary on the sixth edition Unix operating system".

They all use virtual memory, and swap to disk. Disk is slow because of all the swapping, so they make a ram disk from what little
memory they have. Since this is time sharing, you need to have the fastest machine,memory and high RPM disks,
To pay for all this, you needed to share the costs, thus more users. But with more users you need more virtual memory so you add a token 8Kb more RAM and the computer gets bigger and slower and slower over time.
Had UNIX been really a been a un-multiplexed operating system, I might give it more thought.

I went to 18 bits, so could have ample addressing space of 64kb or more for a single process, and several addressing modes for bytes and words in a single instruction word. Indexing or word immediate requires a second word of course.
AT&T do have a UNIX with no MMU, but I can't remember what was called. I think FUZIX is based on that.
Small C is the best I can do for now, with the file system in ROM. Going is slow because I keep changing things around,
The file system is slow to write because it is in assembler.

File systems are roughed out, and most of the code is in rom. I have hooks for subdirectories, but for now it is a single root
directory of 64 files. A 8.2 file name is used, and a time stamp is planned for when I get RTC. Time is just AM,PM and a date 1970+,day,month. I get about 1.5 Mb per disk, not great but better than 8 inch floppies.
Fixed a logic bug with the shift encoding.

Revised and simplified the order code,now that I have the general encoding done. Needed to wire in the last *two* inputs to the Control CPLD frpm the bus. Now I have most of the features I wanted - now on version --- owl 1973. Most of the problems were
updating the CPLD's from the wrong subdirectory, and not having the serial cable connected after changing the cards.
The major change was encoding of register and index modes, and now having set of 15 GP registers plus the PC.
Now that it all saved to the bit bucket, I am calling it a night.

15 is a lot for 1973. 74'189 chips? I am beginning to appreciate that only a few registers can get a lot done if coding in assembler.

The original concept was 3 bit alu slice with 74x181 and 2 74x170 4x4 ram and other hardware on a pcb,
with the fact that TTL logic was so cheap (compared to memory) you could waste a few chips.
6 -3 bit slices would make a 18 bit alu. You had 4 registers A,B,X,S and PC. Two addressing modes,
# and indexed, a 6800 style cpu.
This was before the cheap PCB's , so I decided to use a FPGA card to emulate the design.
The FPGA card never compiled the logic correctly, so would have timing issues between code changes.
It may work, it ,may not work.
Some time later I decided to use SMALL C as the compiler, and that required a design change for a real
stack pointer.
Now with cheap PCB's, I dropped all the FPGA stuff. and moved to the more stable CPLD's.
Here I am using 74X219's a non inverting 16x4 ram. The same concept of a 3 bit slice, still works with
a 16x4 ram. Since this a microcoded design, the exact details are not needed for the 1973 microcode
other than a 256 x 16 rom is needed. PROM's and PLA's came out in 1973.
PS: I forgot I am using a more modern ALU, I need to change things for a 74181.

I'm guessing those 64-bit SRAM chips were cheaper than the equivalent TTL because they all switched to using it for their register files around that point.

Oddly INTEL made the first 16x4 ram at about $100 each in the late 60's.
TI had a 16x1 ram in the early 70's, used in the PDP-11. Around 1972 most
MSI chips became common, but many suppliers had their in house, ram chips at that time.
Signetics 25120 is a typical example. The NOVA computers used a TI 74172
8x2 dual port ram $40? each.
Before the 1970's scratch pad core was used instead. The late 60's gave low cost (< $10 each)
SSI gates but even then it was about 2 chips per bit.
1969 to 1973 really marked the growth of micro chip logic.

Cp/m is up and running. Control Program for Mini-computers.
Since most of the file calls are in rom, the shell is really small and stupid.
Changes drive A or B
Runs a *.SV file
Now I can start getting small C working and then port the assembler.

Congrats!
I thought CP/M was written in assembler for the 8080/Z80, did you port the whole thing?

CP/M is control programs for microprocessors.(8 /16 bits)
mine is Cp/m control programs for minicomputers.(9/18 bits)
All the good names have been taken years ago.
I want to add sub directories later so I have to use a FAT type of OS.
DOS would be a option, but there is no source and it all x86 segmented.
The same goes for Minix.
Flex (68xx) is long gone with no source code.
StarDos had source, but it all gone as well.
All the small computers in the 70's other than the PDP11 or TI-990 are too limited in the
instruction set and addressing modes to have well developed software and programing
languages, but even then a MMU is required. There is nothing I can steal in software
for me to use that generates good code.
Having said that, my order code seems stable, and I can port the design for 20 bit
cpu, and have good chance of it working. This will give me a bigger address space
to handle bloated code sizes. Then I will have Cp/M Control programs for MainFrames.
(10/20 bits)
Ben.

I decided to try porting Dunfield's C compiler, for my cpu.
Stupid C standard, wants both signed and unsigned bytes.
I had a spare bit around, so I am using that as a unsigned flag bit.
Took all my versions from this month and backing it up to the CD rom.
Ran out names , so the directory is T18 - transistor 18.
Ben.
PS Since I am starting from the 6809 model, I plan to add the 6809
indirection [x] as a assembler macro, using a scratch register for indirection.