Z80 vs. 6502

[Thomas Jentzsch]

 

Loop
	lda $FFFF,x	; 4-5
Dest
	sta $FFFF,x	; 5

 

Why do you use $xxff? Using $xx00 saves one cycle (no page penalties). The main loop then still takes constant 14 cycles/byte.

 

Unrolling once would reduce the loop to 11.5 cycles/byte at the cost of 10 more cycles/page.

 

By unrolling 8 times you would get down to ~10 cycles/byte.

[Rybags]

In his example, it's self-modifying code, so the addresses are setup before the loop - the initial value ($FFFF / whatever) doesn't matter since it's changed.

 

Benefits of self-modifying code can vary, generally it doesn't lend so well to unrolled loops since you have to modify each extra operand which eats up the savings.

[carlsson]

Hm, either I was cross-eyed last night or the 6502 reference manual I was checking is wrong, as it seemed to claim ($nn),y takes 5-6 cycles but $nnnn,x always takes 6 cycles. I probably should check that once more, against another source in case Dr. Watson's book contains errors.

 

Anyway, unrolling loops would take a lot of code space, and something we should not ignore is that LDIR is an instruction that could take or be set up with arbritrary values multiple times in the program, I suppose even dynamically unlike the 6502 solutions all of us posted so far, which to a certain amount would be compile-time, but of course it only takes a little more effort to set up either the RAM space where the code executes (for self-modifying) or the zeropage pointers to read a dynamic address for a more generic solution.

 

Of course Z80 programmers should be free to come up with own memory move implementations that don't use LDIR, in case those solutions would be faster per byte than what the CPU instruction is.

Edited September 12, 2014 by carlsson

[Rybags]

The variable cycle thing is thanks to speculative read - e.g. LDA $3FF0,X will do the first read but need to read a second time if the indexing caused overflow such that the high byte of the address changed.

Speculative write obviously can't be done in the same way otherwise you'd get corruption, so write instructions will usually have a fixed cycle count.

 

Yep, the LDIR instruction is somewhat more versatile - it replaces a whole bunch of instructions that you'd otherwise need to do the increment of address, decrement of counter and the branch back.

Luckily 6502 instructions tend to have lower cycle counts, so the advantage loss isn't that great.

[Thomas Jentzsch]

Agreed, LDIR is more versatile than the code above. But unlike instructions code can be tailored by the programmer to its needs. So normally, if you really need the speed, you can always optimize the code to the special situation and get close to the theoretical throughput (which is 9 cycles for the 6502).

 

Not sure how optimized LDIR is, when compared to indexed load/store instructions. If it is optimized for speed, than it should take about as many cycles as a load/store (minus fetching and decoding the instructions) per byte. Since silicon was not cheap at that time, I suppose they had to make compromises here.

 

Also, the target computers for the 6502 when it was designed hardly ever had more than a few pages of RAM, probably this was already different for the Z80.

[Rybags]

From what I could gather for LDIR, it's 21 cycles per byte except the last which is only 16 since no loopback is done.

 

Seems in many cases CPU instructions are slower than what we'd theorize on - even 68000 MOVEM instruction appears to take twice as long as you otherwise might have thought.

[Thomas Jentzsch]

From what I could gather for LDIR, it's 21 cycles per byte except the last which is only 16 since no loopback is done.

 

Seems in many cases CPU instructions are slower than what we'd theorize on - even 68000 MOVEM instruction appears to take twice as long as you otherwise might have thought.

Both indicate that they have implemented it pretty much straight forward, optimizing for space instead of speed. Did MOVEM become faster over time or were more specialized instructions added later on?

[Rybags]

MOVEM can operate on byte, word or doubleword level and involve arbitrary number of registers.

But from what I found it's 8 cycles per operation in dblword mode - 68000 does 16-bit accesses to memory so you'd assume it could be quicker.

 

Later Motorola 68K models introduce cache and 32-bit data bus, so there should be cycle time improvements in many situations.

 

https://wiki.neogeodev.org/index.php?title=68k_instructions_timings

