Introduction

Wouldn't it be nice to have a proper and working operating system running on this board? I've looked for Minix, but that way to large and complex. Then I read about FUZIX. It is a unix "like" operating system designed for old tiny 8 bits systems with a Z80 or 6502 CPU, and is ported to all kind of single board computers including MC68000! It is even ported to the Raspberry pi pico!

All the hardware is driven by FUZIX; the BIOS is only used for starting the system. The most interesting is, it has a build in (unix like) filesystem.

System requirements

• Some kind of IO (serial will do) > check.
• The operating system occupies about 64K, I have 128K > check.
• Reoccurring interrupts (100Hz) for scheduling and multitasking; I have a programmable timer+IRQ > check.
• Some kind of storage; the system is has a (very slow) interface for SD-card > check.
• Optional RTC; the system is connected to a DS1307 RTC > check.
• Free programable vectors (trap #12 used for calling the system). Oops; the ROM is mapped from 0x0000 to 0x4000; all vectors are fixed. But is this really a problem? Of course not; the BIOS is owned by me and I can easily reroute trap #12 to ROM, and use an RAM address for jumping. Just need to change the vector address in fuzix > check.

But on the other hand; this will be a major project...

Tool chain (Jan 2022)

The first thing before you can even think of porting this, is a tool chain. That's not as simple as it looks; you need a m68k cross assembler/linker/compiler and they are not common these days. First I tried serveral LINUX scripts and virtual box, but that didn't work for me; all kind of errors I couldn't handle. Then I found on Rosco's Rosco's page a m68k gcc toolchain installed from home-brew; that worked like a charm on a Macbook and Mac mini! Easy to install and the compiler, linker and assembler were working at once!

Geek... it compiles! (Jan 2022)

After downloading FUZIX from git it got really exciting; I expected all kind of compiler errors, but it compiled without any error! Of course it isn't working but for me this is a big moment to decide to go further. I have a Fuzix.ELF file which easily can be converted to a S19-file. I even got the addr2line util working; tip it needs a "-f" option to work. 

First steps (Feb 2022)

After changing lot of assembly coding for TTY and SD-card it now shows -without crashing- fuzix' start text and detects the SD-card. Also the 100Hz clock interrupt are on. The next step is to create and mount the filesystem.

Out of memory (march 2022)

Since the last update I made some progress:

• Updated the BIOS for rerouting trap #12 through memory.
• Added tty input (so I can enter bootdev "hda1".
• Created the whole disk image by compiling all the provided stuff and wrote it to a SD-card. (It could compile all but one file: the find-util).

Fuzix stopped with the message "No /init". This can mean anything; no filesystem, wrong filesystem, no access rights, wrong file type, wrong relocation information etc. After some debugging it turned out that the system is out of memory. After reducing the disk buffers from 16 to 4 (that saves me 6 KB) it started /init. But then again out of memory. Init is forking itself and needs another  31 KB. 

Of course I can remove some unused device drivers from the kernel, saving me some extra KBs, but the gap is at least 20KB.  I am afraid the 128 KB is not enough for a 68000 system to run :-( 

I really have to think about heating up the soldering iron and add  more memory to the system...

Found some memory (March 2022)

After investigating the system, I found a lot of wasted memory:

• Every process gets 16kB stack (elf2flat -s 16384); I reduced this to a configurable max 1kB.
• Reduced (temporaly) the disk buffers from 16 to 3 (freed 7 kB).
• Reduced (temporaly) the number of processes from 16 to 5 (freed a few hundreds bytes).
• Removed unused device drivers (ZX-keyboard, quart cart) which gave me some extra kB.
• In execv32 the load process reserved temporaly memory for the relocation information. In uses the bss-segment and increase this if necessary, but didn't use the stack space. Just a simple change in the calculation saves again several honderds of bytes.

After loading Fuzix it I have 71kB free; 23 kB more than before.

Address error (March 2022)

This nasty address error was shown after loading the shell; the PC is on an odd address (02C4A1). This kind of errors are very difficult to track down, because you can't use the PC and find the routine in which the error occurred. 

Usually the stack is overwritten (so I enlarged the stack > nope). 

The error was very stable, always the same address and the same moment, so it seemed not related to the interrupts.

Entering debug statements is an option, but this means edit source > compile > make diskimage > write diskimage to SD > place SD to system > start Fuzix and see how it works. Because al these steps takes time the turnaround time are several minutes.  

After debugging it seems to go wrong in the source of shell: Applications/V7/sh main.c > name.c (assnum()) > print.c in "itos()". This is a very simple routine for converting an integer to string. The 32 bits devision (in 68000 not available so the compiler has to call a subroutine for it) went wrong! After changing type "int" to "uint16_t" it worked fine.