kodiak64-co-uk-fzfr.staging.mediaserve.pro Open in urlscan Pro
23.137.224.167  Public Scan

Form analysis
1 forms found in the DOM

POST https://www.paypal.com/donate

<form action="https://www.paypal.com/donate" method="post" target="_top">
  <input type="hidden" name="hosted_button_id" value="RPKEFXVNFAN5E">
  <input type="image" src="https://static.kodiak64.com/assets/Paypal_Donate_NEW2.gif" border="0" name="submit" title="PayPal - The safer, easier way to pay online!" alt="Donate with PayPal button" class="inputhover">
  <img alt="" border="0" src="https://www.paypal.com/en_GB/i/scr/pixel.gif" width="1" height="1">
</form>

Text Content

PARALLAXIAN TECH ARTICLES YOUTUBE



THE HOME OF PARALLAXIAN








KODIAK64 MICROBLOG


WEBSITE UPDATE APRIL 2022

Posted on 28-April-2022 by Kodiak

By now I presume most of you still checking this blog out from time to time have
probably given up on Parallaxian due to my prolonged radio silence.

However, the truth is, the game's development has been ongoing since last
autumn.

The incommunicado issue has been the result of the following factors:



 * The catastrophic loss of my main laptop in early October 2021, resulting in
   very limited ability to update my website (and the loss of many months' worth
   of Parallaxian backups).
 * A torrent of behind-the-scenes difficulties related to my efforts to return
   to my native UK after a long period of living on the continent.
 * A succession of extremely frustrating technical problems caused by my
   webhosting provider.


Thankfully, I have been able to review and update the website in the past few
weeks, removing some old articles, adding new content and replacing lost or
damaged images, and am now at the point where I can resume posting on it.

So, with that lengthy preamble out of the way, let's summarise and then review
the major changes:



 1. The newsletter has been terminated.
 2. The pathetic t-shirt experiment has been cancelled.
 3. The "Hot in the C64 scene" section has been replaced with direct links to my
    YouTube channel's videos.


NO MORE NEWSLETTER?

Yes. Because, to be frank, it was a monumental waste of time.

Did it expand my mailing list? Sure, but 10 new subscribers for a week or two of
hard graft in writing each newsletter is not exactly worth the bother.

It also was proving too much of a diversion from actually coding Parallaxian, so
it had to go.




ONLINE SHOP GONE TOO?

Everyone and their mama is trying to sell print-on-demand t-shirts these days,
so my "online shop" was somewhat doomed to failure from the start.

When you consider all the hours entailed in putting designs together, designing
the shop interface, etc., and all for just a single sale (if I am remembering
correctly!), then again it's another diversionary / fruitless dead-end.




AND C64 SCENE NEWS AXED?

Well, the idea of having scene news in the first place was to make an effort at
generating daily traffic to my home page.

However, it didn't quite work out that way, as analytics revealed traffic only
went up with each new blog post and then trailed off again to a pitiful low.

The proverbial "spike of hope" followed by the "flatline of nope"!!!

So once more, I had to wield the axe and use the screen real estate allocated to
that feature to promote my YouTube channel, which to date is the most effective
means of generating interest in the project.




CLOSING THOUGHTS

I have to say, the results from the site's relaunch in late 2020 surprised me;
sure, my expectation levels were low from the outset, but the indifference to it
from the scene was even worse than my projected worst case scenario had
predicted!

For example, almost nobody used the Amazon affiliation feature, but in fairness,
it's an overdone thing anyway and people are presumably tired of seeing it on
websites and so just ignore it.

On the positive side, the PayPal donate feature fared slightly better and is
being retained for now.

In any case, my focus now is on finishing Parallaxian, with or without support
from the scene.

As for Deep Winter, it's unlikely to proceed unless Parallaxian does well, so
its fate hangs in the balance.

In closing then, I hope you might have learned something about what not to do in
terms of promoting / trying to monetise what is, let's face it, a website for a
small niche.

And, of course, I would ask you to consider donating via Paypal using the PayPal
button at the bottom of this page (in the orange "box-out"). towards
Parallaxian's continuing development - see the orange box below for special
perks for those who do so.



