home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / BEEHIVE / OS / UZI280.TXT < prev    next >
Text File  |  2000-06-30  |  4KB  |  92 lines
  1. X-NEWS: levels comp.os.cpm: 1126
  2. Relay-Version: VMS News - V5.9C 19/12/89 VAX/VMS V5.3; site levels.sait.edu.au
  3. Path: levels!nt!sirius.ucs.adelaide.edu.au!munnari.oz.au!uunet!bu.edu!orc!inews!cadev4!dbraun
  4. Newsgroups: comp.os.cpm
  5. Subject: Re: UZI-280?
  6. Message-ID: <2825@inews.intel.com>
  7. From: dbraun@cadev4.intel.com (Doug Braun ~)
  8. Date: 23 Aug 90 22:00:38 GMT
  9. Reply-To: dbraun@cadev4.UUCP (Doug Braun ~)
  10. Sender: news@inews.intel.com
  11. References: <900822110949.719125@DMZRZU71-UNI-MAINZ--GERMANY>
  12. Organization: Corporate CAD, INTeL Corporation, Santa Clara, CA
  13. Lines: 77
  14.  
  15. Here is what's going on with UZI-280:
  16.  
  17. First, work is very sporadic.  I did a lot before April, and then didn't get
  18. back to it until a few weeks ago.
  19.  
  20. Here is what works right now:
  21.  
  22. User/system address spaces:  64k user process plus 64k available
  23. for kernel.  Kernel accesses user address space to get system call
  24. arguments, etc.  Processes CANNOT corrupt kernel.
  25.  
  26. Traps are fully supported by kernel.  User processes can generate
  27. segmentation violation, illegal I/O instruction, divide by zero, etc.
  28. signals.  The brk and sbrk system calls set up the MMU to trap
  29. wild pointers in user executables.  All of this is very much
  30. like PDP-11 unix.
  31.  
  32. The kernel will trap itself (and panic) on kernel stack overflow, 
  33. null pointer, etc.  The kernel does not use the user's stack
  34. (obviously).  There is a correct and robust mechanism for processes
  35. to catch and ignore signals.
  36.  
  37. The TTY driver supports stty things such as echo, cbreak, and raw mode.
  38.  
  39. Virtual memory and paging are basis for memory managment and multiprogramming.
  40. Forked processes share copy-on-write pages.  The old UZI swapping to disk
  41. is no longer done.  The command response is now much faster.
  42.  
  43.  
  44. What I'm working on right now:
  45.  
  46. The page replacement algorithm is very crude.
  47. Page access timestamps need to be implemented for the page replacement
  48. algorithm.
  49.  
  50. What I would eventually like to do:
  51.  
  52. Have proper interrupt-driven disk I/O.
  53. Support split I and D space for processes, allow 64K code plus 64K data.
  54. This would require supporting mixed 4K and 8K page sizes.
  55. Have the system self-supporting, which means having compiler and linker
  56. running under UZI  (This is currently feasible).
  57.  
  58.  
  59. What's going on with utulities, compiler, etc.:
  60.  
  61. I have modified the Q/C Z80 C compiler to generate Z280 opcodes,
  62. changing the code generator quite a bit to do better optimization.
  63. This is really an entirely seperate product, that can also be
  64. used on CP/M or as a cross-compiler.
  65. Indexed addressing is used to access all automatics, and register
  66. BC is for a register variable now.  Alas, the Q/C compiler copyright
  67. prevents me from distributing this.  Clever ideas to overcome this
  68. are welcome.
  69.  
  70. I have ported the "Stevie" vi clone (now named "v8") to UZI-280.  Alas,
  71. it barely fits in 64K, so it cannot edit anything more than 25 lines long.
  72. The split I/D enhancement would cure this.  (This is how vi runs on PDP-11s).
  73. If anyone can recommend a screen-based editor I can get source to and port,
  74. such as VDE or VDO, that would be fantastic.
  75.  
  76.  
  77. Also,  I run CP/M 3 on my system now, so if anyone wants a Z280 BIOS for CP/M 3
  78. with memory management (all the fancy stuff), let me know.
  79.  
  80. Doug Braun                Intel Corp CAD
  81.                     408 765-4279
  82.  
  83.  / decwrl \
  84.  | hplabs |
  85. -| oliveb |- !intelca!mipos3!cadev4!dbraun
  86.  | amd    |
  87.  \ qantel /
  88.  
  89.  or:
  90.  
  91.  dbraun@scdt.intel.com
  92.