DEBUNKING THE DEBUNK OF “HOW TO PROGRAM IN VARIOUS DIALECTS OF BASIC”   Leave a comment

DEBUNKING THE DEBUNK OF “HOW TO PROGRAM IN VARIOUS DIALECTS OF BASIC”

commodore-128-basic
A book explaining how Commodore had finally fixed their crappy BASIC 3 years later, but unfortunately they failed to discontinue the Commodore 64 at the same time

Here are TMR’s quotes and what I think of them “Debunking How to program in various dialects of BASIC. Your correspondent had nothing better to do at the time (well strictly speaking he did, but procrastination comes worryingly naturally) so decided to go back and cover points from previous posts more fully. Right now he’s in the middle of finishing off a game for the Atari 8-bit and some writing work so really shouldn’t be doing this but has to make a phone call anyway so will typeset at the same time”.

I know that TMR owned an Atari 8 bit some years ago, which he started programming in BASIC. I think he found it was such a user friendly computer that it eased him into learning 6502 Assembly Language. Later, he transferred this knowledge onto the Commodore 64. I think there were a lot of other people who did this. TRAITORS!

I said “A recent post called “Can everyone really program?”, which I think is supposed to mean could everyone really learn to program”

TMR replied “It was more about how not everyone is actually capable of programming; some people simply don’t have the correct mindset so, even if they learn some BASIC or a similar high level language, they still won’t be able to apply that knowledge in any practical way. The language in the post title is a little mangled because it was posted at stupid o’clock after several hours of “proper” writing, but your correspondent still finds the idea of the author trying to correct someone else’s English amusing. The topic of this post is probably similarly skewed for the reasons discussed above”.

I think that all that’s needed is a bit of organisation applied to programming. All but the most simple and very short programs should start with a flowchart before writing any code. I don’t keep office hours, so this is why my post was made “at stupid o’ clock”.

I pointed out “Each of these programs selects the colour purple to draw on a graphics screen, then draws a 50 pixel long line from the top left hand corner of the screen down and to the right. Unfortunately, no equivalent program has been listed for the Commodore 64! I demand that TMR writes the equivalent program in Commodore 64 BASIC V2 and posts it ASAP!!”

Of course, after this TMR totally failed or refused to post a program in Commodore BASIC V2 which opens a graphics screen and draws a 50 pixel line from the top left hand corner down and to the right. This is because (without a short Machine Code routine and a SYS call, which are banned in this challenge to him and other C64 apologists), such a program would be so mind numbingly complicated, due to all the PEEKs and POKEs and various REMs added to explain each line of the program would very probably have had most people who read it thinking “WTF?!” or some not so modern, more classic, possibly still current, expression used in about 1977 when Commodore BASIC V2 dates from, such as “You what?!”, “Cor blimey”, “F*kin’ ‘ell!”, “Cor, lummy O’Reilly!” or even “Zounds!” Don’t forget that the built in BASIC on any “home computer” was of vital importance, because that was the only language users could write programs in which could run on other users’ computers of the same model, because a compiler required a very expensive disk drive and there was no suitable compiler available at the time Commodore released the C64 or even in April 1985 when I sold it.

TMR further waffled on “And in doing so the author has embarrassingly demonstrated that he failed to understand what he was reading; to reiterate for the hard of thinking, the point was that, although the three BASIC dialects have the same commands, there is no consistency between them so learning one teaches a would-be programmer nothing useful about programming”.

MSXUserMar85
MSX User magazine March 1985, which started an amazing series of articles about translating between different dialects of BASIC

