OH, THAT WOULD BE VERY DIFFICULT! – PART 2   Leave a comment

OH, THAT WOULD BE VERY DIFFICULT! – PART 2

Program listing screen 1

Program listing screen 1

First of all, I should say hello and welcome to all the recent new visitors to this blog who have caused what WordPress call a spike in my ratings which they felt the need to send me an email about! I saw that I was getting a lot of visits from Poland, although I didn’t seem to get much attention from there before.

Program listing screen 2

Program listing screen 2

Following on from my first article in this series, after a lot of distractions, as well as my MSX2 computer power switch breaking down, then me getting it repaired, my camera phone wearing out or just getting corrupted, here’s the continuation. I took the pics and the video on my new Huawei Ascend Y330 Android 4.3 Jellybean based phone, because I’m on a tight budget, but if I had more money I wouldn’t buy an iPhone.

Program listing screen 3

Program listing screen 3

This is the latest version of the program I was writing in MSX2 BASIC or MSX BASIC V2.0, which has a few, but not that many, extra commands compared to MSX BASIC V1.0. These commands are mainly to do with the superior MSX2 hardware, but there are also a few other improvements, such as SET BEEP to change the standard BEEP sound which people may get a bit bored of to a choice of a few others, and SET PROMPT to change the standard “Ok” prompt to whatever the user decides, such as “Ready”, or in my case “MSX2”. The version numbers have nothing to do with Commodore BASIC V2 on the C64 or Commodore BASIC 3.5 on the Commodore 16, Commodore Plus/4 and the very rare Commodore 116. MSX BASIC V1.0 is Microsoft BASIC V4.5.

Program listing screen 4

Program listing screen 4

I should point out to you that due to me not making a flowchart before starting work on the original program, it has now grown into slightly hard to follow “spaghetti code”, which I’ve found is difficult to add anything to. A better designed, flowcharted program should have a number of separate subroutines, each clearly labelled with a REM statement, then a main game loop would be made up mostly of GOSUB commands, as well as, thanks to the advanced MSX BASIC, interrupt commands such as ON SPRITE, ON STICK, and ON STRIG. Interrupts are a limited form of multitasking for 8 bit computers, which were never properly explained by Commodore in their official manuals, instead waffling on about totally incomprehensible crap to do with “IRQs” and “raster interrupts”. Other commands used include SCREEN to select the display mode, SET BEEP to select a more interesting BEEP sound than the default, COLOR= to change some of the default colours, PSET to draw the stars, SPRITE$ to define sprites from DATA statements given here in hexadecimal, PUT SPRITE to position and move the sprites, SPRITE ON to turn collision detection on, SPRITE OFF to turn collision detection off, INKEY$ and IF THEN…ELSE to input whether joystick or keyboard will be used, OPEN “grp:” AS #1 and PRINT#1 to print text on the graphics screen. Of course, if there were any errors, then MSX2 as well as the first version MSX computers would return to the text screen and print the error clearly on the screen, while the Amstrad CPC computers can display text or graphics in any of their three display modes, but the Commodore 64 would stop and print an error message made up of coloured blocks on the graphics screen! A reference guide for MSX2 BASIC is on http://msx.hansotten.com/uploads/msxdocs/MSX-Basic-V2.pdf

This program has hardly anything in common with Commodore BASIC V2 on the C64, except that it uses line numbers, GOSUB commands, and variable names where only the first two letters are significant. It doesn’t contain any PEEK or POKE commands, which are needed for most colour except text, graphics, sound, and reading joysticks on the crappy Commodore 64.

Program listing screen 5

Program listing screen 5

I think the best way I can present this program to you at the moment is to show you the several screenshots of program listing, as well as the video taken on my new smartphone and a short explanation of what I was thinking when I wrote it, then leave you to try and work out how this has been achieved, before I give you a detailed explanation in the next part of this series.

I decided it was time to move past the original fundamental concept of detecting two sprites colliding, then bouncing off each other by showing what would come next as a simple building block of a game. I decided to design and display two more sprites to interact with The Doctor’s TARDIS sprite. These are, firstly from the classic series of Doctor Who, The Master’s TARDIS, with a working Chameleon circuit to change its appearance, disguised as a Doric Greek column, as seen in the stories “Logopolis” (Tom Baker’s finale) and “Castrovalva” (Peter Davison’s premiere). I added some kind of missile, which is a just a single red vertical bar, but in the story “Castrovalva” The Master’s TARDIS shoots some kind of beam or stars. I haven’t done anything with the missile in this version of the program, so at the moment it doesn’t move at all, but is just positioned to the right of the word “difficult” in the title.

The program asks the user to select keyboard or joystick input and responds to either of these by moving The Master’s TARDIS, as well as beeping if the fire button or space bar is pressed, but no missile is fired.

Program listing screen 6

Program listing screen 6

This program could be converted into Commodore BASIC V7 on the Commodore 128 without too much difficulty, but I have no idea how to convert it into Commodore BASIC V2 as on the C64. Commodore BASIC V7 commands whch would be used include GRAPHIC to set the display mode, SPRITE to set sprite colours priorities and expansion, MOVSPR to move sprites, COLLISION to handle how sprites collide, BUMP to find out which sprites have collided, COLOR to select one of only 16 colours compared with 512 colours on MSX2, and JOY to detect the joystick status including fire button. SPRDEF is used to bring up the sprite editor, then the defnition is saved into a file before being reloaded into a BASIC program. It seems that Commodore BASIC V7 has no commands for interrupts, unlike MSX BASIC or Amstrad’s Locomotive BASIC. I’m not sure if there’s any way to define the sprites using another command in combination with READ and DATA statements from within in a program, instead of using the built in sprite editor.

Finally, here’s a video showing this program running…

That’s all for now. In the next part of this series I plan to explain what has happened in this program, the problems with adding any more lines or commands to it, and I hope to present a flowchart of a slightly better program which does all this and more! Apart from this, I’ve also discovered some more secrets about drawing lines on the Commodore 64, as well as how to read an error message printed on the graphics screen!

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.

Advertisements

Posted November 7, 2015 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: