andrei-n <andrei.nesterov@gmail.com> writes:

> Ideal for me would be if it doesn't use any chip more powerful than a
> Z80, and, of course only one Z80.

I'd have no problems with other helpers like micro-controllers with some
big IFs attached:

IF and only IF the assembler for them exists on the OS of that Z80
system too and IF that Z80 system can program those helper chips.

Why?

To avoid the permanent need for a PC nanny to run strange SDKs of insane
sizes.

The ideal Z80 system should be an own complete "digitope".

--
|rom The Future. +++ Breaking News From The Future. +++ Breaking News F|
| The USoA are switching to the binary number system because |
| having more than 1+1 distinct digits is far too woke. |
|+ #MABA + #makeAmericaBinaryAgain + #USA + #USoA + #woke + #MABA + #ma|

> Let's not forget the Z80 itself was a new processor
> built upon an old design and became popular for that reason.

Yes, no, kinda, maybe?
8080 compatibility definitely helped on the software side,
running CP/M and such.

But the Z80's hardware was tremendously easier to use,
almost like silicon-chip Lego, thus becoming the favorite for embedded systems
such as "smart modems", SCSI controllers, terminal servers.
In a way, the Z80 peripherals were "the tail wagging the dog"
because they were so popular, particularly the SIO dual-channel serial I/O chips.

Z80 hardware features:

+5 volts only, no +/- 12v

single phase clock: no special clock generator required

Z80 native peripheral chips self-arbitrated DMA and vectored interrupts via daisy-chain.
No interrupt controller required.

built in dram refresh cycle, making RAM interfacing easier.

The Z80 signals were so direct and easy to use
that they formed the basis of the STD bus (which was later extended).

I/O address space was separate from the 64k memory address space
due to IN, OUT instructions asserting the /IORQ signal instead of /MREQ

and other things :-)

--

> Let's not forget the Z80 itself was a new processor
> built upon an old design and became popular for that reason.

Yes, no, kinda, maybe?
8080 compatibility definitely helped on the software side,
running CP/M and such.

But the Z80's hardware was tremendously easier to use,
almost like silicon-chip Lego, thus becoming the favorite for embedded systems
such as "smart modems", SCSI controllers, terminal servers.
In a way, the Z80 peripherals were "the tail wagging the dog"
because they were so popular, particularly the SIO dual-channel serial I/O chips.

Z80 hardware features:

+5 volts only, no +/- 12v

single phase clock: no special clock generator required

Z80 native peripheral chips self-arbitrated DMA and vectored interrupts via daisy-chain.
No interrupt controller required.

built in dram refresh cycle, making RAM interfacing easier.

The Z80 signals were so direct and easy to use
that they formed the basis of the STD bus (which was later extended).

I/O address space was separate from the 64k memory address space
due to IN, OUT instructions asserting the /IORQ signal instead of /MREQ

and other things :-)

--

On 7/09/2023 1:50 pm, Jeff Jonas wrote:
>> Let's not forget the Z80 itself was a new processor
>> built upon an old design and became popular for that reason.
>
> Yes, no, kinda, maybe?
> 8080 compatibility definitely helped on the software side,
> running CP/M and such.
>
> But the Z80's hardware was tremendously easier to use,
> almost like silicon-chip Lego, thus becoming the favorite for embedded systems
> such as "smart modems", SCSI controllers, terminal servers.
> In a way, the Z80 peripherals were "the tail wagging the dog"
> because they were so popular, particularly the SIO dual-channel serial I/O chips.
>
> Z80 hardware features:
>
> +5 volts only, no +/- 12v
>
> single phase clock: no special clock generator required
>
> Z80 native peripheral chips self-arbitrated DMA and vectored interrupts via daisy-chain.
> No interrupt controller required.
>
> built in dram refresh cycle, making RAM interfacing easier.
>
> The Z80 signals were so direct and easy to use
> that they formed the basis of the STD bus (which was later extended).
>
> I/O address space was separate from the 64k memory address space
> due to IN, OUT instructions asserting the /IORQ signal instead of /MREQ
>
> and other things :-)

I worked in telecom. Equipment originating from Europe (Siemens) tended to
use the 8085 while the Japanese (Ando) used the Z80. So not a great deal
of difference between them in that market. Unlike Zilog, Intel appears
to have lost interest in the 8080 line. I wasn't aware the 8085's 'undoc'
instructions were actually new instructions which Intel, in their wisdom,
chose to disown.

