Micro Computer comparison – Part 1

Recently I ran into the rantings of fan boys about the Commodore 64 and the Sinclair ZX Spectrum. I wasn’t very satisfied with the arguments of either side, as they were both filled with bias and ignorance, just like pretty much any flaming on the internet. One C64 fan even claimed the 6502 was faster than the IBM PC (an 8088 @ 4.77Mhz). So I decided to do some reading of data sheets myself to get a more balanced and accurate view of the real potential of the machines. Just to clarify, whilst I own one of each kind of machine, I didn’t have either as a kid and thus don’t have childhood memories to bias my opinion one way of the other.

This is an incredibly long article so read on if you dare!

One of the most important things that influences the speed of a computer is the speed of the memory, and how fast it can be accessed. I recently repaired my spectrum so I know that memory fitted in those is typically 150ns – 200ns. Now given that the processor in the spectrum is a Z80 running at approximately 3.5 Mhz, the clock cycle time would be about 287.5ns per clock cycle. This means that the processor shouldn’t have any wait states waiting on slow memory. The C64 is similar in that the RAM it uses is about the same speed, but the processor is significantly slower at about 1Mhz (which is 1µs or 1000ns approximately) so it also doesn’t need any wait states. This initial information looks very bad for the C64 and 6502 processors, but reading the data sheet for the Z80 reveals that it takes 3-4 cycles for it to access memory during it’s fetch execution cycles. All this means that in theory at least they can both access RAM at roughly the same rate, with a very slight advantage if any for the Z80.

The RAM story doesn’t end there however. We need to take into account architectural influences such as DRAM refresh and the video card output. Firstly the spectrum is quite a lucky beast in that the Z80 processor will perform DRAM refresh cycles as part of its execution cycle. It does this during phases it is not using the bus for other activity, and it saves the processor from being interrupted by the DRAM refresh circuitry, the other bonus being the support circuitry was simpler. The 6502 in contrast has no built in DRAM refresh circuitry which clearly will cost the processor bus cycles whilst the refresh is being accomplished. I was unable to find enough information on the internet to quantify how much of a disadvantage this would be, so we will ignore the refresh cycles for now.

Unfortunately for both machines the video memory is simply a part of the main memory in both machines. This impacts both machines processors significantly as the video circuitry takes over the bus to read video RAM in order to display the image. The video processor has precedence over the main processor so it has to wait before using the bus. The amount of time the processors wait depends on the graphic mode and display circuitry, lets take the ZX spectrum first as it’s simpler.

In the spectrum the lower 16Kb of RAM contains the video memory, the ULA chip manages this memory and sending it to the video circuit. The video memory is made up of two segments, the monochrome image data, and the colour/attributes section.The monochrome data is simple, a 1 for a on pixel and a 0 for off. The size of this data is 256×192 pixels by 1 bit or 6,144 bytes of data. The attribute data is 1 byte for each 8×8 block resulting in 768 bytes of colour data. The ZX spectrum needs to read all this data as fast as it needs to generate a PAL composite signal (it generates this to feed through the RF modulator). For every 8 pixels it should need to read two bytes (the mono data and the colour data) so it should need to read 12,288 bytes per frame displayed. A PAL signal runs at 25 Frames per second so there should be 307,200 bytes read for display per second. Given that the data bus runs at 3.5Mhz this equates to approximately 8.7% of the total bus time available, but we round that up to 10% on the basis of potential overhead in the memory contention mechanism.

The C64 is a much more complicated beast as it has a number of graphics modes. Apparently the most common modes are based around the 320×200 resolution, and there are a number of hardware sprites supported by the VIC II chip. For the sake of simplicity lets consider the text mode for the C64. Unlike the spectrum, the C64 text mode is much like the character generators for many serial terminals of the era. A segment of memory stores the ASCII data on screen, and a character ROM tells the video circuitry which pixels to turn on and off. So in the case of a monochrome text display the bus bandwidth used is a similar calculation to the spectrum. It needs 1 byte to read the ASCII character, and 1 to read a lump of 8 pixels to put out through the video circuitry. With the 40×25 characters in text mode this should end up at about 16,000 bytes per frame, and at the same 25 frames per second this is 400,000 bytes. With the bus running at about 1Mhz this would mean about 40% of the bus time is used for video in the basic text mode.

Somehow this doesn’t seem right to me, as it would slow the C64 down significantly compared to other machines using the 6502, and I hadn’t taken into account graphic modes which use colour and bit mapped graphics. Schematics for the machine didn’t help me work out a better quantity but suggested something I suspected. I think the high number is a reflection of my lack of knowledge about c64 hardware and its complexity compared to the spectrum. But one thing is clear, the c64 will waste more bus time rendering video than the spectrum does.

I suspect that the c64 has a similar mechanism to the spectrum for accessing memory. On the spectrum the processor is only held up by the ULA if it happens to be accessing the same 16K segment of memory (called contended memory) so the processor can run unhindered if code and data are not in that segment. This means the 8.7% loss of speed on the bus is likely a worst case scenario for the spectrum and that the C64 will, judging by it’s schematics, also have a similar mechanism to limit the amount of loss. The worst case scenario for both machines is when either one tries to blit (copy) an image onto the screen.

Fortunately for the C64, most games can avoid this worst case by utilising the hardware sprite capabilities of the VIC II chip. This is a tremendous advantage for moving sprites, providing you don’t exceed the number of hardware sprites supported. Lets take the case of a 32×32 sprite. On the spectrum without hardware sprites, drawing the sprite to screen requires 128 bytes minimum to display without colour changes and 16 extra bytes for the 8×8 colour block changes. It may need to do this twice to erase where the sprite originally was! The C64 only has to write a few bytes to the memory mapped area for sprites to move them, this is clearly faster by any measure and quite an advantage when it comes to generating graphics for games.

So ends the first part of the in detail examination of both machines. At this point I would consider the spectrum ahead in terms of RAM bandwidth, but behind in graphics chip capability. The magnitude of the memory bandwidth difference is hard to judge, but it’s due to the higher bus speed of the spectrum and bandwidth requirements to support the graphics on both machines.

2 Responses to “Micro Computer comparison – Part 1”

  1. March 2, 2013 at 6:13 am

    Interesting task you have set yourself, dispassionately comparing those two! Make sure to keep your crash-helmet handy, for when the fanboys show up! Thanks for describing what you have found so far.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Enter your email address to follow this blog and receive notifications of new posts by email.

Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

%d bloggers like this: