Z80 vs. 6502

[carlsson]

Another factor in the CPU choice would be the Basic programming language. I know that Atari originally planned to use Microsoft Basic, extended with commands to handle the custom hardware but that the code grew too big and they instead had Shepardson Microsystems to develop an own Basic for the 6502. Did Microsoft have a 6809 implementation available by late summer, early fall of 1978? As you mentioned properly written code can be much smaller on 6809 than 6502, it might've been possible to squeeze in support for graphics, sound, I/O etc within 8K and still get a Microsoft Basic style programming language. If on the other hand no such Basic implementation already was available, at first it might've been one more reason to stick with the 6502 until Atari found out that they needed a new implementation after all.

[JamesD]

Another factor in the CPU choice would be the Basic programming language. I know that Atari originally planned to use Microsoft Basic, extended with commands to handle the custom hardware but that the code grew too big and they instead had Shepardson Microsystems to develop an own Basic for the 6502. Did Microsoft have a 6809 implementation available by late summer, early fall of 1978? As you mentioned properly written code can be much smaller on 6809 than 6502, it might've been possible to squeeze in support for graphics, sound, I/O etc within 8K and still get a Microsoft Basic style programming language. If on the other hand no such Basic implementation already was available, at first it might've been one more reason to stick with the 6502 until Atari found out that they needed a new implementation after all.

That is a very good question and I honestly don't know. There were some other BASICs for the 6809 on FLEX and I remember seeing a comparison in speeds that *may* have also included a Microsoft BASIC... but that might have been for the 6800. 68 Micro Journal might be the place to look for an answer.

 

To be honest, I think some of the other BASICS were better than Microsoft but Microsoft had gained a name for itself. Atari probably could have purchased one of the other companies outright to get a BASIC. It kinda surprises me they didn't even for the 6502.

 

Did Shepardson Microsystems already have a BASIC for 6502 systems?

[carlsson]

According to the Wikipedia entry, Shepardson were finishing a BASIC for a Cromemco S-100 system. The only Cromemco's I know were Z80 based, but I see they had many different systems so perhaps one of them was 6502 based. Otherwise the Atari BASIC would've been truly written from scratch starting in October 1978.

 

On the FLEX User Group homepage, there is both a BASIC and an Extended BASIC, both by Technical Systems Consultants. There is even a cassette version, perhaps it is the same code but not started from the OS. If you're curious, the user manual as well as some other original documentation too. Most of the commands and instructions look similar to Microsoft dialects, even string handling which is where many other implementations tend to differ. File I/O is a little different, but not out of this world. The user manual is copyright 1979 though, which might be an issue if we pretend that Atari would've seeked a mostly available plug-in BASIC already in 1978. Then again the 400 and 800 were not released until the fall of 1979 so quite likely they could have had a reasonably recognizable 6809 BASIC well in time both for the CES and more importantly the actual launch.

 

Another issue would be if Motorola took Atari seriously if they approached them for a quote, or if they were considered "that videogames company" by others in the trade? Steve Jobs of course took Atari seriously due to he used to work for them.

 

By the way, I just discovered the very first issue of Intelligent Machines Journal (later renamed as InfoWorld) was published on December 11, 1978. Already in their second issue ever, January 17, 1979 the two new Atari computers were announced. For some reason, the next two issues were Issue 2-IE (January 31) and Issue 2 Final (February 7) before Issue 3 was published on February 14 and from there on all subsequent issues were numbered as usual.

[JamesD]

On the FLEX User Group homepage, there is both a BASIC and an Extended BASIC, both by Technical Systems Consultants. There is even a cassette version, perhaps it is the same code but not started from the OS. If you're curious, the user manual as well as some other original documentation too. Most of the commands and instructions look similar to Microsoft dialects, even string handling which is where many other implementations tend to differ. File I/O is a little different, but not out of this world. The user manual is copyright 1979 though, which might be an issue if we pretend that Atari would've seeked a mostly available plug-in BASIC already in 1978. Then again the 400 and 800 were not released until the fall of 1979 so quite likely they could have had a reasonably recognizable 6809 BASIC well in time both for the CES and more importantly the actual launch.

