commodore64crap   The C64's 40th Anniversary is nothing to celebrate! Explaining why the Commodore 64's BASIC V2 was crap and how some people managed to program the C64.

FRANKENSTEIN’S COMPUTER

Frankenstein’s Monster’s reaction to finding out he’s made of mismatched parts

As my Dad often liked to point out to me, Frankenstein was the name of a Doctor who created a monster out of various body parts. Frankenstein was the Doctor, NOT the monster. The more accurate name was “Frankenstein’s Monster”, but this was often shortened to just “Frankenstein”, after his creator.

Unlike most other computers, the Commodore 64 wasn’t properly thought out or designed, it was just a collection of mismatched parts, so in that sense it was “Frankenstein’s Computer”!

I often wondered what was wrong with my Commodore 64 when I owned one and was struggling to try and program it with a multitude of PEEKs and POKEs, so I’m glad that now I know! If I’d lived in the USA or Canada, then I think it would have been far less obvious to me that there was something wrong with the Commodore 64 because not many people over there had seen a BBC Micro or a Sinclair Spectrum. This was due to lack of choice, mainly because of Commodore’s price war, led by Jack Tramiel, which forced Texas Instruments out of the market, Timex/Sinclair out of the market in North America, as well as scaring most MSX computer manufacturers (apart from the US company Spectravideo, and Yamaha) from even entering that market, but also because of trade protectionism against foreign computer companies. People in the USA and Canada who bought an Atari, or a Tandy “Coco” had a lucky break, though. People living in Britain and other countries were able to buy INPUT magazine. This had BASIC type ins for the Sinclair Spectrum, Acorn’s BBC Micro and Electron, the Commodore 64, as well as the Dragon and Tandy Colour Computer. Some of the listings also had slight variations for the Sinclair ZX-81 and Commodore VIC-20 as well. Readers of this magazine could soon see that although all these versions of BASIC were quite different, only COMMODORE computers used a series of PEEK and POKE commands, while other computers used PEEK and POKE far more sparingly, or in the case of BBC BASIC not at all, because it used question marks instead of PEEK or POKE, as well as having a built in assembler. INPUT magazine also told them to buy Simons’ BASIC. At this stage I should mention that there was also quite a good magazine published in the USA called “Compute!”, which shouldn’t be confused with the “Compute! Gazette”. The magazine “Compute!” had lots of type in listings, where usually they published versions of the same game, not just for the Commodore 64, but for other computers with then current versions of BASIC. Commodore 64 owners reading this magazine could see that other computers didn’t require a whole load of PEEKs and POKEs to create games. What was wrong with the C64 can be summed up as follows.

The Commodore 64’s reaction to being made up of mismatched parts, as it tries to print an error message on the graphics screen! “WHAT graphics screen?! I’m a Commodore PET!”

It took about 10 months of careful designing to create the VIC-II graphics chip and the SID sound chip. After this, these chips were hastily fitted, hacked, or cobbled together with the existing VIC-20 case and keyboard in a different colour scheme, a VIC-20 ROM with some more code added, and to cap it all the VIC-20/PET Commodore BASIC V2 which didn’t support the graphics or sound hardware, to form the pile of crap known as the Commodore 64! All that mattered to Jack Tramiel was to show a prototype C64 at the CES in January 1982. None of the unlucky Commodore 64 buyers would have minded if the C64 had first been shown at a CES 6 months, a year, 18 months, or two years later, or better still NEVER! After this, the prototype C64 design ended up being roughly the same or even identical to the mass production model!

The program that caused the error above from “Your 64” Issue No. 1, due to a missing bracket in line 200. One of my first type ins

