The Sinclair Spectrum 48K is a nice machine, and it differs from the Commodore 64 very much. Given those great differences, it is more than natural that some people who like the Spectrum do not appreciate the Commodore 64. There’s nothing wrong with it – it’s just a matter of taste. Those machines belong to the same time period, they both enjoyed a great commercial success, so making comparisons is something than cannot be avoided. But, celebrating the Spectrum by throwing a bunch of technically inaccurate criticisms over the Commodore 64 seems a little bit odd though.
Maybe some Sinclair enthusiasts just think that “gaming-oriented” Commodore users don’t have enough technical knowledge to find some evidence against their assertions. I don’t think I have a great knowledge about the Commodore 64 actually, but I still think I have a good idea of its capabilities.
A web article oddly states that the Commodore 64 is clearly better “technically” but that virtually anything was better on the Spectrum.
This article just seems to be written by a C64 “hater” hiding behind polite words. Not only that article is Sinclair biased: it is clearly aimed at Commodore 64 underrating.
Some time ago a Sinclair enthusiast on Youtube wrote this sentence: “The Spectrum was better for loading games, playing them and for programming”. It’s clearly a joke from a Sinclair enthusiast, which was actually a funny way of stating a legitimate opinion. But, this sentence did happen to come handy for this post, because that sentence is more or less what the author of the article mentioned above is actually implicitly saying all the time – yet pretending of making a “fair” comparison between the two machines. Professional coders and/or engineers statements are very often quoted in that article on an effort of providing technical evidence which would seem hard to contradict. Well, I am a hobbyst programmer, but I am not afraid of going against the opinions of talented Spectrum or even C64 coders of the 8 bit era and/or today.
I am not going to give you a link of the article and I won’t provide you with exact quotes from that article either. I am just a simple freelance blogger and I have to respect some rules (including copyright of other sites content). Furthermore, I am only focusing on the contents and I am not against the author of that article, so that’s another reason I am not going to link the original article. But, if you have read that piece of writing, you’ll certainly recognize it from what you will read from now on.
Claim 1: the C64 was basically an entertainment machine – C64 BASIC was more or less just a load of POKE instructions. Since it has arcade-games oriented custom chips, it is little more than a game console.
Well, the Commodore 64 may be regarded as a Commodore PET computer with arcade-style features added (namely, the VIC-II and the SID chips). Given the fact that the PET was mainly used as an educational computer, even if it didn’t have any bitmapping capability – I don’t see why the C64 couldn’t be used for that either. The C64 memory management allowed you to replace its built-in BASIC with no memory waste. You could just swap out its BASIC and replace it with another language if you would like to (LOGO comes to mind for instance). Of course, this could be done on software. Furthermore, I don’t think that the lack of BASIC commands for hi-res graphics and sound would prevent anyone from using it as a learning tool. Do you really need commands for drawing lines and circles to learn programming? I don’t think so. Commodore 64 BASIC in ROM was not “a bunch of POKEs” when it came to text-based programs for instance. You certainly had to rely on some POKE commands if you wanted to use sprites and make music with just the built-in BASIC. But, the Commodore 64 was capable of running generic BASIC programs like any other computer (it actually had the very same version of BASIC that was available on many other computer models of that era). So, you could easily learn programming techniques with no need for “complex” POKE instructions: decision making, jumping, loops, variables assignments, math calculations, string handling… anything was basically like any other BASIC interpreter. And you could type in your code by using a decent typewriter-style keyboard.
If you needed an easy access to bitmap graphics like the Spectrum – plus other features – you could plug-in a Simons’ BASIC cartridge or use other extenders. Even type-in programs from magazines were available. You just needed “graphics libraries” in a sense. And that’s just what happens on today’s computers. Does C language have a native support for bitmap graphics? I don’t think so, you have to use a graphic library for that. But even without a graphic library, can’t you learn programming by using C? You certainly can.
The point is, the Commodore 64 was an 8-bit computer that could be used as a learning-tool, as a small-business system and as a gaming system. A Simons’ BASIC cartridge did not come for free (it costed 50 pounds actually), but that’s another point. With built-in BASIC support for graphics and sound, the Spectrum was a cheaper choice for the BASIC programmer and it offered the clear advantage that BASIC programs using graphics would run on any other Spectrum machine (instead, if you would like to RUN a Simons’ BASIC program on your friend’s C64, he had to own a Simons’ BASIC cart as well – otherwise, you had to bring yours with you). But, those disadvantages were not enough to make the Commodore 64 just a game console.
Claim 2: on the Spectrum, pre-shifted graphics is needed to get a smooth movement in scrollers, but it wastes a lot of memory. But the Commodore 64, even if could do scrollers without such a waste of memory, couldn’t provide easy access to most of its RAM memory, so many games could only use a small part of the total RAM of the C64. A great fraction of the C64 memory was actually shadowed by I/O registers, screen memory and ROM.
So, on the Spectrum they had to use “pre-shifted” graphics to make smooth scrollers. It does have a cost however, not only concerned with memory: you were forced to reduce the details of images. Many elements had to be repeated to save memory and compensate the memory waste caused by the “pre-shifted” graphics technique. On the Commodore 64, thanks to the hardware scrolling, the same amount of memory would provide you with more detailed scrolling screens.
The “slightly awkward” technique for accessing the “hidden RAM” on a Commodore 64 just requires writing a value on an I/O port of the CPU (is it really that difficult?). Furthermore, I just don’t get the meaning of “RAM shadowed by screen memory”. What does that mean? Screen memory is in RAM, so how could RAM be shadowed by itself?
Dealing with memory, it’s the usual Sinclair-biased approach: Sinclair users sometimes say that the Commodore 64 has more RAM memory than the Spectrum, but using some memory “banks” is so difficult that you can actually think that the Spectrum has virtually as much RAM as the Commodore 64. The truth is that in machine language, the Commodore 64 offers up to 60K (4K are always used for custom chips I/O, they are mapped there). Anyway, most of the time Sinclair users will just say that the Spectrum has more memory than the C64, and this assertion is typically based on the 38911 BASIC BYTES FREE start-up message. “The Spectrum is the better machine. It has more memory available”, Sir Clive Sinclair said on an interview. He’s clearly wrong, but at least he definitely had the right to be Sinclair-biased…
For example, despite the 38911 BASIC BYTES free, a 50K machine language program will load with no problems with the default memory configuration. That’s just a quick way to demonstrate my assertions. For further informations on Commodore 64 memory management, you may read this article.
Claim 3: the Spectrum lacked hardware but that was an advantage: it lead to new ways of programming – and new kinds of games were invented (for example, isometric games such as Knight Lore).
On the Commodore side instead, all coders were incapable of doing something different from the usual 2D shoot-‘em-up… that’s what you mean? “Defender of the Crown” was an arcade style game then?
Claim 4: the hardware capabilities of the Commodore 64 were a clear disadvantage as they forced coders to write 2D shoot-‘em-up games only. On the Spectrum, lacking custom chips for graphics and sound, you could just start from scratch instead, coming up with innovative software like isometric or vectors based games.
Despite of how C64 ports of isometric Spectrum titles of the 8 bit era look or play, I don’t understand why the C64 is supposed being not capable at isometric games. Those games are not based on vector calculations. Graphics is drawn using isometric views and sprites are shifted in both X and Y directions at the same time. That’s it. Is it something the VIC-II chip can’t do? Spectrum games were more than likely badly ported on the Commodore 64 by using the same programming approach as on the Spectrum (e.g. by only using the bitmap screen with no hardware sprite aids), so that’s pretty clear why they were sometimes slower on the C64. Again and again, well programmed software from the Spectrum side is compared with not so well programmed software from the C64 side. Is that approach good for comparisons? I don’t think so.
Most isometric titles on the C64 were written just to give the C64 more titles, but having arcade-style features, the C64 just didn’t need them. Furthermore, since the C64 had two joystick ports – accepting standard Atari-style controlling devices – C64 games were more focused on joystick-controlled games. Arcade games were good for a joystick – isometric games were not so good for that instead.
Talking about 3D, that’s different. The Z80 CPU of the Spectrum has a clear speed advantage over the 6510 of the Commodore 64. Vector calculations can be performed faster on the Spectrum’s Z80, as it has 16 bit internal registers. Despite the great clock ratio (3,5 MHz : 0,98 MHz), the Z80 on the Spectrum was not so much faster than the C64 6510. Usually, Z80 instructions required much more clock cycles than the 6510 counterparts. On the Spectrum, you also had contended memory (that means, there were 16K of memory where programs would run significantly slower than on the remaining 32K memory, due to the ULA chip stopping the Z80 at times). All that considered, the Spectrum was still faster computationally on most cases, but not much faster. True 3D games is basically the only kind of software where the faster Spectrum CPU really counts. And 3D titles are only a small fraction of all the games available for both systems.
Still, even if Freescape games like Driller or Castle Master were slower on the Commodore 64, those versions could at least offer much better colours – and they usually had nice musics being played in-game.
There are however 3D titles that play quite fast on the C64, and “Stunt Car Racer” is one of them.
As for “3D effect” style games, Chase HQ was faster on the Spectrum, but Outrun was faster on the C64. Space Harrier was not better on the Spectrum. Despite a good 3D effect, actual game action was quite limited on the Spectrum version. C64 could at best offer colour bars instead of the Spectrum’s 3D chessboard (C64 Sega version of Space Harrier, and Space Harrier II), but action was faster and colours were much better.
Claim 5: C64 game coders made an extensive use of the hardware that they had available. So, they ended-up coding games based on sprites and programmable characters. They did not make use of other programming techniques requiring more CPU power for graphics.
Well, on a Commodore 64, hardware sprites allowed you to move 504 pixels by only writing three values in memory. Why on earth C64 coders should have discarded hardware sprites and should have moved/shifted many more bytes on memory (namely 63 bytes) to accomplish the very same task? Not to mention that sprites were colour clash free even at high resolution. If you needed bigger sprites, you could expand them or you could multiplex them (sprite multiplexing doesn’t make use of a VIC-II bug like the article reports, it was actually a feature obtained by using raster interrupts, and it was meant to be provided to coders by Commodore itself, as it is clearly documented in the Commodore 64 Programmer’s Reference Guide).
Claim 6: the lay-out of the Spectrum bitmap screen is better for vector graphics than the C64’s one. C64 screen lay-out was too complicated and even simple tasks like drawing lines ended-up to be way too complex on the C64. The Z80 CPU had a bigger register set and an efficient 16-bit math, and that helped on vector graphics. On the C64, VIC-II steals many cycles to the 6510, so the VIC-II features come at the expense of 6510 power.
Well, I have coded very lame high CPU power consuming line drawing routines – aimed at testing my math routines (you can find them on my blog, they are still beta versions). So, these line drawing routines were intentionally really complicated (and used the equation of the line – very inefficient). Despite of that, I got decent performances. So clever line drawing algorithms should perform well on a Commodore 64. In fact, many Commodore 64 demos actually show fast line-drawing routines.
Now, what cycles are stolen by the VIC-II when doing vector graphics with the bitmap screen? While in bitmap mode, the C64 just offers the very same CPU power that you have for any other application. Still, when sprites are active, a few cycles are stolen, but with nearly zero cost for the 6510. Otherwise, hardware sprites would have been just pretty useless, don’t you think?
Claim 7: Basically, software is much more flexible than hardware. So, if you have adequate processing power, it’s nearly always easier to solve any given problem in software rather than in hardware.
“Basically”, on a Spectrum you need nearly a Pentium processor to match all Commodore 64 graphics and sound abilities with the Spectrum’s limited hardware.
Claim 8: the C64 had a graphic mode which was very similar to the Spectrum graphics (the 320 x 200 hi-res bitmap mode offered by the VIC-II). But if you tried to port Spectrum games using that graphic mode, you ended-up with games that looked horrible, especially on a tv set. When you tried to use Spectrum shading techniques on the Commodore 64, you ended-up with a lot of unwanted color interference.
Why even bother to port monochrome games on a platform where colour clashing was not really a big issue? Despite of what game developers did at the time, that’s what I wonder.
But, I am not afraid of going into technical details anyhow. RF output could not provide a good video output for the 320X200 resolution on the Commodore 64, that’s a fact. But, you had a DIN connector providing S-Video. That means, using the right kind of cable, you could get a nice video output even for the 320×200 mode on a C64. Sometimes you didn’t even need a monitor for that – a television set was enough, provided it had S-video support.
Claim 8, part 2: to fix the problem, you were forced to use one of the other lower resolution modes available on the C64. Graphics looked poor compared to the more detailed graphics of the Spectrum.
When using S-video on a monitor instead, the C64 offers a good “hi-res” image, nearly providing 15000 points more than the Spectrum on the screen. The GEOS operating system actually makes use of this hi-res mode.
Still, even if you just have a television set with RF connection, there is a way of avoiding colour interference while using the 320 x 200 graphics mode. You just have to avoid one pixel wide vertical lines. That requires that single dots on the screen must be doubled horizontally. This way, you may think that you just end up with a 160 x 200 resolution. That’s not the case, as double-width points can be off by one hi-res point. So, you can still create much more details than by using the 160 x 200 graphics resolution. Take a look at the Commodore 64 ROM font for instance. It’s not a blocky 160 x 200 font. It’s just a 320 x 200 font designed to avoid colour interference on TV sets. And it just follows the above rule. It’s not a low-res font, it’s a bold font for improved readability.
The article then goes on by showing some screenshots. C64 screenshots are clearly zoomed-out so that they seem less detailed than the Spectrum counterparts. Furthermore, that way sprites do seem much more tiny on the C64.
Claim 9: very lately, Commodore developers found out that they could put sprites on the borders. This can be seen as a desperate trick with limited use in games.
A “desperate” trick? Ultra-efficient Spectrum scrolling routines with “pre-shifted” graphics – desperately trying to achieve at least a fraction of what other systems could do on hardware – were far more “desperate” tricks in my humble opinion.
Claim 9, part 2: sprites in the border are nearly ridiculous – you can only put scores on the border with them, they’re not useful at all for other tasks.
Take a look at the game Cabal (euro version), and please see how many nice things sprites can show. The truth is, on a Commodore 64, you could even use the borders to show useful information. On the Spectrum, not only you couldn’t show anything on its big border, but also many coders used to waste a big amount of the screen play area just to show the title of the game (the title was already clear from the title screen, so that’s completely useless). Well, it was actually useful. That way, the Z80 had to scroll only a reduced screen area… that was most of the time the only way to get a software scrolling performed at a decent speed on the Spectrum.
Just consider that many coders achieved a wide range of full-screen effects on the C64 using both the viewable area and the borders.
At a certain point, the article gets even more biased when it tries to make readers believe that the classic Spectrum sounds abilities are more or less the same as the C64 SID chip’s ones. Actually, the 48K Spectrum can at best provide a poor rendition of C64 tunes, eating up much of the CPU power, because it has to emulate on software features that the SID chip offers on the hardware.
Rob Hubbard did provide many tunes that were capable of producing complex sounds without using any sort of samples. His sounds did make use of wavetables, long before they were used by Jeroen Tel. Tel did come up with a bunch of new techniques, but the work of Rob Hubbard already showed many SID features by 1985.
The article basically says that the C64 needed a lot of CPU power to reproduce samples, and that any SID tune of any complexity just couldn’t be played in-game. That’s actually not true. The SID chip can play very complex tunes with little effort for the CPU. Samples and software driven sounds in general may be regarded as a bonus, but they are not really needed on C64 music. Look at Terra Cresta on the Spectrum. It has a nice title music (trying to match the correspondent C64 tune, still clearly failing due to the limitations of the Spectrum sound), but it has no in-game music. Of course, the Spectrum cannot play an in-game music of the same quality of the title screen music: it would just require too much CPU power. On the other hand, the Commodore 64 enjoys a quite nice in-game music. Also the C64 version of Ghost and Goblins does have nice in-game musics as well. On the 48K Spectrum version, you have no in-game musics. The Z80 is a nice 8 bit CPU, but it can’t do miracles.
All that said, it’s clear that to get on the 48K Spectrum something only a bit similar to what the SID chip could offer with little 6510 usage, you had to use a lot of the Z80 power. As a matter of fact, you could get three-channel decent tunes even with BASIC on a Commodore 64. Those “loads of POKEs” most of the times actually allowed on the C64 – by simply using BASIC – things that would rather require machine language on a Spectrum.
While the 48K Spectrum – with all the best tricks – just struggles to match a fraction of SID’s capabilities, the Commodore 64 can be programmed so that it can offer incredibly high quality sound experiences for a humble 8 bit system, that may even come close to what the Amiga could offer. The better performances, the more CPU power required, but that’s just your choice.
You can get really nice tunes on the Commodore 64 even by calling sound routines only once in a frame. That means you only need a small fraction of the CPU power for most tunes. That’s why many C64 games actually feature complex in-game musics, despite the 0,98 MHz clock of the 6510. Built-in custom hardware features matter, that’s the point.