Archive for September 2013

DRAWING THE LINE (PART 2)   Leave a comment


The beginning of my BASIC V2 program to draw a line across the C64 hires screen

I feel I should start this post by telling you all the news that I’ve just managed to buy a Commodore 128 computer from eBay! I didn’t know if I was doing the right thing in bidding on this, but I was bidding on two or three of them, One of them came with a massive 5.25 inch floppy drive and lots of floppy disks, while this one doesn’t come with a floppy drive or anything else apart from the PSU. The C128 has three modes of operation, so it’s really three computers in one. It has its own native C128 mode, which is almost like a Commodore 64 that’s been fixed. I read this was in response to various requests or demands from Commodore 64 users. I suppose they didn’t want to lose the money they’d invested in their peripherals and software after finding out that the C64 was crap! It will be very interesting to see what I can do with Commodore 64 compatible hardware and a decent built in BASIC. Of course, it also has the C64 mode, which I think is more or less 100% compatible with Commodore 64 software. Apart from this, there’s the CP/M mode, which is CP/M Plus or V3.1, also supplied by Amstrad with their CPC6128, as well as their PCW series computers. This is CP/M with added GSX graphics, the ancestor of GEM, as used on some PCs, as well as the Atari ST. You’ll probably be reading on here how I get on with the C128. I wouldn’t dream of chopping it up with an axe, or chucking it on a bonfire, because at the end of the day it’s a USER FRIENDLY computer with a nice BASIC built in, which even allows you to control the SID synthesizer chip! Finally, I get all of this in a case very similar to the Amiga A500, as well as a PSU that looks identical to the Amiga A500 PSU. Actually, it’s the other way round because the C128 came out in 1985, while the Amiga A500 came out in 1987.

A Commodore 128 computer

Now it’s back to drawing a line across the screen in Commodore 64 BASIC V2. While looking at the details of how to open a hires graphics screen and set the colours in the “Commodore 64 Programmer’s Reference Guide”, I thought it would be fun to cycle through the screen and border colours, so here’s a listing to do just hat, which I developed on the WinVICE emulator V2.2 for Windows. I found out a few weeks ago that V2.4 had some bugs which put me off or even prevented me from using it. BTW, this listing doesn’t work under Commodore BASIC V7 on the C128. It does RUN, but it prints text characters on the screen instead of graphics.

Of course, I must comment on TMR’s stupid debunk of me giving notice a couple of days ago that I was about to post an article about how to draw a line across the C64 hires graphics screen. Commodore 64 BASIC V2 makes it impossible for the vast majority of people to actually draw a line across its hires or lores graphics screens. Of course, as he suggests, you CAN use a FOR…NEXT loop in a program to draw a line across the screen, but this is only AFTER you find out how to turn on and clear the screen, as well as whereabouts in the memory map the pixels you want to set are located. Apart from this, TMR has been refusing for about 13 months now to demonstrate to me how this is done, so why does he finally say he’s going to do it?

The end of my line drawing program

The following listing will open a hires graphics screen, which starts as usual in Commodore BASIC V2 graphics programs full of garbage or coloured squares. It then waits for more than several seconds, then slowly clears, before drawing coloured bars moving across, then down the screen, until the whole screen is the same colour, then it changes the border to that colour, before changing the screen colour from the top down again. Almost any other “home computer” of the time could do all this in a second or less, without you having to watch it clear the screen! It would do this with a simple command such as MODE 1 (BBC, Acorn Electron and Amstrad CPC), GRAPHICS 8 (Atari), SCREEN 2 (MSX), or it may have only one display mode, so wouldn’t need a command at all (Sinclair Spectrum). BTW, in the listing below REM statements which have a line all to themselves are all describing what happens in the previous line.

5 BASE=2*4096:POKE 53272,PEEK(53272) OR 8


10 POKE 53265,PEEK(53265) OR 32




25 FOR C=0 TO 15


30 FOR I=1024 TO 2023:POKE I,C:NEXT I





40 GOTO 40