I'm pretty sure TSC was the company advertising how much faster their basic was than the competition on the 6800.

The manual might be © 1979 but the basic was probably in development shortly after the 6809 was released.

The 6809 is largely source compatible with the 6800 so an initial conversion could probably be running in as little as a month or two. It wouldn't fully take advantage of the 6809 initially but it would still beat 6502 code for size and speed. As an exercise, I ported some code from the 6803 (a step up from the 6800) and it only took about a half hour to port a couple hundred lines of code and I hadn't use the 6809 in years. But then I'm looking at it with today's tools and things were tougher back then.

 

Another potential problem with the 6809 is that it was brand new and there probably weren't any 2nd sources for it. If Motorola couldn't produce enough chips, Atari wouldn't be able to build machines. By the time the Atari was released that probably wasn't an issue, but when it was still being designed it might have been a key consideration.

[microprocessor]

The 6502 is "RISCy"?

 

There are a lot of people that think that "RISC" does mean reduced instruction set, in number of available opcodes. This reduces mean in "Complexity" of the instructions.

 

so instructions like 'increment by one the value stored at xxxx' are implemented in RISC processors like below:

read memory at xxxx

increment readed value

store at xxxx the value.

 

Considering this, it is more "RISCY" the z80 that lacks sophisticated memory addressing modes that were available on 6502 (like pre -post indexed).

 

Obviously, neither of the two cpu is RISC. That is the true story.

[microprocessor]

The thing is I prefer the Z80 to the 6502, BUT I prefer 6502 *machines* to Z80 ones. the 6502 ended up in the more interesting machines

there is not relation about cpu used and the graphics or sound capabilities of the machines. So your sentence is a non-sense

[TMR]

there is not relation about cpu used and the graphics or sound capabilities of the machines. So your sentence is a non-sense

He never said there was a relation, just that he preferred the machines that ended up with 6502 variants.

[potatohead]

Which is entirely valid!

 

A CPU runs in context, right?

 

So that context matters, which was the point of the sentence.

[Jess Ragan]

So how come the Z80 shines on SMS but on Spectrum it all looks like regurgitated toe nails?

Oh, this is easy. The processor is the brain of a computer, but that's all it is... a brain. It needs other components to function and communicate with the outside world. The Master System was built with a relatively complex graphics chip and had more memory than past systems. When Clive Sinclair made the Spectrum, he designed it with the cheapest components possible to market it at an attractive price point. It couldn't handle sprites, it could only show two colors per 8x8 square, the sound consisted of simple chirps and buzzes in the early models... frankly, it was completely inadequate as a game system. If the documentary Micro Men is to be believed, this was likely by design... Clive had nothing but contempt for video games and wanted no part of the market.

 

Anyway, the point I'm making here is that the CPU is only part of the picture. It needs to be paired up with capable I/O, graphics, and sound hardware in order to excel as a computer, or a game system. In way of demonstration, the VIC-20, Atari 2600, and NES all use 6502 processors, but were vastly different machines, each with their own distinct identities.

[The Usotsuki]

Heheh. If I can ever get my "Arcade Board Emulation" off the ground, I'm gonna need to figure out how to translate a LOT of code from Z80 to 6502...

 

>_>

[JamesD]

Heheh. If I can ever get my "Arcade Board Emulation" off the ground, I'm gonna need to figure out how to translate a LOT of code from Z80 to 6502...

 

>_>

The best way is by hand. That's how I built that music player for the Mockingboard a gave you for use in Donkey Kong. It started on the Z80 and after several translations ended up on the 6502.

​

For an automated conversion I'd look at how modern compilers work. They generate and optimize intermediate code, then generate code for the target CPU.

 

There was a 6502 to 6809 code translator back in the 80's. It generated pretty mediocre code but it worked. Going the other way would be more difficult though and code size will explode unless you figure out how to make it really smart.

 

 

 

There are a lot of people that think that "RISC" does mean reduced instruction set, in number of available opcodes. This reduces mean in "Complexity" of the instructions.

 

