Welcome Fellow C64 Fans

Posted on 08-Feb-2021 by Kodiak

In a somewhat disparaging, if not brutal recent retrospective assessment of Raid Over Moscow on the Commodore 64 (released in 1984 by U.S. Gold), I made reference to the technical superiority of its contemporary stablemate Dropzone from the same publisher, coded by Archer Maclean.

Dropzone was actually a near direct byte-by-byte port from the Atari 800 original version of the game, which Maclean coded first, so it wasn't even designed from the outset for the Commodore 64's relative strengths, making its technical ascendancy over almost everything that preceded it on the C64 all the more astounding.

So what was so special about it? Why the lavish praise for its technical qualities?

• It had variable speed, bi-directional horizontal smooth scrolling, complete with inertia / momentum effects, which came at a time when this wasn't exactly commonplace.
• It featured in-game AI based on "feedback loops" that responded, on the fly, to the player's inputs and on-screen actions; to this day, very few C64 games have come close to that.
• Its sound effects raised the bar on the platform, which is apparently attributable to it being the first C64 game to use wavetables.
• It was graphically superior to most games of its era... well, its landscape and title screen were, even if the aliens and main sprite in the game were markedly less so. (On the landscape issue, for quite a while many people in the scene believed it was a scrolling bitmap, but according to this online discussion, it was, in fact, 100% chars).
• Unlike many games of its era and well beyond, it exhibited no jagged unstable raster jitter between the scrolling area of the screen and the panel zone; now this may have been a happy accident caused by lack of critical change in background colour, or it may be the result of Maclean knowing how to stabilise the raster at such interfaces... I have never examined the code, so I can only guess!

But, despite all of those positives, there are reasons why this is not a What Makes This Game Great article.

Or rather, there is one elephant-in-the-room, king-sized, over-riding mega reason why this cannot be considered among the greatest of the C64 games:

PLAY-A-BILITY.

Yes, I'm sad to say it, but Dropzone - probably like its Defender inspiration - is not a very playable game.

While there are no playability issues with collecting and depositing the little "men", the rest of the gameplay is a stressful chore at best and a fingernails-scraping-on-a-blackboard irritation at worst.

I refer, of course, to the utterly horrible experience of shooting the enemies, a playability problem which can be deconstructed thus:

1. The enemies (which mostly consist of software sprites made of chars) are too small, especially with regard to their vertical height, making them extremely hard to hit; this problem is compounded by their propensity for sudden dives or climbs.
2. The player's weaponry is too thin... a broad "arc" or other vertically substantial projectile would have been much preferrable.
3. Despite the presence of a radar display to warn you what's off-screen (a feature sadly lacking in Uridium), the central location of the player's sprite plus the high speed at which the scrolling occurs, gives very little reaction time.
4. It may also be the case that the collision detection appears a little squiffy at times, seemingly erring on the side of you missing the enemy, but I have yet to see that really confirmed.

This, of course, provides important lessons / warnings for me as I continue to develop Parallaxian.

I have long been aware of the playability issue of bi-directionally scrolling shoot-em-ups with a centrally located sprite and the Dropzone-like (or Uridium-like!) unfairness and frustration that can result.

The go-to remedy is to have the main sprite drift backwards to allow for more screen real estate between it and whichever side of the screen it is flying towards, and that is something I am considering for Parallaxian.

But there are bigger issues plaguing the gameplay in these games than the centralised sprite dilemma, issues which Parallaxian should fundamentally circumvent by virtue of it NOT being based on any of those games.

So if you've been imagining Parallaxian is a Defender clone, it's time for me to say no, it's not.

It won't have attack waves or unfair formations of enemies materialising off-screen and then charging at you, and your plane won't explode if it brushes against a 1 pixel sized enemy projectile or even if it strikes another craft.

Parallaxian's gameplay is much more nuanced as it seeks to avoid stale cliches, yet without falling into the trap of being incomprehensible or "so smart, it's stupid".

