Archive for December 2015

WHY COMMODORE PET AND VIC-20 PROGRAMMERS HAD A HEAD START PROGRAMMING THE COMMODORE 64   2 comments

WHY COMMODORE PET AND VIC-20 PROGRAMMERS HAD A HEAD START PROGRAMMING THE COMMODORE 64

(DEBUNKING “CODE NOTES – TAURUS 2”)

Video

“Sheep in Space” a C64 game by Jeff “Yak” Minter

 

The Commodore PET wasn’t allowed to be called PET in Europe because it was a Philips trademark, so it was often called what it was marked as a model number 20XX, 30XX or 40XX (X meaning any number) on the case. A typical model, as listed in the lying buyers’ guide “The A-Z of Personal Computers” was the Commodore 4016, released in 1980 with a 40 column 25 row screen, built in mono monitor, no graphics except character graphics, a cassette recorder, only beep as audio and 16K RAM, but the model 4032 came with 32K, although their RAM could be upgraded. Of course, some of this information could be misleading or lies, as in their C64 review. I saw this model or similar at about three different educational establishments, finally studying word processing on it using the software “Wordcraft” (featured being pirated on ITV’s Database series in 1984) at a college for the last three months of 1987, before they were replaced with CPT machines with custom portrait style monitors. My opponent TMR of the rival blog http://c64crapdebunk.wordpress.com has had the cheek to claim in his post on https://c64crapdebunk.wordpress.com/2015/12/18/code-notes-taurus-2/ accompanying a demo by famous C64 games programmer Jeff Minter (who programmed games featuring Mutant Camels as well as light synthesisers) that Commodore PET/20XX/30XX/40XX programmers and VIC-20 owners such as Jeff Minter and himself weren’t somehow well prepared for programming the C64 by programming the PET/20XX/30XX/40XX or VIC-20 before. Jeff Minter started using a Commodore PET/20XX/30XX/40XX as long ago as the late seventies, when hardly anyone had a computer, so this means he probably had quite an easy time of it, under no pressure to write any programs quickly to compete with anyone, because there was basically no competition. I don’t even remember hearing about the Sinclair ZX80 until years later, but I did hear about the ZX81.

BTW, I’m sorry for any text in a different colour or videos appearing only as links, but this is due to problems caused by a new WordPress editor. If only they’d stuck with the old one which worked!

 

I think that Jeff Minter is a bit of a mystery, allegedly born in April 1962, but obsessed with “Psychedelic” concepts which were fashionable when he was supposed to be only about 5 years old and the Wikipedia article on https://en.wikipedia.org/wiki/Jeff_Minter claim he was still at some kind of “school” when he was 18-19, but this isn’t likely in Britain where he might have been at a college or university not a “school”. This article also contradicts itself by saying he wrote a game for the Commodore PET in 1979, but only “took up computer programming in earnest” in December 1981-January 1982, and also says that in 1981 he had been studying at The University of East Anglia, then gave up.

Meanwhile, in 1982 me and my Mum ran away from home to get away from the slum my Dad had created with unfinished DIY jobs and hoarding, then we didn’t come back for about six months, so that was a big distraction for me. Luckily for Jeff Minter he got a Sinclair ZX80 and also had at least access to a Sinclair ZX81, Atari 8 bit computers, and a Sinclair Spectrum, all of which he developed software for. TMR even said that the featured Jeff Minter demo “Taurus 2” worked by “adding values together from a sine curve”, as if people who aren’t good at maths would understand how this was done! I’m going to explain why his claim that programming a Commodore PET/20XX/30XX/40XX didn’t help Jeff Minter program the C64 is all lies!

Video

 

https://www.youtube.com/watch?v=bNAS-fJpKaE

A Commodore PET 2001 playing Pac Man and Space Invaders

 

The Commodore PET/20XX/30XX/40XX and VIC-20 use more or less the same BASIC as the C64, although the PET BASIC kept being debugged, but had few if any commands added until V4.0, which were for disk usage. The PET series had no colour or graphics and hardly any sound either. The games that could be written for these computers could only contain mono text and character graphics with beeps, as in the video above. Atari games consoles of the time had colour graphics, but weren’t designed to be programmed by the users. Commodore BASIC supported the PET’s hardware and was a simple introduction to computer programming without having to worry about lots of 5 digit memory locations to PEEK and POKE. BASIC V2 for the VIC-20 and C64 was based on PET BASIC 4.0, but had the disk drive commands deleted, because the evil Jack Tramiel and his cohorts thought that home users wouldn’t need them! They even required disk users to specify the device number 8 because they thought most users would only have cassette drives. In the USA and Germany there were soon lots of C64 owners buying disk drives, but I never met any C64 users who had one.

