jurjen@cwi.nl (Jurjen NE Bos) (08/22/90)
clldomps@praxis.cs.ruu.nl (Louis van Dompselaar) writes: >Is there anyone who has had some experience in using multitasking >on a Z80 system? Please let me know what is, and what is not, possible... >Louis >clldomps@praxis.cs.ruu.nl Easy! We (4 friends and me) built a multi-user Z80 systems already years ago, featuring 512K RAM, two real floppy drives while the users thought they had 4 floppies each (but if you wanted to read something, you had to walk over and insert your floppy), 5 terminals, etc. The system is still running, and today they are working on a LAN, hard disk, and more goodies. The trick is to get some coprocessors for things like key scanning, disk I/O, and other work that tends to eat away cycles. The CPU can then start doing only the more useful things. But of course, we had a lot more performance- increasing tricks... -- | | "Never imagine yourself not to be otherwise than what | | Jurjen N.E. Bos | it might appear to others that what you were or might | | | have been was not otherwise than what you had been | | jurjen@cwi.nl | would have appeared to them to be otherwise." |
clldomps@praxis.cs.ruu.nl (Louis van Dompselaar) (08/22/90)
Is there anyone who has had some experience in using multitasking on a Z80 system? Please let me know what is, and what is not, possible... Louis clldomps@praxis.cs.ruu.nl
lwj@cs.kun.nl (Luc Rooijakkers) (08/22/90)
jurjen@cwi.nl (Jurjen NE Bos) writes: >clldomps@praxis.cs.ruu.nl (Louis van Dompselaar) writes: >>Is there anyone who has had some experience in using multitasking >>on a Z80 system? Please let me know what is, and what is not, possible... >Easy! We (4 friends and me) built a multi-user Z80 systems already years >ago, featuring 512K RAM, two real floppy drives while the users thought >they had 4 floppies each (but if you wanted to read something, you had to >walk over and insert your floppy), 5 terminals, etc. >The system is still running, and today they are working on a LAN, hard disk, >and more goodies. >The trick is to get some coprocessors for things like key scanning, disk I/O, >and other work that tends to eat away cycles. The CPU can then start doing >only the more useful things. But of course, we had a lot more performance- >increasing tricks... But not too many. Since I'm the creator of the Timesharing software for that machine (Hi Jurjen!), I will give some hints. By the way, the software is still in use and amounts to about 12,000 lines assembly language (when I last counted it about a year ago). Basically, it all boils down to avoiding busy-waiting like the plague. So ALL I/O devices have to be interrupt-driven, and in our environment CP/M programs that constantly sit in a console-status loop are frowned on. Unfortunately, there are quite a lot of these (WordStar, among others, though we don't use it very much). We run multiple CP/M 2.2 systems on the system, with a *big* BIOS that does the sharing and lots of other work. The users each have 4 drives which they can assign to any named disk. When needed, the system asks for the disks, which can then be plugged in in any disk drive. We also support the use of two 5M ST506 hard disks (very old PC hard disks) which are attached to another Z80 system with a SASI adapter. The two systems communicate over our own home-built 500Kbit/s token bus network (built with Z80 SIO chips). The system uses about 100K for disk caching, since we have plenty of memory. It might be worth saying that we started this project back in 1984. The system still works very satisfactory and is in daily use. As a matter of fact, our system averages about 80 percent *idle* time. Humans are just too slow to keep any computer busy. Of course, when you start running more than one CPU-intensive application (like an assembler, or a compiler) then they each get their share of the available CPU time, proportional to the number of running programs. But other I/O-intensive programs like text editors do not suffer from this very much. We did add a little bank switching logic external to the Z80, but that was not really difficult. It basically consists of a 16 byte memory that translates address lines A12 to A15 from the Z80 to address lines A12 to A18 on the bus (the 8th bit is used for write protect). For hardware freaks, these were just two 7485 chips and a few buffers. One thing not possible with our setup is a *secure* multi-user environment, but we didn't need that. You can do this using the more modern Z280 chip, which has the MMU built on-chip (with 3 DMA-controllers and 256 bytes of cache memory and lots of other goodies). The instruction set is upward compatible with the Z80, and has nice additions like divide and multiply instructions and lots of new adressing modes (e.g. LD HL,(SP+n) ). In fact, we have a Z280 lying in some dusty corner, but just never found the time to change our system for it. If you start building a new system, by all means use a Z280! (To me, it has always seemed a waste to use the Z280 only for a CP/M Plus system, which several people seem to be doing currently. It can do so much more!) Summarizing, I would say that almost *anything* is possible. It only depends on how much effort you want to spend on it. There are no inherent limits in the Z80 processor that would limit you. -- Luc Rooijakkers Internet: lwj@cs.kun.nl Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj University of Nijmegen, the Netherlands tel. +3180652271
syswtr@iowasp.physics.uiowa.edu (08/22/90)
In article <3696@ruuinf.cs.ruu.nl>, clldomps@praxis.cs.ruu.nl (Louis van Dompselaar) writes: > Is there anyone who has had some experience in using multitasking > on a Z80 system? Please let me know what is, and what is not, possible... MP/M anyone ??? Bill
donm@pnet07.cts.com (Don Maslin) (08/24/90)
Or if you really want to reach for it - OASIS
UUCP: {nosc ucsd crash ncr-sd}!pnet07!donm
ARPA: simasd!pnet07!donm@nosc.mil
INET: donm@pnet07.cts.comSLSW2@cc.usu.edu (Roger Ivie) (08/24/90)
In article <3696@ruuinf.cs.ruu.nl>, clldomps@praxis.cs.ruu.nl (Louis van Dompselaar) writes: > Is there anyone who has had some experience in using multitasking > on a Z80 system? Please let me know what is, and what is not, possible... I've done two multi-tasking things on a Z80. The first is that I experimented with MP/M on an Apple Softcard; I wrote a simple MP/M BIOS that simply called the CP/M BIOS. I had two jobs going: one just barely large enough to load Microsoft BASIC and the other just barely large enough to run PIP when BASIC was loaded in the other. It was lots of fun. You might still be able to get MP/M. I bought a brand new copy about a year ago, but still have yet to do anything with it. I intend to eventually get it running on my NorthStar; I seem to keep collecting bankswitched memory cards for the thing. The other thing I've done with multitasking was for an embedded system. The company I work for makes an IEEE-488 interface to the VAXBI whereon the IEEE-488 is entirely managed by a Z80 (i.e.: the VAX politely requests that the Z80 do the work for it. Not fast, but it did make the BI interface very simple. Oh yeah; the Z80 knows how to translate VAX virtual addresses; that was fun). The whole thing is written in assembler and uses a decendant of an 8080 multi-tasking kernel originally published in BYTE back when BYTE published that sort of thing. -- =============================================================================== Roger Ivie 35 S 300 W Logan, Ut. 84321 (801) 752-8633 ===============================================================================
geertj@philica.ica.philips.nl (Geert Jan de Groot) (08/25/90)
In article <2108@wn1.sci.kun.nl> lwj@cs.kun.nl (Luc Rooijakkers) writes: >jurjen@cwi.nl (Jurjen NE Bos) writes: > >>clldomps@praxis.cs.ruu.nl (Louis van Dompselaar) writes: > >>>Is there anyone who has had some experience in using multitasking >>>on a Z80 system? Please let me know what is, and what is not, possible... > >>Easy! We (4 friends and me) built a multi-user Z80 systems already years >>ago, featuring 512K RAM, two real floppy drives while the users thought >>they had 4 floppies each (but if you wanted to read something, you had to >>walk over and insert your floppy), 5 terminals, etc. >>The system is still running, and today they are working on a LAN, hard disk, >We did add a little bank switching logic external to the Z80, but that >was not really difficult. It basically consists of a 16 byte memory >that translates address lines A12 to A15 from the Z80 to address lines >A12 to A18 on the bus (the 8th bit is used for write protect). For >hardware freaks, these were just two 7485 chips and a few buffers. A small correction (I am the 'hardware' member of this group, hi Jurjen, Luc): I have had some requests earlier about how to do this, but (yes, I'm ashamed!) lost the Email address: We used 7489's instead of 7485's. 7489's are small, 16x4 bit wide RAMS, but very fast (1984 standards, youth scientist's budget, i.e. remove from scrap PCBs from a large electronics firm in Eindhoven). A15-A12 of the Z80 are connected to the address lines of these RAMs, giving 4Kbyte pages. The data-out lines of these RAMS (we have 2 of them, so 8 bit) are the address lines that go to the rest of the system. One line is reserved for write-protection, giving a 512 Kbyte addres space. In this address space, there is some memory-mapped I/O (a number of video displays), but there is plenty of room left for users. How does one control the RAMs for address remapping? This doesn't seem easy, but it worked out for us: fortunately, thos RAM devices have separate data-in lines. Those data-in lines are connected to the databus. If one uses the 'OUT (B),A' instruction, the CPU really executes 'OUT (BC),A', thus the contents of register C are on A8-15 of the CPU, and you can put the address of the RAM location on b4-7 of register C. Register B contains the I/O address of the RAM chip as usual, and A contains the new contents. Nice and simple. We even didn't need to use an undocumented feature of the Z80; all of this is documented and guaranteed. A Nice Thing about running a multi-user system like this is that there is always a layer 'above' your own program. If your program crashes, under the condition it didn't scribble in the I/O devices (a big no-no for multiuser of course), a special key combination is enough to 'reboot' your virtual CP/M machine; no need to re-load the operating system. The only problem is that all CP/M utilities don't know about the environment they're in and don't know they can fork() and things like that. We wrote all client-slave software ourselves, because IPC isn't defined in CP/M. But, all of the CP/M software we know of works fine on one of the virual machines of our multiuser system, and we don't have much non-standard software (only for demonstration purposes). Still a pleasure to work with! And because of the scrap material, it costed only Hfl 1000,- (can't get disk drives from scratch). Physically, it is a 19" rack more than 1.5 meter high, crammed with racks full of PCB's. It takes at least 2 men to lift it. A real monster, but nice! Why didn't we use MP/M? It was not available (as in: we didn't have a copy), and the young scientists' budget didn't allow us to buy it. We got CP/M via a machine which doesn't exist anymore (I think), and our only chance was to re-use the software that came with that machine.. Remember, this was the time that Exidy Sourcerers were Hot Machines, and we built the thing because the only Exidy we had was always busy. It serves its purpose well. Geert Jan --8<--nip-nip--------------------------------------------------------------- Geert Jan de Groot, Email: geertj@ica.philips.nl Philips ICA, ..!hp4nl!philica!geertj Weisshausstrasse, Ham: PE1HZG 5100 Aachen, West-Germany phone: +49 241 6003 714 "Programs are like waffles: fax: +49 241 6003 709 you should always throw the first one out" [Standard disclaimers apply] - Sutherland