All this does is show solid bars of colour going down the hires graphics screen, as well as the border changing at the end of each screenful of bars. But there’s something wrong here. It’s a bitmapped graphics screen, so how about plotting some points or drawing a line? Brace yourselves, because the following line does just that! Add this to the listing above.

33 POKE 8192,128:POKE 8193,64:POKE 8194,32:POKE 8195,16:POKE 8196,8

Then type RUN and you’ll be able to see in the top left hand corner that 5 pixels have been plotted in black!!!! OMG!!!!!!!! We can plot some additional pixels, each time by increasing the memory location to POKE by 1 (i.e. 8197 is next in the sequence), while each time halving the number to POKE it with, because this is a bit pattern, as in User Defined Graphics characters (UDGs) on most other “home computers” of the time. Let’s try adding this to our line.

33 POKE 8192,128:POKE 8193,64:POKE 8194,32:POKE 8195,16

I’ve gone through a lot of revisions and I’m typing and doing a bit of reformatting in a word processor now. Unfortunately, word processors nowadays display more than 80 columns. At some stage, without warning, the Commodore 64 will refuse to accept any more characters in a single numbered line, then any characters past the limit just won’t appear when you list the line. I thought the maximum line length was 80 characters, or two lines across the Commodore 64 40 column screen. Just to be on the safe side, we’ll continue on another line, but now I’ve counted the line above has only 55 characters, so it’s fine.

34 POKE 8196,8:POKE 8197,4:POKE 8198,2:POKE 8199,1

Run this program, then as before, the screen slowly clears, before colour cycling AND plotting 8 pixels from the top left hand corner of the screen, moving down and to the right with each successive pixel plotted. The top left 8×8 corner of the screen starts at RAM location 8192, which has to be POKEd with 128 to plot the leftmost pixel. This is followed by POKEing 8192 with 64, and so on for the first 8 RAM locations and first 8 pixels. After that, you have to start POKEing from somewhere else higher up in RAM, but it’s not straightforward working out what location this is. I found I had to do it by trial and error.

Don’t forget, here’s how to draw a line from the top left hand corner to the bottom right hand corner of the screen in Sinclair BASIC on the Spectrum

20 PLOT 0,170
30 DRAW 254,-171

Easy peasey lemon squeezey!

I was playing round with lots of revisions of the program, some of them couldn’t be reloaded and some of them didn’t get saved. Here’s the latest version of the program, which has moved on quite a bit from the last version. I’ll have to explain the additional POKEs to higher memory locations to you. After POKEing 8199 with the number 1, I continued by POKEing 8200 with 128, followed by the next few memory locations with 64, 32, and 16 to check what would happen. As I previously predicted, the pixels this set were in the character cell to the right of the cell where I’d been plotting before. I had to find the memory location of the cell on the next row and one column across. I needed a formula for doing this. No formula I tried seemed to work, but I eventually found by trial and error that the next memory location to POKE to continue my line was 8520. The relationship between this number and the start of the screen memory at 8192 is that 8520-8192=328. This tells me that whenever I want to start plotting in a character cell which is one column to the right and one row down from the character cell I’ve just been plotting in, then I need to add 328 bytes to the address of the lowest byte of my last visited character cell. The memory locations where each character cell I use for my long line starts in the program below are as follows – 8192, 8520, 8848, 9176, 9504, 9832. Let’s check if there’s really a recurring pattern there, because it certainly didn’t seem straightforward when I was trying to work it out! 8520-8192=328 (checked again and it’s correct!), 8848-8520=328, 9176-8848=328, 9504-9176=328, 9832-9504=328!

So, from the above, I think it’s safe to conclude that when drawing a diagonal line from the top left hand corner to the bottom left hand corner of the C64 hires screen, after POKEing each character cell of 8 bytes with the sequence of numbers 128, 64, 32, 16, 8, 4, 2, and 1, THEN you continue with your line by adding 328 to the memory location of the beginning of the previous character cell you plotted in. I also get the impression that when you want to draw a diagonal line from anywhere on the screen down and to the right at an angle of 45 degrees, then when you reach the next character square you also add 328 bytes to the start of the previous character square plotted to continue with your line. This will be explored in a future post.

