@MSGID:
<186bfee3-5fa1-4615-91e2-a7acab65ef8en@googlegroups.com> 0dd166e7
@REPLY: 2@dont-email.me> 68068777
@REPLYADDR Bill McMullen
<mcmullenbill0@gmail.com>
@REPLYTO 2:5075/128 Bill McMullen
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<0b23887c-d521-4424-8e62-8758cb92c763n@googlegroups.com> <72829363-c906-4557-ac1c-50a925bc1639n@googlegroups.com>
1@dont-email.me> 1@reader2.panix.com> 1@dont-email.me>
1@dont-email.me> <53812a97-960c-435a-928b-56c5cff20183n@googlegroups.com>
2@dont-email.me>
@RFC-Message-ID:
<186bfee3-5fa1-4615-91e2-a7acab65ef8en@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
 "IMO, the Z180 is not a good example of a "z80 based" CPU. It
broke the I/O opcodes that used the content of the C register to address
ports."

 Perhaps I`m just not experienced enough as I`ve only built more
than a hundred Z80, Z180 and eZ80 systems, all of my own design and
with totally self-written BIOS software as appropriate. With that being
said, I don`t understand the "broken" I/O instruction reference. In my
experience, it`s Z80 software that`s broken when it is limited to hardware that
doesn`t implement the full Z80 capabilities.

 I have heard people refer to the difference between 8-bit I/O and
16-bit I/O, but that argument always seems to devolve into the fact that
someone wrote 8-bit I/O software for a Z80 system where the hardware
designer chose not to implement the full 16-bit I/O capabilities. Indeed, the
IN r,(C) and OUT (C),r instructions have exactly the same definitions
in the Z80, Z180 and eZ80 User Manuals from Zilog. The primary
difference in these 3 variants is that the Z180 reserves a block of 40h I/O
address in the range 00x0h and the eZ80 reserves the entire 00xxh I/O
address range for internal I/O addresses.
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441