Obviously, you can’t start a sentence with And! BASIC was created in 1964 by Professors Kemeny & Kurtz. At that time, computers couldn’t display colour, had no graphics, and any sound was just coincidental, although some people managed to use these sounds to play simple music. It was only some years later that commands for colour, graphics, and sound were added, but by various groups of people working for different companies. This is why those commands are different for one make of computer compared to another, as well as different models of computer from the same company. I heard that there was later an attempt by Professors Kemeny and Kurtz to create a new standard extended BASIC. I think this was called “Real BASIC” or “True BASIC”. After reading some library books, I started to learn about how to program in BBC BASIC. After this, I learnt about various dialects of BASIC used on computers I didn’t own from a series in how to convert BASIC listings from various BASIC dialects to MSX BASIC. I should explain that MSX BASIC is very similar to GW-BASIC, supplied with PCs even up to Windows 98 (where it was hidden in the Windows 95 directory), and “Microsoft Extended BASIC” on Tandy, Dragon, etc, as well as backwards compatible with AmigaBASIC up to a point, but the sprite commands are totally different. MSX BASIC V1.0 didn’t have PROCedures, long variable names, REPEAT…UNTIL, or WHILE…WEND loops, but DID have the ELSE command, easily programmable function keys, a full set of commands for sprites, and interrupts from BASIC. This BASIC conversion series appeared in “MSX User” magazine, published here in Britain. It was really fascinating stuff, although I didn’t even own an MSX computer at the time! The series was published so that MSX users finding it hard to get software could get more programs by typing in listings designed for other computers, such as (in alphabetical order) Amstrad CPC, BBC/Electron, Oric, Sinclair ZX Spectrum, Tandy/Dragon, but make the necessary changes to convert them to MSX BASIC. You can read Part 1 of this amazing course on http://www.scribd.com/doc/65289376/MSX-User-Vol-1-No-4-Mar-1985 , then type 40 into the page number box at the top of the screen. BTW, it doesn’t attempt to deal with the crappy Commodore 64 BASIC, apart from mentioning that the Commodore 64 has a 40 column text display. Unfortunately, I can’t find any other parts of this very informative course archived online at the moment. I was originally interested in MSX as an alternative, user friendly, way out of Commodore 64 hell. It had the latest BASIC from Microsoft, which they called Microsoft BASIC V4.5 or MSX BASIC V1.0. An MSX was nearly my second computer, after lots of interesting programming sessions at John Lewis and Selfridges department stores in Oxford Street, London while my Commodore 64 sat gathering dust at home. I eventually got a Yamaha CX5M Music Computer which was MSX, mainly to write and play music on, with its built in non MSX standard Yamaha DX type sound synthesis module, but this was after MSX had failed to make an impact in the UK. The concepts in this BASIC conversion course included the following. In general, computer graphics screens use a system of “cartesian coordinates”, meaning that each pixel or dot on the screen has a coordinate given in X (horizontal) and Y (vertical) coordinates. Due to different resolutions on different computers, as well as different resolutions in different display modes on the same computer. The BBC Micro and Acorn Electron coordinates were the same for ALL their graphics display modes, but used a wider range of numbers than necessary, possibly to allow for future upgrades. Their X coordinates were 0-1279, while their Y coordinates were 0-511, although the highest resolution was 640×256. This meant that in practice each coordinate referred to 2 or more actual pixels, but this system made it easy to convert graphics from one graphics display mode to any other, unlike with Amstrad CPC or Atari 8 bit computers. Another point was that some computers had their graphics origin point (i.e. coordinates 0,0) at the TOP left of the screen, while others had it at the BOTTOM left of the screen. This meant that Y coordinates such as 4 on one computer with a vertical resolution of 192 pixels would be 187 on another computer which had the same vertical resolution. On all “home computer” BASIC dialects that I’ve read about, the only commands for drawing lines are, surprisingly enough, DRAW, LINE, or DRAWTO. The exact syntax for the coordinates following these commands varies, because they may or may not use brackets or dashes and may have one, or two sets of X and Y coordinates, but that’s certainly light years ahead of Commodore BASIC V2! As the version of BBC BASIC implemented on the BBC Micro series, as well as on the Acorn Electron used X coordinates from 0-1279, while MSX BASIC V1.0 for the original MSX standard (before MSX2) used X coordinates from 0-255, this meant that to convert BBC screen X coordinates to MSX screen X coordinates just required the BBC screen X coordinate to be devided by 5. In a similar way, to convert a BBC Y coordinate to an MSX Y coordinate required the BBC Y coordinate to be devided by 2.66 and that’s all! Obviously, a lot easier to deal with than the mind blowing calculations required to plot BBC BASIC graphics in Commodore BASIC V2. After reading this course, MSX users would be equipped to get hold of a set of the entire series of the excellent magazine INPUT, then convert whatever programs they wanted into MSX BASIC. I usually found that any errors producing bugs in printed listings in any non Commodore specialist computer magazine could be corrected, so long as I had enough understanding of how the relevant BASIC dialect worked. Obviously, this wasn’t possible with Commodore BASIC V2!

