EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: TheRuler8510 on July 25, 2014, 05:52:17 pm
-
RE: How Does the C64 Compare to ATMEGA 8-bit? ( Such as ATMEGA328)
I have always been interested in performance and speed comparisons, so I wonder if anyone has run a simple program for performance testing on a Commodore-64, then run a version (as similar as possible) on an ATMEGA 8-bit processor?
Has anyone done this? If not, then does anyone have an theoretical opinion on how they would compare? In-other-words, if the ATMEGA is running at 1 MHz, will it run a sort routine at the same speed as a C-64? I think C64 was running at 1 MHz.
Then what about floating point calculations--how would that compare?
I would test it myself, but unfortunately I tossed my C-64 15 years ago, and now regret doing that.
Thanks for any expert opinions,
-
The 6502 is pretty fast when not doing any floating point, especially when a skilled programmer programs in assembler and optimizes the hell out of it. Did you see this thread? (6502 is STM8 here) https://www.eevblog.com/forum/microcontrollers/dhrystone-2-1-on-mcus/ (https://www.eevblog.com/forum/microcontrollers/dhrystone-2-1-on-mcus/)
-
Pound for pound, the AVR core handily outperforms historic 6502. Still true even if there are "single cycle" variants, because AVR has more registers, and probably more instructions. If nothing else, the computation is vastly improved with the 8x8 bit multiply instruction.
As for peripherals, if you can mate all the RAM / video / SID / etc. stuff to an AVR bus (older chips had a legacy microprocessor bus available, but that's all but gone now I think), you should be able to do pretty well.
Now, comparing a stock C64 to an ATMega with whatever selection of e.g. Arduino shields you want to throw at it, you might have a challenge. The C64 was literally made for its purpose; the ATMega, you have to slap everything onto it, and that's painful (using serial channels or clunky GPIO bit/byte-banging). I'm pretty sure most everything has been done, at least individually; it should be possible to bring everything together yet (i.e., keyboard, audio, video, etc.) to reproduce the same functionality.
One notable thing that you simply cannot get: RAM. ATMegas do NOT offer much RAM. I don't know offhand if the XMegas offer more. You could hack it by using onboard RAM as live workspace and offload it, page by page, into an external device (again, via GPIO or serial -- somewhere between slow and molasses), or you can try abusing program Flash as RAM (slow to write, awkward to read, and causes wear -- not to mention the possibility of overwriting the program ROM itself, something a C64 BIOS ROM can't worry about).
RAM is the major defining difference between GP and embedded computing -- single-purpose machines rarely need much state, the rest can be stored in ROM (data tables, or the program -- same every time). PCs need a lot of memory: an OS, the drivers to interact with diverse hardware, and the overhead to run one or multiple programs on top of that. The I/O methods likewise tend to be richer in data, if slower in update: 640 x 480 VGA for example, though on original hardware, you wouldn't even be able to touch every pixel before the video controller takes control of that memory again (these days, such modes are hardware buffered, so the hardware is reading and displaying it at the same time the processor is doing whatever with it. Such buffering would've been even more expensive back then!). Conversely, embedded systems tend to include real-time features, like serial channels, GPIOs, UARTs, etc.
More recently, demand has pushed LCD controllers onboard as well, which you might take as a sign that history is repeating itself -- there's the huge, lumbering PC; the small, nimble embedded graphics system echoing generations past; and the ant-like, real-time embedded worker, that might not have any direct communication with a human at all (or only through the vaguest of LEDs and button presses), but is used so frequently that it is not going anywhere.
Tim
-
Dhrystones might be a reasonably benchmark.
http://wiretap.area.com/Gopher/Library/Techdoc/Bench/dhryst.txt (http://wiretap.area.com/Gopher/Library/Techdoc/Bench/dhryst.txt) says a C64 benchmarks at about 35, and http://www.ecrostech.com/Other/Resources/Dhrystone.htm (http://www.ecrostech.com/Other/Resources/Dhrystone.htm) says a 14.x MHz AVR does about 8000 (some other sites say closer to 6000.) It's a little difficult to tell whether they're quoting the same sort of number, but it seems reasonable that the AVR is "much faster."
Some of that comes from clock speed and instruction efficiency. A 6502 ran at least two clocks per instruction (and most instructions were slower), so that's a factor of 32 right there. Then the AVR has many more registers, and probably a much better C compiler... Also, note that the Dhrystone benchmark uses a lot of desktop-like C constructs (pointers, 16 and 32bit math) that were probably particularly difficult to do on 6502.
Note well what T3sl4co1l says about RAM. There's SO much difference between a von Neuman machine with 64k of program/data RAM and a Harvard architecture machine with 64K of flash program memory and 4K of RAM, especially when it comes to doing OS and desktop-like features.
-
While the raw numbers said ATMEGA328 is much faster, but I think the 6502's doesn't feel as sluggish as the numbers may suggest.
Compilers of that era were not Microprocessors friendly. Bare in mind, compilers were ran mostly in place; instead of the IDE on a PC than download the compiled binary to the target MCU. So, compilers for 6502 were dealing with severe resource constrains which PC based IDE doesn't face. With such resource constrain, optimization was what programmers do and was not a job for the compiler. (read on about resource constrains).
I was an Atari 800 owner, also a 6502 but a bit better machine than the Atari 400 which was closer to the C-64 (if memory serves). Still, I had (after OS and map-IO space) 48K left. Audio tape was too slow for mass storage, so I had a floppy (more memory gone to operate it), 40 column text display was too narrow so I had an 80 column x 20 (or 80x16) display. That took another 4 or 8K of ram. So, in the end, I was looking at the C compiler running around 16-32K of ram and program space. That is it. The compiler has to do everything with less than 32K of ram. You can't fit a fancy compiler in that space. So, my favorite language on the Atari was FORTH for the wacky one time stuff and C for the more serious stuff. Best case (no add'l hardware) was 48K, so that is not much more either.
But the handicap forced programmers/developers to be more creative (such as closer integration of C with assembler using "in-line" assembly). The resource constrain developed a bunch of developers far more knowledgeable in how to squeeze down the clock cycles needed for a block of code. Hardly any one thinks about that these days.
With more being done in assembler then, the 6502 based machine doesn't feel as sluggish as the number may suggest.
-
And for that matter, period instruction sets were generally better for assembling. Z80 I like. The registers are good, about as many as you need. The instructions are simple, but not overly so: there is a lot of load-modify-write and pulling stuff through the accumulator, but it's not as bad as 6502 and similar low-register RISC machines. It's pretty orthogonal (not counting the accumulator-centric instructions), not like the complicated heap that followed, x86.
AVR is certainly possible to assemble, and as long as you remember all the instructions, it might even be considered downright easy. (There's something like 200+ individual instruction types, though they're not as tightly grouped as usual: e.g., LD, LDS, LDR.. are all written as being independent, whereas on other architectures, they would be categorized as different addressing modes of a single (e.g., MOV) instruction.)
Downside: NOTHING* modifies memory in a single instruction, so doing absolutely anything takes three or more instructions. Very verbose and tiresome, and yes, this costs some execution time (though where the alternative is having all 4+ cycle instructions, well, it's not so bad after all).
*If you willingly fool yourself that the lower IO registers aren't RAM. Which, to be fair, the register file itself is RAM mapped for whatever reason, so maybe that's not as foolish a distinction.
The RAM and register layout of AVR is more or less tailored to C and other compilers (stack based, lots of registers, straightforward instructions).
As for numerical comparisons like Dhrystones, besides larger numbers (16 and 32 bits), you'll see a lot of arithmetic, including multiplication and division. Something like AVR doesn't have much help at division (even if you have hardware divide, unfortunately, you can't use it for bigger words, only smaller), but having all those registers available still speeds things up, to the tune of maybe 2-3x because you aren't constantly R/Wing memory. With hardware multiply, some multiplications are 100 times faster, which clearly accounts for something! Emulated floating point is also better for the same reason, though it still takes the bit slicing to get everything lined up.
Tim
-
one note regarding AVR and external bus - there we some micros in the past with a multiplexed address/data bus (my lovely first AVR AT90S8515/35), but those were not able to execute program from external memory.
and as it was already mentioned .... you're comparing the not comparable (Harvard vs. Von Neumann).
-
C64 excels as a desktop computer because it is a desktop computer. AVR excels as a microcontroller because it is a microcontroller.
-
The 6502 was a superior processor to the Z80 for a given clock frequency although it only had an 8 bit stack pointer. I believe it got its performance advantage by using an instruction pipeline.
I used to own a C-64. It was nothing special but the video and sound hardware is what made it. I also remember playing around with a BBC computer which had a 2 MHz 6502. I remember its screen updates were amazingly fast compared to a PC with a CGA card.
cheers
-
I remember its screen updates were amazingly fast compared to a PC with a CGA card.
I don't recall even first generation PCs being slower than the existing 8 bit computers at anything when they became available if the programs were written well. There was a "video BIOS" that came with the original cards that abstracted the video hardware away for compatibility sake, but you could always still program directly against the video memory which was mapped into the main address space and then it performed just fine. Anyone interfacing to the video BIOS did get awful performance, that was a well known tradeoff that almost nobody took.
-
I remember its screen updates were amazingly fast compared to a PC with a CGA card.
I don't recall even first generation PCs being slower than the existing 8 bit computers at anything when they became available if the programs were written well. There was a "video BIOS" that came with the original cards that abstracted the video hardware away for compatibility sake, but you could always still program directly against the video memory which was mapped into the main address space and then it performed just fine. Anyone interfacing to the video BIOS did get awful performance, that was a well known tradeoff that almost nobody took.
It was a consequence of the fact that you could not directly write to the display ram at any time because it would cause hash or interference on the display so the trick was to wait for the horizontal and vertical blanking intervals to do the writes which slowed it down considerably. Some CGA cards actually blanked the entire display when they scrolled the text . :D LOL
The later Monochrome and Hercules cards were much better designs ;)
cheers
-
Typically the memory is available on the processor bus via the graphics controller chipset (or if we're talking really early graphics, like IBM's original CGA card built of MSI chips I think it was, then simply however the logic interface was designed), but only when not actively using it. So, you might squeeze in a few bytes during a horizontal refresh (if you can manage to time those few microseconds correctly), but otherwise the processor stays in WAIT states at least until the end of the current scan line.
Vertical refresh lasts a milisecond or so, which was great in the 386+ era when bus speeds became sufficient to write a frame in that time (and hence pretty much every game since WOLF3D has used double or triple buffering), but early computers couldn't necessarily do it, certainly not in the high res modes. (Example: flat out writing bytes to the display, my 8086 can refresh the 640 x 350 x 16 color EGA screen at, I think it was around 5 FPS.)
CGA specifically, I don't know much about. I don't think I've noticed "snow" on any non-original hardware, but I'm aware it was a thing, and waiting for vertical refresh was highly recommended. Perhaps the early designs, and anything directly derived therefrom, didn't resolve bus contention correctly?
Tim
-
CGA had the option of waiting for blanking and having clean displays, or updating memory on the fly and putting up with some snow. (I think the BIOS routines would wait, so this was one of the speed improvements you could get by ignoring the bios...)
If you're talking about "early" IBM PC vs C64, you're probably talking about games written in interpreted BASIC. The CGA was a very simple bitmapped display with "standard" graphics library primitives, while the c64 had a sneakier controller with features aimed specifically at speeding/improving games (and presumably, BASIC commands to use them? Or, even if coding in pure assembler, I think the C64 graphics engine would offer a lot more "interesting" things.)
Also, IIRC the 6502 had a HW architecture where it would only access the memory bus every other clock cycle (fetch, execute), and clever hardware designs used this to share the memory bus with a video subsystem. Lancaster wrote about this a lot.