No, it's an action game, taking cues from the best parts of Choplifter on the C64 (and even on much newer platforms) and from Falcon Patrol, while refining those features and adding totally new, yet fun and therapeutic additional gameplay components, such as the carpet-bombing action.

Nevertheless, Parallaxian owes something to Dropzone beyond hard-earned lessons in gameplay; the sheer technical finesse of the older game is a lesson to anyone aspiring to make a groundbreaking game.

Because, let there be no doubt.

For all its shortcomings in gameplay, Dropzone remains a seminal moment in C64 gaming history, simply because it set new standards for professionalism.

And for that, it deserves to be considered a C64 classic, even though its playability problems mean it cannot justly be called a great.

Posted on 02-Feb-2021 by Kodiak

As you will know if you're a regular visitor to this site or if you've tried to join my Newsletter subscriber list only to find the automated service not working, I have been having increasingly vexing problems with my web host.

Today I discovered a number, which I estimate to be of the order of several hundred, of failed sign-up efforts, every single one of which seems related to the web hosting problem.

As you can doubtless imagine, I am less than pleased at this failing, so, digging further, I checked the most recent communication from them concerning the neverending saga of server problems and this is what they had to say:

We have been experiencing issues with the cloud hosting platform for a while and due to this it is no longer offered. Our system administrators are working on stabilizing the server, but unfortunately we cannot confirm when this will be completed.

We would recommend considering moving your websites/emails to a more modern platform, where you will have a better overall experience than on the current hosting.

You can check our newest offers here:

[link redacted by Kodiak]

If you are interested, we can provide further details.

Obviously the last thing I feel like doing is availing of any more of their services, so I am hoping to make the move urgently; my only worry now is any loss of service during the move, especially with regard to my emails, but other than that, I'm primed to take the leap.

Finally, apologies once more for any incovenience caused by this; you should still try to use the service to sign-up, but, if it fails, you can alternatively subscribe by emailing me direct on jon (at symbol) kodiak64.com and I can manually add your email to the mailing list.

Posted on 01-Feb-2021 by Kodiak

The January 2021 Kodiak64 Newsletter is ready for my subscribers to download.

CONTENTS:

1. PARALLAXIAN WIP: FIREBALLS
2. KODIAK64FM: PODCAST
3. PARALLAXIAN TO-DO LIST
4. CODING: BVC/BVS FOR FAST SWITCHES
5. CODING: FLD 3 WAYS
6. EXCLUSIVE PREVIEW: PUZZLE BOBBLE
7. SCENE CHIC
8. WEBSITE + SOCIAL MEDIA MUSINGS

Posted on 22-Jan-2021 by Kodiak

It was with shrill protestations from some of those who lived in fear of imminent nuclear war during the 1980s that U.S. Gold released Raid Over Moscow in 1984, from the same development team, Access Software, that created Beach Head a year earlier.

It wasn't just a few hysterical harpies-gone-bonkers that threw a strop at the game's release; the Soviet Union's government also got in on the act, singling out poor old Finland for an off-the-record tongue-lashing, no doubt with brows appropriately furrowed, just because it allowed such an offensively-premised game to be imported... Obviously, compared to actually pointing real nuclear weapons at every major city in the West, an 8-bit computer game with primitive graphics and unrealistic gameplay stood as the more compelling political issue.

The game was even banned - allegedly - for a time in Germany, ostensibly for the negative psychological effects it produced in young people!

However, as I found when finally I played it, the only verifiable negative psychological effect it produced was crushing disappointment.

Now, before the howls of derision from its fans bellow out, let me first say that the game has some redeeming features and could have been so much better, all of which I get into further below.

But it has several major problems that debar it from consideration as a true Commodore 64 classic, so if you're a huge fan of the game, either look away now or brace yourself for what follows:

