UZIX Zilog Inside
UNIX Implementation for MSX

[UZIX] [UZIX 1.0] [Status] [TCP/IP] [WWW] [Shots] [Docs] [Downloads]

UZIX 1.0 Technical information

How it works:

      UZIX uses MSX2 memory mapper to achieve multiprocessing. On PC UZIX use additional PC memory for swapping. In both cases UZIX use 64K of virtual address space (full Z80 space or one full segment on PC).
      UZIX itself occupies the upper 32K of address space, and the currently running process occupies the lower 32K.
      UZIX does need some additional hardware support. First, UZIX uses system clock that provide a periodic interrupt. Also, the current implementation uses an additional real-time clock to get the time for file timestamps, etc. The current TTY driver assumes an polling-driven buffered keyboard, which should exist on most systems.

How UZIX is different than real UNIX:

      UZIX implements almost all of the 7th Edition AT&T UNIX functionality. All file I/O, directories, mountable file systems, user and group IDs, pipes, and applicable device I/O are supported. Process control (fork(), execve(), signal(), kill(), pause(), alarm(), and wait()) are fully supported. The number of processes is limited only by the swap space available, with a maximum of 31 processes (total of 1024k memory). As mentioned, UZIX implements UNIX well enough to run the Bourne Shell in its full functionality. The only changes made to the shell's source code were to satisfy the limitations of the C compiler.

      Here is a (possibly incomplete) list of missing features and limitations:
  • The debugger- and profiler-related system calls do not exist.
  • The supplied TTY driver is bare-bones. It supports only one port.
  • Inode numbers are only 16-bit, so filesystems are 32MB or less.
  • File dates are not in the standard format. Instead they look like those used by MS-DOS.
  • The 4.2BSD execve() was implemented. Additional flavors of exec() are supported by the library.
  • The necessary semaphores and locking mechanisms to implement reentrant disk I/O are not there. This would make it harder to implement interrupt-driven disk I/O without busy-waiting.
Developer notes:

      MSX UZIX can be compiled with any ANSI-compatible C compilers. The only true one for MSX is Hitech-C (CP/M version) and MS-DOS Hitech-C (cross-compiler). MSX UZIX was written using Hitech-C. You'll find many constructions and functions not supported (and also limitations) by other MSX C compilers if you try compiling UZIX with them. Of course UZIX can be compiled using other compiler, but it will requires a lot of changes in the source code.
      Initially, MSX UZIX couldn't be compiled for running on a MSX1, since it uses Memory Mapper for multitasking, system real-time clock for file timestamps, and 80-column screen.
      Of course, is possible doing a "light" MSX UZIX for MSX1, with a fake real-time clock (software emulated by the kernel), using a 40-column display and other memory device (such as MegaRAM) for multitasking, but it's not the target of this release.
      But, just for fun (and as a curiosity), there is a version of MSX UZIX for MSX1. It emulates the system real-time clock and uses the Brazilian MegaRAM for multitasking. The system overall performance is lower than using Memory Mapper, since due to switching restrictions of MegaRAM (due to UZIX design, MegaRAM pages can be switched only on memory page 1), some memory block copies are needed for context switching. Also, the user must input the actual date and time when system boots. The 40-column display doesn't represent a serious restriction, but some applications (like top, ps or banner) will display bad formatted texts on screen.
      This release of MSX UZIX can handle a maximum of 31 processes (limited to the size of available RAM). It could handle up to 127 processes (4Mb RAM), but it's nonsense a single user running so many processes at a time. That's why this limit of 31 concurrent processes.