Z80 v Z180

[Randy McLaughlin]

Does anyone have any code snippets to tell if you are running on a Z180 in
software? I know how to tell between 8080 vs. z180 (carry).

[Randy McLaughlin]

Post by Randy McLaughlin
Does anyone have any code snippets to tell if you are running on a Z180 in
software? I know how to tell between 8080 vs. z180 (carry).

I already found the answer myself (a Zilog app note). If anyone else is
interested:

"There are three instructions that are not the same. They are: DAA and
RRD/RLD.

For DAA (Decimal adjust), if you execute this instruction after DEC
instruction (especially DEC instruction on 00h, then execute DAA), Z180
results in F9H while Z80 results in 99H. ..."

I clipped the RLD/RRD examples.

[Ross Simpson]

"Randy McLaughlin" wrote in message...

Post by Randy McLaughlin

Post by Randy McLaughlin
Does anyone have any code snippets to tell if you are running on a Z180 in
software? I know how to tell between 8080 vs. z180 (carry).

I already found the answer myself (a Zilog app note). If anyone else is
"There are three instructions that are not the same. They are: DAA and
RRD/RLD.
For DAA (Decimal adjust), if you execute this instruction after DEC
instruction (especially DEC instruction on 00h, then execute DAA), Z180
results in F9H while Z80 results in 99H. ..."
I clipped the RLD/RRD examples.

Isn't the Z180 supposed to be backward compatable with a Z80? & if so,
why are these commands returning different values, wouldn't that play
havoc if a Z80 program was executed on this Z180 which used these sorts
of calculations?

Cheers,
Ross.

[Lee Hart]

Post by Randy McLaughlin
For DAA (Decimal adjust), if you execute this instruction after DEC
instruction (especially DEC instruction on 00h, then execute DAA), Z180
results in F9H while Z80 results in 99H. ..."
I clipped the RLD/RRD examples.

Ouch. Is this a bug in the Z180? I would have expected

ld a,0
dec a
daa

to yield 99 hex in the accumulator, not F9 hex.

[Randy McLaughlin]

Post by Lee Hart

Post by Randy McLaughlin
For DAA (Decimal adjust), if you execute this instruction after DEC
instruction (especially DEC instruction on 00h, then execute DAA), Z180
results in F9H while Z80 results in 99H. ..."
I clipped the RLD/RRD examples.

Ouch. Is this a bug in the Z180? I would have expected
ld a,0
dec a
daa
to yield 99 hex in the accumulator, not F9 hex.
--
Lee A. Hart Ring the bells that still can ring
814 8th Ave. N. Forget your perfect offering
Sartell, MN 56377 USA There is a crack in everything
leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen

Personally I would call that a bug, but according to Willie boy Gates it's a
feature ;-)

I quoted (tha's why I used "...") a Zilog Z180 question and answer app note:

http://www.zilog.com/docs/z180/z180qa.pdf

[Jack Peacock]

Post by Randy McLaughlin

Post by Lee Hart
Ouch. Is this a bug in the Z180? I would have expected
ld a,0
dec a
daa
to yield 99 hex in the accumulator, not F9 hex.

Personally I would call that a bug, but according to Willie boy Gates it's a
feature ;-)

Well, one thing is you are doing a binary op on a BCD number. Decrementing
a BCD number should be ADD A,99H (BCD complement of -1) then DAA, which
would yield the correct number. My understanding of decimal adjust is that
it's only to be used after a BCD instruction: add, add w/carry, or subtract
w/carry, something about an internal half carry bit only being valid after
those instructions. The high bits in F9 indicate the half carry used by DAA
isn't properly set by a DEC instruction.

I wouldn't call it a bug because it's using the wrong instructions to
accomplish the task. In fact I'd say it's poor coding, taking advantage of
a particular processor variant's instruction results instead of using a
sequence of instructions valid on all variants.
Jack Peacock

[Randy McLaughlin]

Post by Jack Peacock

Post by Randy McLaughlin

Post by Lee Hart
Ouch. Is this a bug in the Z180? I would have expected
ld a,0
dec a
daa
to yield 99 hex in the accumulator, not F9 hex.

Personally I would call that a bug, but according to Willie boy Gates