C64crapPET

A Commodore 4016

 

The Commodore 64 operating system is the Commodore Kernal, built in on ROM. This is a collection of about 39 routines accessed by a jump table of addresses which, as explained on https://en.wikipedia.org/wiki/KERNAL are almost all the same on the Commodore PET/20XX/30XX/40XX range of computers and the VIC-20. None of these routines handle colour, graphics, or sound. I think that Commodore added a few routines for their later computers, meaning that all the PET jump table entries would still work, but there are a few extra routines on the C64, more on the Commodore 16 and Plus/4 and even a few more additional routines on the Commodore 128. A lot of these Kernal Routines are mentioned in the book “Machine Language for the Commodore 64 and Other Commodore Computers” by Jim Butterfield. The Kernal routines on the Commodore 64 are printed in the “Commodore 64 Programmers’ Reference Guide” on pages 272-273 with names and memory locations and some of them are as follows.

CHRIN $FFCF/65487 – input character from channel (e.g. from keyboard)

CHROUT $FFD2/65490 – output character to channel (e.g. to text screen)

GETIN $FFE4/65508 – get character from keyboard buffer

PLOT $FFF0/65520 – read/set X Y cursor position (e.g. how to compensate for the lack of a PRINT TAB(X,Y) command)

SAVE $FFD8/65496 – save RAM to device (e.g. could have been added to useless graphics programs in cassette magazines and type ins that didn’t have a SAVE option)

SCNKEY $FF9F/65439 – scan keyboard

None of these routines would have enabled Jeff Minter or TMR to program graphics and sound demos, but they would have helped them doing some Machine Code programming and encouraged them to learn more. They and other programmers could have specified the X AND Y coordinates for games characters made up of PETSCII graphics characters, then taken input from the keyboard to control them, etc.

Some time ago, I did a few posts about using the built in MONITOR program, on the C128. These were adapted from routines listed in Jim Butterfield’s book “Machine Language for the Commodore 64 and Other Commodore Computers”, which was published before the C128 was announced. In spite of this, the book explained that the Kernal routines were common to all Commodore computers (not referring to any PC clones they’d made, or the Amiga) and that you may just have to relocate where in RAM these routines would be stored and assembled from. I found that the C128 didn’t like the locations given, so I moved them to higher locations and they worked! You can read about this on https://commodore64crap.wordpress.com/2013/10/29/the-commodore-128-the-fixed-and-upgraded-commodore-64-part-2/

That’s all for now! Look forward to some more posts in the very near future, such as another in the series “DRAWING THE LINE”, as well as more development of a game in “OH, THAT WOULD BE VERY DIFFICULT!” I hope to bring these both to a spectacular climax before being evicted sometime in January 2016.

 

Posted December 22, 2015 by C64hater in Uncategorized

OH THAT WOULD BE VERY DIFFICULT – PART 4   Leave a comment

OH THAT WOULD BE VERY DIFFICULT – PART 4

The video accompanying this latest version of the program

So, here’s the continuation of this amazing series showing how it’s relatively easy to program a simple game on other 8 bit computers using their built in BASIC, apart from the crappy Commodore 64 with its Commodore BASIC V2. Of course, the point is that when writing a program bugs will come up, then you have to find and correct them. I used a large Philips CRT style TV instead of an LCD, LED, or even Plasma TV to make the video and take the pics, because CRT TV is the type of TV these classic computers were designed for!

VDiff4-2

Lines 10-140

 

