Porting FUZIX

A project log for 68000 minimal homebrew computer

Single board computer (128KB SRAM) build in 1991.

StevenSteven 02/04/2022 at 16:500 Comments


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

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 pagem68k 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:

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:

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.