it's

Post by Jack Peacock
a

Post by Randy McLaughlin
feature ;-)
I quoted (tha's why I used "...") a Zilog Z180 question and answer app

Well, one thing is you are doing a binary op on a BCD number.

Decrementing

Post by Jack Peacock
a BCD number should be ADD A,99H (BCD complement of -1) then DAA, which
would yield the correct number. My understanding of decimal adjust is that
it's only to be used after a BCD instruction: add, add w/carry, or subtract
w/carry, something about an internal half carry bit only being valid after
those instructions. The high bits in F9 indicate the half carry used by DAA
isn't properly set by a DEC instruction.
I wouldn't call it a bug because it's using the wrong instructions to
accomplish the task. In fact I'd say it's poor coding, taking advantage of
a particular processor variant's instruction results instead of using a
sequence of instructions valid on all variants.
Jack Peacock

On Intel & Zilog's non-Z18X you are allowed to DEC, only the Z180 acts this
way.

I happen to be OK with it, it allows me to know that it is a processor with
other built in functions (MMU etc) that needs to be initialized.

With 20/20 hindsight it is easy to say I wish they had a CPU ID instruction.

I need to modify some code that will run on a wide variety of CPU's. These
CPU's may be 8080, 8085, Z80, Z180, 68K, 8086/8088, etc. all running the
same IO card with a boot ROM. The biggest problem I see now is the memory
location of the boot ROM. For 8080+ and 68K being at address 0 is fine, for
8086 family it needs to be high.

[Ruud Baltissen]

Hallo Randy,

The biggest problem I see now is the memory location of the boot ROM.
For 8080+ and 68K being at address 0 is fine, for 8086 family it
needs to be high.

What about one that shows up at both ranges and using a simple MMU?
The only thing a CPU must do is to swap the not needed ROM for RAM.


--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org

[Randy McLaughlin]

Post by Ruud Baltissen
Hallo Randy,

The biggest problem I see now is the memory location of the boot ROM.
For 8080+ and 68K being at address 0 is fine, for 8086 family it
needs to be high.

What about one that shows up at both ranges and using a simple MMU?
The only thing a CPU must do is to swap the not needed ROM for RAM.
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org

Right now I am only working on getting a working Z80 monitor running on 8085
CPU's, I have nothing to do with the hardware.

I am creating hooks to other processors (especially Z180 initialization), I
intend to use Tutor (motorola's 68K monitor) for the 68K CPU's. Once I saw
that I could hook the 68K monitor using the same ROM as the 8080+ I was very
happy. Having one board with only one ROM that runs on multiple CPU's is
both a neat trick and has huge advantages for support, etc.

Luckily it turns out that supporting 8080, 8085, Z80, Z180, and 68K CPU's
using one ROM is simple. The first eight bytes are DB's that need to be
well commented as to why they are there, followed by the 8080 code.

[Lee Hart]

Post by Jack Peacock
I wouldn't call it a bug because it's using the wrong instructions
to accomplish the task.

Well, here's a quote from the Mostek Z80 Programming Manual v2.0:

DAA

This instruction conditionally adjusts the Accumulator for BCD addition
and subtraction operations. For addition (ADD, ADC, INC) or subtraction
(SUB, SBC, DEC, NEG) instructions, the following table indicates the
operation performed...

In other words, the Z80 clearly defined that DAA can be used after INC
and DEC and will produce the correct result. So, it would be perfectly
legitimate for Z80 software to do it. If the Z180 won't run this program
correctly, that's a bug.

[Randy McLaughlin]

Post by Lee Hart

Post by Jack Peacock
I wouldn't call it a bug because it's using the wrong instructions
to accomplish the task.

DAA
This instruction conditionally adjusts the Accumulator for BCD addition
and subtraction operations. For addition (ADD, ADC, INC) or subtraction
(SUB, SBC, DEC, NEG) instructions, the following table indicates the
operation performed...
In other words, the Z80 clearly defined that DAA can be used after INC
and DEC and will produce the correct result. So, it would be perfectly
legitimate for Z80 software to do it. If the Z180 won't run this program
correctly, that's a bug.
--
Lee A. Hart Ring the bells that still can ring
814 8th Ave. N. Forget your perfect offering
Sartell, MN 56377 USA There is a crack in everything
leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen

Since we all live in the kingdom of Micro$loth it's not a bug, it's a
feature.

[Michael J. Mahon]

Randy McLaughlin wrote:

<snip>

Post by Randy McLaughlin
Since we all live in the kingdom of Micro$loth it's not a bug, it's a
feature.

Come on, Randy--that expression was commonplace before
Microsoft existed. ;-)

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Randy McLaughlin]

