65C816 vs 68000

[cbmeeks]

I don't normally fall for these "vs" posts, but I am curious on your thoughts.

Given two theoretical machines, one driven by a 68000 (8 MHz) and one driven by a 65C816 (8 MHz) and everything else being equal....how would you rank the machines in benchmark tests?

I know this is a LOADED question...and not a fair comparison. But I only know of two mass-produced machines that used the '816 and that was the IIgs and the SNES. Both clocked relatively slow compared to other machines at the time.

I can put my IIgs next to my Amiga 500 (un-expanded) and the Amiga still feels snappier. Of course that comes down to most of the OS being in ROM, dedicated graphics, blitter, etc.

Anyway...not starting a flame war....jut looking for some fun conversation and theories.

Thanks!

[KC9UDX]

The Amiga OS is also unique (compared to all other OSs I'm aware of) in that it puts very high priority on user interaction. So it always feels "snappier." It's not really fair to compare it to anything else.

I think this has been hashed out already though, and the 65816 beats 68k and x86 at a given clock but all else equal. But I can't cite anything at the moment.

[GARTHWILSON]

KC9UDX wrote:

I think this has been hashed out already though, and the 65816 beats 68k and x86 at a given clock but all else equal. But I can't cite anything at the moment.

http://westerndesigncenter.com/wdc/AN-0 ... risons.cfm

A good post of Samuel Falvo's: viewtopic.php?f=2&t=18&p=190&hilit=68000#p190 (I believe the '816 increased more than the 68000 in clock speed after that. All 65816's sold today are guaranteed to be able to do at least 14MHz.)

7-page topic here on the forum: "6502 can be faster than 68k :-)"

[BigEd]

There's a very high level way to look at the comparison, which is approximate, but straightforward.

ARM exists for two reasons: the idea that memory bandwidth is the limiting factor for performance, and the observation that microprocessors available at the time made poor use of memory bandwidth.

From which we'd suppose that at a given speed of RAM, the '816 might do about as well as the 68008 (byte-wide data bus), the 68000 should do better than that (wider data bus) and the 68020 better yet (full width data bus, plus small cache.)

However, the 68000, like the Z80, takes four machine cycles to access RAM, more or less. So the proper comparison to an '816 running at say 4MHz is a 68008 running at 16MHz or a 68000 running at 8MHz.

In other words, at a given CPU clock speed, the 816 should be faster than the 68000 - fundamentally for the same reason the 6502 is faster than the Z80 at a given clock speed, that you'd be comparing systems with very different memory bandwidth. Which is to say, equal clock speed is not a level playing field.

Now, architecturally, the 68k has the advantage of having more and larger registers, which will help performance, but will hurt interrupt response - and interrupt response is often quite important. (That's why the ARM has register banks and efficient multi-register push and pop.)

[ttlworks]

We already had quite a few 68000 versus 65816 comparisons, but after NXP bought Freescale, such discussions became somewhat "academical".

68000\68HC000\68EC000 is out of production. Same thing for 68020\68030\68040\68060.
As for 2016, the 68332 (CPU32 core is a 68020 subset) (TQFP132 or LQFP144 package) is not recommended for new designs. Means that it will go out of production, too.
Fido1100 has a CPU32 compatible core and SDRAM interface (PQFP208 or BGA15*15 package). But availability of the PQFP208 version doesn't look good at DigiKey at the moment.

On the other hand, W65C816 still is in production, at a lower price, and DIP40 or PLCC44 package certainly is more "hobbyist friendly".
And _if_ the 65816 would go out of production, a FPGA implementation of the 65816 might give you less of a headache than a FPGA implementation of the 68000.

I'd say, if one would be out to build a "future proof" hobby computer, from the availability of the chips the choice won't be too difficult...

[BigEd]

Well, both '816 and 68k are quite complex, so implementing and testing HDL is no small task. But, perhaps because of the relative size of the user base, there are several open source 68k cores already available for FPGA, and nothing for the '816.

[ttlworks]

After an internet search, to me it looks like there is no 65816 in VHDL yet. //November 2016.

Let's just hope, that the community does a VHDL 65816 before our only source for 65816 chips might run dry "by accident" someday.

Ok, for our 65C816 versus 68000 discussion we had "availability of chips",
and "VHDL cores as a replacement if chips won't be available anymore".

Another interesting topic would be software.
For 68k without MMU, there seem to be operating system kernals, but not so for the 65816.

;---

Another point is, that from the hardware point of view it feels like there is no "standard" when it comes
to 65816 hobby computer projects.

68K at least had the VME bus which was designed with the 68000 DIP package pinout in mind.

While 80x86 certainly wasn't the most beautiful architecture around (sorry for even mentioning 80x86),
it looks like having a standard there (IBM PC, DOS, ISA bus) made it a success.

[KC9UDX]

There were other, better machines with standards. What made x86 was three things: the letters I, B, and M.

[sark02]

Back in the 80s I moved up from programming in 6502 assembly to 68000 assembly. It's clearly a matter of personal taste, but I found 68000 assembly to be an absolute joy, and it remains a favorite of mine even though it's no longer relevant.

For 8-bit architectures I prefer 6502 over Z80. I think if I put more time into it I'd prefer 6809 over 6502... But I haven't used the 6809 enough to confidently state that.
For 32-bit architectures I prefer 68000 assembly over ARM, MIPS and x86 (in order of preference). 68000 is just a nice place to be.

On a 6502 board that might be an unpopular opinion, but there it is.

[White Flame]

I think it's pretty well accepted that the 68000 has one of the most human-friendly ISAs, but per-instruction timing and interrupt timing wasn't very nice. The 68k family also got to be quite a power pig, iirc. Which aspect is more important depends on the individual's tastes and projects.

[BigEd]

I'm interested to hear someone familiar with ARM still prefers 68k - can you put your finger on any reasons why?

[Aslak3]

White Flame wrote:

I think it's pretty well accepted that the 68000 has one of the most human-friendly ISAs, but per-instruction timing and interrupt timing wasn't very nice. The 68k family also got to be quite a power pig, iirc. Which aspect is more important depends on the individual's tastes and projects.

I never understood why more MPUs don't have a "stripped down" interrupt pin or other mechanism where only the PC and maybe the CC is stacked automatically, leaving the rest of the reg's to be stacked explicitly if the ISR actually needs them? Obviously if you had to stack all bar 1 or 2 registers it would work out slower then if the hardware did a full stack, but for a MPU like the 68K the utility of partial stacking seems obvious. Gah, interrupt latency on the 68008 must be truly horrific.

Unless the 68K does have this kind of thing, but from what I've read and what you are saying it does not. The 6809 does, and it seems pretty useful, it's just a shame they never implemented a software interrupt with the same functionality.

[BigEd]

Looks like the 68000 takes 44 cycles to take an interrupt, plus presumably the time to finish the current instruction - which could be 158 cycles.
https://wiki.neogeodev.org/index.php?ti ... ns_timings
(I suppose it could all be longer, in a large system with memory wait states.)

(For background on the genesis of ARM, whereby the first ARM outperformed the 68020, using only a tenth of the transistor count, see
http://www.4corn.co.uk/articles/sfatvcs/
)

[Arlet]

ARM Cortex has a nice interrupt handling mechanism, explained here. It automatically stacks 5 of the user registers, which allows interrupt handlers written as plain C functions. Also interesting is that it will avoid de-stacking/restacking when two interrupts are handled back to back.

[GARTHWILSON]

BigEd wrote:

Looks like the 68000 takes 44 cycles to take an interrupt, plus presumably the time to finish the current instruction - which could be 158 cycles.

46 is what I got (almost the same as your number) for the chart at the end of the 6502 interrupts primer which I wrote many years ago (year 2002?). I probably got that number from a thick data sheet I had in a box with a ton of 68000 materials before I finally threw it out a few years ago. The number does not include time to finish the current instruction.