8080 vs. Z80 in CP/M applications.

[Roberto Waltman]

A recent thread in comp.sys.raspberry-pi drifted into a discussion
about the ZX80 and 8-bitters, which eventuallly lead me to claim:

"... while a standard CP/M OS required only the 8080 instruction set,
many applications written for CP/M used the extended Z80 set.
So using a Z80 in CP/M machines was almost a requirement."

Replies:

a) "I don't think that was true since a lot of software written to
take advantage of the Z80 instruction set often included 8080 support
and simply tested which cpu was in control of the show and loaded the
appropriate modules. This made such application software, essentially,
CPU agnostic, maximising its market reach."

b) "Most commercial software just used 8080 instructions. There was
some software that only ran on the Z80, mostly public domain stuff."

Any comments?
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]

[Bill Leary]

"Roberto Waltman" wrote in message
news:fi5tv818tetvn4b4q...@4ax.com...

> A recent thread in comp.sys.raspberry-pi drifted into a discussion
> about the ZX80 and 8-bitters, which eventuallly lead me to claim:
>
> "... while a standard CP/M OS required only the 8080 instruction set,
> many applications written for CP/M used the extended Z80 set.
> So using a Z80 in CP/M machines was almost a requirement."

I'm not sure about "many." But then, my machines were Z80 based, so I
didn't really pay close attention.

> Replies:
>
> a) "I don't think that was true since a lot of software written to
> take advantage of the Z80 instruction set often included 8080
> support and simply tested which cpu was in control of the show
> and loaded the appropriate modules. This made such application
> software, essentially, CPU agnostic, maximising its market reach."
>
> b) "Most commercial software just used 8080 instructions. There was
> some software that only ran on the Z80, mostly public domain stuff."
>
> Any comments?

My experience only, others may well have had different experiences.

a) I encountered very little code that did this. It seems that if you were
going to go to the trouble to code (assembler) to 8080 at all, you just
coded for the 8080 and didn't bother to do the Z80. Coding with high level
languages was a bit different. If the compiler offered an 8080/Z80 switch,
then you might find the test and load as noted. But more common, to my
recollection, was there would be two executable versions. The 8080, of
course, ran on either. The Z80 failed on an 8080. You copied whichever was
appropriate to your floppy or hard disk.

b) Is probably at least partially true. On the commercial side I recall a
database package that needed a Z80. And, of course, Turbo Pascal. On the
shareware/public domain/hobby side there may have been a lot. But since my
machines and most of my customers had Z80's, I didn't really pay that much
attention. I did have one customer who had an 8080 box. For him, I did the
compiler switch thing and produce 8080 code. Everyone else got the Z80
build.

- Bill

[s_dub...@yahoo.com]

You are right that the 'standard cp/m' only required 8080 code. That is, the DRI OS and DRI toolsets were developed with the Intel Development System (8080) as the target platform.

When the Z80 became widespread, then third party software utilizing the Z80 followed. The Z80 has some desirable features over the 8080, with the competitive edge, that is where the market went. I never had an 8080 based CP/M machine. My Timex/Sinclair Z81 and my Amstrad PCW and a friends Superbrain all came with Z80's. He rewrote his cp/m OS in Z80 code to tweak some features he needed for data acquisition and hard drive support.

I rather doubt the claim of a), at least I can't point to an example of that (dual use code). I do recall software claims of 'z80 required' though.

As to claim b), by the time of the Amstrad PCW, you bought commercial software built for your machine. Commercial software for the Amstrad PCW, for sure, required not only the Z80 but also utilized the special graphics it offered, as well as its peripherals, (special printer), (additional RAM - 256k).

Steve

[Ed]

I'd say it was more 8085 vs. Z80. In my field (communications electronics)
it was the former that was most often found buried inside an instrument.
I'm guessing major manufacturers preferred to go with the industry leader
(Intel) rather than a start-up (Zilog). I'm reminded of a logic analyzer we
had which also ran CP/M. It used an 8085.

[Chris B]

I agree. The release of the Z80 obsoleted the 8080 instantly because the Z80 needed only 5 volts whereas the 8080 required +5V, +12V and -5V as well as a seperate clock driver chip. If I recall correctly, Intel released the 8085 in response the the Z80 which solved these problems. However, there were no improvements to the instruction set. Nearly all CP/M systems used Z80s because using an 8085 would be perceived as a disadvantage in competing with the majority of the CP/M market that all were using Z80s.