The following program is adapted from the program listed above, but various changes, line renumbering, and additions have been made. If you’re careful, you can edit the program you’ve already typed. It will display the bit mapped screen, clear it, draw two lines, one much longer than the other, then cycle through all the colours for the screen and border, while the lines stay black. I can’t change the colours of the lines yet, because I’m not sure where to POKE, or how the foreground colour was set to black for the whole screen. Unfortunately, there has been some automatic reformatting in lines 90 and 100 of this program. Please ignore the occurrences of several spaces at a time. Only ONE space at a time should ever occur in the middle of these program lines!

5 BASE=2*4096:POKE 53272,PEEK(53272) OR 8:REM PUT BITMAP AT 8192



30 FOR C=0 TO 15

40 FOR I=1024 TO 2023:POKE I,C:NEXT C

50 POKE 53280,C

60 POKE 8192,128:POKE 8193,64:POKE 8194,32:POKE 8195,16:POKE 8196,8:POKE 8197,4

70 POKE 8198,2:POKE 8199,1:POKE 8200,128:POKE 8201,64:POKE 8202,32:POKE 8203,16

75 POKE 8204,8:POKE 8205,4:POKE 8206,2:POKE 8207,1

80 POKE 8520,128:POKE 8521,64:POKE 8522,32:POKE 8523.16:POKE 8524,8:POKE 8525,4

85 POKE 8526,2:POKE 8527,1

90 POKE 8848,128:POKE 8849,64:POKE 8850,32:POKE8851,16:POKE9952,8:POKE 8853,4

95 POKE 8854,2:POKE 8855,1:POKE 9176,128:POKE 9177,64:POKE 9178,32:POKE 9179,16

96 POKE 9180,8:POKE 9181,4:POKE 9182,2:POKE 9183,1:POKE 9504,128:POKE 9505,64

97 POKE 9506,32:POKE 9507,16:POKE 9508,8:POKE 9509,4:POKE 9510,2:POKE 9511,1

98 POKE 9832,128:POKE 9833,64:POKE 9834,32:POKE 9835,16:POKE 9836,8:POKE 9837,4

99 POKE 9838,2:POKE 9839,1

100 POKE 10160,128:POKE 10161,64:POKE 10162,32:POKE 10163,16:POKE 10164,8

110 POKE 10165,4:POKE 10166,2:POKE 10167,1

1000 NEXT C

1010 GOTO 30

1020 GOTO 50

Of course the program can be shortened by using FOR…NEXT loops, as well as READ and DATA statements, but I thought I should show you it the way I developed it, with all the trial and error. Perhaps your homework could be to rewrite the program using the variable BASE, one or more FOR…NEXT loops, as well as READ and DATA statements. It should be quite simple. In this case, I really mean it. No David Lawrence style mental torture here!

Of course, I think it’s a MIRACLE that I’ve managed to work out how to draw a line across the C64 hires screen and I couldn’t care less if TMR or any of his mates say it’s the WRONG way to do it. At the end of the day, IT WORKS! That’s all that matters. The general impression I get is that only a small percentage of people who have ever owned a Commodore 64 could write a program to do this.

I think that’s enough for Part 2 in this series! Next, how to move your line into more character cells, constantly getting closer to that elusive bottom right hand corner, 8000 bytes away from where we started! After this, I’ll try to draw some lines elsewhere on the screen, but I don’t know if I’ll ever manage to translate the famous BBC BASIC “Rotating Squares” program, as used on the TARDIS console monitor in classic Doctor Who to represent travel through the Time Vortex. If I attempted this, I may just end up like the character Vedek Bareil in Star Trek: Deep Space Nine!

Posted September 17, 2013 by C64hater in Uncategorized

DRAWING THE LINE (PART 1)   Leave a comment


An early version of my program to draw a line across the C64 screen, developed using WinVICE V2.2.

