UZIX - UNIX Implementation for MSX (c) 1997-2001 Arcady Schekochikhin Adriano C. R. da Cunha http://uzix.msx.org What is the UZIX? UZIX: UNIX IMPLEMENTATION FOR MSX based on UZI written by Douglas Braun and ported to MS-DOS / MSX by Arcady Schekochikhin and Adriano Rodrigues da Cunha. UZIX is an implementation of the UNIX kernel written for a MSX/PC computer. It implements almost all 7th Edition AT&T UNIX kernel functionality. UZIX was written to run on PC (under MS DOS) or MSX2/2+/TR. The source code is written mostly in C, and was compiled with Turbo-C (PC) or Hitech-C (MSX). UZIX's code was based on public domain Doug Braun's UZI, which was written from scratch, and contains no AT&T code, so it is not subject to any of AT&T's copyright or licensing restrictions. UZIX implements almost all of the 7th Edition functionality. All file I/O, directories, mountable file systems, user and group IDs, pipes, and applicable device I/O are supported. The number of processes is limited only by the swap space available, with a maximum of 31 processes (total of 1024k memory). UZIX implements UNIX well enough to run the Bourne Shell in its full functionality. UZIX is very small. The code size of the kernel is less than 30Kb (in fact, it's 25.8Kb). I think it is the smallest UNIX 7th Edition-like implementation you can get. Due to the limitation of a 64Kb linear addressing space of Z80, UZIX supports only applications with a maximum size of 32Kb. Features: * UZIX is running on any MSX system (MSX2, MSX2+, TR and even emulators); * Full working multitask environment; * Full working multiuser environment; * Stable filesystem, almost bugless; * Very stable kernel, shell and environment; * System shell and utilities running with no errors; * Module support (only used by TCP/IP Stack now); * Harddisk support (ESE MegaSCSI and Sunrise IDE); 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 curiousity), 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. Known bugs and missing features: * Some DiskROMs doesn't work well with UZIX. MSX Turbo-R DiskROM also have this problem, and it's related to stopping the drive. If the drive stops spinning, the next access to it returns a 'not ready' error after a long delay. It can be solved with the appropriate settings on 'Advanced settings' in UZIX installation program or pressing the space bar while ZILO is loading. By an unknown reason, the drive returns`not ready` error for a disk access after stop spinning. The load of init/login access disk continuously, so everything works. During the time UZIX presents `login:` and you enter the login name, disk stops spinning. The disk access after entering login generates the `not ready` error. The solution found is: after each disk block read access, a reset() is done. This is also done in ZILO (via call to 4029h) before loading UZIX kernel. The bad side is that this practice slows down disk access a lot on MSX machines that aren't Turbo-R. * Disk access is slowed down since disk buffers were decreased to accomodate module functions in kernel. Also, the number of simultaneous opened files is less than previous versions (0.1.5 and below); * TABs are not correctly erased by BS key. DEVTTY backs 8 chars in screen, clearing them. It's not perfect, cause the TAB could not jumped 8 chars, but less, so we erase chars that are still in stdin queue; * If lpd can print all the docs, the daemon is fini shed (init executes the wait() and the daemon exits).If not, the process become zombie until SASH exits(init executes the wait() for SASH and lpd). It seems to occur only with RuMSX emulator (sorry, I don't have a printer attached to my MSX to test this...). * UZIX doesn't have the concept of background/foreground applications controlled by user; * Only ESE MegaSCSI and Sunrise IDE harddisk controllers were tested; Novaxis SCSI interfaces return error when system tries to access a disk; UZIX should run on other interfaces (Bert, Gouda, etc) but some fine tunning is necessary; * With ESE MegaSCSI, stopdrive countdown during interrupt must be disabled. If enabled, UZIX can't mount root filesystem. If disabled, when accessing disk-drives, the disk remains spinning forever. * On UCP, if you have an existing directory (for example, /usr) and want to create another dir under this one (for example, /usr/bin), doing: cd /,mkdir usr/bin on UCP causes an inconsistent inode count (check with fsck). You must do: cd /usr, mkdir bin. * FILESYS.C sometimes mark fs as bad if no room for writing a file (UCP). * reset() in DEVFLOP.MSX is a bad procedure. It stops ALL diskdrives connected to MSX. A perfect reset() should stop only the drive given by fdrive. * In passwd.c, getpwuid gets the first password entry that has the given UID. It DOESN'T look for GID, so entries with different GIDs and equal UIDs will be treated as the same. Things that would be nice to do: * Create the man-pages of: aal chat clock clone cr diskusag dosdel dosemu dtree find finger ftp gres ic inodes key keybstat lpd lpr mailf ncheck ncr netstat nslookup od pathchk ping pppd renice roff setclock setchar slattach uuencode uudecode * Implement TTY support on curses library. Now all references on code were supressed. * Create a dosformat utility. * Put a "see also" section on UZIX man-pages. * Better pipe handling in sash (it only supports two commands now). * Implement options -c, -l and -s in cmp. * Create fsck/mkfs/mkboot for UZIX. Copy license: All the UZIX source (kernel, utilities and related sources) is released under the GNU GPL license. Read the COPYING file for details.