Date   : Sat, 22 Jun 1991 00:40:52 GMT
From   : zephyr.ens.tek.com!tektronix!reed!intelhf!ichips!inews!cad412!dbraun@uunet.uu.net (Doug Braun ~)
Subject: UZI-280 update

Here is a more detailed description of the status of UZI-280.

First a report from last March:


UZI-280 is in the process of being written.  My computer system
now has a Z280 with 128K of memory.  The kernel and user processes 
now run in seperate address spaces, but total swapping is still used
at present.  The various hardware traps of the Z280 (privileged instruction,
system stack overflow, access violation) are handled correctly.
There is proper protection, in the sense that a user process cannot munch
kernel data, like in the original UZI.  Current plans include allowing
user processes to run seperated I and D address spaces (thus allowing
64K of code and 64K of data), and implementing demand paging instead of total
swapping.  UZI280 will then have the power and functionality (more or less) of 
a PDP-11/34 or PDP-11/60 running 7th Edition Unix.



Now, what I have done since then:


The demand-paged virtual memory is implemented.
However, the swapper still has at least one bug in it (it crashes 
when trying to handle programs larger than available user RAM.

Anyway, you get a full 64K shared code/data for your process,
and a full 64K for the kernel (lots more room for buffers, etc.)
The kernel does not swap, and currently ties up a minimum of
40K or so RAM. leaving me with at most 88K for user processes.

All the traps, segmentation violations, auto-growing of stack, etc.
work just great.  All system calls will trap on illegal addresses
passed to them, like they should.

The TTY driver is much better than that in the original UZI;
it handles the stty() calls that vi needs.

I have tested UZI280 with two terminals at once.

I have ported "stevie", the vi clone, now renamed "v8".
However the code occupies almost 64K, so it really needs
seperate user/data space to be useful.

The disk drivers are still not interrupt-driven.
One of the Z280 timers is used for the clock, and the
internal UART is used for the console, thus UZI280
is more hardware-independent than the original UZI.



Virtually all of the hard stuff for UZI-280 is done.  However,
I do not plan to spend more time on it myself, and I really
want to distribute it to people who can take advantage of it.

I moved a couple of weeks ago, and all my computer stuff is
still in boxes.  As soon as I have the time, I plan to
package and upload UZI-280 to SIMTEL20 or wherever.
Several people have expressed interest.

I will certainly also distribute my CP/M 3 Z280 BIOS,
and I would like to distribute my Z280 enhancements to
the Q/C C Compiler, if I can legally do so.


Doug Braun                             Intel Corp CAD
                                       408 765-4279

 dbraun@scdt.intel.com

 or maybe:

  / decwrl \
  | hplabs |
 -| oliveb |- !intelca!mipos3!cadev6!dbraun
  | amd    |
  \ qantel /


Doug Braun                             Intel Corp CAD
                                       408 765-4279

 dbraun@scdt.intel.com

 or maybe:

  / decwrl \
  | hplabs |
 -| oliveb |- !intelca!mipos3!cadev6!dbraun
  | amd    |
  \ qantel /