In this instalment I continue to show you games programming in MSX BASIC 2.0. The version number 2.0 is nothing to do with Commodore BASIC V2, but refers to version numbers within MSX BASIC, where even V1.0 is Microsoft BASIC V4.5, which is roughly SIX YEARS ahead of the BASIC that evil miser Jack Tramiel bought with a perpetual licence from Microsoft in 1977! Bill Gates of Microsoft had no idea in his worst nightmares that Jack Tramiel was going to reuse it six years later. Bill Gates has been criticised, but IMHO he’s a saint compared to Jack Tramiel. In spite of all the Microsoft updates available, the Commodore 64 was released with roughly the same BASIC onto an unwitting public, several years later in late 1982, not long before MSX computers were released in 1983-1984 and MSX2 computers in 1985-1986. This was aided and abetted by those buyers’ guide liars writing for “The A-Z of Personal Computers”. I demonstrate how to display and move the missile sprite when the joystick fire button or space bar is pressed and how to get the Doctor’s TARDIS sprite to react to that. This is very similar to MSX BASIC 1.0, except that all occurrences of SCREEN 7,3 would have to be replaced by SCREEN 2,3 as well as all occurrences of SET BEEP and COLOR=(N,R,G,B) being deleted, so not much work to do there!

VDiff4-4

Lines 150-310

 

The whole point of this is mainly self explanatory to get people to look and learn, rather than just explain how people would have learnt to program it, while you just sit back in your chair or sofa reading it. No Github repository needed here, either. Read the program thoroughly and type it in! On MSX and MSX2 computers, owners got an advanced BASIC with nice thick manuals about MSX BASIC, MSX2 BASIC, or MSX BASIC 2.0. Unfortunately, on the Commodore 64 they got an antique BASIC, with a quite thin manual from Commodore, and had to buy “An Introduction to BASIC” (Parts 1 AND 2), as well as buying the “Commodore 64 Programmers’ Reference Guide”, but even with all these additional books, they wouldn’t be able to do much with their colour computer/synthesiser, unlike the lucky MSX and MSX2 owners.

VDiff4-6

Lines 320-500

 

This latest version of the program isn’t all that different from the previous one, but has had lots of REM statements deleted, then the program renumbered using the RENUM command, which of course doesn’t exist in Commodore BASIC V2. The sprite collision detection or sprite retracing its steps routine has also been called.

VDiff4-8

Lines 500-590

 

Unfortunately, this program has a bug, which would be a good exercise for you to try and spot, then work out how to rewrite it. This is that after the fire button has been pressed, even if the Master’s TARDIS isn’t in the right position to hit the Doctor’s TARDIS with a missile, the sound effect is played, then the Doctor’s TARDIS changes colour and goes back the way it came. Apart from this, the missile doesn’t travel very far, usually not far enough to hit the Doctor’s TARDIS.

VDiff4-10

Lines 600-670

 

The sections of program according to line numbers are as follows…

 

VDiff4-13

Lines 650-760

 

10-140 set up display and sprites

150-310 main loop which uses GOSUB 320 in line 190 instead of just BEEP to react to a joystick button or space bar being pressed

320-510 sprite collision or actually sprite moving routine, which doesn’t actually check for collisions. The missile sprite is sprite 2, which is only placed on the screen in line 340, then moved up by line 380, followed by being removed by line 500 by being positioned in the colour 0 or perhaps not, because isn’t colour 0 transparent instead of black?!

520-590 plot stars and print “Oh that would be very difficult!” on a graphics screen

600-620 sprite definitions data

630-700 select joystick or keyboard control routine

710-760 assign joystick or keyboard for input, as well as moving changing the coordinates of The Master’s TARDIS

So, there you go! Who needs “Shoot ‘Em Up Construction Kit”, Gary Kitchen’s “Gamemaker”, “Turbo BASIC”, “Simons’ BASIC” or anything like that trying to fix the mess that Jack Tramiel made?

BTW, at the moment (December 2015) there’s a Doctor Who game maker on the BBC website. This can be found on http://www.bbc.co.uk/programmes/articles/26Y2fJtHFZ2wWp397SHttGM/doctor-who-game-maker , but it doesn’t involve any programming and may not be there for long.

That’s all for now! In the next installment of this series, I plan to make the missile actually collide with its target as well as to react to the collision and keep score of any collisions. Look forward to that. Anything else such as on screen instructions would be icing on the cake, but you can use your own imagination. Perhaps The Doctor is trying to escape from The Master, but if The Master manages to hit The Doctor’s TARDIS a certain number of times, then The Master has won. In any case, this could be the basic for a number of games.

This blog has no means of funding, I’m actually quite skint or broke, and my life is in danger from eviction by a property speculator, probably taking place in January 2016. If you’d like to make a donation, please send me an email on paul.londoner@gmail.com , then I’ll tell you how to do that.

Posted December 18, 2015 by C64hater in Uncategorized