permalink to this post



INDEXED INDIRECT ADDRESSING

Posted on 9-July-2021 by Kodiak

Many, if not all, 6502 coders are familiar with Indirect Indexed Addressing, but
by all accounts very few have ever had reason to use its more esoteric cousin,
the mysterious Indexed Indirect Addressing.

However, in the course of developing the "swarm" effect for Parallaxian, a rare
case use emerged, specifically with regard to setting the MSB condition of each
plexed sprite within the swarm.

The sprites in the swarm are plexed by the NMIs which operate on a minimalist
"fast-in, fast-out" basis, with y- and x-positions set by the NMI along with
pointers and colours and, of course, the tricky MSB conditions, as per the
schematic below:



As intimated above, the coding brief for this required that everything be as
lightweight and fast as possible within the NMI handlers, so I wanted to perform
the logic for the MSB conditions outside the NMIs to avoid losing CPU time with
branch testing inside the NMIs.

We also must update each plexed sprite's MSB condition once per frame,
independently of the others in the swarm, and do so by using just one subroutine
to keep RAM overhead to a minimum .

So the idea is to set the MSB condition using a zero page value with an AND or
ORA instruction that would be hard-written into each NMI handler once per frame
by the raster interrupt (IRST) handler that deals with the lateral (x-direction)
position updates for the swarm, thus requiring the IRST to be able to quickly
modify the instruction dealing with the MSB condition inside each NMI handler.

(The actual value used by the relevant logical instruction in the NMI could much
more easily be written into, and then read from, a ZP variable).

Where the MSB = 0, the relevant NMI handler would have to do this:

LDA $D010
AND #%10111111 ; (Mask out sprite #06 as that's the one used in the swarm)
STA $D010

And where the MSB = 1, the relevant NMI handler would have to do this:

LDA $D010
ORA #%01000000 ; (Mask in sprite #06)
STA $D010

But remember, we need to write the actual instruction into the NMI handler once
per frame, in what is a pretty normal case of self-modifying coding practice;
for example, in the truncated snippet from the NMI handler below, the
instruction in NMIMSBSETROW0 has to be written to that address once per frame by
the IRST that sets the MSB positions for all of the sprites in the swarm:



Simple Plexor within NMI Handler
(Redacted from Parallaxian)

NMIHANDLER2 STA ZPNMIHOLDA ; "Stack" the A-reg
; Set sprite y-pos + pointer LDA #48 STA VICSPR6YPOS NMISETPOINTROW0 LDA #103 ;
SELF-MODIFIED value STA SPRPOINTER6
; Set sprite MSB LDA $D010 NMIMSBSETROW0 ORA ZPSWARMMSBROW0 ; SELF-MODIFIED
instruction STA $D010
; Set sprite x-pos + colour LDA ZPSPR6XPOSROW0 STA VICSPR6XPOS NMISETCOLORROW0
LDA #00 ; SELF-MODIFIED value STA VICSPR6COLOR
; Set NMI "vectors" LDA #<NMIHANDLER3 STA $FFFA LDA #>NMIHANDLER3 STA $FFFB
; NMI exit tasks LDA ZPNMIHOLDA ; Recover A-reg JMP $DD0C ; = BIT $DD0D + RTI


Naturally, the IRST has to be able to exactly write to the correct address in
memory within each NMI handler for that fast MSB-setting code, and it must do so
from a single subroutine, so what we do is make the actual instructions (AND or
ORA) to be written into the NMI handler done so indirectly through vectors held
in a LO/HI byte format in dedicated zero page variables.

In other words, we use indexed indirect addressing to do it, as per the
dumbed-down snippet from within the relevant IRST handler, shown below:



Modifying the NMI handlers' code
(Redacted from Parallaxian)