so instructions like 'increment by one the value stored at xxxx' are implemented in RISC processors like below:

read memory at xxxx

increment readed value

store at xxxx the value.

 

Considering this, it is more "RISCY" the z80 that lacks sophisticated memory addressing modes that were available on 6502 (like pre -post indexed).

 

Obviously, neither of the two cpu is RISC. That is the true story.

If you read the entire thread you'd see that my "RISCy?" reply was more because a CPU is RISC or it's not and the 6502 is not.

 

[carlsson]

Tom Charlesworth converted the music from ZX Spectrum versions of Cybernoid and Cybernoid II to his Mockingboard by using a set of homemade macros and the zero page to simulate Z80 registers. The routine was said to be very inefficient and take 20% of each frame which would be horrible for any game or demo using background music. While a good part of the instruction sets look similar, I suppose addressing and register use would make it a bit of a challenge to do an intelligent automatic converter.

 

You might also want to read David Tindale's recollection of how they made the ZX Spectrum Basic emulator (or perhaps simulator) for the C64, by recoding the Spectrum Basic byte by byte. Of course back in 1984/85 they may not have any other tools at hand.

 

http://www.lemon64.com/forum/viewtopic.php?t=20387

Edited November 11, 2013 by carlsson

[JamesD]

Tom Charlesworth converted the music from ZX Spectrum versions of Cybernoid and Cybernoid II to his Mockingboard by using a set of homemade macros and the zero page to simulate Z80 registers. The routine was said to be very inefficient and take 20% of each frame which would be horrible for any game or demo using background music. While a good part of the instruction sets look similar, I suppose addressing and register use would make it a bit of a challenge to do an intelligent automatic converter.

It sounds like one of those brilliant ideas that sounds good in theory but doesn't work so well in practice. It probably took more time to create those macros than to just port the code. I'll bet a peephole optimizer would have helped on the final code but there is only so much optimization you can do at that stage.

 

The reason I suggested looking at how a modern compiler works is because they generate an intermediate code that is easy to optimize. Going from the Z80 to 6502 is actually not as bad as the other way around. The Z80 has 16 bit support and it doesn't set status bits with as many instructions. That would make it easier to generate an intermediate code. The 6502 on the other had only has 8 bit registers and page zero addressing. Making an optimizer smart enough to figure out the 6502 is dealing with 16 bits and to convert it to 16 bit Z80 code would be close to impossible due to all the ways it can be done.

 

Porting the Z80 AY music player to the 6803/9 first actually made porting to the 6502 easier than going direct. The 6803 has 16 bit support so things came across pretty well. The first version did a lot of register shuffling but once I saw what the code was doing as a whole I could go back and optimize it. Once I had good 6803 code I already had code that looks a lot like 6502 assembly and the 6809 code used two index registers so to some extent made the code a little closer to the 6502 in flow. I had to switch from 16 bits to 8 bits by using page zero more and use nested loops to deal with 16 bit pointers. Writing the 6502 code was much more time consuming than the 6803 code but by going through the 6803 as an intermediate step it really helped. In a way, I used intermediate code similar to how a compiler would.

 

Edited November 11, 2013 by JamesD

[microprocessor]

Which is entirely valid!

 

A CPU runs in context, right?

 

So that context matters, which was the point of the sentence.

Also Graphics and sound hw matters, and somethimes (as the c64 & SMS proves) more than CPU comparison. The comparison to be fair should be done between CPU not considering other hw around obviously.

So, it's correct to compare 8bit systems globally taking into consideration cpu/gfx/sound. But comparing the CPU taking as examples systems were CPU was used and arguing what cpu is better just because the system were this cpu was used was better than another is a complete non-sense. That's because the overall power is influenced a lot by the custom hardware around.

 

So while i can tell that a z80 system called A is better of another z80 system called B, just because the former has a DMA feature that B does not, i cannot absolutely tell that the z80 CPU on system A is better than z80 CPU on system B. The CPU is the same, obviously. the system A is better than B, obviously