Some commands and their equivalents on various computers are as follows –

Select a predefined colour

INK n (Sinclair Spectrum) GCOL mode number,colour number (BBC/Electron) PEN n (Amstrad CPC) COLOR n (MSX)
(Sometimes the colour is given as part of a command such as DRAW or LINE)

Change display mode
Not necessary on Sinclair Spectrum MODE n (n=0-7, BBC Micro or Acorn Electron) MODE n (n=0-2, Amstrad CPC) SCREEN n (n=0-3, MSX BASIC)

Plot a point

PLOT X,Y (Sinclair Spectrum) PLOT mode number,X,Y (BBC BASIC) PLOT X,Y (Amstrad CPC) PSET X,Y (MSX BASIC)

Draw a line

DRAW X,Y (Sinclair Spectrum, coordinates relative to last point)
DRAW X,Y? (BBC BASIC) DRAW X,Y (Amstrad CPC)
LINE (X1,Y1)-(X2,Y2) (MSX BASIC)

I said “As I originally posted last August, here’s a short program which just opens a C64 graphics screen, but there seems to be a bug in line 1060.

1060 FOR I=1024 TO 1023”
TMR replied “Your correspondent can see what’s needed to fix that line (somebody has made a relatively small typo, one character is incorrect) but, since this isn’t an issue with the C64’s BASIC because all BASICs will do the same thing with a mistake like that, it would be better to leave the autho to work out what is wrong for himself because he’ll never learn otherwise!”

I have no real desire to cause myself more stress by reading up on the Commodore 64 BASIC way of addressing its graphics screen memory. At a rough guess, I’d say that if only one character is wrong, then the correct version would be either 1060 FOR I=0024 TO 1023 OR 1060 FOR I=1024 to 2023.

I pointed out “Finally, I must mention that I keyed in TMR’s Atari listing above and found out that it just brought up a blank purple screen!”

TMR made the excuse “That’s partly because the listings were there to demonstrate the diversity in command implementation, not to actually be typed in and executed! Your correspondent did indeed forgot to transcribe the COLOR command in the Atari 8-bit listing when moving it from emulator to blog post however, so the listing has been updated with a note added to reflect the author’s part in the process”.

I further explained “There’s some kind of relationship between any colours displayed on screen at the same time which can affect how the other colours will look. I think it’s a bit like the Amiga’s HAM mode, and/or colours being generated by setting hue, saturation, and value, instead of RGB values”.

TMR attempted to deny the strong links, caused by their hardware designer Jay Miner, between the Atari 8 bit computers and the Amiga by saying “Goodness alone knows where the bit about the Amiga’s HAM mode came from because it’s not like that at all! The reason for the purple background colour is clearly explained in the relevant footnote”.

I pointed this out because, while changing the colours and using various GRAPHICS modes, I was shown again that the results of keying in various values in SETCOLOR were unpredictable as far as I could tell. Unfortunately, I’ve now discovered that I can’t find my copy of “Inside Atari BASIC” by Bill Carris, so I can’t give you the detailed explanation at the moment. He said at the beginning of this section of the book that programmers should remember one thing, that while Atari colour was fairly easy to understand, it wasn’t extermely easy to understand. Basically, it’s not possible to use any of the 256 colours in combination with absolutely any of the other 255 colours.

This was because it had a 6502 derivative CPU (the 8502) running at only 2Mhz compared to the Amstrad’s Z80 at 4Mhz, only a 16 colour palette compared to the Amstrad’s 27 colour palette, and it still used 51/4 inch flimsy floppy disks, compared to the Amstrad’s 3 inch disks in their hard cases.

C128D
The Commodore 128D with integral floppy 51/4 inch floppy disk drive which was the standard disk size for the Commodore 128

