dwatola@NEXTASY2.EECS.WSU.EDU (David Watola) (10/30/90)
With all this banter about Z80MU i am wondering if there is major interest
out there for a Z80 emulator that runs under UNIX. I am currently working on
one of these since I am buying a REAL computer next month (i.e. a standalone
engineering workstation). That way I can ditch my nasty S100 system but
still run some of CP/M software (Manx C, Turbo Pascal, etc) for generating
Z80 code for Z80-based controllers. When I finish this thing (IF I finish
this thing, the way school is going right now), I am considering distributing
it to interested parties, probably free... if I do make it shareware, it will
be dirt cheap ($5-$10) for registration for updates/bug fixes. Of course,
the source will be available... So, really, is anyone interested? If there
is enough interest, I can summarize the features of CP/M that I PLAN to
support (like I said, I really only plan to run a few select pieces of
software on my own system -- but I do plan to support the Z80 CPU completely).
You can post or email responses to : dwatola@yoda.eecs.wsu.edu
@eecs.wsu.edu
@nextasy2.eecs.wsu.edumrapple@quack.sac.ca.us (Nick Sayer) (10/31/90)
If anyone cares, I also have written a Z-80 interpreter and CP/M system for unix, and it's currently in beta-test. It is painfully slow, but that's to be expected, really. The BIOS is written in C, but the BIOS table can be played with, if you want, and BIOS can be moved "down" to make himem space available. Since it's in Beta, there's tons of debug stuff in the code that will probably come out (special thanks to eichin@athena.mit.edu for all his bug fixes), but it appears to run pretty well. The interpreter also has interrupt hooks, and all sorts of other junk. It actually simulates a Mostek MK-3880, but that should be the same thing as a Z-80. If there is tremendous interest, I could post the thing to comp.sources.misc, but the codes sort of messy right now. The code is copy-lefted. You can pass it around, but you can't charge for it. -- Nick Sayer | Disclaimer: "Don't try this at home, | RIP: Mel Blanc mrapple@quack.sac.ca.us | kids. This should only be done by | 1908-1989 N6QQQ [44.2.1.17] | trained, professional idiots." | May he never 209-952-5347 (Telebit) | --Plucky Duck | be silenced.
darcy@druid.uucp (D'Arcy J.M. Cain) (11/01/90)
In article <a72a05.1701@quack.sac.ca.us> mrapple@quack.sac.ca.us (Nick Sayer) writes: >If anyone cares, I also have written a Z-80 interpreter and CP/M >system for unix, and it's currently in beta-test. It is painfully >slow, but that's to be expected, really. The BIOS is written in >C, but the BIOS table can be played with, if you want, and BIOS >can be moved "down" to make himem space available. The sudden interest here in CP/M emulators has got me back to work on mine. Perhaps everyone who has one in the works should get together and get something finished. Anyway, since everyone is describing the features of their stuff here is mine. --------------------- Canned speech starts here ------------------------- This is a quick overview of my CP/M emulator for Unix. I wrote a decoder for the 8080 instruction set. Eventually I will upgrade it to a full Z80 decoder. Whenever the PC is >= 0xfec0 it executes a return no matter what is in RAM at that location. Before calling the routine for each instruction I look at the PC and end the program if it is zero or perform a BDOS function if it is 0xfec0 or BIOS if it is >= 0xff00. Since the emulator ignores the contents of memory as far as instruction decoding is concerned, The system has the interesting property of being able to use all of memory except the first 0x100 bytes for user programs by putting the stack at 0xfffe. In fact the default stack when a program is run is set to 0xfff0. I use Unix commands to simulate some CP/M commands such as DIR, REN, TYPE and handle things such as SAVE internally. I use the Unix file system for drives. The user defines Unix directories to CP/M drive mappings. This allows CP/M to use the same file system as the Unix but does force CP/M conventions on the file names such as upper case, must have 1 and only 1 period, etc. It is easy to handle though since one can always link files as necessary, even from CP/M since I also include a '!' command to do Unix commands from within CP/M. Programs that use IN and OUT opcodes will fail. All I/O must go through the BDOS or the BIOS. The user can set up the following devices: Screen (CON out), keyboard (CON in), RDR, PUN and LST. The default for screen and keyboard is stdout and stdin. The user can set up Unix files for any of these devices. The file of course can be an actual file, a device or even a pipe to a command, even another CP/M command that has the keyboard reading from the same pipe. It's not quite finished yet but I am running simple programs with it now. All the 8080 opcodes are being emulated and some of the Z80. --------------------- End of canned speech -------------------------------- It is running programs now but it is just so slow that I am trying to improve the decoder. If I ever get it finished I will be sure to post it. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | I support gun control. West Hill, Ontario, Canada | Let's start with the government! + 416 281 6094 |
eichin@ATHENA.MIT.EDU (Mark W. Eichin) (11/03/90)
So how many people are interested in collaborating on CP/M or Z80 emulator development? I had a Z80 emulator on my todo list for years, and then Nick Sayer came along and announced his, so I went and helped him test and debug it, rather than duplicate effort; however, there are a number of different strategies one might use, and there's room for many other designs (in its current form, with all of my additions, Nick's is quite useful for debugging, but it is dismayingly slow. A faster implementation might use a different strategy but not be as good at debugging.) If you're interested in actively coding or designing and discussing strategies for particular instructions or for the overall implementation, send me email (eichin@athena.mit.edu) and if there is enough interest, I'll set up the list. _Mark_ <eichin@athena.mit.edu> MIT SIPB Member/N1DPU/Z88 Hacker ps. My motivation includes possibly doing a simulator of the Z88, for development there too. If you're interested in that, consider joining the z88-hackers list <z88-hackers-request@sipb.mit.edu>.