• The graphics are ugly and utilitarian, much like its predecessor, Beach Head and the visually unimproved successor to both games, Beach Head 2.
• The pilot in the hanger level is a giant compared to his craft but then gets teleported - and shrunk - to fit inside it in what constitutes one of the wackiest visual effects you'll ever see on the C64.



• Almost every level of the game looks like it could have been written in BASIC (and this charge is likewise levelled at its two Beach Head stablemates), so lethargic, ponderous and simplistic is the gameplay.
• The explosions are simply pathetic, barely animated at all, seemingly taken from the Zaxxon textbook of feeble blasts.
• The sound effects are hopeless too and again, could have been written in BASIC; actually, I literally encountered some type-in games back in the 1980s with better sfx than this.
• The use of the standard C64 charset for the scores is another reprehensible act of gross game development negligence... and yes, others back in 1984 were doing the same, but that's no excuse.
• Apart from the first two levels / scenes of the game, none of it is remotely what I personally could have hoped for in a game called Raid Over Moscow... destroying things with a bouncy frisbee thing, for example... what on earth were the developers thinking?

Now, that all said, the fundamental concept of a Cold War themed game was solid and some of the ideas of R.O.M. could, if better implemented, have cemented its status as a bona fide classic.

For example, I really liked the hangar idea, so much so that it inspired the pilot-out-of-plane elements of my game in development, Parallaxian.

I also very much admire the idea behind the low level flying raid on Russian territory, even if it was crudely executed.

And the Strategic Air Command overview scene was another highlight.

But where was the actual "raid over Moscow"?

Where was the flak, the surface-to-air missiles screaming up towards you, the incoming fighters, and above all, the bombing over the target that the name of the game merited?

It is of course, easy to be critical looking back at it from 2021, with the knowledge of programming and designing for the Commodore 64 we have accumulated over the intervening years.

All I could say in my own defence is look at Dropzone, also released the same year by U.S. Gold.