TMR replied “Correcting the misunderstandings and mistakes above in order; the difference between a 2MHz 6502 (which is the maximum speed, it doesn’t always run that fast) variant and a 4MHz Z80 is very close to nonexistent because the Z80 takes more cycles to execute commands, on average about twice as many. As far as colours go, over the two displays (they run simultaneously) it’s actually thirty colours in total. The C128 was designed to either use the 1571 or 1581 disk drive (both of which work with a C64 as well) with the latter taking 3.5” DS/DD disks, exactly the same as used by the Atari ST or Commodore Amiga; the Amstrad CPC’s CF2 disks were far harder to come by, had a lower capacity and cost anywhere up to four times the price”.

Various people have said that the 4Mhz Z80 as used in the excellent Sinclair Spectrum allowed for faster graphics execution. TMR said that 2Mhz was the maximum speed for a 6502, but actually it was an 8510 in the C128. Amstrad took the amazing step of incorporating a floppy disk drive in their CPC664 and CPC6128 computers. This helped to make disk drives affordable for lots of people. The whole computer systems cost little more than just the price of a disk drive before these computers appeared on the market.

I only care that the official Commodore specs said it had 16 colours. I don’t care how many more colours some people managed to squeeze out of it with PEEKs and POKEs or Assembly Language! The 51/4 inch disks were the standard for the Commodore 128, especially as the model C128D even had a disk drive of this size built in! The page on http://en.wikipedia.org/wiki/Commodore_128 gives the specs and even points out that the Commodore 64 CP/M cartridge would only work with early Commodore 64s made in 1982! This obviously shows that a change was made, making some software incompatible, but there was no change to the BASIC ROM, which may as well have been upgraded to something like Commodore BASIC 3.5 at the same time as the other change was made, because the idea of maintaining compatibility with very early Commodore 64 models had already gone out of the window! While using the WinVICE V2.2 Commodore multi model emulator in C128 mode I was surprised to find that the old C64 POKEs 53280 (border colour) AND 53281 (screen background colour) also worked in C128 BASIC. I suppose this was all part of maintaining compatibility with C64 software. I read later in the book pictured at the top of this post that lots of memory locations had changed on the C128, though. Unfortunately, not much software was ever produced for the C128, which meant it was forced to fall back on C64 software. A lot of software started being labelled as C64/C128. Basically, the C128 offered a user friendly programming environment with Commodore BASIC 7, but the underlying hardware was Commodore 64 compatible. What this meant was that if or when programmers could somehow learn on this computer how to write in 6502/6510/8510 Assembly Language, or if they could somehow write a program in a high level language and compile it into 6502 or 6510 Machine Code, then unless that program required more than 64K RAM it was similar to a Commodore 64 program, or could be fairly easily converted into a Commodore 64 program which would then run on a Commodore 128 AS WELL AS a Commodore 64.

I didn’t really care about its Z80 CPU running at 4Mhz for CP/M use only, but I don’t remember hearing that it had 16 colours in 640×200 mode.

The Z80 isn’t just for CP/M and can quite happily be used all the time. And yes, the 80 column mode (it’s actually larger than 640×200, that’s just the default size) is sixteen colours, has optional character or bitmap modes, hardware smooth and coarse scrolling and it’s own dedicated block of RAM – really, a C128 is either a C144 or C192 depending on the model.

I have never heard of the C128 Z80 being used for anything other than CP/M, which was all that Commodore intended it to be used for.

I hope at some stage in the future to post a listing where two Doctor Who TARDIS shaped sprites collide, then bounce off each other and head in opposite directions. Remember that the Commodore group leader of a computer club I went to said “Oh that would be VERY difficult!”, which was when I totally lost faith in the Commodore 64.

Your correspondent awaits this programmatic delight to see if the author really wanted to make two sprites actually bounce (as in rebound in a fairly realistic way) or just do something simple like make them reverse direction on collision.

I plan to just make them reverse direction on collision. This was what my Commodore 64 group leader at the computer club said would be “VERY difficult!”, so that was the end of it for me, when I totally lost faith in the Commodore 64, but this is the ROOTS of gaming! After I do this, then I’ll work on how to drive one of the sprites under joystick or keyboard control.

Advertisements

Posted August 23, 2013 by C64hater in Uncategorized

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: