Path: utzoo!attcan!telly!druid!darcy
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Newsgroups: comp.os.cpm
Subject: Re: cpm emulators under unix
Message-ID: <1991Jan16.220758.2078@druid.uucp>
Date: 16 Jan 91 22:07:58 GMT
References: <9101152311.AA10420@yoda.eecs.wsu.edu>
Organization: D'Arcy Cain Consulting, West Hill, Ontario
Lines: 57

In article <9101152311.AA10420@yoda.eecs.wsu.edu> David Watola writes:
>rct@erasure.East.Sun.COM (Robert C. Terzi - Sun Consulting) writes:
>>Does a Z-80/8080 emulator exist that runs under Unix, preferably
>>that can boot CP/M, using files to emulate the floppies?
>
>what a coincidence.  my emulator is just about done.  'just about'?
>well, that means there are a few bugs to work out whenever i find

Mine needs a little work but it is running code.  It also has a
built in debugger which is handy.  That is the part that needs the most
work right now.  The debugger is a compile time option because it
is slooooooooow with it in.  I haven't compiled it under anything but
my 386 system so I can't guarantee plug and play but it is mainly
ANSI so should work on ANSI compilers.  I use GNU C.

I'll post it to alt.sources.  Comments are greatly appreciated.  I
thought there was a mailing list for discussing this.  It seemed
like everyone was writing a CP/M emulator at one point and someone
started a mailing list to swap code and ideas.  I remember joining
the list but I can't remember who was running it and I haven't seen
anything.  Anyone know if this is still happening?

>the time.  right now it runs Manx Aztec CII, M80, L80, and a few
>other applications without any problem.  but it chokes on Wordstar
>(not that i would ever use such a pig--but its a great test) and,
>more importantly on ASM and MAC.  anyone ever try to debug a program

Aztec C, MAC, HEX and a bunch of others work on mine.  One thing
needed is a test suite.  My idea is to run instructions and jump
to zero on error.  A debugger can then watch to see where the jump
occurs since the error immediately stops the system.  Of course it
is important to test the test and jump instructions rather early.

>that emulates a microcode interpreter?  it sucks tracking down that
>single instruction that isn't working quite right.  the good news

That's why I built in a debugger.  It helps debug the processor itself.

>though, is that it
>runs very fast on my 25MHz 68040 even though it is in C.  faster than
>z80mu (which is mostly machine code) runs on a 20MHz 386.  i think
>that when i finally write the entire thing in 68000 assembly language
>it will run (on the average) about as fast as a 3.5 or 4 MHz Z80.
>on the other hand, it really pokes along on a 25MHz 68030.

Mine isn't too bad.  I emulate CP/M rather than loading a real copy.
It helps speed things up.  An interesting side effect of the method
I use is that the TPA can stretch from 0100 to fffe, 258 bytes short
of the entire 64k, as long as the high 1 or 2 k is only used for
stack or data.  Programs that do standard checking for top of TPA
still have up to fec0 where the BDOS seems to sit.

-- 
D'Arcy J.M. Cain (darcy@druid)     |
D'Arcy Cain Consulting             |   There's no government
West Hill, Ontario, Canada         |   like no government!
+1 416 281 6094                    |