I’ve decided once and for all to make another attempt, after 29 years, to investigate how the hell it would be possible to carry out the simple feat of drawing a line across the high resolution or low resolution graphics screen on a Commodore 64, using its built in Commodore BASIC V2! Of course, I was originally planning a court case against the computer dealer, the computer magazine, and/or Commodore themselves, challenging them to show in court how to draw a line across the screen. I wanted my money back, as well as compensation for distress caused. I also wanted to show the Court how it was done on other computers. I’m coming back to this problem after years of studying and using various programming techniques on several different computers, such as the BBC Micro, Amstrad CPC, MSX, Amiga, Windows PC, Linux, and Atari 8 bit computers. Get set for a big shock, because I’ve actually made some progress! Be careful while reading this article, because it contains numerous Commodore BASIC V2 PEEKs and POKEs. I think these can cause brain damage. You have been warned!

I hope everyone reading this now knows that the BASIC built in to the Commodore 64 wasn’t even written for the Commodore 64, but was ported from the original Commodore PET released in 1977, which was 5 years before the Commodore 64 came out! To recap, Commodore BASIC V2 was roughly the same as a very early version of Microsoft BASIC for the 6502 processor. Apple used the same source code for their BASIC, but had the decency to add commands for colour, graphics, and sound. For more details about the common core code of these BASICs see Jack Tramiel, founder of Commodore, did a dirty deal with Microsoft back in 1977 that for a one off fee of US$25,000 Commodore could use their early version of 6502 BASIC on as many Commodore computers as they liked. This was the very beginning of mass market computers, so Bill Gates of Microsoft decided to accept the deal, instead of an alternative deal of US$3 per each computer sold by Commodore which used this BASIC. That meant that unless or until Commodore sold more than 8,333 computers, Microsoft wouldn’t lose out. No one could predict how popular computers would become. Little did Bill Gates realise that Jack Tramiel was so miserly, he would continue to use this version of BASIC on 3 ranges of computers, the Commodore PET/2000/4000/8000, Commodore VIC-20, and Commodore 64 for 7 years until leaving Commodore, then it wouldn’t be until 17 years later that the Commodore 64 ceased production in 1994! Commodore somehow adapted the original Microsoft 6502 BASIC for use in their computers, starting with what they called “Commodore BASIC V1”, then making some very minor changes for “Commodore BASIC V2”. In the meantime, Commodore produced and sold cartridges offering some extra commands that should have been built in to their computers. These were called the VIC-20 Super Expander, the Super Expander 64, and Simons’ BASIC,. There were a lot of third party extended BASICs as well. Neither the cartridges nor any extended BASIC on tape could produce programs that would run on any Commodore 64 without the cartridge or a copy of the extended BASIC. Magazines tended not to list articles on programming in any extended BASIC, because there were so many different extended BASICs available. INPUT magazine had various listings in Simon’s BASIC, though.

