README.md

   1 [![Build Status][travis-image]][travis-url]
   2
   3 **FuzixOS**: Because Small Is Beautiful
   4
   5 This is the initial public tree for the FuzixOS project. It is not yet useful although you can build and boot it and run
   6 test application code. A lot of work is needed on the utilities and libraries.
   7
   8 # FUZIX
   9
  10 FUZIX is a fusion of various elements from the assorted UZI forks and
  11 branches beaten together into some kind of semi-coherent platform and then
  12 extended from V7 to somewhere in the SYS3 to SYS5.x world with bits of POSIX
  13 thrown in for good measure. Various learnings and tricks from ELKS and from
  14 OMU also got blended in
  15
  16 # Pre-built images
  17
  18 Some pre-built filesystems are now available on www.fuzix.org, and other
  19 images should follow in time.
  20
  21 ## What does FUZIX have over UZI
  22
  23
  24 * Support for multiple processes in banked memory (as per UZI180) but
  25         with Minix style chmem and efficient use of bank allocations.
  26 * Support for multiple processes via hard disk or non mappable RAM
  27     drive switching (as per UZI, UZIX).
  28 * The ability to run single tasking on small devices, for bring up
  29     and for standalone tool execution
  30 * Support for "real" swapping combined with banked memory.
  31 * Proper sane off_t and lseek
  32 * Normal dev_t
  33 * 30 character filenames
  34 * Proper sane time_t
  35 * System 5 signals (half baked)
  36 * Posix termios (does all the original UZI tty did but much can be added)
  37 * Blocking on carrier for terminals
  38 * Optimisations to avoid bogus uarea copying compared to UZI180
  39 * More modern system call API: 3 argument open, mkdir, rmdir, rename,
  40         chroot (with correct .. semantics), fchdir, fchmod, fchown, fstat,
  41         fcntl, setpgrp, sighold and friends, waitpid, setpgrp, nice
  42         O_NDELAY, O_CLOEXEC, F_SETFL, F_DUPFD etc
  43 * Address validation checks on all syscall copies
  44 * Builds with a modern ANSI C compiler (SDCC)
  45 * Kernel boots to userspace on both 6502 (bitrotted), 65C816, 68000, 6809, 8080, 8085, MSP430 (bitrotted) and Z80/Z180
  46 * Core code can be built for 6502, 65C816, 6809, 68HC11, 68000, 8080, 80805, 8086, MSP430, pdp11 and Z80/Z180 so should
  47   be far more portable
  48 * Core architecture designed to support building and maintaining
  49         multiple target machines without forking each one
  50 * Helpers to make many bits of implementation wrappers to core code
  51 * Lots more bugs right now
  52
  53 ## What does UZI have over FUZIX
  54
  55 * Can run in 64K of RAM (32K kernel/32K user). FUZIX would need
  56         banked ROM or similar to pull this off. If you have banked
  57         ROM then our kernel footprint in RAM is about 8K plus userspace
  58         plus any framebuffers and similar overhead. On a 6809 it's just
  59         about possible to run in a straight 64K
  60
  61 ## What do the UZI branches have that FUZIX has not yet integrated
  62
  63 * Minimal TCP/IP (UZIX 2.0). Unfortunately the original TCP was never
  64 released openly.
  65 * Symbolic links (UZIX)
  66 * Various clever fusions of syscalls that may save a few bytes
  67         (UZIX)
  68 * setprio (UZIX)
  69 * Rather crude loadable drivers (UZIX)
  70 * Use of __naked and __asm for Z80 specific bits to avoid more
  71         .S files than are needed (UMZIX)
  72
  73 Plus OMU has a really clever function passing trick for open/creat and
  74 friends, while UMZIX has a neat unified "make anything" function.
  75
  76 ## What Key Features Are Missing Still
  77
  78 * ptrace, ulimit
  79 * root reserved disk blocks
  80 * banked executables
  81 * TCP/IP (in progress)
  82 * select/poll() (in progress)
  83 * Support for > 32MB filesystems (but first figure out how to fsck
  84         a giant fs on a slow 8bit micro!)
  85 * Smarter scheduler
  86 * Optimisations for disk block/inode allocator (2.11BSD)
  87
  88 ## Tool Issues
  89
  90 * 6809 gcc and cc65 don't have long long 64bit (for sane time_t)
  91 * SDCC can generate ROMmable binaries but not banked ones (hack fixes done)
  92 * SDCC has no register passing function call support, and for some
  93         stuff it really shows
  94 * None of the above have an O88 style common sequence compressor
  95 * CC65 can't handle larger objects on stack, and lacks float support
  96 * We need a 'proper' 65C816 C compiler
  97 * ACK 8080 lacks floating point support
  98
  99 [travis-image]: https://travis-ci.org/EtchedPixels/FUZIX.png?branch=master
 100 [travis-url]: https://travis-ci.org/EtchedPixels/FUZIX