What’s that coming over the hill?

Debunking Frankenstein’s computer

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”!

In computer design it’s impossible to use “mismatched” parts because they simply won’t work together and, much as the author believes that of the C64, it rather obviously isn’t true. A lot of the C64’s competition were mostly assembled from off-the-shelf components so if anything they’re more fitting of the “Frankenstein’s Computer” label.

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!

We already know from the author’s writings, dear reader, that the problem is what is known “in the trade” as EBKAC.

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.

So how dear reader did Commodore apparently “scare” some of their opposition? By having products that people wanted to buy and priced competitively to the point that they outsold the competition. They weren’t the first into the market but produced computers that were popular; the PET series sold well, the VIC 20 sold a million units before any other home computer despite much of the competition having a head start and the C64 ended up in the Guinness Book Of World Records for sales and is still fondly remembered by the majority of people who owned one.

And we have to note that the author mentions the Timex Sinclair computers but, whilst Timex might have an American arm, it’s parent company was based in the Netherlands whilst Sinclair were British so the “trade protectionism” the author whines about doesn’t seem to be particularly effective. Because, as noted previously, the primary barrier for manufacturers from one country selling their wares in another was the cost of importing their kit for sale – the bump in price would have priced those machines out of the market without Commodore’s help.

Edit: your correspondent made a mistake in the above paragraph and wishes to correct it; Timex’s origins are actually in the United States and not, as stated above, in the Netherlands. The point does stand, however, since the author’s claims of “trade protectionism” would still have been a stalling point for the Timex Sinclair partnership.

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.

So just to recap dear reader, we have a “compatible” computer that couldn’t run all of the software from Atari’s previous model without third party software whilst simultaneously offering upgrades that meant software written for it wasn’t backwards compatible with those earlier machines either. This isn’t particularly “compatible” in computing terms.

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.

Except of course it didn’t cause problems; if there had been any issues we wouldn’t have more backroom-developed software for the C64 than any other platform from that era. The “problem” is that what the author perceives as being important doesn’t actually tally with what programmers wanted and we can see from the software released that this is as much true of other computers as it is the C64.

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!

The final design for the Amstrad CPC was turned out in less time than the C64 so it would be very hard to claim that “a lot more care” was taken, especially when the people hired by Amstrad have described it as being done in a “rush”. A two man team started on it in early 1983 with a 6502-based design but they were, essentially, found to be shining Amstrad on and the second team, Roland Perry and William Poel, were handed the job in the summer of 1983. They continued with a 6502 at the heart until August when Locomotive Software were approached about providing the BASIC and suggested switching to a Z80[1] so they could reuse some of their existing code. This is the point where the Amstrad CPC as we know it today was “born”, late August 1983 with the first prototypes appearing in October, so just eight months from start to the design being sent off in March 1984 for manufacturing.

The author’s blog has offered a skewed version of these events of course, but for a better breakdown of the Amstrad CPC’s origins your correspondent recommends readers pop over to the Register for their article You’re NOT fired which was written in collaboration of the people who actually built the Amstrad CPC.

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!

This is more for typographical reasons than anything else; it isn’t unusual for someone typing one of these listings to misread an 8 as a B or indeed D as a zero if the print quality isn’t brilliant like it was in the 1980s, so using hexadecimal numbers makes the process of data entry less reliable both for the person at home typing the program in and whoever was typesetting the listing at the publisher.

Your correspondent developed a type-in game for a print magazine a couple of years ago; the print quality has obviously been vastly improved whilst the chances of errors being introduced during typesetting are drastically reduced (partly because the listing can be submitted as a text file pretty much straight from the programmer’s development files[2]) but there’s still the issue of someone misreading the listing when typing it into their computer to consider and, to avoid frustrating people, we went with decimal numbers.

[1] Your correspondent personally feels that it was something of a shame that the Amstrad CPC ended up with a Z80 rather than a 6502; being very similar to the Spectrum meant that it was treated roughly by a lot of software houses and most fans of the machine quite rightly feel somewhat betrayed when it comes to cheap and cheerless Spectrum ports. The 6502 would have made the CPC more like a BBC Micro and there were already some very skilled programmers who could do wonders with that hardware who would have had a head start if tempted over to the Amstrad. Imagine games like Fire Track (your correspondent’s favourite BBC Micro game) but with more colours…

[2] In this case the BASIC listing was generated from the machine code by a custom written cross development tool.

This entry was posted in Debunking and tagged , , , , . Bookmark the permalink.