UZIX Zilog Inside
UNIX Implementation for MSX

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

UZIX 2.0 Technical information

How it works:

      UZIX uses MSX2/2+/TR memory mapper to achieve multiprocessing. UZIX itself occupies 64K address space, divided in two parts: 48K for transient kernel and 16K for the resident kernel part. The resident part is the interface between applications and the rest of kernel. During system calls or interrupts the kernel transient part is swapped like any other process. Applications occupies a minimum of 16K and a maximum of 48K address space (depending of their size).
      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 252 processes (total of 4096k 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.
  • 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.