Jack Tramiel only cared about cutting costs, while Clive Sinclair DID cut costs, but gave users of his computers reasonable versions of BASIC. Commodore started by making the PET computer, which was basically a cheap, cut down copy of an Apple ][ computer. This was followed up by the VIC-20, which was supposed to be better than just a video games console, because it had a keyboard and the same old Commodore BASIC V2 built in. It was also a way to make use of a crappy old video chip called the VIC-I, which Commodore had developed back in 1977, but failed to find a market for. After this, Commodore decided to make a cheap copy of the Atari 800 computer, which they called the Commodore 64. Meanwhile, Clive Sinclair and Sinclair Research made something like a cheap copy of a Tandy TRS80, but with its own BASIC instead of a Microsoft BASIC, and called it the ZX80. It had a black and white mono display, like the TRS80 and could do rough, blocky graphics, also like the TRS80. It did this with the PLOT command, while the TRS80 used the SET command.

Now let’s get back on track with the very daunting task of drawing a line across the screen in Commodore BASIC V2. To attempt this, I’ll be consulting only sources which were published in or before 1984, when I got a Commodore 64. Before the beginning of 1985, I’d given up on it and was drooling over the prospect of getting an Amstrad CPC and/or an MSX. At the moment I’m thinking of “Your 64” magazine, as well as the books “The Working Commodore 64” by David Lawrence, and “Graphic Art on the Commodore 64” by Boris Allen. I read these books and magazines back in 1984. I can make a list of those all important memory locations to PEEK and POKE from there.

Don’t forget, here’s how to do this in Atari BASIC, a non Microsoft style BASIC, which came out in 1979!

20 COLOR 1
30 PLOT 0,0
40 DRAWTO 319,190
50 GOTO 50

The Commodore 64 has a lores graphics mode of 160×200 dots or pixels and a hires graphics mode of 320×200 pixels. I will attempt to use either of these modes to draw a single line across the screen. The lores screen is multicolour mode, meaning that it can display up to 4 colours in each 8×8 pixel character square. The hires mode can only display 2 colours in each 8×8 character square. These display modes each take up 8K. The graphics origin is the top left hand corner of the screen, the same as most other computers of the time.

Some relevant memory locations are as follows –

1024-2023 – these locations seem to be connected with mapping the screen into character cells, even for the lores and hires graphics screens

53265 – POKE this location with 32 to enter bit mapped mode. Perhaps you could use the variable SM to stand for screen mode, because of course, only the first two letters of any variable in Commodore BASIC V2 are counted.

53272 – register used to control where the VIC-II video chip gets character data OR what address to use for the start of RAM for the hires screen. POKE with 8 to set the address to 8192. Perhaps the variable SA could stand for this. On some computers the address is fixed, but there’s a choice of locations on the Commodore 64 and some other computers. This enables quick switching between screens that have already been drawn. I think the Atari 8 bit also has this, while the Amstrad CPC screen RAM is fixed at &C000 or 49152.

Don’t forget, here’s how to draw a line across the screen in BBC BASIC, which should run not only on the BBC Micro, but the Acorn Electron, Acorn Archimedes, BBC BASIC for Windows, and possibly on Brandy BASIC for Linux including the Raspberry Pi computer as well. Different versions of BBC BASIC may give slightly different results. I tested this on BBC BASIC for Windows running under WINE in Linux. Unfortunately, Brandy BASIC locked up or crashed on me!

10 MODE 1
20 PLOT 1,1279,0
30 DRAW 0,511
40 GOTO 40

Your 64 magazine Issue No. 1 had an article about plotting points and drawing lines on pages 61-62. You can find a copy of this magazine on . Unfortunately, the listing about plotting points didn’t actually work, so that’s not much good, is it? Obviously, I have no way to debug it, because to do that I would actually have to understand how the crappy Commodore BASIC V2 works on the C64 in the first place! For some strange reason, the listing about drawing lines between random points on the graphics screen DOES work, though. The most important part of each of those two programs seems to be the equation B=8 1 9 2 +I N T ( Y/ 8 ) * 3 2 0 + I N T ( X/ 8 ), where B represents the pixel to be turned on, 8192 is the beginning of the graphics screen RAM., and X and Y represent the horizontal and vertical screen coordinates, the same as on NORMAL computers!

I bought the book “The Working Commodore 64” by David Lawrence, in 1984, because I thought it would enable me to make use of sprites and graphics screens, due to the summary on the back of the book, which mentioned graphics. Unfortunately, it was very disappointing because the graphics drawing program listed lacked a SAVE function! Author David Lawrence claimed it would be “a simple matter” to add this to the program, so obviously this actually meant it was virtually impossible and the program was useless to me, because I’d lose any drawing at the end of a session. Thanks for nothing David! The Commodore BASIC V2 SAVE command doesn’t save blocks of RAM, only BASIC programs. MSX BASIC and GW-BASIC have BSAVE to do this. His sprite program was just an editor which enabled users to edit, save, and load sprites, but there was nothing else about what to do with the sprites in a program! It contained a save routine involving the commands OPEN and PRINT#, but the sprites were stored in the cassette buffer and I have no idea if or how this technique could be adapted to save a graphics screen. In short, the whole book was crap. I don’t think any follow up answering these questions was ever published. David Lawrence also co wrote the book “Commodore 64 Machine Code Master”, but there was no point learning Machine Code just because Commodore BASIC V2 was crap. It was far less stressful just to buy a different computer instead. A quick look at the contents page of this book reveals that it’s mainly concerned with a type in Assembler/Disassembler/File Editor which allows you to extend the inadequate Commodore 64 BASIC V2 by adding 14 new commands, but unfortunately it seems NONE of these commands were for colour, graphics, or sound, which is what Commodore 64 programmers were crying out for. It did actually include the commands BSAVE and BLOAD, which I suppose it may have been possible to use in conjunction, with the annoying, incomplete graphics program mentioned above.

The way to plot points on the graphics screens using Commodore BASIC V2 seems to be by doing quite complicated mathematical equations, similar to the geometry problems I used to get kept behind after class for. Some important points from this book are as follows, but rephrased due to Copyright, but it’s fun just to expose the thinking behind this system.

You need to know how the Commodore 64 hires bitmapped screen is organised, because Jack Tramiel was too mean to pay US$3-US$10 per Commodore 64 sold for a later version of BASIC with built in graphics commands. If you find this too stressful, and/or aren’t good at maths, then just go out and buy a Sinclair Spectrum, a BBC Micro, an Acorn Electron, a Dragon, a Tandy Color Computer, an Oric, or an Atari instead. The C64 hires screen has 320×200 pixels, a total of 64,000 pixels. To store each of these separately you need 8,000 bytes, meaning 64,000 bits. Each character position needs 8 bytes. Starting from the top left hand corner of the screen, the first 8 bytes (0-7) are used for what on the text screen would be the first character position, the second eight bytes are the second character based 8×8 grid, and so on. With 40 characters positions for each line, each line takes up 320 bytes. The line of 8×8 grids can hold 8 lines each a single pixel wide, but drawing them all would look like a solid bar.

This seems to me to mean that if you want to draw a line from the top left hand corner of the screen to the bottom right hand corner of the screen, then after drawing the first 8 pixels, what follows in the screen RAM is the top left hand corner of the second 8×8 pixel block on the top row of the screen. If you carry on like this, then it will look like you’ve printed a row of backslash characters across the top row, then you’ll just continue on each row following this until the whole screen is full of these backslashes. The first pixel should be located at location 8192, followed by 8201 for the next pixel down and one to the right, followed by 8210, 8219, 8228, 8236, 8245, and 8254. At this point, you have to calculate the location in RAM for the 8×8 character based cell in the second position of the second row. This should be 41 bytes higher up in RAM. The screen has been set up to start at memory location 8192, so that should give us location 8233, or should it? Apart from this, do we POKE each location with a number from 0-15 representing a colour, or with a bit pattern telling it which dots to turn on, which are 1 pixel down and to the right of the previous pixel we’ve set?

I recently re read parts of the “Commodore 64 Programmer’s Reference Guide”, which was supposed to be like the Bible of Commodore 64 programming. I think the pages looked like it was designed in the 1960′s and that was the way Commodore wanted it to look, in line with their antique BASIC, although that was from 1977. Actually, it doesn’t tell you that much. They had a section on graphics which used SIN and COS functions. Obviously, I hated these because I don’t understand geometry and I used to keep getting kept in half an hour after maths classes because of this. It also meant that these examples of plotting points were useless to me! I think TMR of probably loves geometry!

I’m afraid I’ll have to leave it there for now. I’ve nearly finished what I thought would be Part 1 in this series, demonstrating how to plot a series of points, or in other words a line in Commodore 64 BASIC V2, but the article seemed too long and involved, so I’ve decided to split it into two parts. The second part will be posted in the next couple of days, so look forward to that. Meanwhile, just digest the information in this post.

Posted September 16, 2013 by C64hater in Uncategorized

WAS THE C64 EVER FIXED?   3 comments


This was one of the C64 books I bought, about how to program text adventures, the only contemporary game that could be fairly easily programmed using the C64 built in BASIC. Of course, the graphic on the book cover is just an example of what the programmer or player may imagine, because there would be no graphics in your finished game and the Commodore 64 can’t display graphics of this resolution

In 1982 Commodore released the Commodore 64 onto an unsuspecting World. They showed off its colour, graphics, and sound, as well as its “64K” RAM, but they didn’t bother pointing out to potential buyers that they would probably or almost definitely be unable to use these facilities in their own programs.

I really don’t care about various software released by third parties or even by Commodore themselves which went part of the way to alleviate the situation. This software included “extended BASIC” packages, Commodore BASIC compilers, disk only languages such as Commodore LOGO or Logo, Sprite LOGO or Logo, Pascal with added graphics commands, graphics editors or paint programs, music composition software, or games making software.

The only real way the Commodore 64 could have been fixed is with a replacement ROM fitted by Commodore to the motherboard and this should have happened at the latest after it was shown at the CES, but before it went on sale.

Unfortunately, throughout the whole lifetime of the Commodore 64, Commodore never ever produced a replacement BASIC ROM suitable for fitting to the motherboard, so they never fixed it. Third parties may have fixed it up to a point, but I only care that Commodore brought out the Commodore 64 which wasn’t equipped with a decent BASIC language and as far as they knew, no one else would ever fix this problem for them. As for the Commodore 64 OS or “Kernal” ROM, I think this was updated, causing compatibility problems with some software, such as the CP/M cartridge and BASIC type in listings. I’m pretty sure I found this out the hard way, when I typed in a very very long listing from a book about producing graphics, then it failed to run, even after I debugged it very carefully.

In 1984, when I was unlucky enough to buy a Commodore 64, that computer had been on the market for 1-2 years, so any initial problems with a crap ROM containing a 5 year old BASIC should already have been sorted out. It wasn’t up to third parties to sort out these problems, it was up to Commodore themselves. All of this drove me to desperation and the verge of a nervous breakdown!

I only put the Commodore 64 onto my short list of computers because it had a 3 channel synthesizer chip, instead of just a tone generator. Little did I know, that not only was it virtually impossible to program this in BASIC, but that the sound was distorted through any TV. I longed for a custom 3 ended lead, or a dedicated internal speaker, like on the BBC Micro, which I really enjoyed listening to in various shops. I was also surprised at how clear the Atari 800XL sounded through a TV! Of course, the Commodore 64 sound output was crystal clear on the very expensive Commodore monitors.

The Super Expander 64 packaging

At the time I’m writing this, I’ve just found over 500 results for Commodore 64 computer on eBay, but only one result for the Super Expander 64 cartridge and one result for its accompanying manual. This cartridge gave the Commodore 64 the missing commands it needed, upgrading it to somewhere between Commodore BASIC 3.5 and Commodore BASIC 7. Of course, programs written using these cartridge based commands wouldn’t run on any other Commodore 64 without that cartridge plugged in.

The only type of game that Commodore 64 owners could program on the Commodore 64, using the built in BASIC, which looked similar to what could be done on other computers was an adventure game. Unfortunately, this would obviously have to be text only, because there was no easy way of incorporating graphics showing the locations, which could be done on non Commodore computers using BASIC. A popular software package for creating text adventure games on various computers was “The Quill”, which started on the Sinclair Spectrum and produced finished adventures in Machine Code. Users could add graphics with an extension called “The Illustrator”. I think these two programs were combined into one on the Commodore 64. Another package was “The Graphic Adventure Creator”, which started on the Amstrad CPC. These two packages made life easier for Spectrum and Amstrad CPC users, but were essential for Commodore 64 users.

I think that an easy fix, better late than never, that could have been applied to the Commodore 64 was quite simple. When the Commodore 128 was released in 1985 it should have been at the same or a very similar price to the Commodore 64, due to falling RAM prices, as well as the massive profits being made by Commodore. At the same time, the Commodore 64 should have been discontinued, then that would’ve been the end of this mess!

So, to sum up, I don’t think the Commodore 64 was ever fixed!

BTW, I’m still eagerly awaiting a program from TMR or any Commodore 64 fanatics written in Commodore BASIC V2 which draws a line across either the hires OR the lores graphics screen. No Machine Code or SYS commands allowed, just BASIC! I think that the lack of such a program after 13 months of this blog proves that the Commodore 64 is CRAP!

Posted September 6, 2013 by C64hater in Uncategorized