Post by Michael J. Mahon
<snip>

Post by Randy McLaughlin
Since we all live in the kingdom of Micro$loth it's not a bug, it's a
feature.

Come on, Randy--that expression was commonplace before
Microsoft existed. ;-)
-michael
Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

I can't think of anyone that before Gates that declared obvios bugs to be
features. More than that if you have a dialup connection and load XP (and
you don't happen to have SP1 on CD) try and download the bug fixes. Name
anyone before Gates XP that had > 200mb of bug fixes.

[Michael J. Mahon]

Post by Randy McLaughlin

Post by Michael J. Mahon
<snip>

Post by Randy McLaughlin
Since we all live in the kingdom of Micro$loth it's not a bug, it's a
feature.

Come on, Randy--that expression was commonplace before
Microsoft existed. ;-)
-michael
Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

I can't think of anyone that before Gates that declared obvios bugs to be
features.

Nonsense--I've been programming since the 60's, and anytime
a "bug" was reported that the programmer didn't feel like fixing,
he/she argued that it was a "feature".

Many cases of "unexpected" behavior can, in fact, be defended
in this way. Of course, some are clearly bugs. ;-)

But the joke is almost as old as computers (but not quite
as old as Grace Hopper ;-).

Post by Randy McLaughlin
More than that if you have a dialup connection and load XP (and
you don't happen to have SP1 on CD) try and download the bug fixes. Name
anyone before Gates XP that had > 200mb of bug fixes.

...and OS/360 had several thousand "known bugs", only a fraction
of which had patches.

The total size of patched code is irrelevant, since now the preferred
way to "patch" is to distribute a complete new DLL. The number
of bugs is also meaningless unless normalized by the number of
non-comment source lines that contain them.

Any sufficiently large software system will have a large number
of bugs--both known and unknown.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[J.C. Wren]

Michael J. Mahon wrote:

[snip]

Post by Michael J. Mahon
The total size of patched code is irrelevant, since now the preferred
way to "patch" is to distribute a complete new DLL. The number
of bugs is also meaningless unless normalized by the number of
non-comment source lines that contain them.

So adding comments fixes bugs? :)

--jc

(It's all in how you parse it)

[Michael J. Mahon]

Post by J.C. Wren
[snip]

Post by Michael J. Mahon
The total size of patched code is irrelevant, since now the preferred
way to "patch" is to distribute a complete new DLL. The number
of bugs is also meaningless unless normalized by the number of
non-comment source lines that contain them.

So adding comments fixes bugs? :)

Sorry if the statement was formally ambiguous.

Clearly it means that only non-comment source lines should
be counted for the denominator. It is the non-comment source
lines that contain the bugs (unless we are considering _documentation_
bugs ;-).

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Randy McLaughlin]

Post by Michael J. Mahon

Post by J.C. Wren
[snip]

Post by Michael J. Mahon
The total size of patched code is irrelevant, since now the preferred
way to "patch" is to distribute a complete new DLL. The number
of bugs is also meaningless unless normalized by the number of
non-comment source lines that contain them.

So adding comments fixes bugs? :)

Sorry if the statement was formally ambiguous.
Clearly it means that only non-comment source lines should
be counted for the denominator. It is the non-comment source
lines that contain the bugs (unless we are considering _documentation_
bugs ;-).
-michael
Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

A well comment source lets the reader (of the comments) know what the
programmer wanted to do, it does not necessarily tell you what the program
does.

[Lee Hart]

I can't think of anyone that before Gates that declared obvious
bugs to be features.

It is an old joke. I have a cartoon in my 'idiocy file' from the early
1970s. On the left is a drawing of a cockroach, and under it the word
"BUG". On the right is a drawing of the same cockroach, but wearing a
suit and tie; underneath it is the word "FEATURE".

