dwatola@YODA.EECS.WSU.EDU (David Watola) (01/16/91)
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 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 that emulates a microcode interpreter? it sucks tracking down that single instruction that isn't working quite right. the good news 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. also, there is a program called upm over in comp.sources.misc or comp.sources.unix that does this. its pretty slow though, esp. since it requires an image of BDOS that it interprets. the main program loop is also structured kind of inefficiently (not that there is anything inherently wrong with it though). you might want to try it out if you need something NOW.
wilker@gauss.math.purdue.edu (Clarence Wilkerson) (01/16/91)
I'm using a cp/m emulator for unix that I got from the U. Of Tokyo
ftp site a year or so ago. It does 8080 only, and is not complete
emulation of all flags. In particular Wordstar does not run.
For some reason, WS uses JPO in a way that depends on a very
good emulation ( this is jump on odd parity). The implementor of
my version tried to just always save the last arithmetic result
and then recreate the flags when needed. This should work for
reasonable code, but obviously fails for code like
lxi h, arbitrary_word
push h
pop psw
Anyway, the version I have runs CP/M, MAC, M80, L80, MBASIC, etc,
so I haven't made the ultimate effort to track down the last ergs
fr the emulation.
You can try out the look and feel of CP/M-80 by rlogging into
"cpm@hopf.math.purdue.edu". This is readonly system, so about all
you do without getting kicked off is run SD, MBASIC, etc.
Clarence Wilkersondarcy@druid.uucp (D'Arcy J.M. Cain) (01/17/91)
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 |