Not rocket science – part 6

Debunking Oh that would be very difficult – part 6

Goodness dear reader, on the same day a newly-minted C64 programmer puts out his first intro as an official part of the C64CD team the author returns from the digital wilderness of his comments with a post about his C64 to C128 BASIC program conversion… but sadly, the news he brings isn’t good.

Several months ago, I posted here that I was trying to convert a crappy C64 BASIC V2 listing, which contained lots of PEEK and POKE commands, into the much improved C128 Commodore BASIC V7 language, which as you should know from previous posts, documentation in official Commodore manuals, as well as from books and magazines by third party publishers, includes commands for colour, graphics, and sound, which Commodore 64 owners had been deprived of. C64 BASIC contains only 71 commands, while C128 BASIC contains over 140 commands!

And yet that “crappy C64 BASIC V2 listing” actually works as intended whilst none of the author’s various attempts to convert it into the “much improved” dialect of BASIC used on the C128 which have been going on since March do not work. Having nearly twice as many commands in BASIC certainly doesn’t seem to have helped the author with his endeavour, does it dear reader? Your correspondent converted the listing to assembly language for the C64 and later C128 without issue and in a tiny fraction of the time!

We also need to remember once more that the author previously made the rather bold claim that converting the same C64 BASIC listing to platforms without hardware sprites apparently “presents no problems” especially in the light of his fruitless flailing around on a machine that actually shares the C64’s sprite hardware.

The problem is that although Commodore BASIC V7 includes interrupt commands to get sprites moving, the way of dealing with collisions is to redirect control to subroutines with the command COLLISION type, line number. The problem seems to be that although this command is also interrupt driven, it needs to redirect control to a line number

How is the command meant to work without handing control to a specific part of the author’s program when a collision occurs, dear reader…?

I eventually came to the conclusion that this would require another routine written in Assembly Language/Machine Code to set up an interrupt, called with a SYS command, which would be constantly checking the situation, ready to redirect control to another Assembly Language/Machine Code routine in the same code that deals with it!

Along with sounding like a bad workman blaming his tools, this conclusion is both interesting and somewhat contradictory dear reader;  previously the author has stated that he didn’t think that “Commodore BASIC V7 require any POKE commands at all to use their sprites” and now he’s advocating the use of assembly language routines instead!

The author reached his conclusion by assuming that, simply because he personally couldn’t make something work, it wasn’t possible to do; this is just another example of his “I know best” attitude which was inherited from his father, who the author has recently declared was “certainly a prick”.[1]

I can’t help wondering what happened with Commodore BASIC V7 to cause this problem. I think it may have been yet another case of rushing to release a computer onto the market before development was finished, even though Jack Tramiel left the company before the earlier Commodore 16 and Commodore Plus/4 were released. Unfortunately, he taught the Commodore staff all they knew about business.

This is a childlike and quite frankly ridiculous attempt to lay the blame for what the author perceives to be shortcomings in the C128’s BASIC at the door of someone who was no longer at the company. Businesses change when the people running them leave, their influence goes with them and the people who remain have their own ideas about how things should be done.

So that’s it, I’m afraid. I can’t find any solution to this problem! Why not try going over the examples I’ve listed on this site? Can anyone reading this provide a solution?

The solution is simple enough dear reader, put the C128 into C64 mode with a GO64 command and simply run the original BASIC listing since that actually works! Or failing that, why not use one of your correspondent’s assembly language ports for either mode because they will also work too! In fact the only thing that hasn’t worked was the author’s effort, saying quite a bit about his “abilities” as a programmer.

But now that failed attempt has been put aside, perhaps we can look forward to him spending half a year struggling and ultimately failing to convert the original C64 BASIC program to a platform without sprites since he feels that “presents no problems” – the Dragon 32/64 seem to be on his radar at the time of writing for example – or even targeting the Atari 8-bit since that does have hardware sprites but, just like the C64, lacks BASIC support for them?

[1] The entire response is worth reading for the comedy of the author desperately grasping the wrong end of the stick and trying to run with with it.

Posted in Debunking | Tagged , , , , , | Leave a comment

Release notes – Funky Stars (C64)

Here’s a little surprise dear reader, Funky Stars is a C64CD  entry into the CSDb Intro Creation Competition (16K category) 2019 which wasn’t programmed by your correspondent! aNdy began learning to code for the C64 around a year ago and his first release was in January of this year and, whilst C64CD has published one of his previous works called Super Galax-I-Birds,  aNdy wasn’t a member of the group until he officially joined today. And may whichever deity you might believe watches over us protect his soul!

The title for this release comes from the soundtrack, a conversion of the similarly titled tune (also known as Hybrid Song) by Quazar of Sanxion; that’s usually ten channels of Impulse Tracker tune which aNdy has somehow persuaded to fit into just three for the C64’s SID chip.

Funky Stars (C64)It’s also worth noting in passing dear reader that the author has spent most of the time aNdy spent learning to program on the C64 trying to convert an eleven line BASIC listing from one dialect from another… perhaps that conversion will actually appear at some point?

Posted in Meta Discussion, Programming | Tagged , , , , , , , , , | Leave a comment

Release notes – Death Weapon (C64)

It’s the final day for contributions to the RGCD 16K cartridge competition and your correspondent has been working on a second release for it from the C64CD stable; Death Weapon is an arena-style shoot ‘em up where the player must destroy all of the other spacecraft on each stage to progress. What’s a little unusual is the control scheme, holding fire whilst pushing the joystick will launch a bullet in the direction of travel but moving the stick on its own will still manoeuvre the craft but cause it to fire in the opposite direction. Enemies materialise at regular intervals and for a few moments are immobile and glowing, shooting them in this state will earn the player a score bonus.

The original inspiration for Death Weapon was the game Death Dealer, a simple action game which was developed in the late 1980s by Jeff J Gosden (and exists in a second form as The Perfect Weapon) but with a few inspirations borrowed from the Hallucin-O-Bomblets sub game from Batalyx by Jeff Minter – the idea of reversed firing came from there and was combined with Death Dealer’s forward-facing guns – and Andrew Braybrook’s Intensity – primarily this was where your correspondent borrowed ideas for the backgrounds and the parallax effect on the starfield – which were released in 1985 and 1988 respectively.

Death Weapon (C64)

A couple of tricks have been employed to seemingly produce more colours than are usually present on a C64 and to make the player’s bullets appear to be semi transparent; these don’t entirely work under emulation or indeed with online videos, but with an actual C64 connected to a CRT display as nature intended they do fool the eye surprisingly well. The source code for Death Weapon can be delved into at our Github account as usual – the work files for Char Pad or Sprite Pad for the graphics and GoatTracker for the music are included – and the game itself is available from the relevant tabs on this very website or via a dedicated page at our shiny new Itch.io presence.

Posted in Programming | Tagged , , , , , , , ,