So adding comments fixes bugs? :)

Certainly! The comment says, "It's supposed to do that." :-)

[Exegete]

This post might be inappropriate. Click to display it.

[Ross Simpson]

"Michael J. Mahon" wrote in message...

Post by Michael J. Mahon
<snip>

Post by Randy McLaughlin
Since we all live in the kingdom of Micro$loth it's not a bug, it's a
feature.

Come on, Randy--that expression was commonplace before
Microsoft existed. ;-)

I'm not so sure Grace Hopper would have refered to the first reported
computer bug a feature.

Cheers,
Ross.

[Michael J. Mahon]

Post by Ross Simpson
"Michael J. Mahon" wrote in message...

Post by Michael J. Mahon
<snip>

Post by Randy McLaughlin
Since we all live in the kingdom of Micro$loth it's not a bug, it's a
feature.

Come on, Randy--that expression was commonplace before
Microsoft existed. ;-)

I'm not so sure Grace Hopper would have refered to the first reported
computer bug a feature.

That's because she was complaining about it. (Remember, it was
a hardware bug, not a software bug.)

The hardware designer might have been tempted to defend it. ;-)

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Ross Simpson]

"Michael J. Mahon" wrote in message...

Post by Michael J. Mahon

Post by Ross Simpson

Post by Michael J. Mahon
<snip>

Post by Randy McLaughlin
Since we all live in the kingdom of Micro$loth it's not a bug, it's a
feature.

Come on, Randy--that expression was commonplace before
Microsoft existed. ;-)

I'm not so sure Grace Hopper would have refered to the first reported
computer bug a feature.

That's because she was complaining about it. (Remember, it was
a hardware bug, not a software bug.)

Sure, the Amstrad CPC464 had some nice features in it's BASIC! ;-)

Unfortunately, I'll have to go back & see what they were! :-(
Or get someone in from comp.sys.amstrad.8bit to explain (if they'd
like)! :-)

Cheers,
Ross.

[Charles Richmond]

Post by Ross Simpson
"Michael J. Mahon" wrote in message...

Post by Michael J. Mahon
<snip>

Post by Randy McLaughlin
Since we all live in the kingdom of Micro$loth it's not a bug, it's a
feature.

Come on, Randy--that expression was commonplace before
Microsoft existed. ;-)

I'm not so sure Grace Hopper would have refered to the first reported
computer bug a feature.

ISTM that this was *not* the first reported computer bug, if
you are referring to what I think you are. A moth was found
under some relay contacts, and the caption in the log read:

"First actual case of bug being found."

IOW, there had been many bugs before, but finally an actual
"bug" was found...the moth. That is my interpretation.


--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[Charles Richmond]

Post by Lee Hart

Post by Jack Peacock
I wouldn't call it a bug because it's using the wrong instructions
to accomplish the task.

DAA
This instruction conditionally adjusts the Accumulator for BCD addition
and subtraction operations. For addition (ADD, ADC, INC) or subtraction
(SUB, SBC, DEC, NEG) instructions, the following table indicates the
operation performed...
In other words, the Z80 clearly defined that DAA can be used after INC
and DEC and will produce the correct result. So, it would be perfectly
legitimate for Z80 software to do it. If the Z180 won't run this program
correctly, that's a bug.

ISTM that what is needed is that the "add" instruction sets
the "half carry" flag (HC). If INC and DEC will *not* affect
the half carry flag, then DAA will *not* work with these
instructions.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[Randy McLaughlin]

Post by Charles Richmond

Post by Lee Hart

Post by Jack Peacock
I wouldn't call it a bug because it's using the wrong instructions
to accomplish the task.

DAA
This instruction conditionally adjusts the Accumulator for BCD addition
and subtraction operations. For addition (ADD, ADC, INC) or subtraction
(SUB, SBC, DEC, NEG) instructions, the following table indicates the
operation performed...
In other words, the Z80 clearly defined that DAA can be used after INC
and DEC and will produce the correct result. So, it would be perfectly
legitimate for Z80 software to do it. If the Z180 won't run this program
correctly, that's a bug.