And yes, while its gameplay was era-typically limited, it was a technical tour de force, and may have been the first ever C64 game to deploy wavetables for its sound effects, which were on a different planet (ahem!) to those used in R.O.M... its scrolling and overall slickness were also years ahead of the vast majority of its peers on the platform, so my point is, with the right development team, R.O.M. could have been so much better. `

Nevertheless, it's still a fundamentally interesting idea and arguably a milestone in the progression of gaming on the C64, as well as an objective lesson in using controversy as a marketing ploy.

But a C64 classic?

No way!

Posted on 16-Jan-2021 by Kodiak

Welcome to the first ever "Kodiak64FM" podcast, in which I ramble in a steady sleep-inducing monotone about the twofold purpose of the revamp of Kodiak64.com in recent times, those 2 purposes being:

• To build my newsletter subscriber list (if my unreliable web host would only get its act together consistently enough for that to occur), and,
• To get some support to help me justify the time I spend on Parallaxian to my increasingly weary family.

I also talk a little bit about which countries most of my visitors come from and which type of articles are the most popular.

Anyway, it's my first ever attempt at a podcast so lower your expectations accordingly!

VOLUME TOO LOW? If the audio is a little too quiet on your browser, you can always download the podcast from the control bar above and play it back at a higher volume.

Posted on 14-Jan-2021 by Kodiak

If you're new to 6502 coding on the Commodore 64 or, at least, new to working with interrupts, you've probably seen the "textbook" way to enter and exit them.

And sure, it's not without good reason it's done that way... it reinforces the need for the programmer to be mindful of certain things that must be taken care of as part of any interrupt code, specifically, recording and recovering the registers and acknowledging the interrupts themselves.

But textbook - or "cargo cult" in the lingo of the coding snobs - is not necessarily optimal in many cases.

However, before elaborating on why that's the case, let's consider the typically taught way of entering an interrupt:

Plainly, therefore, the above does 3 things:

1. It stores the contents of the Accumulator out of harm's way for later retrieval at the end of the interrupt.
2. It stores the contents of the X-register out of harm's way for later retrieval at the end of the interrupt.
3. It stores the contents of the Y-register out of harm's way for later retrieval at the end of the interrupt.

Then, at the end of the interrupt, the standard thing to do is recover the registers in the following fashion, which is cognisant of the first-in, last-out way of using the Stack for storing values:

These actions ensure that, when the interrupt finally finishes and the CPU returns to executing the code in the program's "main loop", all the registers are restored to the exact condition they were in just before the interrupt started.

Now, this becomes a waste of code and CPU cyles when the interrupt handler code only uses 1 or 2, but not all 3 registers, so to enter and exit efficiently, we should only record and recover the actual registers the interrupt handler code uses, as per the example below:

Since the X-reg and Y-reg were not used in the main handler code, there was no need to record and restore them, thus saving 10 CPU cycles on entering the interrupt handler and 12 on exiting it (22 cycles altogether which is approximately one third of a raster line saved); the RAM saved is 4 bytes on entry and 4 on exit = 8 overall.

And if you're not doing anything exotic like interrupting the interrupt handler using the NMI, you could avoid the Stack altogether and just replace the opening PHA with STA ZPHOLDA, where ZPHOLDA is a zero page (or "Zeropage") value that will be used to temporarily hold the A-reg's value on entering the interrupt handler; then, at the end of the handler, you would replace PLA with LDA ZPHOLDA.

That process takes 2 more bytes of RAM overall than just using the PHA/PLA construct, but it takes 1 cycle less because the LDA ZPHOLDA operation only takes 3 cycles, not the 4 cycles the PLA requires.

You could also just enter with some self-modifying code such as STA ARECOVER+1 (4 cycles) and exit with ARECOVER LDA #$00 (2 cycles... immediate value modified via STA ARECOVER+1).

All of the foregoing should, of course, highlight the folly of doing something stupidly unnecessary like this:

The moral of the story being: never use extra registers unnecessarily!

Of course, where your interrupt handler must use 2 or all 3 registers, you can also apply the zero page holder variable method or the self-modifying code method, as per the technical notes in my Deep Winter Tech Demo article.

Similar posts:

Illegal Opcode SAX/AXS: A Practical Use

ORA: A Special Use in Branch Testing

Interested in coding on the C64? Check out these books on Amazon (and yes, I get a tiny pittance if you buy via any banner below):

Posted on 07-01-2021 by Kodiak

Things have been a bit quiet with the blog this week and for good reason; I've been snowed under coding a new explosion sequencer for Parallaxian.

As part of my "all killer, no filler" mantra for the game, these explosions must not look clichéd... out go the stereoptyped 7-8 frame fireballs so popular in shoot-em-ups and in comes an ambitious, bombastic visual effect inspired by the toggleplex concept.

That being said, I am hoping to get my next two blog posts finished very soon; one covers the issue of efficiently entering and exiting interrupts, while the other is a technical critique of Raid Over Moscow, so look out for those coming shortly.

And if all goes to plan, my first toe-dip into podcasting should also be online very soon, so again, look out for that.

Anyway, back to coding fireballs... (or as the Rowlands brothers might have said when coding Creatures 1 & 2, "back to coding furballs").

Posted on 02-Jan-2021 by Kodiak

In a recent post, I talked about some special uses for the EOR instruction, particularly with regard to saving CPU time on addition and subtraction.

Now it's the turn of ORA, which can also be used for adding within certain conditions on 6502, as per this Codebase piece on Combining Bits / Substitute Logical Operations.

Changing track from maths, a nice little hack you can apply (and which is used occasionally in Parallaxian) is where you start with something prosaic like this:

The above assumes, in all instances of the variables being tested, that 01 = relevant condition is active and 00 = relevant condition is inactive (i.e. turned off).

Note that if any single one - or more - or all - of those conditions is / are active, the effect will not be performed; in other words, all of those conditions must = 00 for the effect to be executed.

You could, in plain English, say this:

"If any one or more of ZPPLANEBLOWMODE or ZPTAILSLIDE or ZPTURNSTATUS or ZPRESPAWN is turned on, then we do not perform the effect."

So we can convert that sentence into code thus:

By the same token, you could use AND everywhere instead of ORA and finish with a BEQ to the exit location, but the key aim is always the same: to save some needless branch-testing cycles and RAM by using ORA or AND in this fashion.

SCHEDULED AS AN EXCLUSIVE FEATURE ARTICLE IN THE JAN 2021 NEWSLETTER: FLD Three Ways - CPU + RAM efficient ways to perform FLD.

____

Similar post:

Illegal Opcode SAX/AXS: A Practical Use

Interested in coding games on the C64? Check out this book on Amazon (and yes, I get a tiny pittance if you buy via the banner below):

Posted on 30-Dec-2020 by Kodiak

Ongoing issues with my web hosting provider continue to turn the Newsletter subscription service on and off every day, but I am trying to work with the web hosting provider to resolve the problem.

Again, apologies for any incovenience caused by this; you should still try to use the service to sign-up, but, if it fails, you can alternatively subscribe by emailing me direct on jon (at symbol) kodiak64.com and I can manually add your email to the mailing list.

Posted on 28-Dec-2020 by Kodiak

As the year draws to a close and I sit here mindful of the freezing, snowy scene outside, my thoughts turn again to the tech demo videos I released back in early 2020 of Deep Winter on the Commodore 64, my planned sequel to Parallaxian.

It's true to say I rushed the coding side of it, being pressed for time (as usual), but the fundamentals are there in the form of a nice NMI (Non-Maskable Interrupt) chain that interrupts the IRSTs (Raster Interrupts).

The principle is simple: let the IRSTs do the heavy-lifting of scrolling the parallax landscape and meanwhile we interrupt the scroll code with precisely timed NMIs to nip in quickly, plex the tree sprites, and get out again quickly, without skipping a heartbeat.

Of course, the whole NMI-plexing-while-suspending-IRSTs concept has its origins in Parallaxian and has also been ported into the chase levels of my good friend John Henderson's game in development, The Wild Wood, which I have been helping out with, as per this detailed tech article.

It's a truly great way to mix sprite plexing and scrolling based on screen split effects on the venerable C64, so one day I hope to reveal it in all its gory technical detail, ideally after Parallaxian's release.

In the meantime, check out the snowstorm effect in the clip below; it's a new recording and while it suffers from some of the same video capture problems that plagued the Youtube version, the quality is better; this is an effect that needs a real C64 (or a VICE running without rival applications slowing it down) to truly execute flawlessly.

That effect is entirely built on the Toggleplex concept; in this example, a sprite "canvas" is projected over the landscape and then simple falling snow sprite definitions are updated as required.

The game itself is to be a survival-against-the-wild experience, where each day you must source enough food, water, heat, medical aid, clothing, shelter, etc., to survive until spring, while also avoiding dangerous interactions with wild animals and other survivalists in the mountains.

Gameplay is envisaged as a combination of problem-solving, exploration and strategy elements, so it should be quite different to almost anything ever seen on the C64 prior to it.

More information on the game concept in this article.

Posted on 22-Dec-2020 by Kodiak

In my own personal, ongoing quest for doing things quicker or more RAM-efficiently with code, some time ago I blundered into some nice little hacks with the EOR instruction, the "Exclusive OR".

Some of my favourites are:

1. A tiny EOR-based switch aka "alternator" for frame-skipping in raster interrupts.
2. Using EOR for faster subtraction.
3. Using EOR for faster addition.

Lets consider each of them in turn:

1. EOR-based alternator: At some point in many coding scenarios, you will probably want to perform certain tasks only on every other frame; it could be some game AI, it could be something like Toggleplexing, an audio effect, a scroll event or whatever; the key thing is that you need to do it every other frame.

For this, you could do as follows (which has probably been used by many coders since the 1980s, so it's not my invention!) inside one interrupt handler, so that it fires once every frame (i.e. screen refresh):

LDA ZPTOGGLE
EOR #$01
STA ZPTOGGLE
BNE ODDFRAME ; Branch to ODDFRAME every "odd" frame, whereas this BNE is ignored on every "even" frame

; EVENFRAME code goes here

All you have to do when setting this up at the start of the program is to ensure the variable ZPTOGGLE = either 0 or 1 and EOR will invert that value every frame, producing a 0,1,0,1,0,1,0,1,0 cycle ad infinitum.

SPECIAL NOTE: I like to use another way to perform the toggle logic that saves 1 cycle on both odd and even paths compared to the above, but it requires the use of self-modifying code and consumes more RAM for the logic... this is scheduled for inclusion in the next Newsletter for subscribers.


2. EOR for faster subtraction: Normally you would subtract using SEC and SBC, such as per the following example:

LDA #%00011111
SEC
SBC BITTABLE,Y ; where BITTABLE,Y is known to hold only values less than #%00011111

That takes 2 + 2 + 4* cycles = 8-9 cycles, the actual number depending on whether or not the page boundary is crossed by the SBC,Y operation; and if we say, by way of illustration, that the value in BITTABLE,Y = #%00001111 (15 in decimal), the result will be #%00010000, i.e, 31 - 15 = 16.

So if we can safely predict the range of the value being subtracted, we could use EOR to do the subtraction like this:

LDA BITTABLE,Y
EOR #%00011111 ; Shorthand for subtracting BITTABLE,Y from #%00011111

The same calculation (with the same result, obviously!) now takes 4* + 2 cycles = 6-7 cycles, the actual number depending on whether or not the page boundary is crossed by the LDA,Y operation, with the extra bonus of the carry flag remaining unaltered by the calculation!

Again, the idea of using EOR for this kind of subtraction is not my invention and it's probably impossible to know who did it first, but it's slick and saves 2 precious CPU cycles and 1 byte of RAM from the standard way of subtracting.

(Incidentally, this forms part of the landscape damage encoding routine in Parallaxian, in which trees set on fire by bombing are still on fire next time they scroll on to the screen).


3. EOR for faster addition: Just as you can use EOR for fast subtraction if the constraints of that subtraction are first known and understood, so you can also use it for some fast addition, with the same fundamental proviso.

For example, let's say you want to add any number less than #$F0 (in decimal, 128 or, in binary #%10000000) to #$F0; normally, you would use CLC and ADC to do the following (we should keep it all in binary to help understand what's happening with the various bits):

LDA #%00001010
CLC
ADC #%10000000

That gives a result of #%10001010 (138 in decimal) in the A-reg and takes 2 + 2 + 2 = 6 cycles, but consider that the following will give you the same result:

LDA #%00001010
EOR #%10000000

...which puts #%10001010 (138 in decimal) in the A-reg but takes only 2 + 2 = 4 cycles, with the saving still applying over different addressing modes if you replace like with like and, as with the EOR subtraction, you walk out of the calculation with the carry flag unaffected!


Of course, that's only the tip of the iceberg in terms of what can be done with EOR; for example, you can use it to save space in the VIC bank if you have a sprite that has a flickering flame such as that used by Parallaxian's "Backfire" enemy.

So instead of keeping the full definitions for the craft with and without the flame showing, you only need one and use EOR to manually draw / clear the sprite data for the flame on alternating frames.

Another nice use for EOR I came across was where you can use it to obfuscate code, as per the final example on this Dustlayer post about Bit Manipulation.

Finally, there are some helpful generic, non-C64-related tools online that will allow you to perform tests using the big 3 logical operators of AND, ORA and EOR (which sometimes is known as XOR), such as this one: bitwise-calculator.

Similar post:

Illegal Opcode SAX/AXS: A Practical Use

Interested in coding on the C64? Check out this Kindle e-book on Amazon (and yes, I get a tiny pittance if you buy via the banner below):