This process was in stark contrast to Atari and other manufacturers. I asked for a demonstration of an Atari 800XL computer at Silica Shop and was really impressed! Although I didn’t know it at the time, this was due to the design process for the original Atari 400 and 800 computers, compared with the Commodore 64. The Atari 800XL was an upgraded, compatible, debugged version which came with BASIC on ROM and 256 colours as standard, as well as 64K RAM. Some earlier Atari software won’t run on the XL, due to a ROM OS upgrade, but a third party program fixes this. The design work for Atari computers started in late 1977, as soon as the Atari 2600 games console was released. It was based on making an improved version of the 2600, but Atari decided to make a full blown computer to compete with the Apple ][. Atari wanted to use a version of Microsoft BASIC, but it wouldn’t fit onto an 8K ROM even as it was, without the ALL IMPORTANT EXTENDED COMMANDS to support their GRAPHICS and SOUND hardware! Atari commissioned Shepherdson Microsystems to produce a suitable BASIC which would fit onto an 8K ROM, but that company decided it was best to create a non Microsoft type BASIC without LEFT$ MID$ and RIGHT$, which also handled arrays differently, similar to Data General style BASIC, instead of DEC style BASIC, which Microsoft BASIC was based on. These computers weren’t shown at a CES until January 1979, but Atari’s advance plan was that, as they didn’t expect Atari BASIC to be ready in time, to use Microsoft BASIC at that show, then switch to Atari BASIC for the mass produced models. Obviously, this is what Commodore should have done with the C64! By this I mean Commodore BASIC V2 just for the CES, followed by Super Expander 64 BASIC or something like Commodore BASIC 3.5, as on the Commodore 16 and Plus 4, for the mass production models. I think Atari made a few changes after the CES, because their 400 and 800 computers didn’t ship until late 1979. That makes a design process of 18 months to 2 years!

Even apart from its BASIC, the Commodore 64 KERNAL ROM contains no routines for handling colour, graphics, or sound, which obviously created lots of problems for Assembly Language programmers. After selling my C64, I found out that the Amstrad CPC ROM has a whole host of routines designed to handle these facilities, though. I managed to use these routines in Assembly Language programs on my Amstrad CPC664. I’ve recently found out that the Atari ROM has some graphics routines like this starting at memory location $FCFC, but I’m not sure what they are yet. Don’t forget that these routines were programmed back in 1977-1978, though. Of course, a lot more time and care was taken to design the Amstrad CPC464 than the Commodore 64. Amstrad’s Locomotive BASIC even accepts hexadecimal numbers and has commands for interrupts! Commodore BASIC V2 doesn’t accept hexadecimal numbers, although short routines in BASIC programs enabled it to understand hexadecimal numbers. In spite of this, all the books and articles about the Commodore 64 which I read in 1984 which contained Machine Code in DATA statements used decimal numbers!

The Amstrad CPC464 was designed as follows. Amstrad first of all designed the case before they had anything to put into it! This was an unusual approach, but at least they left plenty of space for the motherboard and everything else. As Amstrad wasn’t a computer company, they didn’t base the CPC464 on any of their older computers, because they didn’t have any. They hired people who knew about computers to put the best package together. Roland Perry went round lots of companies shopping for a version of BASIC, instead of just buying the latest version of Microsoft BASIC, which would have been written in 1983 or 1984, making it similar to MSX BASIC or GW BASIC. He eventually decided to make a deal with Locomotive Software. This wasn’t long after Locomotive Software had produced a version of BBC BASIC for the Acorn BBC Micro Z80 second processor, as the BBC Micro is a 6502 based computer. Locomotive Software produced a slightly different version of this BASIC for Amstrad, deleting the PASCAL like procedure based commands DEFPROC, ENDPROC, and PROC, but adding some commands such as SYMBOL to redefine characters instead of the BBC VDU 23, a more powerful ENVELOPE command for controlling sounds, as well as using different numbers for the MODE command, although both computers used the 6845 video chip. Long variable names were kept. The number of display modes was rationalised from 8 on the BBC Micro Model B down to 3 on the Amstrad CPC464, although these modes were roughly the same resolution as the BBC Micro, but they could all display text and graphics, with a border cutting the vertical resolution from 256 to 200 and no predefined Teletext mode. A neat engineering trick gave the Amstrad CPC464 a palette of 27 colours instead of just 8 on the BBC Micro Model B. The Amstrad CPC464 started out with a choice of 20, 40, or 80 column text, although the Commodore 64 was limited to 40 column text, requiring a third party add on card or a special font for 80 column text.

After I sold my Commodore 64 and got an Amstrad CPC664, I was so traumatised by my Commodore 64 experience, that when my Mum told me she was going to have a quick POKE behind our stand up piano in the living room to find a particular kind of wool, I told her not to to have a quick POKE behind the piano, but to have a quick CALL behind the piano instead. This was because the command CALL is used in Amstrad’s Locomotive BASIC on the CPC computers to run Machine Code programs from BASIC. PEEK and POKE are used as well, but obviously nothing like as much as in Commodore BASIC V2! At the time, I was learning about this from the amazing book called “Sensational Games for the Amstrad CPC464”, which had a collection of type in games written in the excellent Amstrad Locomotive BASIC.