ISTM that what is needed is that the "add" instruction sets
the "half carry" flag (HC). If INC and DEC will *not* affect
the half carry flag, then DAA will *not* work with these
instructions.
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

I did not quote the full text from Zilog:

"There are three instructions which are not the same. They are: DAA and
RRD/RLD.

For DAA (Decimal adjust), if you execute this instruction after DEC
instruction (especially DEC instruction on 00h, then execute DAA), Z180
results in F9H while Z80 results in 99H. It is because the Z80 CPU refers
"Internal Carry flag" while the Z180 doesn't. For RLD/RRD (Rotate
Left/Right Digit), Z180's flag will reflect the contents of the memory
location pointed by HL register, while Z80 reflects the contents of the
Accumulator.

But, there are very few applications which use DAA instructions after DEC
and use flag after RLD/RRD instructions."

It is obvious that Zilog does consider it to be a bug, but they decided to
leave it alone (for consistency I assume). I happen to appreciate the bugs
since they allow me to determine CPU type.

http://www.zilog.com/docs/z180/z180qa.pdf

[Jack Peacock]

Post by Randy McLaughlin
But, there are very few applications which use DAA instructions after DEC
and use flag after RLD/RRD instructions."
It is obvious that Zilog does consider it to be a bug, but they decided to
leave it alone (for consistency I assume). I happen to appreciate the bugs
since they allow me to determine CPU type.

Since Zilog didn't build the first iteration of the Z180 it may be they
inherited the bug from the original Hitachi HD64180. Then it beomes a
question of fix the bug to keep Z80 compatibility, or leave it in to
maintain 64180 compatibility. Given that the Z180 was the replacement for
the 64180 when Hitachi gave up on it leaving the bug in place made sense.
The Z80 had moved from general purpose CPU for early PCs to embedded
controller as it's primary market by then, so any new design would be more
likely based on the 64180 and the follow on Z180.

I used a 64180 in an embedded design that included BCD arithmetic, never
even noticed the DEC A bug since I've always used ADD/SBC before DAA. It
was habit from other processors that also had a DAA equivalent instruction.

I still have a running 64180 based CPM V3 system, based on a spare board
from the project. I never noticed any problems from the bug, though I don't
do much other than run an assembler on it.
Jack Peacock

[Scott Moore]

Post by Jack Peacock

Post by Randy McLaughlin
But, there are very few applications which use DAA instructions after DEC
and use flag after RLD/RRD instructions."
It is obvious that Zilog does consider it to be a bug, but they decided to
leave it alone (for consistency I assume). I happen to appreciate the

bugs

Post by Randy McLaughlin
since they allow me to determine CPU type.

Since Zilog didn't build the first iteration of the Z180 it may be they
inherited the bug from the original Hitachi HD64180. Then it beomes a
question of fix the bug to keep Z80 compatibility, or leave it in to
maintain 64180 compatibility. Given that the Z180 was the replacement for
the 64180 when Hitachi gave up on it leaving the bug in place made sense.

Zilog aquired the design from Hitachi as part of a lawsuit. So you could
say they are equivalent. However, the Z80 itself was redesigned several
times. It had to be, it went from NMOS to CMOS, a fairly radical change.
However, it also went from random logic to microcoded core at one
point. My ex boss at Zilog was famous for doing that one.

Post by Jack Peacock
The Z80 had moved from general purpose CPU for early PCs to embedded
controller as it's primary market by then, so any new design would be more
likely based on the 64180 and the follow on Z180.

Yea, Zilog appears to have depreciated the z380 for their new ez80, which
is in the Z180 family. The z380 was not Z180 compatible. It was actually
better, using real memory management instead of a bank selection scheme,
but the processor series is so old that most customers only are interested
in supporting existing, very old, code.

Post by Jack Peacock
I used a 64180 in an embedded design that included BCD arithmetic, never
even noticed the DEC A bug since I've always used ADD/SBC before DAA. It
was habit from other processors that also had a DAA equivalent instruction.
I still have a running 64180 based CPM V3 system, based on a spare board
from the project. I never noticed any problems from the bug, though I don't
do much other than run an assembler on it.
Jack Peacock

There are Z80s in use, but not too many 8080s I'll bet, the series has better
staying power than the original grandpaw processor.

[Lee Hart]

Post by Charles Richmond

Post by Lee Hart

Post by Jack Peacock
I wouldn't call it a bug because it's using the wrong instructions
to accomplish the task.

DAA
This instruction conditionally adjusts the Accumulator for BCD addition
and subtraction operations. For addition (ADD, ADC, INC) or subtraction
(SUB, SBC, DEC, NEG) instructions, the following table indicates the
operation performed...
In other words, the Z80 clearly defined that DAA can be used after INC
and DEC and will produce the correct result. So, it would be perfectly
legitimate for Z80 software to do it. If the Z180 won't run this program
correctly, that's a bug.

ISTM that what is needed is that the "add" instruction sets
the "half carry" flag (HC). If INC and DEC will *not* affect
the half carry flag, then DAA will *not* work with these
instructions.

Right. But in the Z80, INC and DEC *do* correctly set the half carry
flag. So, DAA *does* work with them.

[Charles Richmond]

Post by Lee Hart

Post by Charles Richmond

Post by Lee Hart

Post by Jack Peacock
I wouldn't call it a bug because it's using the wrong instructions
to accomplish the task.

DAA
This instruction conditionally adjusts the Accumulator for BCD addition
and subtraction operations. For addition (ADD, ADC, INC) or subtraction
(SUB, SBC, DEC, NEG) instructions, the following table indicates the
operation performed...
In other words, the Z80 clearly defined that DAA can be used after INC
and DEC and will produce the correct result. So, it would be perfectly
legitimate for Z80 software to do it. If the Z180 won't run this program
correctly, that's a bug.

ISTM that what is needed is that the "add" instruction sets
the "half carry" flag (HC). If INC and DEC will *not* affect
the half carry flag, then DAA will *not* work with these
instructions.

Right. But in the Z80, INC and DEC *do* correctly set the half carry
flag. So, DAA *does* work with them.

Right...and if I understand all this correctly, the original
point was that the Z180 does *not* have the DAA work correctlty
after using and INC or DEC. And the Z80 does...so nee-ner,
nee-ner, nee-ner... ;-) That way some ingenious folk can
use this difference (aka bug) to determine which processor that
the software is running on.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[Harold Bower]

On Sun, 11 Jan 2004 14:14:26 -0600

Post by Randy McLaughlin
Does anyone have any code snippets to tell if you are running on a
Z180 in software? I know how to tell between 8080 vs. z180 (carry).

8080 vs Z80/Z180

Perform 8-bit subtraction. Parity flag reflects overflow instead of
parity

Z80 vs Z180

Do 8 by 8 multiply (e.g. 2 in E x 3 in D) and check result in DE for 6

Hal

[Randy McLaughlin]

Post by Harold Bower
On Sun, 11 Jan 2004 14:14:26 -0600

Post by Randy McLaughlin
Does anyone have any code snippets to tell if you are running on a
Z180 in software? I know how to tell between 8080 vs. z180 (carry).

8080 vs Z80/Z180
Perform 8-bit subtraction. Parity flag reflects overflow instead of
parity
Z80 vs Z180
Do 8 by 8 multiply (e.g. 2 in E x 3 in D) and check result in DE for 6
Hal

Thanks, I am setting up a ROM monitor that initializes Z180 when present.
The fun part is I'm putting 68K monitor with it (the 1st 8 bytes will
contain the address for RAM & 68K monitor that are also 8080 instructions
that can be ignored). It will end up with one ROM that recognizes what CPU
and be able to handle 8080, 8085, Z80, Z180, or 68K.

[Michael J. Mahon]

Post by Randy McLaughlin
Thanks, I am setting up a ROM monitor that initializes Z180 when present.
The fun part is I'm putting 68K monitor with it (the 1st 8 bytes will
contain the address for RAM & 68K monitor that are also 8080 instructions
that can be ignored). It will end up with one ROM that recognizes what CPU
and be able to handle 8080, 8085, Z80, Z180, or 68K.

Now _that_ sounds like fun!

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Randy McLaughlin]

Just for fun is there anyway in software to tell the difference between 8080
& 8085?