fzsitvay@techbook.com (Frank Zsitvay) (10/30/90)
In article <22875@grebyn.com> bob@grebyn.com (Robert A. Baumann) writes: >In article <1990Oct24.233232.11580@mthvax.cs.miami.edu>, max@mthvax.cs.miami.edu (Max Southall) writes: >> Not liking Joan's attitude as a reason for using and not paying for her >> CP/M and Z80 emulation package sounds like a rather convenient >> justification for taking advantage and saving bucks. If you feel you can't >> use her stuff in good conscience, don't use it at all. That's like saying >> it's OK to rob banks because some of them invest in South Africa! Sheesh. >> >> References: <1990Oct19.204926.17576@techbook.com> <PLTFR2w163w@ijpc.UUCP> <6435@plains.NoDak.edu> > > >Er... This is a fascinating discussion. What's intriguing to me is that >Z80MU *DOES* support the "set DMA" call perfectly well! Furthermore, >every assembler and compiler and loader that we've come across works >perfectly well under Z80MU. At least, they work perfectly well under >LEGITIMATE copies of Z80MU. > the copy of z80mu i have is version 3.10, dated 3/14/86. it does not run load.com, the cp/m hex loader. i doubt that it is a corrupted copy (i.e. corrupted by a missed error in transfer) because it gives me an error message. it doesn't lock up the system, it terminates the loader, says that i'm trying to use an unsupported feature, and gives me back the artificial ccp prompt. it even identifies the function i'm trying to use. if the gremlins of crc error dectection are at work, they sure did a thorough job!! >Is it possible that somebody is using a corrupted copy of Z80MU? That's >the only logical explanation that I can think of. We have seen quite a few >corrupted copies out there. Who knows how or why it happens, but that's >the breaks of Electronic Distribution. Once you let it out, you can't >control what happens to it. > now, there is always the possibility that somebody "patched" it to make it fail, but i doubt this. most idiots that go to the trouble to do that would have done other things, like low leveled my hard disk, written sporatic trash into the directory, or scrambled the FAT. z80mu is nice, when it works. it's about as fast as a 2mhz z80 on my system (16mhz 286 with neat chipset and very fast ram) but it seems that it (at least the one i have) doesn't emulate cp/m as well as i need for my uses, so i'll probably stick to running cp/m code on a cp/m machine. the z80 emulation is fine, but if it can't run cp/m then it's REALLY an orphan. >I'm setting the record straight because I own Z80MU. Not a copy of it. The >*REAL* Z80MU that Joan Riff wrote for me 4 years ago and that I rewrote >myself. That's how I know that a *REAL* copy supports CP/M 2.2 perfectly >well, even down to redirecting hardware I/O port addresses to 16-bit >IBM PC port addresses for you fanatics who *REALLY* want to run a CP/M >version of KERMIT or whatever. > >Drop me a line. I'll be glad to help to identify legitimate copies of >Z80MU 3.10 (the last public domain version) and Z80MU 5.2b (the >current, commercial version). > >There are thousands of folks running *LOTS* of off-the-wall CP/M software >with Z80MU, and just about everything works perfectly well for them. > >Gosh, maybe there *ARE* benefits to buying a legitimate copy... > > Bob Baumann > Computerwise Consulting Services > P.O. Box 813, McLean, VA 22101 > (703) 450-7175 -- fzsitvay@techbook.COM - but don't quote me on that.... American Oil Company motto - Bend over, We'll pump!!!
zeke@shamash.cdc.com (Robert Scott) (10/31/90)
What an interesting discussion about Joan Riff and her software. Now how about you move it to misc.elsewhere? Zeke -- ~~~~~~~~~~~ From the Shrine of the "Last Gasp of ETA Systems" ~~~~~~~~~~~~~ Extra zesty disclaimer: MINE! MINE! ALL MINE! <chortle snort froth drool> Robert K. "Zeke" Scott internet: zeke@eta.cdc.com Control Data Corp, Supercomputer Support Group
fzsitvay@techbook.com (Frank Zsitvay) (10/31/90)
In article <22875@grebyn.com> bob@grebyn.com (Robert A. Baumann) writes: >In article <1990Oct24.233232.11580@mthvax.cs.miami.edu>, max@mthvax.cs.miami.edu (Max Southall) writes: > >Er... This is a fascinating discussion. What's intriguing to me is that >Z80MU *DOES* support the "set DMA" call perfectly well! Furthermore, >every assembler and compiler and loader that we've come across works >perfectly well under Z80MU. At least, they work perfectly well under >LEGITIMATE copies of Z80MU. > >I'm setting the record straight because I own Z80MU. Not a copy of it. The >*REAL* Z80MU that Joan Riff wrote for me 4 years ago and that I rewrote >myself. That's how I know that a *REAL* copy supports CP/M 2.2 perfectly >well, even down to redirecting hardware I/O port addresses to 16-bit >IBM PC port addresses for you fanatics who *REALLY* want to run a CP/M >version of KERMIT or whatever. > another beef... z80mu 3.10 does not support parameters in a submit command. i.e. simple submit files work, but when you have any parameters after the sub filename, it gives you an invocation summary, and does not run the command. this is a big problem for me since i use submit files to automate program assembly and compilation. this requires specifying the source filename after the subfile name. > > Bob Baumann > Computerwise Consulting Services > P.O. Box 813, McLean, VA 22101 > (703) 450-7175 -- fzsitvay@techbook.COM - but don't quote me on that.... American Oil Company motto - Bend over, We'll pump!!!
ianj@ijpc.UUCP (Ian Justman) (10/31/90)
fzsitvay@techbook.com (Frank Zsitvay) writes: > the z80 emulation is fine, but if it can't run cp/m then it's > REALLY an orphan. I personally don't use Z80MU or even 22NICE all that much. My hard disk space is currently devoted to other tasks. When I do need to run a Z80-based application on an oddball setup, I go to my CompuPro System 8/16 running Concurrent DOS 8/16. I can run a few well-behaved MS-DOS programs on it, like PKARC (PKZIP isn't that well-behaved with CDOS). Plus with SPUZ board, that thing can run Z80-based applications like a bat out of hell with a Z80H processor on it! Also I have gobs of TPA space because "BDOS" and "BIOS" (actually, the bulk thereof) are located outside of the SPUZ's memory area (what IS in there is some code to prepare to jump to the 86 XIOS code), so I can do some memory-intensive stuff. As for software emulation of a Z80, I have heard that the 68K would be a better candidate for the job than, say, the 8088, or even the 80286.