Edited February 7, 2014 by microprocessor

[Hatta]

There's only one way to settle this. Give two teams the exact same materials, and have them each build a robot. One controlled by a 6502, one controlled by a Z80. Then let the robots fight it out.

[carlsson]

Why not take it one step further and design two thermonuclear missile launchers, one powered by each CPU?

[JamesD]

There's only one way to settle this. Give two teams the exact same materials, and have them each build a robot. One controlled by a 6502, one controlled by a Z80. Then let the robots fight it out.

Number 6502 is alive!

 

But seriously... we already know the winner. Binder runs on a 6502.

 

[+nanochess]

There's only one way to settle this. Give two teams the exact same materials, and have them each build a robot. One controlled by a 6502, one controlled by a Z80. Then let the robots fight it out.

 

Hehe, there is a big chance that 6502 wins the battle. If you remember Terminator was programmed in 6502

 

[microprocessor]

There's only one way to settle this. Give two teams the exact same materials, and have them each build a robot. One controlled by a 6502, one controlled by a Z80. Then let the robots fight it out.

I suspect that to have a terminator-like robot "powered" by a 8 bit processor, you may probably need the computational power of 10^20 8 bit processors. I also suspect that in the entire world there are not so many chips available.

[microprocessor]

Oh, this is easy. The processor is the brain of a computer, but that's all it is... a brain. It needs other components to function and communicate with the outside world. The Master System was built with a relatively complex graphics chip and had more memory than past systems. When Clive Sinclair made the Spectrum, he designed it with the cheapest components possible to market it at an attractive price point. It couldn't handle sprites, it could only show two colors per 8x8 square, the sound consisted of simple chirps and buzzes in the early models... frankly, it was completely inadequate as a game system. If the documentary Micro Men is to be believed, this was likely by design... Clive had nothing but contempt for video games and wanted no part of the market.

 

Anyway, the point I'm making here is that the CPU is only part of the picture. It needs to be paired up with capable I/O, graphics, and sound hardware in order to excel as a computer, or a game system. In way of demonstration, the VIC-20, Atari 2600, and NES all use 6502 processors, but were vastly different machines, each with their own distinct identities.

I must totally Agree.

[TMR]

i s'pose if people want a "benchmarking" platform there's always the Commodore 128, it has both CPUs so similar code for both can be executed in the same surroundings?

[Rybags]

The supporting chipset isn't really any sort of means of comparison. With a bit of effort you could interface Antic, GTIA, SID, VIC-2 to a Z-80 or equally, the popular TI audio/video chips to a 6502.

 

Look at modern day benchmarks which target specific parts of the machine. To make it a fair comparison, you use equivalent components for the remainder of the system as much as possible.

 

When you're talking 2 ancient CPUs, then the obvious comparison is to omit the rest of the system as much as possible and just concentrate on throughput for equivalent tasks.

[Keatah]

What are we comparing? The bare microprocessor? Or a microprocessor with support chips and co-processors?

[Rybags]

I'd propose a set of benchmarks for common game type tasks. For each task, have 2 routines, 1st optimised for pure speed with very generous a limitation of memory allowed for code/lookup tables/working variables, 2nd constrained to work within a tight memory limit.

 

Common tasks could be: Render softsprite to bitmap, softsprite to characters, XOR mode softsprite to bitmap, (for all types with/without preshifted mask/data), perform move of 1000 bytes 40 bytes back in memory as per V-scrolling, perform move of 1000 bytes 1 back in memory in rows of 40 as per H-scrolling, perform bounding box collision detection among 100 objects with 8-bit X/Y coordinates and stores result in 100 byte array.

 

Just assume linear bitmap and Atari/C= style of character set. Result per bench can be total cycles used.

Edited February 8, 2014 by Rybags

[carlsson]

In the case of the C128, doesn't all I/O go through the 8502 even in Z80 mode, so you'd effectively swap CPU all the time you want something on screen, sound, input or output? I figure a such benchmark would put the Z80 to big shame, in particular as the 8502 natively runs at 2 MHz anyway.