As an industry, it was opportunity lost by not writing code to take advantage of the Z80's greatly expanded instruction set. This meant that code took up more memory space, which wasn't that big of a problem. I do remember how writing code for 8085 backward compatibility was more laborious. The 8080 couldn't directly save a copy of the DE, BC or SP, for instance.

[glen herrmannsfeldt]

Chris B <cb...@sbcglobal.net> wrote:

(snip)

>> I'd say it was more 8085 vs. Z80. In my field (communications electronics)

(snip)

> I agree. The release of the Z80 obsoleted the 8080 instantly
> because the Z80 needed only 5 volts whereas the 8080
> required +5V, +12V and -5V as well as a seperate clock driver
> chip. If I recall correctly, Intel released the 8085 in response
> the the Z80 which solved these problems. However, there were no
> improvements to the instruction set.

As I remember from the Osborne book on 8 bit processors, they
consider both the 8085 and Z80 have an equal claim as descendants,
as the Z80 was designed by a group who left intel from the 8080
group.

The supply voltage naturally scales with the size of MOS
transistors. I believe they have an internal charge pump
to supply the substrate bias (-5V).

The Z80, unlike the 8080, was built with static logic.
That allowed stopping the clock for debugging. (More for
embedded development than for CP/M, though.)

The extra Z80 instructions were convenient, I am not sure
that they ran so much faster, though.

-- glen

[Mr. Emmanuel Roche, France]

Hello, Glen!

> The extra Z80 instructions were convenient,
> I am not sure that they ran so much faster, though.

Indeed.

Each time that a Forth was written in Z-80 code, it was slower than the previously available Forths in 8080 code!

Only a handful of opcodes remained available.

Hence the curious, un-orthogonal instruction set of the Z-80, known as the "Zoo" to some programmers...

Yours Sincerely,
Mr. Emmanuel Roche, France

[Ed]

Chris B wrote:
> ...

> As an industry, it was opportunity lost by not writing code to take advantage of the Z80's
> greatly expanded instruction set. This meant that code took up more memory space, which
> wasn't that big of a problem. I do remember how writing code for 8085 backward compatibility
> was more laborious. The 8080 couldn't directly save a copy of the DE, BC or SP, for
> instance.

My impression is the Z80 was a favourite of small companies producing controllers
as they could employ hobbyists familiar with the chip. This didn't last as the Z80 still
required a swag of support chips. For small projects the new "all-in-one" microcontroller
chips (8048/51 etc) were more economical. By this time CP/M was fading away, and
the 8080/85/Z80 with it.

[Chris B]

At all times, most Z80s were being used in dedicated-purpose computers such as microcontrollers and video games. CP/M systems were a brief but notable use for the Z80 in its 40 years of production.

I didn't have the impression that companies chose the Z80 because it would mean they could hire hobbyists to do development. But I do believe there are many cases where hobbyists did turn their hobby into employment because of the Z80.

I chose the Z80 as the CPU of an industrial microcontroller for a company I worked for in the 1980s because it was capable, inexpensive and tools were widely available. My design didn't happen to need any support chips.

Over time, the Z80 CPU evolved to include more and more integrated support. Just look at the eZ80; 10 years old, but in a single chip, it has flash ROM, RAM, UARTs, I2C, SPI, clock/calendar, an ethernet MAC, PLL, timers, an interrupt controller, IrDA, PWM, GPIO and a JTAG debugger.

Chris Brock

[Ed]

Chris B wrote:
> ...

> I didn't have the impression that companies chose the Z80 because it would mean they could
> hire hobbyists to do development. But I do believe there are many cases where hobbyists did
> turn their hobby into employment because of the Z80.

Agreed.

> Over time, the Z80 CPU evolved to include more and more integrated support. Just look at
> the eZ80; 10 years old, but in a single chip, it has flash ROM, RAM, UARTs, I2C, SPI,
> clock/calendar, an ethernet MAC, PLL, timers, an interrupt controller, IrDA, PWM, GPIO and a
> JTAG debugger.

I haven't kept up with technology and wasn't aware of that chip. I recall a Z80-like chip being
used in early Gameboys (?)

[Greegor]

In 2005, Cheap Chinese MP/3 players
used the Actions Semiconductor
ATJ2085 System on Chip which runs
Z-80 code at up to 60 MHz.