Z80 vs. 6502

[Rybags]

That's different, I wasn't referring to reuse - there's a trick to get vertical pixel sizes beyond the normal 2x max. It works something like toggling between single/double height to get bigger pixels. So, expensive party trick, not all that useful for games.

[Mr SQL]

Does the C64 have the option to double size the sprites like some other machines? I'm wondering if that would be a cheap way to create a Mega Bug clone without a lot of processing time.

 

I think coding Mega-Bug for the c64 or the A8 would be easier to write than the CoCo version; the CoCo had neither sprites nor dedicated sound chip so the CPU had a lot more work to do.

 

Beyond wait states, the advanced sound and graphics chips in the C64 and A8 offload a lot of work from the CPU.

 

On the other hand, if Rybags could put a 6502 in the CoCo it wouldn't have enough power for a Mega-Bug game

 

Despite the slightly slower clock speed the 6809 is about 3 times as powerful as the 6502 so it can do things in software that would otherwise require dedicated hardware.

[potatohead]

Actually, I think a 6502 on the CoCo would do the game just fine.

 

http://www.youtube.com/watch?v=RB-y4qHI7cQ

 

An Apple at 1Mhz renders the game nicely enough. Apple ][ computers and the CoCo do not have wait states for graphics display. A 6502 at the sub 1Mhz clock might struggle some, but the higher clock in the CoCo would be just fine, particularly given the CoCo does feature larger pixel sizes, saving the writes to the screen needed on the Apple, and a linear memory map for the screen, which means smaller code and fewer tables indexes needed to write to the screen.

 

Seems to me, doing this game on the Atari might just work out nicely bitmapped just like the original.

 

Here's the color computer:

 

 

Quicker setups and we can see the 6809 doing faster redraws, but not so much faster that the game can't be done, IMHO.

[Thomas Jentzsch]

That's different, I wasn't referring to reuse - there's a trick to get vertical pixel sizes beyond the normal 2x max. It works something like toggling between single/double height to get bigger pixels. So, expensive party trick, not all that useful for games.

That's what I meant. During the last line of the sprite you trigger an interrupt and change the sprite's vertical position or size so that the sprite's end is never reached.

[Mr SQL]

Actually, I think a 6502 on the CoCo would do the game just fine.

 

http://www.youtube.com/watch?v=RB-y4qHI7cQ

 

An Apple at 1Mhz renders the game nicely enough. Apple ][ computers and the CoCo do not have wait states for graphics display. A 6502 at the sub 1Mhz clock might struggle some, but the higher clock in the CoCo would be just fine, particularly given the CoCo does feature larger pixel sizes, saving the writes to the screen needed on the Apple, and a linear memory map for the screen, which means smaller code and fewer tables indexes needed to write to the screen.

 

Seems to me, doing this game on the Atari might just work out nicely bitmapped just like the original.

 

Here's the color computer:

 

http://www.youtube.com/watch?v=wZIKyqZRlDc

 

Quicker setups and we can see the 6809 doing faster redraws, but not so much faster that the game can't be done, IMHO.

potatohead,

nice implementation of Mega-Bug on the Apple! Did Bjork code that one too?

 

Yes the CoCo had no wait state thanks to the SAM managing the VDG; IMO a 6502 in a CoCo would not be powerful enough to manipulate the DAC to create the four voice music and digitised speech in the CoCo as this pushes even the 6809. Perhaps if you added a SID chip or Pokey; I notice complex sound is missing on the apple version.

[JamesD]

I think coding Mega-Bug for the c64 or the A8 would be easier to write than the CoCo version; the CoCo had neither sprites nor dedicated sound chip so the CPU had a lot more work to do.

 

Beyond wait states, the advanced sound and graphics chips in the C64 and A8 offload a lot of work from the CPU.

 

On the other hand, if Rybags could put a 6502 in the CoCo it wouldn't have enough power for a Mega-Bug game

 

Despite the slightly slower clock speed the 6809 is about 3 times as powerful as the 6502 so it can do things in software that would otherwise require dedicated hardware.

The 6809 to 6502 speed ratio is as debatable as the 6502 to Z80 ratio. The numbers I quoted earlier for the latter two were from another debate that took place on another forum, I don't even remember which forum anymore. But such comparisons depend on what you are doing and some code can favor one CPU over another. Overall that number in your comparison is probably accurate when you look at code size difference between the 6502 and 6809 but I wouldn't say it's for everything.

 

Any comparison of CPU vs CPU ultimately has two different factors. One is brute force speed which is what the topic started out talking about. But then there is the support hardware. The Apple II was hampered by the weird screen layout and a clicks for sound, but it has zero wait states. The C64 has wait states, but it has a simpler screen layout, sprites and a sound chip, The Atari has a higher CPU clock, graphics modes aplenty, and player/missile graphics. The CoCo has a slow clock, but it has the 6809, a simple screen layout, easy double buffering, a DAC, etc...

 

Mega Bug was clearly implemented in a way that is CPU intensive. Maybe it doesn't port well to the C64 or TREK as written but maybe the game doesn't have to be written the same way on those machines.

 

As to sound chips offloading the CPU... it really depends on game implementation. For noise, the Apple just has an extra LDA instruction and a counter test every now and then. The CoCo is similar but it just outputs a byte to the DAC every now and then. It's not as cool sounding but it's sound. Updating a sound chip like the AY requires fewer tests and outputs, but when you do output it does more bytes at a time to pick the internal register number and output to the register. I'm not real familiar with the SID or POKEY but I believe they use the same internal addressing, if I'm wrong I'm sure someone will let us know.

 

Background game music favors the sound chip a LOT because ears will detect any flaws in the tones and you have to update the speaker more often. With a sound chip you just update it from a timed interrupt. With the CoCo 3 you have a programmable timer interrupt and can just step through a sound sample. But without a timer... outputting music with only a speaker or DAC becomes a clock counting nightmare. This is why CoCo 1/2 games don't use background music during gameplay. Very few games ever pulled that off and the perfect example of one that did is Manic Miner on the Spectrum and it's a bit rough sounding.

 

BTW, if the CoCo 1/2 had included the same timer as the CoCo 3, you would have heard some amazing in game music and sounds on the little beasts. But similar things could be said for other machines.

 

<snip>

Seems to me, doing this game on the Atari might just work out nicely bitmapped just like the original.

I couldn't find a video of the Atari version but I'm sure it's very similar to the Apple and CoCo versions.

The clock speed of the Atari makes up for any wait states from the hardware.

I would think the game would port well to the Plus/4 given how the game depends more on CPU than special hardware. The screen update code would probably be very similar to the Atari.

On the C64 it's just an issue of do you have enough clock cycles or is there a way to save enough clock cycles.

I thought maybe screen updates could be simplified by using multiple sprites for the zoom window.

[JamesD]

potatohead,

nice implementation of Mega-Bug on the Apple! Did Bjork code that one too?

 

Yes the CoCo had no wait state thanks to the SAM managing the VDG; IMO a 6502 in a CoCo would not be powerful enough to manipulate the DAC to create the four voice music and digitised speech in the CoCo as this pushes even the 6809. Perhaps if you added a SID chip or Pokey; I notice complex sound is missing on the apple version.

I believe Bill Budge wrote the Apple version. <edit> Scratch that, it was Bob Bishop.

 

Actually, I think 4 voice music or digitized sound would still be easy with the 6502. There were a lot of wait states in the 4 part harmony music players on the CoCo and the waveforms used in the player are 255 bytes in length. You wouldn't even have to worry about crossing a page boundary and the 6502 would auto wrap back to the start of the sample. I even ported the CoCo music routine from the William Tell demo to the Z80.

 

Stepping through a waveform and outputting it to the DAC for a digitized sample is something the 6502 would do very well.

Edited December 5, 2012 by JamesD

[potatohead]

Yes, precisely. I spent a lot of time with these two chips. Apple, Atari and CoCo 2/3

 

Apple click sound really takes a lot of CPU. Had there been an interrupt to use, or even a timer, sound would have been better. Those got added as did good sound, in later machines and via add on cards with good results.

 

I thought it a fine implementation otherwise. I will play it this weekend too. Need a reason to get the machines out.

 

As for that 3x power, it really depends. A 6502 would drive the DAC just fine, given some interrupt support.

 

When moving a lot of data, the 6809 is quicker. Decisions and logic not so much. Math favors 6809. Doing lots of on the fly interrupt stuff is a toss up.

 

No cut n' dried answers here. Apple computers consistently impressed me given the clock and screen. A great 6502 programmer could get it to do a lot. IMHO 6809 is easier in this way, but a great programmer could also get it to do a lot. Check out some of the CoCo 3 demos Remz did. Sheesh full on bitmap mode too.

 

I always wanted a 6809 in the Apple...

[JamesD]

Apple click sound really takes a lot of CPU. Had there been an interrupt to use, or even a timer, sound would have been better. Those got added as did good sound, in later machines and via add on cards with good results.

The Mockingboard had one or two VIA and AY chips depending on the model. The VIA has a built in timer so it's a nice solution for the Apple. But sadly interfacing the AY through the VIA instead of it being memory mapped means more clock cycles to set the sound chips. Same thing on the Oric.

It's still way better code wise than clicking the speaker every few instructions to try to make music. It also sounds way better.

 

I always wanted a 6809 in the Apple...

I think it was 'MICRO' that had an article about a 6809 add on card for the Apple. It was faster to transfer data to the 6809 card, process it, and read the result back than to perform the same operation on the 6502. I don't remember what the guy was doing but I'm sure it was math intensive and multiplication was probably involved.

There is an archive of scanned MICRO issues on the web, you might like the article if you can find it. It would of coarse be better to have the 6809 as the main CPU.

The 65802/65816 isn't a horrible compromise by any means.

[Rybags]

That's what I meant. During the last line of the sprite you trigger an interrupt and change the sprite's vertical position or size so that the sprite's end is never reached.

 

The explanation of how what I was describing works is in C= Hacking #5 - if you clear then set the Y-expand bit for a sprite, Vic will automatically think it's only on the first scanline for that row of pixels. So you can just keep doing it for each extra scanline you want a row of pixels stretched to.

 

The usage for the effect would typically be for text scrollers - it's different to the set Y position for reuse in that the same sprite is occupying more area due to stretched pixels, not because Vic starts drawing the sprite again.

[Charlie_]

I think coding Mega-Bug for the c64 or the A8 would be easier to write than the CoCo version; the CoCo had neither sprites nor dedicated sound chip so the CPU had a lot more work to do.

 

Beyond wait states, the advanced sound and graphics chips in the C64 and A8 offload a lot of work from the CPU.

 

On the other hand, if Rybags could put a 6502 in the CoCo it wouldn't have enough power for a Mega-Bug game

 

Despite the slightly slower clock speed the 6809 is about 3 times as powerful as the 6502 so it can do things in software that would otherwise require dedicated hardware.

 

I just found out this game has been coded for the A8 already. "Tumble Bug"

Check it out:

http://atari.fandal.cz/detail.php?files_id=3236

Sorry, if this is already mentioned, I just skimmed through the posts.

[sack-c0s]

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

 

much better support hardware - the SMS graphics chip isn't that different from the one in the MSX and has it's own memory pool to avoid contention and cycle-stealing from the CPU. The speccy basically has a 2bits per pixel framebuffer and colour RAM and that's it.

[Mr SQL]

I believe Bill Budge wrote the Apple version. <edit> Scratch that, it was Bob Bishop.

 

Actually, I think 4 voice music or digitized sound would still be easy with the 6502. There were a lot of wait states in the 4 part harmony music players on the CoCo and the waveforms used in the player are 255 bytes in length. You wouldn't even have to worry about crossing a page boundary and the 6502 would auto wrap back to the start of the sample. I even ported the CoCo music routine from the William Tell demo to the Z80.

 

Stepping through a waveform and outputting it to the DAC for a digitized sample is something the 6502 would do very well.

James,

that's pretty cool you transposed the routine from the William Tell demo! that was one of the first demo's to get four voice sound out of the CoCo. I'm curious what was the Z-80 machine with the DAC you ported it to?

 

I haven't programmed Pokey but the TIA and SID hardware facillitate in game music and sound effects easily whereas the same via the DAC usually pauses the game action as a result of the wait states.

[sack-c0s]

It is the problem of any thread using the "vs" (versus) word in title (check C64 versus Atari)

 

People starts thinking that one of the two should win. But reality is that though I understand both Z80 and 6502, I prefer more Z80. And everyone here have their own preference.

 

That's all folks!

 

Now go in peace and write some good code.

 

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

[JamesD]

James,

that's pretty cool you transposed the routine from the William Tell demo! that was one of the first demo's to get four voice sound out of the CoCo. I'm curious what was the Z-80 machine with the DAC you ported it to?

It's for the VZ200/300. Just don't be too quick to pat me on the back.

 

The 6809 demo code depends on a clever trick. I had to change that from big to little endian but otherwise it's just loops. At first that part of the 6809 code was a bit confusing. If I remember right the MSB of a counter is the LSB for the offset in the waveform, and the LSB of that variable just delays between steps. The value you add to that number determines how fast you step through waveforms. A neighboring byte was used to grab that MSB as an LSB for the index. Other than that it was pretty straightforward and little endian code just reverses the variables and changes where lables are on the lines. The player basically keeps outputting to the DAC in a loop, steps through each waveform at the proper interval for each channel with counters (the player only used one waveform but actually supports multiple for different instruments), it mixes waveforms of all channels each time you output by adding the values (yup, overflow is just ignored), and you have to time how long to play notes for each channel but length was also related to the source data. It's actually not terribly difficult once you understand what's going on but you have to get the timing right or it will sound off key, play at the wrong tempo, etc... and if you calculate the offsets into the waveform wrong, you just get random noise.

<edit> Waveforms are 256 bytes btw.

 

Which brings me to the Z80 code. I wrote the Z80 code for someone that had built a D/A converter and he was doing the testing. We were getting really nasty sounds but when he tested his DAC on a PC with known good software to drive it he said it didn't sound right there either. He got busy and without hardware or emulator support to test on, I can't put the final touches on the code. The video he made clearly sounded like the player was stepping through the music but the waveform output was horrid. That could be hardware, software, or both. I'd build a DAC to test it on myself but I'm not very motivated to build hardware I'd use for a few days and never touch again.

 

Someone is building a new emulator for the VZ. I'll drop him a note and see if he will support DAC output so I can test it.

If the code has a bug in the waveform stepping, it will only require changing a define or a few lines of code so it's not a huge issue. I just can't be certain it works without good hardware to test on and adjusting the timing values will take some trial and error or a lot of clock cycle counting on both CPUs... something I'd like to avoid.

 

I haven't programmed Pokey but the TIA and SID hardware facillitate in game music and sound effects easily whereas the same via the DAC usually pauses the game action as a result of the wait states.

You have to keep outputting to the DAC at close intervals to get it to recreate a waveform.

A DAC should really be driven by a timed interrupt (more often than vertical blank) or DMA. The CoCo 3 offers a timed interrupt and the Amiga uses DMA.

DMA would be the preferred method since it requires a lot fewer clock cycles.

Edited December 9, 2012 by JamesD

[sack-c0s]

 

much better support hardware - the SMS graphics chip isn't that different from the one in the MSX and has it's own memory pool to avoid contention and cycle-stealing from the CPU. The speccy basically has a 2bits per pixel framebuffer and colour RAM and that's it.

 

okay - I ballsed this post up and nobody realised until after the edit deadline passed.

 

I meant *1* BPP, giving *2* unique colours per 8x8 cell...

[BillyHW]

Just curious everybody: If you were designing your own console/computer in the early 80s, would you have chosen the Z80 or 6502? Also, what if you had the choice of something else entirely, what would you choose? (Money *is* an object in my question, so please factor in cost in your decision.)

[JamesD]

Just curious everybody: If you were designing your own console/computer in the early 80s, would you have chosen the Z80 or 6502? Also, what if you had the choice of something else entirely, what would you choose? (Money *is* an object in my question, so please factor in cost in your decision.)

I think cost was pretty much a wash CPU price wise by the 80s.

How early in the 80s are we talking? 1980-1982?

 

If I had a previous generation system on the market I'd use the same CPU that was in it.

If I had no legacy system to grow from my first choice would be a 6809.

If I couldn't use the 6809 and didn't have a previous system...

 

The 6502 would be easier to interleave video and CPU access to RAM and would be easier to have video anywhere in memory.

The Z80 can fit a larger BASIC in the same ROM space or you can use fewer ROM chips for the same BASIC implementation.

 

If I were just targeting business, I'd lean towards the Z80.

If I were just targeting the home audience, I'd say 6502.

 

Since I'd aim for Apple II flexibility but with custom hardware capable of things more like the Atari or C64... I'll say 6502.

Edited December 15, 2012 by JamesD

[Rybags]

The shitty thing about 6502 is that practically nothing that used it in it's prime ever ran over 2 MHz. At least with the Z80 there was a bit of upscaling where you had the TRS-80 @ 1.78 Mhz, early 80s machines typically double that and later machines going higher again.

 

Choice for machine - I have a bias towards 6502 mainly because I used it so much more and the "better" machines IMO used it, exceptions being Amstrad, MSX2, Sam Coupe but honestly both CPUs were on their last legs by the time the ST and Amiga were released.

 

Cost - really, I think the 6502 had the advantage for the most part there. C= owning MOS probably helped, they produced a reasonable suite of support chips to go with it at good prices and the sheer number of machines that used 6502+derivatives helped too.

You can't argue with the economies of scale that 25 million+ C64/128 and peripherals, 30 million Atari 2600s, and probably 10+ million more that went into Atari 8-bitters + peripherals.

 

Sure, Z80 had the low-end market sewn up with the likes of ZX80/81 and later the Spectrum but look under the hood - there's not exactly much there.

[JamesD]

The shitty thing about 6502 is that practically nothing that used it in it's prime ever ran over 2 MHz. At least with the Z80 there was a bit of upscaling where you had the TRS-80 @ 1.78 Mhz, early 80s machines typically double that and later machines going higher again.

I have to wonder if the 6502 ran over 2MHz in NMOS. CMOS could certainly handle 4MHz since the IIc+ used that, but when that fast of a part was first offered is another question entirely. It really surprises me that nobody but Apple offered a higher speed (>2MHz) version of their 8 bit machines.

 

If Atari had introduced a 3.5MHz turbo mode on their machines when they updated the design from the 400/800 you have to think they would have dealt a serious blow to the competition. That would have been 1983? Only a year after the C64 is introduced and the same year the IIe was introduced. The C64 and Apple IIe would have looked dated right out of the gate.

The C64 should have been ~2MHz to begin with. After all, the VIC20 was 1MHz and the Atari 8 bit had been out for years at 1.7MHz. I guess it was all about cost at that time.

[Rybags]

Ram access speed was a stopping point for a while.

But by the time XL came out they were using 150 ns chips, and pretty sure the XE had 90 ns chips.

 

To do 3.6 MHz, something around 125 ns would probably be required. Possible that the Rom/Eproms might have needed to be respecced too.

 

Antic could have gotten a considerable upgrade. As it is, the bandwidth is there already to do 4bpp in 160 mode, although Antic/GTIA comms is a stopping point. With something like a combined Antic/GTIA they could have done an 8bpp mode and stomped the opposition.

[JamesD]

Ram access speed was a stopping point for a while.

But by the time XL came out they were using 150 ns chips, and pretty sure the XE had 90 ns chips.

 

To do 3.6 MHz, something around 125 ns would probably be required. Possible that the Rom/Eproms might have needed to be respecced too.

 

Antic could have gotten a considerable upgrade. As it is, the bandwidth is there already to do 4bpp in 160 mode, although Antic/GTIA comms is a stopping point. With something like a combined Antic/GTIA they could have done an 8bpp mode and stomped the opposition.

So it may not have been even possible.

I do know that the ROM in the later MSX machines was the limiting factor.

[Rybags]

Thinking some more, it would have been OK to introduce slow cycles for Rom and I/O accesses. 7800 does it for CPU to certain I/O locations and Maria has slower access to Rom than to Ram.

 

Most disk based games will spend the majority of the code path executing or accessing Ram, so slower Rom access doesn't become a huge handicap.

[JamesD]

Thinking some more, it would have been OK to introduce slow cycles for Rom and I/O accesses. 7800 does it for CPU to certain I/O locations and Maria has slower access to Rom than to Ram.

It's certainly doable. If there was external logic to tell the the system to slow down when accessing certain addresses, later machines using faster parts could take advantage without having to redo the main chips. People could also plug in an upgrade kit into earlier versions of the machine to get more speed.

 

Most disk based games will spend the majority of the code path executing or accessing Ram, so slower Rom access doesn't become a huge handicap.

Unless you are running BASIC.

 

Most CoCo 1/2 machines could run double speed when accessing ROM and as a result, BASIC programs ran almost twice as fast even though RAM was still slow. This is because the majority of time spent executing a BASIC program is actually ROM access.

 

ATARI BASIC would probably run about 10% faster. Maybe a little more since the 6502 is more dependent on page zero than the 6809. OTOH, the 6502 requires a lot more code that the 6809 so it could be less than 10%.

 

If this hypothetical machine could switch out all ROMs for RAM, you could get around the problem by mirroring ROM to RAM (what the MSX machines do) and execute it from there. But you couldn't do that with a bankswitched ROM carts so some BASIC upgrades wouldn't work. You'd double the speed of ATARI BASIC that way though.

[Mr SQL]

James,

good point about the CoCo; it could access ROM at double speed but has the external logic to slow down for RAM access; it also had logic to access RAM at double speed but this simply took over the VDG's turn (no display) since the RAM was already running at double speed so as to allow the multiplexer to alternate RAM access between the CPU/VDG with no wait states.

 

I'm not sure how the GIME in the CC3 kept the display solid during double speed RAM access without 4X overclocking the RAM; perhaps that was the solution since the parts were all rated for greater speed by then.

Edited December 17, 2012 by Mr SQL