X-NEWS: levels comp.os.cpm: 1126 Relay-Version: VMS News - V5.9C 19/12/89 VAX/VMS V5.3; site levels.sait.edu.au Path: levels!nt!sirius.ucs.adelaide.edu.au!munnari.oz.au!uunet!bu.edu!orc!inews!cadev4!dbraun Newsgroups: comp.os.cpm Subject: Re: UZI-280? Message-ID: <2825@inews.intel.com> From: dbraun@cadev4.intel.com (Doug Braun ~) Date: 23 Aug 90 22:00:38 GMT Reply-To: dbraun@cadev4.UUCP (Doug Braun ~) Sender: news@inews.intel.com References: <900822110949.719125@DMZRZU71-UNI-MAINZ--GERMANY> Organization: Corporate CAD, INTeL Corporation, Santa Clara, CA Lines: 77 Here is what's going on with UZI-280: First, work is very sporadic. I did a lot before April, and then didn't get back to it until a few weeks ago. Here is what works right now: User/system address spaces: 64k user process plus 64k available for kernel. Kernel accesses user address space to get system call arguments, etc. Processes CANNOT corrupt kernel. Traps are fully supported by kernel. User processes can generate segmentation violation, illegal I/O instruction, divide by zero, etc. signals. The brk and sbrk system calls set up the MMU to trap wild pointers in user executables. All of this is very much like PDP-11 unix. The kernel will trap itself (and panic) on kernel stack overflow, null pointer, etc. The kernel does not use the user's stack (obviously). There is a correct and robust mechanism for processes to catch and ignore signals. The TTY driver supports stty things such as echo, cbreak, and raw mode. Virtual memory and paging are basis for memory managment and multiprogramming. Forked processes share copy-on-write pages. The old UZI swapping to disk is no longer done. The command response is now much faster. What I'm working on right now: The page replacement algorithm is very crude. Page access timestamps need to be implemented for the page replacement algorithm. What I would eventually like to do: Have proper interrupt-driven disk I/O. Support split I and D space for processes, allow 64K code plus 64K data. This would require supporting mixed 4K and 8K page sizes. Have the system self-supporting, which means having compiler and linker running under UZI (This is currently feasible). What's going on with utulities, compiler, etc.: I have modified the Q/C Z80 C compiler to generate Z280 opcodes, changing the code generator quite a bit to do better optimization. This is really an entirely seperate product, that can also be used on CP/M or as a cross-compiler. Indexed addressing is used to access all automatics, and register BC is for a register variable now. Alas, the Q/C compiler copyright prevents me from distributing this. Clever ideas to overcome this are welcome. I have ported the "Stevie" vi clone (now named "v8") to UZI-280. Alas, it barely fits in 64K, so it cannot edit anything more than 25 lines long. The split I/D enhancement would cure this. (This is how vi runs on PDP-11s). If anyone can recommend a screen-based editor I can get source to and port, such as VDE or VDO, that would be fantastic. Also, I run CP/M 3 on my system now, so if anyone wants a Z280 BIOS for CP/M 3 with memory management (all the fancy stuff), let me know. Doug Braun Intel Corp CAD 408 765-4279 / decwrl \ | hplabs | -| oliveb |- !intelca!mipos3!cadev4!dbraun | amd | \ qantel / or: dbraun@scdt.intel.com