Home
The Z80 codebase supports multiple different retro and hobbyist Z80 platforms. A good minimum configuration is about 96K of RAM plus a hard disk. Banking of some kind is needed for the Z80 port. The linker has been modified so that the kernel can reside in multiple 16K banks at the same address in order to suit platforms like the Spectrum 128K. The Z80 code supports fixed banks with a common area, 16K banks, with single and multiple processes in memory. The kernel uses no undocumented instructions. IEEE doubles are not supported but act instead as floats.
Supported using the banked model and the Z80 codebase. Better memory management might be possible with some kind of base/limit memory allocator (perhaps steal the ELKS one), but the current supported platforms tend to have 512K+ memory so it's a non issue at this point.
Some initial porting but no fully fledged platform.
The 8080 port runs on a virtual 8080 emulation. Only the banked model is currently supported although it should be possible to support a single process model given a disk controller with DMA. The compiler used is the ACK 8080 compiler, and this needs to be from at least Feb 16th 2019.
Very close to the 8080 port this uses the extra 8085 fetures. Only the banked model is currently supported. Currently working on ironing out the bugs in this and a new 8085 C compiler to get the full benefits of the CPU. Runs on the RC2014-8085 platform.
This is a fairly complete port and currently runs on the rc20914-6502 platform. It's difficult to see how to port it to most period 6502 machines as they tend to lack memory (or fill it with ROM), and when they have memory they bank it in strange ways.
Operating in banked memory mode the 6502 kernel will spot the 65C816 and do some speedups. There isn't currently a native 65C816 compiler that seems suitable. Without banked memory the 65C816 is problematic as the compiler generates constructs that only work with data in bank 0.
Work in progress - debugging the compiler
Fairly complete port for the rc2014-6803/6303 board. There are still some compiler bugs to deal with but it mostly works.
The 6809 platform supports the Tandy COCO2/Dragon 64 with cartridge, the Tandy COCO3, and some other platforms including the FPGA based 'multicomp' and rc2014-680. The 6809 tree is built with gcc6809 and the compactness of the code means it is just about possible to run in 64K of memory with serial console.
Somewhat bitrotted port with userspace and shell. Very tight on memory
Runs on the rc2014-68HC11 platform with banked memory. Should be fairly portable.
Supports simple one process in memory systems and larger flat memory models. Hardware support includes the tiny68K 16MB system, and the rc2014-68008 prototype board.
Core code builds with gcc toolchain, basics of a PC port slowing being added.
Work in progress ports to armm0 (Raspberry Pi PICO) and armm4.
Core code builds with gcc and some of the minimal asm bits sketched out. Currently blocked by binutils bugs.
Platform specific full port for ESP86, basic ESP32 port
Mostly being used to debug the compiler at this point
- SDCC 3.8 (Z80)
- gcc + lwtools (6809)
- CC65 (6502, 65C816)
- GCC (68000, 8086, MSP430, 68HC11, PDP-11, ESP8266, ARM)
- ACK (8080,8085)
The file system is based upon the UZI file system but has been extended to 30 character filenames and the superblock has an 'epoch' base to allow for time beyond 2038 in a window.
The standalone tools provided are
- Chmem - set the memory slot for a binary
- Fsck - fsck a Fuzix fs
- Mkfs - Make a Fuzix fs
- Ucp - A tool for building and modifying Fuzix file systems. Really wants replacing with a script parsing tool that assembles a file system from a recipe
Fuzix: because small is beautiful