Z80 vs. 6502

[JamesD]

 

I can't locate any info on page 36 about the SY6516..

 

 

I found a Follow Up Article here on PDF Pages 69-76:

http://archive.6502.org/publications/micro/micro_34_mar_1981.pdf

 

 

MarkO

I copied that from a post somewhere else. I don't think I found it either when I tried to look it up.

There was supposedly an article in infoworld or some other trade magazine at the time.

I thought I found it at one time, but I did another search and couldn't find anything.

[phoenixdownita]

https://plus.google.com/108984290462000253857/posts/6JeiVQrwKHi

 

http://blog.3b2.sk/igi/file.axd?file=2016%2F8%2FSYNERTEC+SY6516.pdf

[jvidalw]

On 11/25/2012 at 5:06 PM, BillyHW said:

The vast majority of the systems in the late 70s and early 80s were built around these 8-bit CPUs. Could anyone with programming or engineering experience from that era chime in with what some of the advantages and disadvantages or each chip were? Which do you think was better? For computing? For gaming?

 

Here's a quick list that I can think of. Please correct me where I'm wrong and add your own that I've missed.

 

Z80:

 

Adam/ColecoVision

Sega SG-1000

Sega Master System

MSX

most early arcade games

Game Boy

Game Gear

Astrocade

(Also listed as a coprocessor on many 16-bit arcades/consoles)

 

6502:

 

Atari 2600

Atari 8-bit computers/5200

Apple II

NES/Famicom

Atari Lynx

Commodore 64

PC Engine/TurboGrafx 16/Duo/Express

 

The Commodore 128 was unique in that it had both a Z80 and a 6502.

 

And what ever happened to Zilong and MOS? Why were they never able to translate their success in the 8-bit market over into the 16-bit market and beyond?

Just a small clarification, the atari 2600 used a 6507, the commodore 64 used a 6510, the Commodore 128 used an 8502 CPU (all are 6502 derivatives, though)

[adamchevy]

To misquote Mr Bill Mensch jr. ,” I’m not sure why my competitors didn’t make a superior product? They could have, but they didn’t. It was 2 to 4 times better than the other guy. Did Wozniak know that? I don’t know. When you make something the best you can do it, and nobody can do it better. You know that. We did the best possible Architecture at 8 bits, and we knew that.”

 

 

 

 

It’s at about 1 hour 50 minutes.

 

 

[JamesD]

On 1/12/2020 at 9:32 PM, adamchevy said:

To misquote Mr Bill Mensch jr. ,” I’m not sure why my competitors didn’t make a superior product? They could have, but they didn’t. It was 2 to 4 times better than the other guy. Did Wozniak know that? I don’t know. When you make something the best you can do it, and nobody can do it better. You know that. We did the best possible Architecture at 8 bits, and we knew that.”

 

Pretty sure Bill is biased. 
2 to 4 times better how?  In clock cycles vs Z80, or in number of additional instructions required vs 6809. 
The Z80 works differently, so it's normally clocked at least twice as fast because a lot of the clock cycles are internal. Pretty sure Bill knows that.
As has already been mentioned, 6809 code is around 30% smaller. 
And ask Bill why everyone else added a hardware multiply on later CPUs, but he never did.  The 6803 had multiply, and it supposedly first reached customers in 1977.

This, originally 2012 thread seems to get resurrected every two years by first time posters we'll probably never see again.
 

[adamchevy]

Pretty sure Bill is biased. 

2 to 4 times better how?  In clock cycles vs Z80, or in number of additional instructions required vs 6809.  [emoji14]

The Z80 works differently, so it's normally clocked at least twice as fast because a lot of the clock cycles are internal. Pretty sure Bill knows that.

As has already been mentioned, 6809 code is around 30% smaller. 

And ask Bill why everyone else added a hardware multiply on later CPUs, but he never did.  The 6803 had multiply, and it supposedly first reached customers in 1977.

 

This, originally 2012 thread seems to get resurrected every two years by first time posters we'll probably never see again.

 

 

Probably not. But atleast its fun to learn new things about these old processors.

 

I think the 6809 is in the Vectrex and is capable of 16 bit instructions? My memory is a bit fuzzy. It’s been a while since I studied the 6809.

 

I’m sure Bill is very Biased. Success and Millions of dollars has a way of doing that I’d bet.

 

Side note, my daughter who is 13 learned the word bias in school last year. She said we all have our BY Asses, you wave goodby to them every time they walk away.

