Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!gauss.math.purdue.edu!wilker
From: wilker@gauss.math.purdue.edu (Clarence Wilkerson)
Newsgroups: comp.os.cpm
Subject: Re: CP/M Emulators
Message-ID: <9163@mentor.cc.purdue.edu>
Date: 31 Mar 91 21:26:02 GMT
References: <9103310818.AA10937@ucbvax.Berkeley.EDU> <1991Mar31.142550.9466@druid.uucp>
Sender: news@mentor.cc.purdue.edu
Reply-To: wilker@gauss.math.purdue.edu.UUCP (Clarence Wilkerson)
Organization: Purdue University, West Lafayette
Lines: 26

The main hassles in writing a 8080 emulator ( or worse, Z80 emulator)
are getting the condition codes (flags) exactly right. Another
slowdown is if the host machine for the emulator has a different
byte order than the 8080 for words. To my knowledge, this stacks
up as
8080, 80X86, VAX, 32032?? ....LITTLE_ENDIAN
680X0, RS6000, SPARC    BIG_ENDIAN.
But the flags are a major slowdown, and more if you include
parity, half parity, and so on. 
In C ,one has to do extra arithmetic to compute the flags, such
as carrying more digits to detect overflows. In assembler,
you can try to match your host CPU flags to the 8080/Z80 flags,
but there are lots of gotchas there. Later versions of Joan Riff's
Z80MU do a pretty good job at decent speed on a 80286 ( say,
equivalent to a 1.2 mhz z80 if run on a 12 mhz 80286 ). I think this
could be sped up some by unrolling the jumps into more code, etc,
but I doubt if anything would give a factor of 2 better.

I haven't "benchmarked" any emulators written in C running under
UNIX. The version I have running on a sparc feels like it's connected
to a 600 baud modem from the command line, but the disk performance
is quite peppy, so it probably assembles stuff at the rate of my
old H89. I tried the code on a IBM RS6000. It ran, but the stty
stuff on IBM style of unix is enough different that the terminal
handling is screwed up.
Clarence