Como funciona:

O UZIX usa a memória mapeada do MSX2 para obter multiprocessamento. No PC, o UZIX usa a memória adicional do computador para troca de contexto. Em ambos os casos, o UZIX usa 64kB de espaço de endereçamento virtual (o espaço completo do Z80 ou um segmento cheio no PC).

O UZIX propriamente dito ocupa os 32kB superiores do espaço de endereçamento, e o processo em execução corrente os 32kB inferiores.

Ele necessita de algum suporte adicional de hardware. Primeiro, o UZIX usa o temporizador do sistema para prover uma interrupção periódica. Também, a implementação corrente usa um relógio de tempo real adicional para obter a data e hora para arquivos, etc. O driver de TTY corrente assume um teclado com buffer por polling, o qual existe na maioria dos sistemas.

Como o UZIX é diferente do UNIX real:

Implementa quase todas as funcionalidades da 7ª Edição. Todas as operações de E/S de arquivos, diretórios, sistema de arquivos montável, usuários e grupos, pipes e dispositivos de E/S aplicáveis são suportados. O controle de processos (fork(), execve(), signal(), kill(), pause(), alarm() e wait()) é totalmente suportado. O número de processos é limitado apenas pelo espaço de troca disponível, num máximo de 31 processos (num total de 1024kB de memória). Como mencionado, o UZIX implementa o UNIX bem o suficiente para executar a Bourne Shell em toda a sua funcionalidade. As únicas modificações feitas no código-fonte da shell foram para satisfazer as limitações do compilador C.

Aqui está uma (possivelmente incompleta) lista de funcionalidades faltantes e limitações:

• As chamadas de sistema relacionadas a debug e profile não existem.
• O driver TTY é dependente do terminal padrão do computador. Ele suporta apenas uma porta.
• Os números dos inodes são 16 bits. Logo, os sistemas de arquivos têm 32Mb ou menos.
• A hora e data dos arquivos não está no formato padrão. Ao invés disso, elas se parecem com aquelas usadas pelo MS-DOS.
• A chamada execve() do BSD 4.2 foi implementada. Outra variantes do exec() são suportadas pela biblioteca.
• Os semáforos e mecanismos de trancamento necessários para implementar E/S de disco reentrante não estão aqui. Isso tornaria difícil implementar E/S de disco controlada por interrupção sem espera.

Notas para desenvolvedores:

O UZIX para MSX pode ser compilado com qualquer compilador C ANSI-compatível. O único verdadeiro para MSX é o Hitech-C (versão para CP/M) e o Hitech-C MS-DOS (cross-compiler). O UZIX para MSX foi escrito usando o Hitech-C. Você encontrará muitas construções e funções não suportadas (e também limitações) por outros compiladores C para MSX se você tentar compilar o UZIX com eles. É claro que o UZIX pode ser compilado usando outro compilador, mas isto requereria muitas mudanças no código-fonte.

Inicialmente o UZIX para MSX não podia ser compilado para ser executado em um MSX1, já que ele usa memória mapeada para multitarefa, relógio de tempo real para data e hora e tela em modo de 80 colunas. É claro, é possível fazer uma versão "leve" do UZIX para MSX1, com um relógio de tempo real falso (emulado por software pelo kernel), usando a tela em 40 colunas e outro dispositivo de memória (como a MegaRAM) para multitarefa, mas este não é o objetivo do projeto.

Mas, apenas por diversão (e como curiosidade), existe uma versão do UZIX para MSX1. Ele emula o relógio de tempo real e usa a MegaRAM brasileira para obter multitarefa. A performance geral do sistema é mais baixa que usando a memória mapeada, já que devido às restrições de chaveamento da MegaRAM (devido ao design do UZIX, as páginas da MegaRAM só podem ser chaveadas na página 1 da memória) algumas cópias de blocos de memória se fazem necessárias para a troca de contexto. Além disso, o usuário deve fornecer a data e hora atual quando o sistema é carregado. A tela em 40 colunas não representa uma restrição séria, mas algumas aplicações (como top, ps ou banner) exibirão textos mal formatados na tela.

Esta versão do UZIX para MSX pode lidar com um máximo de 31 processos (limitado pelo tamanho da RAM disponível). Ele poderia manipular até 127 processos (4Mb de RAM), mas não faz sentido apenas um usuário executar tantos processos ao mesmo tempo. Este é o motivo do limite de 31 processos concorrentes.

Mais informações em: http://uzix.sourceforge.net