On 2023-09-07, dxforth <dxforth@gmail.com> wrote:
> On 7/09/2023 1:50 pm, Jeff Jonas wrote:
>>> Let's not forget the Z80 itself was a new processor
>>> built upon an old design and became popular for that reason.
>>
>> Yes, no, kinda, maybe?
>> 8080 compatibility definitely helped on the software side,
>> running CP/M and such.
>>
>> But the Z80's hardware was tremendously easier to use,
>> almost like silicon-chip Lego, thus becoming the favorite for embedded systems
>> such as "smart modems", SCSI controllers, terminal servers.
>> In a way, the Z80 peripherals were "the tail wagging the dog"
>> because they were so popular, particularly the SIO dual-channel serial I/O chips.
>>
>> Z80 hardware features:
>>
>> +5 volts only, no +/- 12v
>>
>> single phase clock: no special clock generator required
>>
>> Z80 native peripheral chips self-arbitrated DMA and vectored interrupts via daisy-chain.
>> No interrupt controller required.
>>
>> built in dram refresh cycle, making RAM interfacing easier.
>>
>> The Z80 signals were so direct and easy to use
>> that they formed the basis of the STD bus (which was later extended).
>>
>> I/O address space was separate from the 64k memory address space
>> due to IN, OUT instructions asserting the /IORQ signal instead of /MREQ
>>
>> and other things :-)
>
> I worked in telecom. Equipment originating from Europe (Siemens) tended to
> use the 8085 while the Japanese (Ando) used the Z80. So not a great deal
> of difference between them in that market. Unlike Zilog, Intel appears
> to have lost interest in the 8080 line. I wasn't aware the 8085's 'undoc'
> instructions were actually new instructions which Intel, in their wisdom,
> chose to disown.