[carlsson]

Interesting thought if the 6502 and Z80 were developed for different kinds of applications. Obviously the 6502 stems from 6800, and can (in variants) be found in anything from KIM-1 and Atari 2600 to 16-32K PETs, Apple ][ and probably a few more large-memory computers from the first generation. The Z80 stems from the 8080 which is popular with S-100 systems among others, things like Cromemco, later on TRS-80 and many others with ability to run CP/M and other operating systems. While there are Z80 SBC's and trainers too, I'm not sure if those came a bit later.

 

I never studied the 6800 instruction set, but I suppose it doesn't have any particularly complex instructions neither? Cost of silicon might have been a factor, as I seem to recall the 6502 was relatively cheaper than e.g. the Z80, but then again the type of application might not have been quite as cost sensitive.

 

On the other hand, if one could dream about added instructions on the 6502 from the start (not considering the undocumented op-codes of which some may be useful), I could come up with a handful that I'd need more than an instruction to copy a whole block of data.

Edited September 12, 2014 by carlsson

[Rybags]

In 1975 typical appications would have been calculators and hobby/kit computers.

 

6800 is somewhat better featured although as history shows that didn't do it a lot of good. Initial intention of 6502 I suppose was "because we can" and to undercut the competition which they obviously did with success.

 

Z80 was a similar philosophy and story in that it's creator left Intel and the CPU was instruction compatible with the earlier 8080, although looking at the early history of both it's obvious the Z80 started in a somewhat more "upmarket" position.

 

But I stand by my earlier claim and history proves it - the best selling and superior home computers of the late 70s - mid 80s were mostly 6502 machines. And funnily enough, it was the toy/entry level machines like Sinclairs that went with Z80. Fair enough, there were some high-flyer Z80 machines like Sam Coupe and the later Amstrads but their entry was at the time of the 16-bit boom where 8-bit machines were becoming irrelevant.

[Thomas Jentzsch]

On the other hand, if one could dream about added instructions on the 6502 from the start (not considering the undocumented op-codes of which some may be useful), I could come up with a handful that I'd need more than an instruction to copy a whole block of data.

True. Some simple ones like TXY/TYX or an unconditional branch would have helped already.

[carlsson]

BRA, TXY, TYX, for sure. STX,Y and why not STY,X (and LDY,X) while we're onto it. Possibly also instructions like PHX, PHY, PLX, PLY, INC and DEC accumulator. Sometimes I've wished for an instruction that would swap the two nybbles in the accumulator but it might be a bit application specific. And those are still rather moderate wishes. Of course the addressing mode ($nn),X would have been highly preferred over the ($nn,X) mode that I keep speaking with seasoned 6502 coders but very few ever touched, much less use regularly.

 

The more I look at this list, the more I realize I'm describing a 65C02...

Edited September 12, 2014 by carlsson

[Rybags]

I'm not sure I've ever used the (ind,X) more than a few times. Or even if the Atari OS even uses an instruction in that mode. If it was replaced with something else, I doubt it'd be missed much.

Those other instructions - largely covered by the later 65C02, but of course it's of little use when the established base was already there on the original CPU.

What was sorely missing is JMP/JSR relative - with a few additions it could have been relatively painless to have relocatable code.

 

Swap nybbles - that's something useful, in many cases you want to just play with a couple of bits in a byte, a nybble swap would reduce the number of bitshift operations needed.

[Lynxpro]

In 1975 typical appications would have been calculators and hobby/kit computers.

 

6800 is somewhat better featured although as history shows that didn't do it a lot of good. Initial intention of 6502 I suppose was "because we can" and to undercut the competition which they obviously did with success.

 

Z80 was a similar philosophy and story in that it's creator left Intel and the CPU was instruction compatible with the earlier 8080, although looking at the early history of both it's obvious the Z80 started in a somewhat more "upmarket" position.

 

But I stand by my earlier claim and history proves it - the best selling and superior home computers of the late 70s - mid 80s were mostly 6502 machines. And funnily enough, it was the toy/entry level machines like Sinclairs that went with Z80. Fair enough, there were some high-flyer Z80 machines like Sam Coupe and the later Amstrads but their entry was at the time of the 16-bit boom where 8-bit machines were becoming irrelevant.

 

Well, don't forget that the Z80 was used in the CP/M computers, not to mention MSX computers, the Colecovision, and the various pre-Sega Genesis consoles. Even in the Genesis - and the SNK Neo Geo - the Z80 was used for audio processing even if it wasn't the main CPU. It's pretty interesting how many Coin-Op arcade games used either the Z80 or 6502 to either manage audio chips or function as audio chips themselves.

 

One of the other reasons why Atari Inc should've switched to the 6809 is because apparently it's twice as efficient with processing code than the 6502 [from my understanding]. So even though the 6809 would've cost more per unit than the 6502 derivatives, Atari would've saved money in the long-run because they could've used smaller ROMs per cartridge for its consoles. So I'm now wondering had the 2600 featured a 6809 CPU instead of the 6507, would a 2K version of Pac-Man equaled or surpassed the 4K version we ended up with for the 6507.

[Rybags]

6809 was a bit late to the party to be eligible for the 2600, plus back then the cost was a big consideration. As it was, the 6507 is somewhat a compromise against the 6502 but probably saved a good few bucks per unit at the time.

 

I'd doubt the 6809 being twice as efficient for code in space or cycles for common tasks but 20-30% for code and 30-35 for speed wouldn't be out of the question.

 

Atari was probably the biggest arcade user of 6502 - most of what they released from ~ 1979 -1984 used it. Japanese companies seemed to almost exclusively use the Z80 in that same timeframe.

Some Atari games were Z80 or 6809 but I think most/all were licenced versions of Namco games.

[carlsson]

Yes, if a full 6502 was too complex/expensive for the VCS, I can't imagine what a 6809 would have done to the price. There are more Motorola CPUs in those series, 6803 perhaps being the most familiar one and present in later computers like the Tandy MC-10, but I don't know how much more simple or cheap it was to a 6809.

 

If I recall correctly, in this or another thread we recently discussed the CPU choice of the Atari 8-bit computer range, including both the mystery 6509 processor (which probably would've been a completely different beast than the MOS 6509 launched a few years later in the CBM-II line of computers) and the 6809. In a home computer with reasonable amounts of RAM, perhaps the savings on ROM chips (as long as the finished cartridge sold at the same price) would not be as large. Of course a 6809 based Atari 800 would also have spelled a 6809 based Atari 5200, and put an interesting question what happened with the 7800, being backwards compatible with the 2600 which has a 6507. To be honest, I don't know if or how well a 6809 can run 6502 binary code, I suppose the answer is "not". It would either have spelled that Atari reverted to the 6502, the new console not being backwards compatible or that the 7800 would have been a two CPU solution... wow, speak about expensive engineering with small benefits.

 

Colecovision is an interesting case, as it is a consumer product with a Z80 but very little RAM for the CPU, now if we assume that systems with low RAM usually would be paired with the 6502, and the more expensive systems with the Z80. On the other hand, by 1982 Zilog and second sourcers might have dropped the prices so much it no longer was an issue.

Edited September 12, 2014 by carlsson

[Rybags]

6809 can't run 6502 code, but conversion from source wouldn't be entirely hard.

 

Williams arcade were large users of 6809 - looking at early/mid 80s titles like Defender, Joust, Robotron, clearly powerhouse machines compared to many contemporaries.

 

Re pricing - by the 80s the gap would have closed somewhat. No shortage of budget Z80 machines like Sinclair ZX80/81/Spectrum. But by then many companies were set in their ways. Atari obviously with the strong 6502 culture as it was used in so many applications.

 

Also - don't forget the modern day 6809 adaptor for the 8-bit machines. Good example of how the 2 CPUs are similar in architecture, just a board and simple interfacing allowing an entire different processor.

[Chilly Willy]

MOVEM can operate on byte, word or doubleword level and involve arbitrary number of registers.

But from what I found it's 8 cycles per operation in dblword mode - 68000 does 16-bit accesses to memory so you'd assume it could be quicker.

The 68000 is rather like the Z80 in that instructions take multiple clock cycles. The standard no-wait read and write bus cycles take four clocks per word, so 8 clocks per long is just what you would expect. You can make the bus cycle longer by not asserting /DTACK by the second clock cycle, but 4 clocks is the shortest you can go. The Amiga took advantage of that to use the first two clock cycles for the custom chip ram accesses, and the second two cycles for the 68000 (or custom chips if needed). It's rather like some of the 8-bit systems that interleaved the CPU and custom chip accesses.

 

Not all 68000 instructions are multiples of 4 (they are all multiples of 2), so if a 68000 read or write to chip ram started on the wrong timing boundary, the custom chips would hold off /DTACK for 2 clocks automatically. That made it slightly more difficult to get cycle timing perfect. You were better off making a custom COPPER list than trying to use cycle-timed 68000 code for raster effects.

[Lynxpro]

6809 was a bit late to the party to be eligible for the 2600, plus back then the cost was a big consideration. As it was, the 6507 is somewhat a compromise against the 6502 but probably saved a good few bucks per unit at the time.

 

I'd doubt the 6809 being twice as efficient for code in space or cycles for common tasks but 20-30% for code and 30-35 for speed wouldn't be out of the question.

 

Atari was probably the biggest arcade user of 6502 - most of what they released from ~ 1979 -1984 used it. Japanese companies seemed to almost exclusively use the Z80 in that same timeframe.

Some Atari games were Z80 or 6809 but I think most/all were licenced versions of Namco games.

 

In the scenario, I should've typed 2600-replacement. Since the original plan was to bring out the 2600's successor in 1979, it could've been eligible for a 6809 just as the Atari 8-bit computers almost went with the 6809. This was a concern with Atari going back to when Commodore bought MOS. According to Al Alcorn, Manny Gerard was concerned about having to deal with Tramiel but apparently not enough to convince him to purchase MOS for $1 million as a counter-offer. It helped that Atari got the right to second-source the 6502 with any other chip manufacturer once Atari purchased 50k 6502s from MOS. When Al gave his talk at the Sunnyvale Atari Party, it did seem like he was amused about Tramiel only making a profit from 50k CPUs whereas Atari had millions of 6502s - and derivatives - produced by Synertek and others thanks to that agreement.

 

Personally, I wish Atari would've bought MOS and then either merged it with Synertek or sold it to Motorola. That would've prevented Tramiel's price war, assuming he wouldn't have been able to purchase Synertek, Zilog, or some other small CPU manufacturer.

 

As for the 5200, it could've went with the 6809. After all, the Vectrex did. And even if Atari would've had to still bundle a 6507 inside such a beast, that would've probably contributed $1 to $2 more in manufacturing costs.

 

Regarding the Colecovision, it probably wasn't the Z80 that was expensive, it was probably the TI Graphics chip - which had 16K itself - that was probably the most expensive part in that console.

 

Fascinating stuff!

[carlsson]

Hm yes. It if hadn't been for Tramiel setting up a price war, home computers would have remained overly expensive and only for the really rich families. It would have made video games more viable solutions to play games, never mind the load of really poor games flooding the market. Furthermore, it would have kept programming something only for men in white coats, and we would have got away with a bunch of evil hackers over the years. Some of us who could not afford computers but would have been fed up with the video games might even have spent more time outdoors and not put on so much overweight.

 

All in all, the world would have been a MUCH better place if Commodore never had bought MOS and by using vertical integration push the prices down.

 

(Do I need some smiley faces to indicate irony, or does it go without pointing it out?)

[Rybags]

I don't think we should give him too much credit. He simply brought forward events that eventually would have happened.

It's like the space race - we got the silicon chip largely thanks to it's needs, but the consumer market would have seen it eventuate in time regardless.

But I suppose better that we got the faster cheaper computers when we did - it'd be a bit of a downer if in the modern day we'd only just gotten to the point of a sub-$1000 PC.

[Lynxpro]

Hm yes. It if hadn't been for Tramiel setting up a price war, home computers would have remained overly expensive and only for the really rich families. It would have made video games more viable solutions to play games, never mind the load of really poor games flooding the market. Furthermore, it would have kept programming something only for men in white coats, and we would have got away with a bunch of evil hackers over the years. Some of us who could not afford computers but would have been fed up with the video games might even have spent more time outdoors and not put on so much overweight.

 

All in all, the world would have been a MUCH better place if Commodore never had bought MOS and by using vertical integration push the prices down.

 

(Do I need some smiley faces to indicate irony, or does it go without pointing it out?)

 

Prices would've went down without Tramiel, just not as quickly. What Tramiel did was psychotic and as a personal vendetta to destroy TI regardless of the costs to his own company or the rest of the industry. He destroyed the profit margin of non-Apple 8-bit computers.

[JamesD]

6809 was a bit late to the party to be eligible for the 2600, plus back then the cost was a big consideration. As it was, the 6507 is somewhat a compromise against the 6502 but probably saved a good few bucks per unit at the time.

 

I'd doubt the 6809 being twice as efficient for code in space or cycles for common tasks but 20-30% for code and 30-35 for speed wouldn't be out of the question.

 

Atari was probably the biggest arcade user of 6502 - most of what they released from ~ 1979 -1984 used it. Japanese companies seemed to almost exclusively use the Z80 in that same timeframe.

Some Atari games were Z80 or 6809 but I think most/all were licenced versions of Namco games.

The 6502 compares pretty favorably with the 6809 ccle wise if you can line data up within 256 byte pages.

With the music player I ported to both CPUs, the code size difference was pretty dramatic.

The 6809 code was around 1/3 the size of the 6502 code with the initial comparison but I've made some optimizations to the 6502 version since then.

If I assemble the 6502 version so that songs are within 256 byte boundaries the code shrank quite a bit and the 65C02 version was even smaller.

I think the 6809 version is still a lot smaller than the 6502 version and I haven't done any optimizations to it.

Self modifying code might save a few clock cycles and bytes on the 6502 version but I hadn't gotten to the point I thought it was needed yet.

Edited September 13, 2014 by JamesD

[MarkO]

A CoCo user by the handle of "camillus Blockx" posted recently on the CoCo Mailing List that he has a source of

HD63C09EP's.

 

If you think you might want a Hitachi 6309 to replace your Motorola 6809 device, the cost is minimal..

 

I am not he, but I am sending him a few dollars to get a few of these for myself...

 

MarkO

 

=============== Begin Post ========================================================

 

Hi, coco enthusiasts and builders/hackers, interested in HD63C09EP?

 

Can get my hands on a batch, and can let them go for $1.75 for 1.

 

Take them by 3 pieces then it is 1.50/piece. Shipping is for buyer and I use USPS unless you send me a label and pickup schedule from an other carrier.

 

 

If interested, please let me know asap, I only order this batch from the moment the requested amount is 60 pieces.

 

This is 20 persons that order 03 pieces.

 

12 persons that order 05 pieces.

 

06 persons that order 10 pieces.

 

 

Order send to Camillus.b.58 at Gmail.com at =@

 

Please do not order via the cocolist, as this is inappropriate. And I do not maybe see your order,

 

When it comes true my mail I always go there once a day.

 

 

 

 

thank you

 

 

cba

 

=============== End Post =========================================================

Edited September 17, 2014 by MarkO

[MarkO]

Another CoCo Mailing List poster noted that the magazine Micro, which started out as only 6502, added the 6809 in JUN-1981.

 

The JUN-1981 Issue, has a great side-by-side comparison of the two processors...

 

 

=============== Begin Post =========================================================

 

http://micro.applearchives.com

 

Starting with the June 1981 issue, coverage of the 6809 began.

Starting with the Oct 1981 issue, coverage of the coco began.

 

=============== End Post =========================================================