SWARMSETXJ1 (tasks @ loop start) ; Y-reg = loop counter
; MSB = 0 @ this stage SWARMSETMSB0 LDA #%10111111 ; Mask for sprite 06 with MSB
= 0 STA ZPSWARMMSBROW0,Y LDA #$25 ; #$25 = AND in ZP mode
JMP SWARMNEXTROWTEST0
; MSB = 1 @ this stage SWARMSETMSB1 LDA #%01000000 ; Mask for sprite 06 with MSB
= 1 STA ZPSWARMMSBROW0,Y LDA #$05 ; #$05 = ORA in ZP mode
SWARMNEXTROWTEST0 LDX #00 ; SELF-MODIFIED value STA (ZPMSBLOINSROW0,X) ; INDEXED
INDIRECT!
SWARMNEXTROWTEST INY ; Increment swarm row counter CPY #$06 ; 6 rows to update
BEQ SWARMRESETROTEST ; Quit loop if counter = 6
TYA ASL A ; Multiply counter by 2 STA SWARMNEXTROWTEST0+1 ; Store as index
BCC SWARMSETXJ1 ; Branch to start of loop
SWARMRESETROTEST (continue with IRST)


CONCLUSION: Where you need a fast operation within a loop to write to an
absolute (i.e. 16-bit) address in RAM, where the target absolute address changes
with each iteration of the loop as a function of the loop counter, indexed
indirect addressing is ideal (so yes, it's something of an outlier case use).

In the case of Parallaxian, the (unspoken) brief stated:



 * To minimise impact on the IRST handlers' on-screen operations, the NMI
   handlers had to execute ultra fast and thus consume a minimal amount of CPU
   cycles, to which end logic tests + branching within the NMIs had to be
   avoided; instead, any logic should be performed outside the NMIs and the
   results hard-written back into the NMIs in the form of an ORA instruction or
   an AND instruction, complete with appropriate masks, to ensure the MSB value
   is always correct for each sprite plexed by the NMIs.
 * The code writing to the NMI handlers to modify the instructions as described
   would be executed from within the IRST schema once per frame for each of the
   6 NMI plex zones and it too, given that it had to run from a RAM-efficient
   loop, had to execute as quickly as possible, so extraneous or bloaty
   instruction sequences had to be avoided (which, btw, is a general principle I
   use in Parallaxian).
 * A C128 version of the game would not need the limitation of performing this
   via a loop, as RAM is much more abundant on that platform.
 * The "heavy lifting" calculations for the swarm effect were to be performed by
   the game's main loop.


So hopefully by now you can see why I ended up using indexed indirect addressing
for the swarm effect; it's the only thing that meets both the CPU cycle
consumption and RAM efficiency requirements of the coding brief!

There is a slight downside, though; I had to sacrifice 6 x 2 = 12 zero page
locations to hold the target addresses within the NMI handlers and I also had to
have a subroutine during the game's initialisation that writes the addresses
into those zero page locations in LO/HI byte form, but it still represents a RAM
saving compared to unrolling the loop that updates the MSB instruction writes to
the NMIs from the IRST and remember, the number one priority was a performance
gain in terms of CPU cycle expenditure during the NMI handlers plexing the
sprites and during the IRST that modifies the logic instructions within the said
NMI handlers.



permalink to this post



NEXT GENERATION GRAPHICS ON THE COMMODORE 64

Posted on 15-03-2021 by Kodiak

Not that long ago, someone challenged me on my YouTube channel over my use of
the term Next Generation Graphics for describing the graphical style used in my
Deep Winter tech demo.




His exact words were:

"It looks very cool, but still being 320x200 and 16 colors... Not exactly
nextgen (16-bit) like."

Obviously exceeding 320 x 200 px resolution is impossible on the C64's native
hardware, so that was a bit of a big ask for start!

He also clearly did not notice that some non-standard colours are used in it,
taking the palette beyond the base 16, but both of those issues aside, I now
feel I should at least try once more to define what "next gen graphics" on the
C64 might consist of.

However, before I proceed to attempt to provide such a description, I do accept
that the term is substantially subjective and may also be a little inadvertently
pretentious, but I have to define it somehow and do so in the least offensive,
uncontentious manner possible.

In other words, this is my personal definition of "next generation graphics" on
the C64 and has no broad consensual backing from the wider C64 scene:



 1. As a fundamental rule, next gen eschews the wanton use of blocky multicolour
    mode (MCM) graphics and instead emphasises the use of smoothing expedients,
    such as hi-res, anti-aliasing where hi-res is impossible, and other methods
    to avoid totally or to reduce, where avoidance is impossible, any unwanted
    jaggedness from MCM. MCM thus becomes a tool of last resort.
 2. Rather than using the Silkworm style of stippling (or dithering, as it's
    better known nowadays) to produce half-tones, next gen uses non-standard
    colours, either the Alternate Line Method so popularised by Mayhem in
    Monsterland or the lesser known Dynamic Colour Mixing - see my Luma Driven
    Graphics for a detailed description of these techniques.
    Silkworm: A blocky stipple-fest.
 3. Next gen requires all sprites to be visible against their backdrops, which
    means they must have predominant colours that strongly contrast with those
    in the backdrop, so as to avoid what I call "Flimbo's Syndrome", in which
    the sprites and backdrop have such similar hues as to make it hard to
    differentiate between them (Flimbo's Quest is not the only culprit in making
    this design faux pas, but stands out to me as the premier example given the
    scale and ambition of the game). In practice, the sprite visibility remedy
    would normally entail making either black or white the main sprite colour in
    instances where the backdrop is colourful (as opposed to the blackness of a
    space-based shooter, for example).
    Flimbo's Quest: Spot the main sprite.
 4. Next gen should also use parallax scrolling where possible and other
    graphical effects to enhance the gaming environment, such as warping
    effects, transitions, char-enhanced sprites, sprite-enhanced char blocks,
    etc., as part of an effects-driven gaming environment.
 5. Next gen might even use a synthesised 80 column mode font, as my game in
    development, Parallaxian, does in its panel zone, to further endow it with a
    16-bit look / aspiration.


While I am always keen to avoid or minimise the use of clichés in design and
gameplay, that is not the primary driver behind my fixation on next generation
graphics on the C64.

My main objective, rather, is to raise the bar, design-wise, in pursuit of
closing the gap on the 16-bit platforms that followed on from the C64.

And in doing so, by no means am I saying all gfx styles that preceded my own are
automatically inferior; I acknowledge and accept that, beauty being in the eye
of the beholder, some people will dislike my design style outright and prefer
the old school stipples and blockiness.

I also concede that, despite a surfeit of horrible exceptions, there are many
outstanding pieces of standalone artwork and in-game graphics availing of the
traditional methods, some such works still being made today; all I'm saying is
that for my games, I prefer the next generation graphics style described herein.


permalink to this post



LES NEWS DU C64 AVEC PARALLAXIAN

Posted on 05-03-2021 by Kodiak

Cette vidéo montre un bel aperçu de Parallaxian en français ... merci beaucoup à
Olivier Cappelaere pour avoir présenté mon jeu sur sa chaîne.

Je vous conseille vivement de vous abonner à son canal YouTube et de le suivre
également sur Twitter!




permalink to this post



IN RETROSPECT: DROPZONE

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 wonder!


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 clichés,
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.



permalink to this post



IN RETROSPECT: RAID OVER MOSCOW

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,
from the same development team, Access Software, that created Beach Head a year
earlier in 1983.

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! (Interpretation: The
German government's real motive was probably that it didn't want to provoke the
Kremlin).

However, as I found when finally I played it, the only verifiable negative
psychological effect it produced in me 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!



permalink to this post



ENTERING AND EXITING INTERRUPTS EFFICIENTLY

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:



Textbook way to enter an interrupt
(3+2+3+2+3 = 13 cycles to record registers, takes 5 bytes of RAM)

PHA ; [3] Push contents of A-register (Accumulator) on to Stack TXA ; [2] Since
there is no PHX instruction, do X -> A PHA ; [3] Push contents of X-register on
to Stack via A-reg TYA ; [2] Since there is no PHY instruction, do Y -> A PHA ;
[3] Push contents of Y-register on to Stack via A-reg ; Interrupt's proper tasks
begin here


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:



Textbook way to exit an interrupt
(4+2+4+2+4 = 16 cycles to restore registers, takes 5 bytes of RAM)

; Interrupt acknowledged before this point PLA ; [4] Pull contents of Stack into
Y-reg via A-reg TAY ; [2] Since there is no PLY instruction, do A -> Y PLA ; [4]
Pull contents of Stack into X-reg via A-reg TAX ; [2] Since there is no PLX
instruction, do A -> X PLA ; [4] Pull contents of Stack into A-reg RTI ; Return
from interrupt


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:



Simple interrupt handler using only A-register
(3 cycles to record A-register, 4 cycles to recover, 2 bytes of RAM)

PHA ; [3] Push contents of A-register on to Stack LDA #%00001110 ; Set charset
to $7800 STA $D018 LDA #06 ; Set background colour = BLUE STA $D021 LDA #<IRST6
; Set vectors for next handler STA $FFFE LDA #>IRST6 STA $FFFF LDA #$80 ; Set
trigger point for next handler STA $D012 ASL $D019 ; Acknowledge interrupt PLA ;
[4] Pull contents of Stack into A-reg RTI ; Return from interrupt


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 superfluous use of diverse registers LDX #<IRST6 LDY #>IRST6 STX $FFFE STY
$FFFF


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



permalink to this post



ORA: A SPECIAL USE IN BRANCH TESTING

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:



Bloaty way to test multiple conditions for same trigger condition
(20* cycles until EFFECT is reached, takes 16 bytes of RAM)

LDA ZPPLANEBLOWMODE ; Disable effect if plane is exploding BNE QUIT LDA
ZPTAILSLIDE ; Disable effect if plane is tail-sliding BNE QUIT LDA ZPTURNSTATUS
; Disable effect if plane is turning BNE QUIT LDA ZPRESPAWN ; Disable effect if
plane is respawning BNE QUIT ; EFFECT ... ... ... QUIT RTS



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:



Compact way to test multiple conditions for same trigger condition
(14* cycles until EFFECT is reached, takes 10 bytes of RAM)

LDA ZPPLANEBLOWMODE ; Disable effect if plane is exploding ORA ZPTAILSLIDE ;
Disable effect if plane is tail-sliding ORA ZPTURNSTATUS ; Disable effect if
plane is turning ORA ZPRESPAWN ; Disable effect if plane is respawning BNE QUIT
; EFFECT ... ... ... QUIT RTS



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



permalink to this post


View older posts



WIP CLIPS


ON YOUTUBE: PARALLAXIAN LEVEL 2

Old WIP clip.

Apr 15, 2020






ON YOUTUBE: DEEP WINTER

Tech demo.

Feb 18, 2020






ON YOUTUBE: PARALLAXIAN WIP

Stress test.

Jan 22, 2020






ON YOUTUBE: PARALLAXIAN GFX

Mapping sprites.

Oct 25, 2019






ON YOUTUBE: PARALLAXIAN WIP

Compressed scroll.

Oct 22, 2019







HELP MAKE PARALLAXIAN HAPPEN!


...AND GET SPECIAL PERKS!

Progress on Parallaxian has slowed down since summer 2021 for several reasons,
one of which has been the very low level of support from the C64 scene which has
made it difficult to continue justifying to my family the long hours of hard
work a project as complex as this requires.

Now, I understand these are difficult times and I admit I am not entitled to any
support at all, but it really does encourage me to continue developing this
sensational game when you make a regular Paypal donation.

And as a special thank you, all who do this can enjoy the following perks:

 * Your name credited in the game (unless you opt out of it if you have the same
   kind of incognito hermit tendencies I do).
 * Access to the ongoing beta-testing of the game (unless you would prefer not
   to see it before its release date).
 * The finished game on media (e.g. cartridge) for FREE one week before its
   release.













Home Terms of Use Privacy Policy About Contact Copyright Notice Reddit YouTube





© 2018-2024 kodiak64.com


×
Home PARALLAXIAN TECH ARTICLES Terms of Use Privacy Policy About Contact
Copyright Notice Reddit YouTube
Your browser either does not support JavaScript or you have disabled it.
Accordingly, much of this website's functionality will be unavailable to you
until you redress this issue.