[jvidalw]

Do you guys think a machine like the C64 or Atari 800 could handle Zanac-EX?

It has very fast paced gameplay, AI, fast music, hundreds of sprites on-screen simultaneously, etc...

[JamesD]

1 hour ago, jvidalw said:

Do you guys think a machine like the C64 or Atari 800 could handle Zanac-EX?

It has very fast paced gameplay, AI, fast music, hundreds of sprites on-screen simultaneously, etc...

How about starting a new topic since this isn't directly related?

[Serguei2]

On 4/5/2020 at 3:45 PM, jvidalw said:

Do you guys think a machine like the C64 or Atari 800 could handle Zanac-EX?

It has very fast paced gameplay, AI, fast music, hundreds of sprites on-screen simultaneously, etc...

Because Z80 can handle hundreds of sprites on-screen simultaneously?

 

Why does Colecovision only support 32 sprites on-screen?

[JamesD]

1 hour ago, Serguei2 said:

Because Z80 can handle hundreds of sprites on-screen simultaneously?

 

Why does Colecovision only support 32 sprites on-screen?

Um, because of the graphics chip?

[carlsson]

Well, the V9938 in MSX2 only does 32 sprites, max 8 per scan line before you start to multiplex them. The art of reusing sprites on the screen was common on many other systems too, including the C64 and Atari 8-bit but perhaps neither reuses sprites to the point they can claim 100 on screen.

 

Simply you no longer are comparing processors, but graphics chips: the GTIA + Antic from mid 1981, the VIC-II from late 1981, early 1982 and the V9939 from mid 1985, roughly 3.5 years later than the others.

[+OLD CS1]

8 hours ago, Serguei2 said:

Because Z80 can handle hundreds of sprites on-screen simultaneously?

Say what??

[Serguei2]

12 hours ago, JamesD said:

Um, because of the graphics chip?

So. Z80 can handle hundreds of sprites on-screen simultaneously if a graphics chip supports it.

 

Ok.

[RevEng]

Can someone point me to a zanac-ex video moment that demonstrates "hundreds" of moving objects. Really I'm having a tough time finding dozens, in the play-throughs I've looked at.

 

Having coded a demo on the 7800 that has 100 bigger-than-a-bullet moving sprite objects (with a lowly 6502!?!) I'd say that "hundreds" would pretty much cover the screen, so it should be pretty obvious.

[JamesD]

1 hour ago, Serguei2 said:

So. Z80 can handle hundreds of sprites on-screen simultaneously if a graphics chip supports it.

 

Ok.

Throw enough additional hardware on a CPU, and it can do a lot.  
If all the CPU has to do is turn on, off, update the position of sprites,  change which sprite cell is displayed, and check for hardware generated collision data... hundreds is pretty easy.
If the CPU has to worry about multiplexing sprites because the hardware doesn't support that many, or actually drawing bitmapped sprites, etc... that is a totally different matter.

If you look at Robotron, it's based on the 6809.  Look at how much stuff is moving.  Between the blitter, sprites, and a CPU to deal with sound, there is a lot happening on the screen.
Even with the added hardware, you'll notice the robots don't all move every frame.  Memory bandwith on such an old system limits how many of the non-hardware sprites can be updated with the blitter per frame.

23 minutes ago, RevEng said:

Can someone point me to a zanac-ex video moment that demonstrates "hundreds" of moving objects. Really I'm having a tough time finding dozens, in the play-throughs I've looked at.

 

Having coded a demo on the 7800 that has 100 bigger-than-a-bullet moving sprite objects (with a lowly 6502!?!) I'd say that "hundreds" would pretty much cover the screen.

That's kinda how games like that look, and I really don't care for games like that.  They just look too... busy.  Crap flying everywhere.

[carlsson]

It may have been mentioned before in this thread, but I find that 6502 based systems more commonly have memory mapped support chips (see e.g. the VIC-II which has all of its registers mapped at $D000 and onwards) while Z80 based systems tend to have ports based I/O where you communicate through a few addresses, telling the custom chip what to change and to what. Under that assumption, I would think that e.g. a 1.78 MHz 6502 would run circles around a 3.58 MHz Z80 if it only was to shuffle data to the beefy graphics chip.

 

Same about music, just poke the memory mapped registers of your sound chip. On the C64 itself, there are several examples of multispeed music, which means that instead of calling the music routine once per frame, it is called 2-4 or even more times in the same frame. Of course the more you tax the sound chip, the less time you have for other calculations, shifting graphics data etc. Calling the player multiple times per frame is not done in order to play the music faster but to get a different sound. Running a game at a decent frame rate usually is not a problem, even if it involves lots of calculations and AI.

[JamesD]

1 hour ago, carlsson said:

It may have been mentioned before in this thread, but I find that 6502 based systems more commonly have memory mapped support chips (see e.g. the VIC-II which has all of its registers mapped at $D000 and onwards) while Z80 based systems tend to have ports based I/O where you communicate through a few addresses, telling the custom chip what to change and to what. Under that assumption, I would think that e.g. a 1.78 MHz 6502 would run circles around a 3.58 MHz Z80 if it only was to shuffle data to the beefy graphics chip.

 

Same about music, just poke the memory mapped registers of your sound chip. On the C64 itself, there are several examples of multispeed music, which means that instead of calling the music routine once per frame, it is called 2-4 or even more times in the same frame. Of course the more you tax the sound chip, the less time you have for other calculations, shifting graphics data etc. Calling the player multiple times per frame is not done in order to play the music faster but to get a different sound. Running a game at a decent frame rate usually is not a problem, even if it involves lots of calculations and AI.

Z80 I/O ports are memory mapped, they just use a separate select signal, and separate instructions to use the I/O region. 
IN & OUT are simply LD & ST instructions for the I/O region.  Z80 BASICs normally include IN & OUT functions to use I/O.
So this does not make accessing hardware I/O ports slower.

It does make hardware mapping easier because you can just decode one byte to address a 256 byte I/O region if you want, and it might make the I/O code faster. 
You can use the full 64K if you test all the address lines.  So you could have 64K of RAM/ROM + 64K of I/O.
Samsung's first PC interfaced it's graphics memory of of the I/O buss. 
This leaves a lot of RAM for code (it could run CP/M), but it brings up one limitation of the Z80. 
There are no logical operators for the I/O region, and no indexed operators for I/O, just the load (in) & store (out).
This would significantly slow down the 64 column graphics text driver I wrote for other machines.
Paging graphics RAM in & out of regular RAM would be much faster.
Most other Z80 machines had memory mapped video RAM, or separate video RAM was accessed via ports on the VDP.
 

[fitten]

Bit of a thread necro but I ordered an Agon Light 2 board (has yet to arrive) that has an eZ80 so I'm brushing up on eZ80 (and Z80) ASM and found this thread. Very fun read.

The first ASM I ever learned was 6502 and I wasn't ever that good at it. There are a *lot* of nooks and crannies to look into to get the best performance out of it. In any case, the eZ80 has a bunch of improvements over the Z80, obviously... pipelined, 24-bit registers, pipelined, 24-bit ALU, etc. I saw it mentioned earlier in the thread, too. I was wondering if @JamesD got around to writing his library targeting the eZ80.

[JamesD]

On 5/16/2023 at 12:12 PM, fitten said:

Bit of a thread necro but I ordered an Agon Light 2 board (has yet to arrive) that has an eZ80 so I'm brushing up on eZ80 (and Z80) ASM and found this thread. Very fun read.

The first ASM I ever learned was 6502 and I wasn't ever that good at it. There are a *lot* of nooks and crannies to look into to get the best performance out of it. In any case, the eZ80 has a bunch of improvements over the Z80, obviously... pipelined, 24-bit registers, pipelined, 24-bit ALU, etc. I saw it mentioned earlier in the thread, too. I was wondering if @JamesD got around to writing his library targeting the eZ80.

I haven't specifically targeted the eZ80.  If you skip DMA the code is mostly the same as HD64180/Z180, only faster.  The 24 bit registers might cause some issues with some Z80 optimizations, but I'm not sure.
 

[fitten]

1 hour ago, JamesD said:

I haven't specifically targeted the eZ80.  If you skip DMA the code is mostly the same as HD64180/Z180, only faster.  The 24 bit registers might cause some issues with some Z80 optimizations, but I'm not sure.
 

Yeah, the eZ80 can work in mixed memory modes or even Z80 mode so routines can be Z80 compatible (just faster because of the various other optimizations to the processor... wider ALU, pipelining, etc.) There are a handful of eZ80 only instructions (multiply and maybe some others) but for the most part, it looks the same. I'm no expert by any means... just now getting into Z80/eZ80 ASM and doing searches on the 'net and reading stuff.