What about Steve Ciarcia's (sp?) SB180 single board computer as featured in
Byte Magazine (before it's demise). He had a column called "Circuit
Cellar", I think.

As I recall, though, it used a Hitachi chip of some sort rather than a Z80.

Well, CP/M faded from the scene far too early in my opinion, but I still use
jstar to satisfy my WordStar finger memory from thsoe days.

pH in Aptos

pH <wNOSPAMp@gmail.org> writes:

> What about Steve Ciarcia's (sp?) SB180 single board computer as
> featured in Byte Magazine (before it's demise). He had a column
> called "Circuit Cellar", I think.
>
> As I recall, though, it used a Hitachi chip of some sort rather than a
> Z80.

This one?

<https://archive.org/details/BYTE_Vol_10-09_1985-09_10th_Anniversary_Issue>

--
This stealth signature intentionally left blank.

On Thursday, September 7, 2023 at 9:03:26 AM UTC-7, pH wrote:
.....<snip>......
> What about Steve Ciarcia's (sp?) SB180 single board computer as featured in
> Byte Magazine (before it's demise). He had a column called "Circuit
> Cellar", I think.

Correct on all counts! The Ciarcia SBC was based on the Hitachi Z180. 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. There was a good reason for that (too detailed to go into here), but unfortunately those opcodes were used in a lot of legacy Z80 applications. It was a nifty way to address multiple I/O ports just by changing the content of C. In order to run those old Z80 applications on a Z180, the parts of the code that used those opcodes had to be rewritten.

The claim was that the Z180 was 100% binary code compatible with the Z80 was obviously not true, and that might have been a factor in the lack of popularity of that CPU? It certainly never achieved the same level of acceptance as the venerable Z80! BTW, that same "glitch" might exist in the eZ80 as well. I just don't know.

Roger

On 2023-09-07, yeti <yeti@tilde.institute> wrote:
> pH <wNOSPAMp@gmail.org> writes:
>
>> What about Steve Ciarcia's (sp?) SB180 single board computer as
>> featured in Byte Magazine (before it's demise). He had a column
>> called "Circuit Cellar", I think.
>>
>> As I recall, though, it used a Hitachi chip of some sort rather than a
>> Z80.
>
> This one?
>
><https://archive.org/details/BYTE_Vol_10-09_1985-09_10th_Anniversary_Issue>
>

That sure looks to be the animal...wow, thanks for the link!
pH

On 2023-09-08, Roger Hanscom <norwestrzh@gmail.com> wrote:
> On Thursday, September 7, 2023 at 9:03:26 AM UTC-7, pH wrote:
> ....<snip>......
>> What about Steve Ciarcia's (sp?) SB180 single board computer as featured in
>> Byte Magazine (before it's demise). He had a column called "Circuit
>> Cellar", I think.
>
> Correct on all counts! The Ciarcia SBC was based on the Hitachi Z180.
> 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.
> There was a good reason for that (too detailed to go into here), but
> unfortunately those opcodes were used in a lot of legacy Z80 applications.
> It was a nifty way to address multiple I/O ports just by changing the
> content of C. In order to run those old Z80 applications on a Z180, the
> parts of the code that used those opcodes had to be rewritten.
>
> The claim was that the Z180 was 100% binary code compatible with the Z80
> was obviously not true, and that might have been a factor in the lack of
> popularity of that CPU? It certainly never achieved the same level of
> acceptance as the venerable Z80! BTW, that same "glitch" might exist in
> the eZ80 as well. I just don't know.
>
> Roger

Ah, I had not known any of those details about the Z180.

I wonder if any of those got out into the real world and used much.

pH

>

"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.

On 9/09/2023 1:51 am, Roger Hanscom wrote:
> ...
> The claim was that the Z180 was 100% binary code compatible with the Z80 was obviously not true, and that might have been a factor in the lack of popularity of that CPU? It certainly never achieved the same level of acceptance as the venerable Z80! BTW, that same "glitch" might exist in the eZ80 as well. I just don't know.

eZ80 borrows 'unused' instructions (LD B,B LD C,C LD D,D LD E,E) saying if
the assembler encounters them they will be replaced with NOPs. So clearly
not 'binary compatible'. Has Zilog ever made such a claim? Here's what
they say in the eZ80 manual:

"The Z80 and Z180 programs are executed on an eZ80 CPU with little or no
modification."

On Friday, September 8, 2023 at 4:31:58 PM UTC-5, pH wrote:

> I wonder if any of those got out into the real world and used much.
>
> pH
>
I have one of those blank boards that I bought back in the day. I rediscovered it during a clearout last year but I wasn't able to find the EPROM code for download anywhere, so it sits in my PCB drawer unused. I'd love to get it up and running though.

On 2023-09-19, mrgcm...@gmail.com <mrgcms2001@gmail.com> wrote:
> On Friday, September 8, 2023 at 4:31:58 PM UTC-5, pH wrote:
>
>> I wonder if any of those got out into the real world and used much.
>>
>> pH
>>
> I have one of those blank boards that I bought back in the day. I
rediscovered it during a clearout last year but I wasn't able to find
the EPROM code for download anywhere, so it sits in my PCB drawer unused. I
'd love to get it up and running though.

Maybe one of the hobby sites can write an eprom for you.
Here's a website that talks about it.

http://dunfield.classiccmp.org/mmint/

Maybe he'll pull his eprom and copy it for you.

pH

On Tuesday, September 19, 2023 at 11:04:28 PM UTC-4, pH wrote:
> On 2023-09-19, mrgcm...@gmail.com <mrgcm...@gmail.com> wrote:
> > On Friday, September 8, 2023 at 4:31:58 PM UTC-5, pH wrote:
> >
> > I have one of those blank boards that I bought back in the day. I
> rediscovered it during a clearout last year but I wasn't able to find
> the EPROM code for download anywhere, so it sits in my PCB drawer unused. I
> 'd love to get it up and running though.
> Maybe one of the hobby sites can write an eprom for you.
> Here's a website that talks about it.
>
> http://dunfield.classiccmp.org/mmint/
>
> Maybe he'll pull his eprom and copy it for you.
>
> pH

http://cini.classiccmp.org/systems.htm
Scroll down to "SB180/COMM180" and check out "Monitor source code (asm)":
http://cini.classiccmp.org/files/mon20.z80

On Wednesday, September 20, 2023 at 1:22:27 AM UTC-5, pbi...@gmail.com wrote:
> On Tuesday, September 19, 2023 at 11:04:28 PM UTC-4, pH wrote:
> > On 2023-09-19, mrgcm...@gmail.com <mrgcm...@gmail.com> wrote:
> > > On Friday, September 8, 2023 at 4:31:58 PM UTC-5, pH wrote:
> > >
> > > I have one of those blank boards that I bought back in the day. I
> > rediscovered it during a clearout last year but I wasn't able to find
> > the EPROM code for download anywhere, so it sits in my PCB drawer unused. I
> > 'd love to get it up and running though.
> > Maybe one of the hobby sites can write an eprom for you.
> > Here's a website that talks about it.
> >
> > http://dunfield.classiccmp.org/mmint/
> >
> > Maybe he'll pull his eprom and copy it for you.
> >
> > pH
> http://cini.classiccmp.org/systems.htm
> Scroll down to "SB180/COMM180" and check out "Monitor source code (asm)":
> http://cini.classiccmp.org/files/mon20.z80

Ah, excellent - thanks!

On 2023-07-31, ladislau szilagyi <ladislau_szilagyi@euroqst.ro> wrote:
>
>> Would a 20MHZ z80 (or more) be able to play Zmachine games (z5 and z8 version)
>> with enough speed? I think the 6502 on the C64 with a REU it's able to play
>> Z5 games with a few seconds delay and Z8 games run very slow.
>>
>> You know, the interpreter to run Infocom games, but there are several
>> "amateur" (not so amateur since the 1993's game 'Curses!'). games to try.
>>
>> Bear in mind Z3 games will run fine in any 8bit machine, but for Z8
>> games a 286.386, or 68k machine it's expected.
>
> I'm not an expert on Z machine games... can you give me a hint about where to download some v5 or v8 games for Z80?
>
> I suppose no color/graphics is required...
>
> I have a 25MHz Z80 machine (Z80ALL), the screen has 64x48, it is VT52 compatible, let's give it a try :)
>
> Ladislau
>
>

gopher://gopher.661.org
ftp://ftp.if-archive.org

Under games/zcode.

Anchor.z8 it's pretty well known, and 'Tangle.z5' (Spider and Web)
it's another good example for Z5 games.

Not for Z80, but for a Z machine interpreter. ZXZVM it's a good
example:

https://www.seasip.info/ZX/zxzvm.html

Porting hints:

https://www.seasip.info/ZX/zxzvmport.html