?Device Not Present

edoM esreveR

2011-03-30T12:44:00.000+01:00

I've had a good think about the ASCII conversion problem over the last couple of days, and toyed with a few possibilities. The options are:

Chuck the whole idea in the bin and just go back to using the already-working 6502 code which runs during application startup, working through all the in-memory strings and converting them where they lie.
Write a DASM macro to encapsulate strings in some sort of byte markers, and then write a post-processor to scan the assembled binary looking for those markers and convert the strings.
Dive into the DASM sourcecode and add either a custom directive that would convert strings during the assembly process, or a more generic directive that would allow a branch out to a named process during assembly which could do whatever was needed.
Alter the existing pre-processor to somehow encode converted strings in such a way that control codes like ASCII 13 wouldn't break the line structure.
Change the mechanics of the way the pre-processor works so that it generates binary data instead of modified sourcecode, and have DASM pull that data in with INCBIN.

As I said last time, I'm loathe to choose Option 1 because it's always going to be more elegant to have the strings already in screen-code inside the binary, and thus not require space for conversion logic or time during startup to execute it. Option 2 was where I'd tentatively got to, but it wasn't ideal - not least because my suspicion about labels being offset from the actual string was proven true, and I didn't really like having to add 'junk' around each string to identify it. Option 3 has a certain appeal, but it could easily take me several months to figure-out what changes to make without breaking anything. And Option 5 was a brief favourite, but upon investigation turned-out to be a bit unwieldy - in order for labels to work properly, every string would have to be a separate INCBIN. Yuck.

Which leaves Option 4, finding a way to alter the encoding of converted strings so they don't upset DASM. By chance, I was idly looking at the original CHARPLOT code which handles string plotting, and noticed something interesting - I use a bit in the Control Byte to indicate whether characters should be plotted in normal or reverse mode, and simply AND that bit into Bit 7 of the character before it gets spat to the screen. Bit 7 controls whether a (non-graphical) character is displayed as ink-on-paper colours, or paper-on-ink (inverse) colours, and all the screen-codes are stored with this bit clear - CHARPLOT sets the bit for each character it plots if the Reverse Mode flag bit in the Control Byte is set.

So the solution to the encoding problem presented itself - if I encode the strings in their converted form, but additionally have the pre-processor set Bit 7 before writing them out to the source file, they'll all be in the range 128-255 and thus won't trigger any ASCII control code issues. Then I can modify CHARPLOT so that it works the other way around - instead of setting Bit 7 if the Reverse Mode flag is set, it can just clear Bit 7 unless the Reverse Mode flag is set. This is absolutely no extra work for the routine, and means that I can make everything work by with just two minor tweaks to code I already have.

I'll post an updated link to the pre-processor when I get a moment.

Preaching To The Unconverted

2011-03-28T11:08:00.000+01:00

There I was, merrily chugging along turning pseudocode into real 6502, when I hit a roadblock. The thing about roadblocks is that they stop you in your tracks - you have to back up, have a look around, figure out an alternate route, and then forge a path forwards. Sometimes you have to back up quite a way before being able to proceed again - this is both irksome and time-consuming, because all the effort you're putting into reversing and finding a way forward again is of course effort you're not putting into actual real forward progress.

It's even worse when the roadblock is a chunk of rubble you've dropped, all unwitting, into your own path. Grr.

In my last post, I gloried in my own cleverness; I'd found a way to preconvert PETSCII strings in the sourcecode so that they were assembled that way and thus already in screen-code when the program ran, meaning I didn't need a couple of chunks of code in the app itself to do that conversion at startup. I wrote a little C# utility to run prior to the assembly, turning strings into codes and letting the development rig do the work of the conversion instead of the VIC. How jolly efficient.

Yeah. But.

Something I didn't anticipate jumped up and bit me over the weekend. The converter utility has been working perfectly over the past couple of weeks, quite happily chewing through the bits of sourcecode I've fed it, and spitting-out nice results - until yesterday, when DASM started falling-over in a heap complaining about unreadable junk in a source file and politely but firmly telling me it frankly wasn't good enough and would I please sort it out before trying again. So I had a look and, as you can probably guess, the offending lines were where my converted strings were. Something had gone wrong in the conversion process, flying in the face of weeks of faultless operation.

It was immediately obvious what was wrong - the build script runs the converter when the file with strings in changes, and I'd just added a couple more messages to the list, so it'd been converted. The resultant source file looked mostly OK, apart from a line I'd changed which now included an 'M'. Incredibly, no other message prior to this point had had an 'M' in it, so this was the first time it had been encountered. The converter duly took that ASCII 'M' and turned it into screen code 13 before writing it back to the source file. And ASCII code 13 is CR, Carriage Return - which meant the line of source now had a line-break in it and DASM didn't like it.

So, I'm now having to back-up and rethink the converter, since I can't really brag about it if it won't handle the letter 'M' - it's embarrassing, and I'm not going to expend effort in trying to write messages in my games that don't have 'M's in! Obviously preconverting the sourcecode isn't working, so I think I shall have to post-process the assembled code and convert the strings inside the executable binary itself. But how to find them?

I could embed a few marker bytes in the sourcecode around the string area, and then zero-terminate each string within that region so that a post-processor could find and identify each one - but that requires that the strings be contiguous, and have nothing else around them. So you wouldn't be able to have strings defined as part of larger structures, because the converter wouldn't be able to differentiate between a string byte and any other byte.

So instead, I'm thinking of writing a DASM macro that handles the embedding of strings, with some sort of identifier byte combination to indicate where a string starts, and a zero terminator to show where it ends. This naturally adds a few bytes to the length of each string, but would mean that the post-processor could just scan the entire binary looking for the string marker and converting everything until hitting a zero. What could be tricky is labelling - wherever the code refers to a string, it's usually via a label, and that label will have to point to the actual start of the string rather than the marker bytes. Or maybe I'll just accept the fact that the label will be a couple of bytes off. This is something I won't know for sure what the solution is until I get into writing the macro itself.

Why bother with all this? After all, the 6502-based converter code works perfectly well, so why not just revert to doing the conversion on the VIC when the app starts? Well, if all else fails, I will - but having got so close to a working solution that saves on code size and execution time (on the VIC) I'm loathe to give up without a fight.

Pesky PETSCII Prevented

2011-03-04T15:23:00.000Z

I'm in the process of converting all of the pseudocode from the previous posts into real, genuine 6502 assembly, and it's going well - I may post some actual code in a few days. Simultaneously I've been thinking about the main thing that the old CHARPLOT mechanism did that the new Sprite framework doesn't do, which is support plotting of text strings to the screen - the CHARPLOT structures incorporated a feature which allowed strings to be hooked onto the object, and then processed using the same basic logic, but there's no facility to do this in the new model.

I quickly came up with a modified structure that strips-out all of the CHARPLOT object-plotting stuff (because we use the Sprite engine for that now) and optimised the string-handling feature, leaving a new STRPLOT structure that is very easy to manage, and can be passed directly to the low-level plotting logic inside the Sprite engine - so no separate string-specific drawing code is needed. This means that strings are defined as separate entities to Sprites, as you'd expect, but use Sprite-drawing features when they need to be displayed. I can now group all the games' strings together in a tight little bunch, and just refer to them when I want one drawn. Which is nice.

This then got me thinking about the technique I used to convert strings from ASCII (as they appear in the sourcecode) to PETSCII screen codes, which is what the VIC uses when drawing direct to the screen. Regular readers may recall earlier discussions on the topic, which resulted in a slick little routine which gets called when the game starts to convert all these strings in-place; the downside was that since the strings were CHARPLOT objects, the converter had to know all about how the objects were structured in order to do it's thing - essentially it had to mimic a chunk of the CHARPLOT drawing logic, but convert the characters instead of displaying them. I was never entirely happy with that.

However, I now have all the strings collected together in a simplified structure. In fact, it's so simple that I realised I could tackle the problem in a completely different way, by having the strings converted to PETSCII directly in the sourcecode, before assembling the program. The build script I'm using is very straight-forward as it just takes the name of the root source file and gives it to DASM with a few preset parameters; so there's no reason why I couldn't include a step prior to that which pre-processed a specific file, looking for ASCII strings and converting them in-place to PETSCII. By assembling the code with the strings already converted, I can then lose both the (tiny) converter routine and the (larger) structure-interpreting routine which needed to run at startup.

A matter of an hours' work in Visual Studio gave me a little app which takes a path to a 6502 source file as its' parameter, and then scans through it looking for DC.B strings. When it finds any, it applies the same code-conversion logic as the original 6502 routine did, and writes the new values back into the strings. Finally, it copies the original source file to a backup, and writes the modified copy out - this is so any INCLUDEs in other source files will point at the converted version and DASM will just build everything as normal. The caveat is that the converted file may become difficult to edit, because some PETSCII codes get interpreted as control characters when viewed in ASCII - which is why the app creates a backup, so you can always delete the converted version and copy the original back over it for editing.

It's a repeatable process - if the app finds that a backup of the source file already exists, it assumes the file has been converted and won't attempt to convert it a second time (which would scramble things rather spectacularly). Consequently I can embed the call to it in the build script and let it run on every build, but it'll only do something when it spots there's no backup for the file it's targetting.

Download link to a zipfile containing the binary over there on the right. Just drop the files into a folder somewhere, no lengthy install required - but you'll need the .NET 3.5 or 4.0 framework on your machine first, of course.

Teh Pseudocodez, Part II

2011-02-28T18:29:00.000Z

Continuing work on the pseudocode for the new Sprite Manager framework, we can now look at the logic that handles movement and cleaning-up the AST. This routine was originally three separate passes through the AST to undraw sprites, move them, and handle deactivations - but after a goodly amount of brainstorming, I managed to combine them into a single pass through the table:

; Unplot sprites by redrawing underlying character, then either zap the AST entry or calculate movement
SPZAPMVE:
  FOR X = AST[0] TO AST[AST.NSAB] ; Process each sprite in the table
    CALL CHARPLOT (X.SCB.7, X.SPB, X.UPCB, X.UPCN) ; Draw the original character at the screen position
    IF X.SCB.6 = 0   ; Sprite active?
      CALL (X.SOAL.SMAB) (X.SCB.7, X.SPB) ; Yes, call movement handler (sets X.SCB.7, X.SPB and maybe X.SCB.6)
      IF X.SCB.6 = 1    ; Sprite inactive? (moved beyond end-of-path)
        CALL SPKILL (X)   ; Yes - destroy current sprite
      END IF
    ELSE
      CALL SPKILL (X)   ; Destroy current sprite
    END IF
  NEXT

We first undraw the sprite by plotting the original character that was at the screen position before the sprite moved to it during the previous cycle, and then - for any sprites that are active this time around - call the object movement handler routine, which determines what the next position will be. If the movement sends the sprite beyond any end-of-path boundary, it'll also mark it for deactivation. Lastly, any deactivated sprites get zapped from the AST using the 'SPKILL' logic outlined in the last post.

Here's an example of the movement handler for the Dropship object:

; Move the Dropship
DSMOVE:
  X = AST[DROPSHIP]  ; Processing the AST entry for the Dropship during SPZAPMVE
  X.SPB = X.SPB + 22  ; Down 1 screen line
  IF X.SPB GT 255  ; Did we cross the mid-screen page boundary?
    X.SCB.7 = 1   ; Yes - set the Base Offset bit
  END IF
  IF X.SCB.7 = 1 AND X.SPB GT 192 ; Did we fall past the end of the playfield area?
    X.SCB.6 = 1   ; Yes - set the Deactivation bit
  END IF

Fairly simple, eh? Now here's the logic that happens at the end of the cycle to draw active sprites to the screen:

; Plot active sprites
SPDRAW:
  FOR X = AST[0] TO AST[AST.NSAB] ; Process each sprite in the table
    IF X.SCB.6 = 0   ; Sprite active?
      CALL CHARPLOT (X.SCB.7, X.SPB, X.SOAL.PCB, X.SCB.0-3) ; Yep - draw the character at the screen position
    END IF
  NEXT

It's that easy. But here's the tricky part - this is the heart of the whole thing, the bit that makes the magic happen: testing for and handling collisions between sprites, and between sprites and the playfield (the static background stuff):

; Sprite collision-detection
SPDETECT:
  FOR X = AST[0] TO AST[AST.NSAB] ; Process each sprite in the table
    X.UPCB = GETUPCB (X.SCB.7, X.SPB) ; Get screen character code at sprites' position
    X.UPCN = GETUPCN (X.SCB.7, X.SPB) ; Get screen colour nybble at sprites' position
    FOR Y = AST[X+1] TO AST[AST.NSAB] ; Scan all subsequent sprites in the table
      IF X.SCB.7 = Y.SCB.7 AND X.SPB = Y.SPB ; Does another sprite have the same target position as this one?
        FOR Z = 0 TO X.SOAL.SCB.0-3  ; Yes - scan this sprites' object definition collision-objects list
          IF X.SOAL.COP[Z][1] = #Y#.LO         ; Is the other sprite in this sprites' collision list?
            CALL (X.SOAL.COP[Z][2])  ; Yes - invoke collision-handler for these two sprite objects
            BREAK    ; Exit inner loop and check next sprite
          END IF
        NEXT
      END IF
    NEXT
    FOR Y = SOD[PLAYFIELD] TO SOD[END]  ; Process playfield SODs (at end of SOD table after sprites)
      IF X.UPCB = Y.PCB    ; Is this sprite going to hit a playfield character?
        FOR Z = 0 TO X.SOAL.SCB.0-3         ; Yes - scan this sprites' object definition collision-objects list
          IF X.SOAL.COP[Z][1] = #Y#.LO  ; Is the playfield character in this sprites' collision list?
            CALL (X.SOAL.COP[Z][2])  ; Yes - invoke collision-handler for the sprite and playfield objects
            BREAK    ; Exit inner loop and check next sprite
          END IF
        NEXT
      END IF
    NEXT
  NEXT

Yep, as you'd expect this is a fairly complicated routine to look at - but actually, it's pretty simple in operation. After grabbing the screen character and colour data for where the sprite is about to go (we execute this routine after SPZAPMVE but before SPDRAW) the logic is actually just doing two things; first, a pass over all the sprite objects in the AST after this one to see if any others are going to move to the same place, and second a pass over all the playfield sprite object definitions (which go at the end of the SOD table after the 'proper' sprites) to see if any of those register as collisions. In either case, if a collision happens we call the appropriate collision-handler routine as described in the SOD for this sprite, and carry on.

If any collisions did occur which resulted in an action being taken, the collision-handler takes care of all of that, and possibly sets this or the other sprites' deactivation bit. In order for all this to hang together, things have to happen in this order:

; Update screen
UPDTSCRN:
  CALL SPZAPMVE   ; Undraw, move and/or zap sprites
  CALL INITSPR   ; See if any sprites need instantiating
  CALL SPDETECT   ; Check for and handle collisions
  CALL SPDRAW   ; Draw sprites
  WAIT VSYNC   ; Wait for VSYNC to draw screen

And we're done - there are a few other minor support routines and tables of addresses that sit alongside this stuff, but this is the meat on the bones. Now to turn it into real 6502 code...

Spritely Progress

2011-02-27T12:11:00.001Z

So, I switched to N++ for code-editing and managing the Assemble-Launch-Test stuff, and it all seems to be hanging together quite nicely. I fired-up the sourcecode for Meanies, and everything looked good - at which point I put my biggest thinking-cap on, and started to map out what the Sprite framework should look like. This has resulted in a good few lines of structure definitions and pseudocode, which I have now refined into an optimised form. Let's see what we've got so far.

This is the structure for a Sprite Object Definition (SOD - unfortunate nomenclature, but there it is) which largely replaces the original CHARPLOT structure:

Sprite Object Definition
------------------------

Sprite Control Byte
  7 : Colour 2
  6 : Colour 1
  5 : Colour 0 
  4 : Initial Screen Position Base Offset (0=0, 1=256)
  3 : Collidable Object Count 3
  2 : Collidable Object Count 2
  1 : Collidable Object Count 1
  0 : Collidable Object Count 0

Initial Screen Position Byte
  Value added to SCB.4 for initial screen position

Plot Code Byte
  Character code to be plotted

Sprite Movement Address Word
  1-2 : Address of movement routine for this object

Collidable Object Pointer(s)
  1 : Byte reference to SOD with which this object can collide
  2 : Byte reference to SCHT entry for address of collision-handler for this collision type
  
Notes: SOD entries must not cross page-boundaries as the lo-byte of each entry is used as the pointer in the AST.SOAL.

In this model, sprites are constrained to character-level plotting, but the design allows for this to be extended to bitmap-level (i.e. pixel-based) hi-res mode later. Each SOD occupies a minimum of 5 bytes, plus 2 more for each Collidable Object reference - if this sprite needs to do something when it hits another sprite, we add a Collidable Object reference which gives us a pointer to the other sprite(s) which can be collided-with and a pointer to the address of the routine to call when we collide with it. The SCHT (Sprite Collision Handler Table) is a simple table of addresses which point to the collision-handlers:

Sprite Collision Handler Table
------------------------------

Sprite Collision Address Word
  1-2 : Address of collision-handler between first/second objects
  
Notes: SCHT entries must not cross page-boundaries as the lo-byte of each entry is used as the pointer in the SOD.COP.

So these two tables together represent the 'static' object definitions and the pointers to the routines which handle their movement and any collisions with other objects. If a SOD can't collide with anything (that is, if we don't want to know when it collides) then it has no COP entries; on the other hand, anything we want to know about collisions with, and do something about, has a two-byte COP entry which points to the other SOD entry we want to register collisions with, and to the address of the routine which handles those collisions. Each SOD can register up to 15 collidable objects, but that's only limited due to the use of 4 bits in the SCB.

So we now need a structure which manages 'active' sprites - as we instantiate a sprite based on its' SOD entry, we have to keep track of where it is and what it's doing, and that's where the Active Sprite Table makes its' appearance:

Active Sprite Table
-------------------

Next Slot Address Byte  [Next free AST slot]

Last Slot Address Byte  [Last AST slot at end of table]

Sprite Object Address Lo-Byte [Initialised from SOD Address]

Sprite Control Byte  [Initialised from SOD.SCB]
  7 : Screen Position Base Offset (0=0, 1=256)
  6 : Deactivate Sprite (0=Do not deactivate, 1=Deactivate)
  5 : Unused
  4 : Unused
  3 : Unused
  2 : Colour 2
  1 : Colour 1
  0 : Colour 0 

Screen Position Byte  [Initialised from SOD.ISPB]
  Undraw Plot Code Byte  [Initialised to screen character code]

Undraw Plot Colour Nybble [Initialised to screen character colour]
  7 : Unused
  6 : Unused
  5 : Unused
  4 : Unused
  3 : Colour 3
  2 : Colour 2
  1 : Colour 1
  0 : Colour 0 
 
Notes: Sprites are active when they have an entry in the AST - when inactive, they do not appear here.
AST entries must not cross page-boundaries since the NSAB and LSAB are indexes into the table.

The first two bytes of the AST control where the current end-of-table point is and what the maximum is - each AST object entry is 5 bytes, which means that if we align the table to the start of a page it can host up to 50 sprites simultaneously. Meanies is going to need about a dozen, so we've got the option to reduce the maximum table size and have it share page space with the SOD table - ideally these will both sit in the Zero Page, meaning all the accesses can be written using ZP addressing for speed. For projects needing more sprites, the tables might have to sit in separate pages, and I'd need to tweak the code to do 'normal' address-mode access.

Speaking of code, let's look at the pseudocode for instantiating a sprite from the SOD into the AST:

  ; Sprite activation (called as new sprites are needed)
  SPCREATE:
    IF AST.NSAB GT AST.LSAB ; Is next free slot address higher than last available slot address?
      ERROR   ; Yep - too many sprites, crash and burn
    ELSE
      X = AST[AST.NSAB]  ; No - there is a free AST slot
      Y = SOD   ; Specified sprite object definition for this new active sprite
      X.SOAL = #Y#.LO  ; Populate new AST entry, lo-byte of address of the SOD
      X.SCB = Y.SCB  ; Control Byte
      X.SPB = Y.ISPB  ; Set Screen Position to Initial Position
      X.SCB.0 = X.SCB.5  ; Move sprite colour from bits 5-7 to bits 0-2 (LSR)
      X.SCB.1 = X.SCB.6
      X.SCB.2 = X.SCB.7
      X.SCB.7 = X.SCB.4  ; Move Initial Screen Base bit 4 to Base bit 7 (ROR)
      AST.NSAB = AST.NSAB + 5 ; Increment pointer to next free AST slot
    END IF

Assuming there's a free slot at the end of the AST, we copy the SOD pointer, its' Control Byte, and Initial Screen Position Byte to the new AST entry, shuffle the bits in the SCB around to throw away the COP count and put things in positions which are faster to work with, and increment the AST pointer to the next slot. The two other AST bytes (UPCB and UPCN) don't need to be initialised - they're populated later, as we'll see. And that's it, the sprite is now active!

I'll end this post with the reciprocal code to deactivate a sprite and destroy its' AST entry. This routine gets called whenever a sprite is registered as being out of play, which arises either when a collision event occurs which kills it, or if it reaches an end-of-path situation (such as falling off the screen):

 ; Destroy a sprite AST entry and shuffle the rest down
SPKILL:
  FOR X = AST[N] TO AST[AST.NSAB]  ; Process sprites from 'N' to the end of the AST
    X.SOAL = X+1.SOAL     ; Copy all sprite data down a slot (destroys object N)
    X.SCB = X+1.SCB
    X.SPB = X+1.SPB
    X.UPCB = X+1.UPCB
    X.UPCN = X+1.UPCN
  NEXT
  AST.NSAB = AST.NSAB - 5    ; Decrement pointer to next free AST slot

That's it for now - next time, I'll present the pseudocode for drawing/undrawing sprites, and the special sauce that is the collision-detection routine. I'll also demonstrate the order in which these various routines must be called during each frame-display cycle, and maybe post some actual code. Stay tuned!

Resurrection Ship

2011-02-11T13:10:00.000Z

Well, I'm back. I can't believe my last post was in September of last year, and that over four months have passed me by - but then, that's what happens to side-projects like this when Real Life decides to slap you around a bit. It started with a bad back, which meant I couldn't sit in The Chair of Coding for a fortnight or so. Then some other family-related stuff consumed a bunch of time, followed by Christmas, New Year, and then the return of the bad back which actually took a serious turn and needed proper medical attention. I'm now on the mend (though still restricted of movement and unable to sit for more than 20 minutes at a time) thanks entirely to a wonderful physiotherapist who entertains herself by spending an hour every few days bending my lower back into new and interesting shapes.

So, with a Big Project just appearing over the horizon - I'm in the R&D stage right now, hoping to kick-off in April/May - and a little spare time available, I want to finish this game and publish it for all to enjoy, point-and-laugh at, or fall to their knees in awe of (delete as applicable). I've been thinking about the technicalities of the code over the past few days, and have decided that the best thing to do regarding the collision-detection cycle situation is to bite the bullet and write a proper framework to do this stuff in - kind of like what I did back at the beginning when pondering how to write to the screen efficiently, and which subsequently gave us CharPlot.

So, over this weekend my plan is to create a new 'Sprite' object structure, which will include the CharPlot structure but extend things by giving me a simple way to describe what was under the object when it moved, what to draw after it moves again, and what conditions trigger a collision-event. I use the term 'Sprite' loosely, since we're still working at the character level rather than at the pixel level, but since the CharPlot structure is already designed to accommodate pixel-level granularity (even though the CharPlot logic doesn't yet) this is a precursor to switching to that level in a later revision.

I will spend some hours reworking the routines that call CharPlot so that they route through a new Sprite handler to get to the right bits of data, and then I can rip out the nastiness that is the current collision-detection logic (or illogic, to be honest) and replace it with a nice Sprite-based routine which will use the extended features of the new structure.

But before I do any of that, I'm going to see if Notepad++ is really as good as it looks like it might be. Crimson Editor has served me well, but it's not quite up to the job of handling the kinds of complex macros I want to run when doing the save-assemble-test loop - and having played a little with N++ I'm thinking it might be just what I need to speed things up and remove some manual point-and-click steps when getting the code running in VICe.

So tonight is just going to be a couple of hours of environment tweaking, and then the next couple of sessions will be the aforementioned Sprite stuff. Stay tuned!

Slow Meanies

2010-09-27T14:47:00.000+01:00

I've been incredibly busy with other stuff over the last two or three weeks, and haven't been able to get near the game aside from the odd 15-20 minutes here and there - hardly long enough to fire the development environment tools up, re-orientate myself to remember what needs doing next, and write anything productive longer than a few instructions.

However, I did plug-in the code to stash the contents of the screen location that a Meanie is about to move to, so that we can then check to see what it hit after the event, rather than before. This kind-of worked, in that I now have a view of what the Meanie overwrote when it moved, but I got lost in a tangle of logic when trying to figure-out exactly when I should look at that data to decide if the Meanie hit something (and therefore to trigger the events that happen when it does).

So I sat down and wrote the main game loop as a psuedo-code script, to make it easier to determine what happens when (and therefore when things need to be updated and checked) during each game cycle. This helped immensely, because although the code is not especially complex, it can sometimes be tricky to keep the whole picture - and the event sequence - in your head. Writing the sequence out has two benefits - firstly, you can see the whole chain of events at a glance, and don't have to keep trying to remember if the bit of code you're writing happens before or after a critical point; and secondly it forces you to account for things that happen in one cycle that have an effect in the next (or even the one after that).

So I now see why my first attempt at tracking Meanie collisions wasn't working - although I am now correctly stashing the screen contents before the Meanie moves, and correctly checking it later, there's actually a three game-cycle activity going on, where I had imagined it only as two:

     Cycle    Action
   1       Meanie moves, and we track that it overwrote a wall character
   2       Meanie moves again, but we recognise that previously it hit a wall, so just blank it
   3      Meanie is now out of play and can be re-instantiated

This three-cycle collision sequence only became apparent when I mapped it out in pseudo-code, as before I was trying to combine two of these three steps in a single cycle. This meant I either didn't blank the Meanie when it hit a wall, or I did but then had the 'out-of-play' flag set at the wrong point in the cycle and had 'random' Meanie appearances even after it was supposed to be dead.

I can now go back and rework the main loop to handle this sequence - it reminds me of Eric Morcambe, playing the piano with Andre Previn: "All the right notes, just not necessarily in the right order".

Collision Complication

2010-09-04T23:48:00.000+01:00

Solid progress today, much better than I expected - I now have Meanies and the Fuelship moving around on the screen, tidying-up after themselves and not leaving little trails lying around. The Meanies move the right way, the Fuelship appears at the right sort of interval and descends gracefully, and suddenly the whole game is starting to look 'alive'. There's a fair way to go yet, but it's definitely getting there!

I dropped a little 'Vsync' wait into the main game loop to get rid of plotting flicker, so the main loop now runs once per screen refresh and then waits for the raster counter to reset before continuing. There's no point running the game faster than this, because although it actually can run about 50 'cycles' per frame, the player can't see the benefit of it because the screen isn't redrawn that quickly. Also, running faster than the refresh rate makes the updates a bit flickery, so it looks slightly rubbish. By waiting for Vsync, we only update the screen once per frame, just before the VIC chip draws it, which looks super-smooth. As it happens, the game is running much faster than the original BASIC version (hardly surprising, since it's 100% assembler) so I've also had to put a sizable delay loop around Vsync to make it wait for around 50 or so frames to pass, just to slow things down and make it playable!

The problem I'm grappling with now is that of collision detection - figuring-out whether a moving thing has hit something else, and doing something appropriate if it did. The difficulty is that the logic is structured so that we check to see if something will collide before it actually does, as when the Fuelship lands - we want to know that it is about to hit the floor, not that it has hit (and sunk into) the floor. This is working fine - the ship lands and I get a flag set to tell me so, and I can then both deactivate it (which removes it from the playfield) and increment the current fuel level.

However, Meanies have to actually smack into something before they explode, so checking to see if a Meanie will hit a wall (for example) is no good - I don't want to do the collision processing until it actually impacts. Unfortunately, when the Meanie does hit a wall, it overwrites the wall character with itself - which means that if I try to alter the check to see if the Meanie did just hit something, all I see at that position is the Meanie.

I may have to stash the character the Meanie just overwrote when it moves, just so I can look to see what was there before the Meanie arrived. Not a huge issue, but since the VIC doesn't support hardware sprites and masks, I'll have to do it myself...

Slow But Sure...

2010-09-03T16:52:00.000+01:00

The beginning of a new school term and a heavy cold both kept me away from the code for a few days - but I have managed to scrape a few updates together in the odd spare minute or two, so progress continues albeit at a slow pace.

I now have a nice wrapper-routine around the Random Number Generator, through which I can pass a range limit value and have a sensible value passed back. So, for example, I can pass '2' in and get a random number back in the range of 1 to 2 (a 50/50 chance); equally, I can pass '5' in, and get values in the range 1 to 5 back (which is a 20% chance). The wrapper code uses pre-calculated tables to split the 0-255 RNG values into 'n' bands, and currently there are just two sets of data to split values into 2 or 5 bands. However, the code has a small amount of robustness built-in - if I pass in a range limit which has no table data defined, it always returns 255 rather than just chewing through memory until hitting a BRK.

I've also written some object-initialiser code which handles the instantiation of Meanies (and anything else) when a new one is needed - this code was previously inlined in the main loop, and was both unwieldy and non-generalised, so it's much nicer now. Also, the decision logic for moving objects around has been separated-out and much-improved, and is now a lot slicker than before. I need to add a little bit of code to re-calculate Base Offset Bit settings when objects move across the mid-screen page boundary, but aside from that it's largely complete.

Next on the list is to generalise the code that is specific to Meanie movement, because at the moment it's duplicated for each of the two Meanie objects; it should be lifted-out and turned into a general-purpose routine, because it's exactly the same except for the bits that reference each Meanie object. That way, the code exists in just one place, and I can then have each Meanie 'mover' decision-maker call it with a pointer to the Meanie in question. At the same time as I rework this routine, I'll also add the last missing piece of the jigsaw, which is to update the 'delete' table with the objects' old position so that the main update routine can draw the objects in their new positions and zap them from the old.

There's about three or four hours' work there, including debugging time, which in theory means I can get these tasks done over the weekend, and be ready next week to crack on with the next crucial bit of code which checks for collisions and out-of-bounds positions (like where a Meanie falls off the bottom of the screen). I'm still hoping to finish the game by the end of September, but I'm not too worried if it runs into next month, as is now looking likely. It'll be great when it's done and I can publish the whole thing though - really looking-forward to getting feedback on it!

Movement!

2010-08-23T14:00:00.000+01:00

The routines for updating mobile characters are in place and working, so I now have a Meanie moving around on the screen. I also have the stubs ready to hook-up movement rules for the Repair Bot and the Fuel Ship, though the 'bot movement will have to wait until I have the logic written to process user keypresses, since it only moves in response to those. I didn't quite get around to doing collision-detection yet, so I'll hold-off on posting a demo until that's in place - which is next on the list, but first I have to revisit the Random Number Generator.

The RNG itself is working fine, but I want to write a little 'wrapper' around it to make it easier to use. The game actually only calls it in two places, both for Meanie movement - once to determine whether the Meanie moves horizontally at all (one or two positions to the left, or right, or not at all) and then again to find out if it moves down a line. In other words, there's a call asking for a 1-in-5 response (left two, left one, no movement, right one, right two) and another asking for a 1-in-2 response (move down, don't move down). So that equates to a 20% chance for horizontal movement of some kind - including no movement - and 50% for a vertical drop.

The RNG returns 256 possible values in the range 0-255, so the code currently does a simple series of tests to see where the return value is in that range. For the 50% test, that's just a case of checking the value to see if it's greater than 127 - if it is, the Meanie drops a line; if not, it stays on the same line. The code gets a bit nastier when checking the 20% response though, as it has to test a series of four values (51, 102, 153, 204) to see which fifth of the range the value is in, and determine horizontal movement based on that. What I want is a neater way of calling the RNG so that I can pass a value in (e.g. 5 or 2) and have a simple value returned in the range of 1 to 'n', where 'n' is the number I gave it. A 50/50 test would then call the RNG with a value of 2, and get either 1 or 2 back; passing a value of 5 would return a value in the range 1 to 5.

This means the wrapper has to automatically calculate where in the 0-255 range the actual RNG result occurs based on the number of 'slices' the range has been asked to divide by. This is a matter of dividing 256 by the passed-in value, finding out how many 'slices' that equates to, and then figuring-out which 'slice' the RNG result falls into and returning that as the output value. For the 50/50 test where a value of 2 would be passed in, it would divide 256 by 2 (giving 128) and then ask the RNG for a result - which would then map into either the 0-127 band, giving 1 as an output, or the 128-255 band, giving 2. It's a bit more complicated for the 20%-chance test, but the same basic principle.

I've decided that since this game is making limited use of the RNG, there's not much point writing a sophisticated routine to handle any given range value - we're only using 2 and 5, after all. So instead I'll pre-calculate the boundary values in a table and have the wrapper just look them up to decide where the RNG result falls, and return the appropriate value. It's not a fully-generalised solution, but there seems little advantage to writing an all-singing-and-dancing version when I only actually need two cases handled. If and when I re-use the code and need a more flexible solution, I can drop the auto-calculation logic into it and chop-out the table lookup. For now, it does what I need and is fairly efficient, so it'll suffice.

Deep Thought

2010-08-19T11:49:00.000+01:00

I've decided to leave CHARPLOT alone after having a good think about whether to tweak it so that the structures use absolute addresses instead of the base+offset model it currently supports. Weighing-up the pros and cons, I couldn't see any absolute advantage in making the change, and in fact there were one or two things that I had a feeling might be less useful - for example, CHARPLOT figures-out where the screen is when it plots a character rather than having to do that work every time a structure is initialised. This makes the whole thing very adaptable to varying configurations of the system, as well as opening the door to double-buffering if I ever need it (by changing the SCREEN base address before calling a bunch of CHARPLOT updates). As a consequence I've decided to write a general-purpose structure update routine that manages the adjustments needed whenever a mobile object changes position.

The other problem, where CHARPLOT structures have no concept of a 'last' position, isn't actually that big a deal; I was playing with the idea of creating clone structures so that I could calculate the new position (of a Meanie, for example) but still have the old structure lurking around so that the screen-update routine could erase the character at the old position before drawing the new. In fact, I only really need to hold the Control Byte and Offset Byte of a character to be erased, and just drop those two bytes into a table which I can run through to zap whatever was at that position. So I can write a routine to step through the CHARPLOT objects, pick the first two bytes out of each and stash them somewhere, recompute the location of the object and update the structure, and then have a small loop zip through the 'old' positions table to clear those locations on screen.

I'll write these two routines this evening, and test them out with the one Meanie I currently have instantiated. Once they're working, I'll write some collision-tester code to detect when a Meanie hits something and goes out of play - and then I'll bring Meanie #2 online and have both wibbling around on the screen blowing stuff up. At that point, I might post a demo, even though it'll be fairly dull, just to prove to myself that progress has been made. ;)

Restore Restart

2010-08-17T12:20:00.000+01:00

I implemented a couple of routines over the weekend, the first of which was the Random Number Generator. Unsurprisingly, it bears a striking resemblence to the snippet of code which Muttley posted as a comment a while back. Since it works in almost exactly the same way (aside from using Zero Page instead of ROM as part of the generated value) it's a virtual carbon-copy, even down to the initial seed value - which is as good as any other, and there didn't seem to be any advantage to changing it:

;-------------------------------------------------------------------------------
; RANDOMGEN
; Generate a random number from 0-255
; Notes:    Returns value in .A, uses no other registers

randomgen    SUBROUTINE
             lda $0                     ; Get next ZP value
             adc .seed                  ; Add seed value
             adc RASTER                 ; Add current raster count
             sta .seed                  ; Update seed value
             inc randomgen+1            ; Increment ZP address in first instruction
             rts

             ; Seed value
.seed        DC.B $73                   ; Initial seed value

I plugged it in, and as if by magic it started returning a pseudo-random sequence of values from 0-255. So I now have a way of making 'random' decisions about Meanie movement, and indeed about any situation where chance is a factor.

I also decided I wanted a way to abort the game in progress and return to the title screen. Since I also needed a way to disable RunStop/Restore, it seemed like an obvious solution to combine the two - instead of the RS/R key combination generating an NMI which returns to BASIC, how about if it instead restarted the application?

The first part of the trick is to trap the NMI (Non-Maskable Interrupt) that RS/S produces. It's hard-wired into the VIC design that this key combination will fire the NMI, and, unlike the IRQ interrupt, there's no way to disable it - it's called non-maskable for a reason! However, those jolly nice chaps at Commodore set things up so that the first thing the Kernal NMI handler does is an indirect jump through a vector at $0318/0319. By default, that vector just points straight back into the Kernal routine, but of course you can make it point anywhere else. So now the initialisation section of the main Meanies program adjusts the NMI vector to point at this:

           ; NMI handler to handle 'Restore' interrupts
.nmitrap   bit V1PORTAO       ; Read VIA1 Port A Output Register to acknowledge NMI
           inc RESTART        ; Set restart flag
           rti                ; Return from the NMI

All we do here is a read of the VIA#1 Port A Output Register with the BIT instruction, set a flag we check in the main game loop, and return from the interrupt. By reading Port A, we trip the VIA handshake signal and the NMI is thereby 'acknowledged' so that further NMIs can happen. We use BIT because it affects no register values, except for flags in the Status Register - but that's OK, because the NMI logic in the 6502 is very well-behaved and saves both the PC and PSR registers when it gets invoked, and restores them after the RTI instruction. In other words, when we return from this custom NMI handler, the CPU state is exactly as we left it.

By incrementing the 'RESTART' flag value, we can have a simple test in the main game loop that looks for non-zero values - as long as the address contains zero, we carry on, but as soon as it gets incremented we exit the loop and go back to the title screen. So I now have a way to abort the game, and a handler for RS/S which prevents the game from being broken-into. Well, makes it harder to break into it, anyway. ;)

Sadly, it wasn't all sweetness and light whilst I was doing all this - after I'd got the RNG working, I started coding the routine to make the Meanies move based on the RNG output, and that was when the words of Field Marshall Helmuth Carl Bernard von Moltke came to mind:

'No battle plan ever survives contact with the enemy'

It turns out that CHARPLOT, my stable and reliable screen-plotting workhorse, isn't quite suitable for plotting mobile objects after all. It's fast enough, absolutely, and pretty flexible when it comes to putting things at predefined places, but as I started to write the code to move a Meanie around, I encountered a weakness - it's actually a bit of a drag having to recalculate a characters' position in terms of a base+offset, and then update the CHARPLOT structure each time. Plus, the structures have no concept of a 'last' and 'current' position, which means I have to do some faffing-around with cloned structures in order to be able to calculate a new position without overwriting the old data so that I can erase the object from its' old location and draw it at the new location.

So I'm having a rethink about the way CHARPLOT works. The fundamentals are good, but I'm toying with the idea of altering it to use an absolute address as the base, rather than a simple bit which indicates where the base is. If I do that, I can then carry-out simple 16-bit mathematics on the address rather than having to do some inelegant bit-twiddling; I can then also span repeated sequences across the page boundary in the middle of the screen, plus I get an easy way to check for out-of-bounds sequence overruns.

I'm still playing with this in my head, really just trying to figure-out if it'll then give me what I want and not trap me in a corner again further down the line. It means the CHARPLOT structure will grow by a byte, but I think the tradeoff in flexibility will make up for the slight increase in space requirements. I might write a test version later and see what it looks like.

Random Thoughts

2010-08-12T11:52:00.000+01:00

And ... we're back, and picking-up right where we left things with random numbers.

Getting the Meanies to move randomly requires a little bit of code to generate a random value which will indicate how the little blue guys should change position. Generating random numbers is reasonably straight-forward, provided you choose your generation source carefully - what is needed is a source of values that change frequently, which you can tap as the baseline value to use in deriving what looks like randomness. The problem with computer-generated random numbers is that they're never 'truly' random, because ultimately the environment is deterministic - we want the computer to behave in a known, repeatable, predictable way, and having random unpredictable stuff happening is highly undesirable. So we have to create the illusion of randomness by using some root value that appears to be unpredictably different every time we look at it.

I'd been thinking about using the VIC Raster Counter register at $9003/$9004 as the baseline value for a RNG (Random Number Generator) and Muttleys' earlier comment on a previous post shows that this is a typical approach. The VIC doesn't support hardware raster interrupts (unlike its' successor the C64) so the raster counter simply keeps track of how many video raster lines have been drawn per frame - it starts at zero and rapidly counts up to however many lines are displayed (which varies depending on whether you're looking at the picture on a PAL or NTSC model) before resetting. Since this counter runs very rapidly, consecutive reads of the register will return different values, and provided you aren't reading it at precise intervals you'll get a different value from the range every time.

Of course, the Meanie code is fairly linear, so there is a slight chance that we could fall into a situation where we are reading the raster counter at regular intervals - which means we might get the same value every time. Ironically, this is precisely what coders want when they need to synchronise video effects to the raster line, but for the purposes of generating random numbers it's a disaster. So we need to add a further skewing value to what we get out of the raster counter, to ensure that even if we do end-up synchronised to it, we'll still get a variable result - and that's why I'm using a page of ROM data as an additional source (Muttley uses another memory area on the C64) to guarantee variability. By adding sequential values from ROM to the value obtained from the raster counter, we get pseudo-randomness - in the worst case, where we've synchronised to the raster count, we'll still get 256 successive values from the ROM that have the appearance of being random.

But that still isn't random 'enough', because we'd still only have a domain of a maximum of 256 values (which is itself unlikely, since a page of ROM code is probably going to contain a tiny subset of that) and that is quite a small working set - small enough that a keen eye could eventually spot a pattern and might therefore be able to predict with some success what was going to happen next. So we also need a 'seed' value, which changes over time, to act as a further layer of randomness - by incorporating the seed in the algorithm, we add an additional level of complexity to the values the RNG produces, ensuring that the worst-case scenario (synchronisation to the raster counter and a predictable ROM pattern) still generates apparent randomness.

The VIC raster counter occupies 9 bits, with $9004 holding the first 8 bits and the 9th bit sitting in bit 7 of $9003 - this makes sense, because a PAL or NTSC screen is made up of either 312 or 261 raster lines respectively, both of which require 9 bits to represent in binary. The VIC registers, like every other memory location, are bytes - so they contain 8 bits, and that means the 9th bit has to go somewhere else. In this case, it tucks into the end of the register at $9003, and is therefore clear when the counter is less than 256, and set when greater-than or equal to 256.

We can ignore that 9th bit though, and just read the contents of $9004 - it'll give us values from 0-255, and it doesn't matter that it wraps back to zero before the end of the frame when bit 7 of $9003 is set for raster lines 256-312 (or 261 for NTSC). So I'm going to create a little subroutine that will pick-up the current value of $9004, add it to a sequentially-incremented ROM location (actually, thinking about it, I might use Zero Page - it's a faster operation, and just as 'random') and finally add a seed value. I'll post the code once it's in place, in a day or two.

Intermission

2010-07-22T11:03:00.000+01:00

I'm taking the Dev box off the grid for a week or two, as it's due for a disk upgrade and I'm using the opportunity to do a full rebuild of the OS. Win7 has been totally rock-solid since I installed it, but I want to adjust some of the partition sizes and do a few other bits of housekeeping that are easier when you're playing with a fresh build.

So whilst that's going-on, Meanies development will be on a short hiatus. I'm expecting to have everything up and running again early in August, at which point we'll resume normal service here. See you soon!

The Opposite of Artificial Intelligence

2010-07-19T20:12:00.000+01:00

...is, of course, natural stupidity.

It wasn't DASM doing odd things to the 'included' data. It was my code. I admit it - mea culpa. In my defence, it was late and I was tired and the cats were bugging me to let them out and there was something good on TV and my back was hurting. Oh, and I forgot to update a label in the CHARPLOT structures file for the new BSOD entries, which meant CHARCONV was reading junk and splatting data all over the memory map. Sigh.

So, on we go. We now have the playfield drawn, with the walls, floor, reactor core and laser turrets in place. I have a new routine called DRAWMOBS which is responsible for plotting all the 'mobile' characters during gameplay, which includes two Meanies, the Repair Bot, the Fuel Ship, laser beams, explosions, and in-game messages. And the first Meanie and the Repair Bot have made their appearance:

The next item on the agenda is getting the Meanie to move - and this is going to be very interesting, because it requires the use of random numbers to dictate what position it moves to. That's something I've never done in Assembly language before, so it'll be fun to find out how the mechanics of generating a random number series will work. :)

User Defined Gibberish

2010-07-18T23:00:00.000+01:00

I've adjusted BSOD so that it uses CHARPLOT instead of STROUT, which took about an hour to do, and it's working fine again - so I'm finally free of that particular ROM routine and its' little temper tantrum caused by my Zero Page usage. Which meant I could return to the code to draw the main gameplay screen, which is pretty straight-forward. It's at this point that things start to get interesting, because the game now switches to a UDG (User Defined Graphics) characterset.

I yanked the chunk of binary data for the UDGs from the original game (which are stashed above the BASIC code at $1C00) and simply 'include' that as a block of data at the same place in the Assembler code - my current high-water-mark is at around $1400 or so, which means I have lots of room before I might start to encroach on that memory area. Since the original game doesn't climb that high, I have no significant worries that the 6502 code will get anywhere near it either. Which makes the problem I'm tackling all the more puzzling.

The character data looks fine in CharPad, a nifty little Windows utility written for designing maps, sprites and UDGs for the C64, and which handles VIC-20 UDGs just as neatly. But oddly, the first six characters - @, A, B, C, D and E - have some minor corruption when I display them in the game. Everything after that is exactly as CharPad shows them, but those first six (48 bytes) are slightly, but not entirely, damaged.

My suspicion is that something somewhere is splatting some random values over those memory locations - but the game is barely doing anything yet, and there just doesn't appear to be anything going remotely near that block of data. So I'm going to write a little test program to just pull the characterset in and display it without any other code to possibly injure it, and see what it looks like. If I'm right, and there's something in the Meanies code that's misbehaving, those six characters will look OK.

Of course, if that's the case, I'll have to do some careful tracing to see what is going wrong in the game, as I really am pretty confident that there just isn't anything that I'm doing that could cause the problem. If it is the game code, it must be something to do with the way the BASIC stub line is being constructed that is causing some bizarre side-effect. On the other hand, if the characters are still corrupted even in my test code, that means that DASM is doing something odd when it includes the data at assembly time - and that could be a really nasty one to resolve.

I'm hoping to run the test code in the next day or so to see what light it sheds on the problem. It's a tricky one...

BSOD 2 - The Tweakening

2010-07-15T14:26:00.000+01:00

I was debugging a little bit of code last night, and dropped a BRK instruction into the code to trigger the BSOD routine so I could see whether the registers contained what I thought they should. At which point STROUT bit me in the behind again.

You might remember that I used this ROM routine to generate the BSOD display, and subsequently wrote CHARPLOT because it wasn't fast enough to draw the games' playfield screen - that exercise has been wholly successful, resulting in a nice chunk of code that's fast and flexible enough to let me draw the playfield instantly, as well as act as the 'engine' for moving things around during gameplay. I didn't bother going back to convert BSOD to use CHARPLOT because it just writes lines of text to the screen when the CPU hits a BRK instruction - at that point, speed is irrelevant because we're in a failure scenario and just displaying the wreckage.

However, my Zero Page usage has gone up recently to more than double the previous high-water-mark - I'm now using almost 30 bytes, and there will definitely be more added before I'm done. The thing about Zero Page is, it's used extensively by the BASIC and KERNAL ROMs - which is not a problem when you're in pure Assembly mode and not using any ROM routines which have ZP dependencies, but can be a headache if you happen to call a routine which, in turn, needs some ZP location you've overwritten with game data. Like, for example, STROUT - which evidently relies on something in those first 30 bytes of ZP that I have appropriated for the game. Consequently, when BSOD gets invoked and starts making calls to STROUT, all manner of nasty things now happen and the CPU gets shunted off into the weeds somewhere - VICE pops up an alert telling me everything has gone pear-shaped, and the BSOD never appears.

I could trace through STROUT and figure-out what it's getting upset over, and then leave whatever byte(s) of Zero Page it needs alone - but actually, I don't really want to, because that would leave me with 'holes' in my ZP map which are only there because STROUT sulks otherwise. And of course STROUT is only being called by BSOD, which in the 'release' version of the code won't even be there (I use a conditional assembly directive to include BSOD in the 'debug' version of the code, and leave it out of the 'release' version). So I'm now back in the innards of the code converting it to use CHARPLOT instead.

Some days it feels like 2 steps forward, 1.97 back...

Interrupted Interrupts

2010-07-14T19:12:00.000+01:00

Having got the character translation routine finished, I have now written a short routine that executes when the game starts and which processes all the embedded strings, converting them to Screen Codes in-place. It bears more than a passing resemblance to CHARPLOT itself, since it processes the actual structures that are defined and given to the drawing routine - so it has to be able to interpret the Command Byte to isolate the Repeat/Length bit and figure-out where the characters start and how many there are to convert. Instead of drawing the characters, it just calls the translation routine and saves the result back to the structure - so it's a very simple cut-down variant of CHARPLOT itself, with the drawing and colour logic chopped out.

Having returned from these little diversions, I can now continue with the main task of converting logic from the games' BASIC sourcecode into Assembly. But before progressing to the next stage of the process, I just needed a quick dive into the Kernal to see where the IRQ routine goes to read the keyboard - the title screen and main game itself both need to be aware of keypresses, but the program runs with interrupts disabled (for maximum speed) and therefore the keyboard-handler routine isn't automatically called. The IRQ routine at $EABF calls a few different routines needed to keep the machine ticking-over, and one of them is SCNKEY at $EB1E - this processes signals from VIA1 which is continually scanning the keyboard, and converts the results into characters in the keyboard buffer.

The IRQ handler calls SCNKEY (and all the other housekeeping routines) 60 times a second, but I don't need all those other bits of code running - so Meanies executes an SEI as its' very first instruction to disable the IRQ flag in the CPU and stop interrupts occurring. Consequently, it becomes the games' responsibility to call SCNKEY at appropriate times and intervals to have keypresses processed and made available. So, for example, the title screen waits for a keypress using the following simple loop:

         ; Wait for keypress to start game
.keywait jsr SCNKEY       ; Scan keyboard
         lda KEYCOUNT     ; Get count of keypresses
         beq .keywait     ; Loop until any key is pressed

Of course, this is a spinlock - nothing else (except for NMIs) can happen whilst this loop is executing, so it's not the technique I'll be using in the main gameplay section. But it demonstrates the principle.

I now also have a short bit of code which initialises a set of gameplay variables like Energy, Score, and so on. This includes a few CHARPLOT structures for things like the Repair Bot and Meanies - you'll recall that I have CHARPLOT running at around 50 frames per second, so it's plenty fast enough to draw all the 'mobile' entities in the game.

The next thing to do is finalise the drawing of the main playfield elements, and then we'll be into the main loop of the game where Stuff Happens. :)

It's Not Big or Clever...

2010-07-09T18:58:00.001+01:00

I spent an hour last night finalising the mapping rules to convert PETSCII to Screen Codes, and then writing the code to implement them. I guess I've spent a total of three hours on this task, although the first half of that was occupied trying to figure-out how another mapping routine I found actually worked.

It was very clever, in that it used only the input value given in the Accumulator, and no other registers or memory. By shifting and masking bits in the PETSCII value it was given, and then selectively testing for specific resultant values, it derived the mapping value and left it in .A upon exit. The problem with it was that it is very difficult to trace the logic, because at any moment in the execution path you have to be aware of whatever operations have been performed on .A up to that point, what the current value in .A is, and how that relates to the original PETSCII value. Aside from some comments asserting the mapping rules at the top of the code, none of the actual logic had any annotation, so I went through it line-by-line and added my own as I worked out what it was doing.

By the time I'd finished, I'd almost lost the will to live. Whilst I'd figured-out what the routine did, it was still pretty cryptic to look at, and worst of all I'd found a discrepancy between what the comments at the top said the results should be and what the code actually did. However, at that point I conceded defeat - I couldn't face working through the logic yet again to confirm the discrepancy, and I wasn't 100% sure I hadn't made a mistake myself and the code was actually right after all. So with a possible glitch in a 43-byte routine I'd spent 90 minutes looking at and still wasn't absolutely certain I understood properly, I decided enough was enough, and abandoned it.

I fired-up a copy of Excel and produced two simple columns with the PETSCII characters and Screen Code characters side-by-side. I then converted their decimal values to binary, and analysed the differences where one mapped to the other - which gave me a simple rule in each case for what to do to the PETSCII value to turn it into a Screen Code value. I didn't have to do this for all 256 characters, because they actually map in blocks of 32 (except for value 255) so I ended-up with 9 rules - and there were duplicates, so the actual number of distinct rules is only 6.

    PETSCII Value    Mapping Rule              Logical Operation
      0-31            No change   
      32-63           No change   
      64-95           Clear bit 6               and #%10111111
      96-127          Clear bit 5               and #%11011111
      128-159         No change   
      160-191         Set bit 7, clear bit 6    ora #%10000000, and #%10111111
      192-223         Clear bit 7               and #%01111111
      224-254         Clear bit 7               and #%01111111
      255             Output 94                 lda #94

I then wrote the code in it's simplest form, just testing for specific values and mapping appropriately - which gave me a routine 57 bytes long. I then spent a few minutes combining the duplicate rules, which reduced the byte count to 49. And finally I optimised it so that it re-used rule fragments where possible, and the code dropped to 40 bytes. More importantly, that's 40 bytes of readily-understandable logic, with comments. It only manipulates .A, uses no other registers or memory, and is a simple drop-through routine which only actually changes the value in .A when it performs the mapping, rather than twiddling bits as it progresses.

;-------------------------------------------------------------------------------
; CHAR2SCREEN
; Converts PETSCII values to the appropriate Screen Code.
; Notes: Load .A with PETSCII value - converted value is returned in .A
;     Uses no other registers or memory
;
;
; PETSCII Value    Mapping Rule              Logical Operation
;   0-31            No change
;   32-63           No change
;   64-95           Clear bit 6               and #%10111111
;   96-127          Clear bit 5               and #%11011111
;   128-159         No change
;   160-191         Set bit 7, clear bit 6    ora #%10000000, and #%10111111
;   192-223         Clear bit 7               and #%01111111
;   224-254         Clear bit 7               and #%01111111
;   255             Output 94                 lda #94

char2scrn SUBROUTINE
     cmp #255       ; Input = 255?
     bcc .tst192      ; Less than 255, skip to next test
     lda #94        ; Input = 255, reset to 94
     rts          ; Exit

.tst192  cmp #192       ; Input >= 192?
     bcc .tst160      ; Less than 192, skip to next test
     and #%01111111    ; Input >= 192, clear bit 7
     rts          ; Exit

.tst160  cmp #160       ; Input >= 160?
     bcc .tst128      ; Less than 160, skip to next test
     ora #%10000000    ; Input >= 160, so set bit 7
.clear6  and #%10111111    ; Clear bit 6
     rts          ; Exit

.tst128  cmp #128       ; Input >= 128?
     bcc .tst96      ; Less than 128, skip to next test
     rts          ; Exit (leave unchanged)

.tst96  cmp #96        ; Input >= 96?
     bcc .tst64      ; Less than 96, skip to next test
     and #%11011111    ; Input >= 96, clear bit 5
     rts          ; Exit

.tst64  cmp #64        ; Input >= 64?
     bcs .clear6      ; Input >= 64, so clear bit 6
     rts          ; Less than 64, leave unchanged

It might not be as 'clever' as the routine I found, but it's understandable, and shorter. Which is nice.

Plz sNd mE Teh Codez

2010-07-07T22:15:00.005+01:00

I've had a whole bunch of requests (well alright, one) for a peek at the code I've been writing, and writing about. So here's CHARPLOT in all its' glory, although the sharp-eyed amongst you will notice immediately that I'm not using the BIT command I wrote about a couple of posts ago. As it turned out, the motivation for sequencing the bits in the Control Byte so that I could do a fast test on the N and V flags with BIT became somewhat redundant when I stopped needing to test the Effect and RVS bits on every iteration through the drawing loop. So now the bits are arranged in a comfortably convenient way, since there's no speed advantage to be gained in coercing the structure any further.

Here's the routine, followed by the working-storage allocations which go in Zero Page; I have them starting at location $03, but you could assemble them anywhere safe:

;-------------------------------------------------------------------------------
; CHARPLOT
; Displays one or more characters on the screen.
; Notes: Load .A and .Y with address of charplot data table
;     Uses all registers and ZP locations $03-0d for working storage
;     Assumes character(s) have been converted from PETSCII to Screen Codes
;
;     Character-based screen plotting
;       * Control Byte
;         * Offset Byte
;         * Repeat/Length Byte
;         * Character Byte(s)
;
;     Control Byte Bits
;         * 7 : Repeat/Length Type (0=Repeat Specified Character, 1=Use String of Specified Length)
;         * 6 : Screen Base Offset (0=0, 1=256)
;         * 5 : Unused
;         * 4 : Unused
;         * 3 : Colour 2  0=Black, 1=White, 2=Red, 3=Cyan, 4=Purple, 5=Green, 6=Blue, 7=Yellow
;         * 2 : Colour 1
;         * 1 : Colour 0
;         * 0 : Reverse Mode (0=RVS OFF, 1=RVS ON)

charplot SUBROUTINE
     sta CPDATALO     ; Store charplot data start address in ZP (LSB/MSB)
     sty CPDATAHI

     ; Calculate and store charplot character address in ZP (LSB/MSB)
     sty CPCHARHI     ; Assume character(s)
     clc          ; Clear C flag before we start
     adc #3        ; Add 3 to data LSB for character offset
     sta CPCHARLO     ; Save it to ZP

     ; Adjust character MSB if carry was set
     bcc .setscrn     ; No carry - skip MSB adjustment
     inc CPCHARHI     ; Increment character MSB

     ; Set charplot screen and colour base MSB in ZP
.setscrn lda #>SCREEN     ; Get screen base MSB
     sta CPSCRNHI     ; Save in ZP
     lda #>COLOUR     ; Get colour base MSB
     sta CPCOLRHI     ; Save in ZP

     ; Set RVS mask value
     lda #0        ; Assume RVS is off
     sta CPDATARM     ; Save in ZP

     ; Get Repeat/Length, Offset and Control bytes
     ldy #2        ; Set ZP indirect offset in .Y to third charplot byte
     lda (CPDATALO),y   ; Get character repeat/length byte
     sta CPDATARL     ; Save it to ZP (repeat/length value)

     dey          ; Decrement .Y for second charplot byte
     lda (CPDATALO),y   ; Get character offset byte
     sta CPSCRNLO     ; Save it to ZP (charplot screen/colour address LSB)
     sta CPCOLRLO

     dey          ; Decrement .Y for first charplot byte
     lda (CPDATALO),y   ; Get control byte
     tax          ; Save in .X for later

     ; Isolate and save RVS mode bit
     ror          ; Rotate RVS bit into C flag
     ror CPDATARM     ; Rotate C flag into RVS mask bit 7

     ; Isolate and save the colour value
     and #7        ; Mask colour value
     sta CPDATACOL     ; Save it to ZP (colour value)

     ; Is there a screen base offset?
     txa          ; Get control byte from .X
     and #%01000000    ; Mask offset bit
     beq .plot       ; If bit not set (N flag set) skip base increment

     ; The offset bit is set
     inc CPSCRNHI     ; Add 1 (i.e. 256) to charplot screen/colour base address MSB
     inc CPCOLRHI

     ; Check repeat/length bit
.plot   ldy #0        ; Assume we're repeating one character
     txa          ; Get the control byte from .X
     bpl .getchar     ; If N flag isn't set then we're repeating one character

     ; The length bit is set, so this is a string to display
     ldy CPDATARL     ; Get offset into string

     ; Draw the character and colour
.getchar lda (CPCHARLO),y   ; Get character byte
     ora CPDATARM     ; Apply RVS mask
     ldy CPDATARL     ; Get repeat/length value
      sta (CPSCRNLO),y   ; Store Character at screen location
     lda CPDATACOL     ; Get colour from ZP
     sta (CPCOLRLO),y   ; Store colour at colour location

     ; Decrement repeat count / string offset
     dey          ; Decrement repeat/length value
     sty CPDATARL     ; Save it to ZP
     cpy #$ff       ; Did we decrement past zero?
     bne .plot       ; Loop until repeat/length done

     rts

     ; CharPlot working storage (ZP)
CPDATALO DS.B 1            ; CharPlot data address pointer (LSB)
CPDATAHI DS.B 1            ; CharPlot data address pointer (MSB)
CPCHARLO DS.B 1            ; CharPlot character address pointer (LSB)
CPCHARHI DS.B 1            ; CharPlot character address pointer (MSB)
CPSCRNLO DS.B 1            ; CharPlot screen base address (LSB)
CPSCRNHI DS.B 1            ; CharPlot screen base address (MSB)
CPCOLRLO DS.B 1            ; CharPlot colour base address (LSB)
CPCOLRHI DS.B 1            ; CharPlot colour base address (MSB)
CPDATARL DS.B 1            ; CharPlot Repeat/Length value
CPDATARM DS.B 1            ; CharPlot Reverse Mode mask value
CPDATACOL DS.B 1            ; CharPlot Colour value

And here's a short demo program which uses CHARPLOT to draw a few simple lines on the screen. It's hardly rocket science, and in terms of graphical 'wow'-factor it's sorely lacking - but it does demonstrate how the 4-byte definition structure works, and shows how to invoke the routine to make it do its' thing:

;-------------------------------------------------------------------------------
; CHARPLOT Demo

     ; Assemble for 6502 CPU
     PROCESSOR 6502

     ; Disable interrupts and make sure Decimal mode is off
     sei          ; Disable interrupts
     cld          ; Clear decimal mode

     ; Start
.restart lda #0        ; Clear keyboard buffer
     sta KEYCOUNT
     jsr CINT1       ; Reset VIC
          jsr CLRSCRN      ; Clear the screen

          ; Display a block of coloured lines
        ldx .cplen      ; Get line table length
.lineloop stx TMPSTOX      ; Store .X in ZP  ** Note - define this in ZP somewhere **
     lda .cpaddr-1,x    ; Message address LSB
     ldy .cpaddr,x     ; Message address MSB
          jsr charplot     ; Draw to screen
     ldx TMPSTOX      ; Get .X from ZP
     dex          ; Decrement .X for next line address
     dex
     bpl .lineloop     ; Loop until all lines displayed

     ; Wait for keypress
.keywait lda KEYCOUNT     ; Get count of keypresses
     beq .keywait     ; Loop until any key is pressed

     cli          ; Re-enable interrupts
     rts          ; Return to BASIC

     ; CHARPLOT data
.cpline1 DC.B 12    ; Control Byte
     DC.B 70        ; Character Offset
     DC.B 13        ; Repeat Byte
     DC.B 160       ; Character Byte
     
.cpline2 DC.B 12    ; Control Byte
     DC.B 114       ; Character Offset
     DC.B 13        ; Repeat Byte
     DC.B 160       ; Character Byte
     
.cpline3 DC.B 12    ; Control Byte
     DC.B 158       ; Character Offset
     DC.B 13        ; Repeat Byte
     DC.B 160       ; Character Byte
     
.cpline4 DC.B 12    ; Control Byte
     DC.B 202       ; Character Offset
     DC.B 13        ; Repeat Byte
     DC.B 160       ; Character Byte
     
.cpline5 DC.B 141    ; Control Byte
     DC.B 92        ; Character Offset
     DC.B 13        ; Length Byte
     DC.B "0123456789!=-+" ; Character String

     ; Charplot line addresses
.cpaddr  DC.W .cpline5,.cpline4,.cpline3,.cpline2,.cpline1
.cplen  DC.B (.-1-.cpaddr)

     ; Subroutines
     INCLUDE "charplot.6502"

Note: there are a few symbols defined here that refer to VIC-20 memory locations or ROM routines - just download my VICMap.6502 file from here and include it at the top of the routine to have them resolved at assembly time. In DASM, natch. :)

I'm still working on getting the PETSCII mapping routine done so that I can send readable messages to CHARPLOT for 'printing'. There are a couple of solutions around already, generally doing either a primitive table lookup (which is not wonderful, because it consumes 512 bytes for the mapping table) or some clever but convoluted bit-shuffling to remap without a lookup table. The latter is much neater, but quite hard to follow and not particularly efficient in the way it's structured - so although it's the approach I'm taking myself, I'm not simply dropping a pre-written chunk of code into Meanies; I've got an idea for a slicker technique which will be elegant and structured such that it's readable and readily-understood.

The hard part is getting the mapping table right in the first place, which is where my attention is focussed right now; simply listing the PETSCII codes and Screen Codes next to each other isn't enough - I'm looking at the binary patterns each mapped chunk follows, and codifying rules that will translate one to the other (and back, if need be). When that's done, I can write a streamlined bit of 6502 that will action the appropriate rule (or rule-chain, to be precise) depending on the input.

Pesky PETSCII

2010-07-06T17:41:00.000+01:00

At long last, and after no less than five significant revisions since the first working version...

CHARPLOT is finished.

Whew!

It's turned-out pretty nicely, I think - it handles plotting of single characters, repeated characters, and character strings to any location on the screen in any of the eight standard character-colours, plus a reverse-mode option. It's fast enough to fill the screen (i.e. change the character and colour at every visible location) 48 times a second with the standard IRQ handler active, and well over 50 times a second with interrupts disabled. It occupies 86 bytes of memory, plus 11 Zero Page bytes for working storage. It'll do. ;)

There is, however, a small fly in the ointment - and it's something I remember knowing about back in the '80s when I was writing code on real VICs and PETs, but had forgotten in the intervening years and have now been rudely reminded of. It's simply this - the PETSCII* codes used to display characters on the screen via the ROM 'Print' routines are not the same as the Screen Codes needed to map characters directly to the screen. The character 'A', for example, has a PETSCII code of 65, but a Screen Code of 1. So although CHARPLOT is working, it's being fed PETSCII codes (because that's what STROUT wanted) and so I get garbage plotted on the screen.

The thing to do is to write a little mapping routine that converts PETSCII into Screen Codes - a simple matter in theory, but in practice it's complicated by the fact that the mapping isn't contiguous. In fact, it's all over the place - chunks of PETSCII map into different areas of Screen Code values, so this isn't just a case of subtracting 64 from the PETSCII code to convert 'A', for example. I'm currently writing a routine to do this mapping, so that I can still include readable strings in my code, and have them converted automatically into Screen Code values when the program runs - this conversion will happen once, when the program starts, so that CHARPLOT doesn't have to re-map 'on-the-fly' but can just take the pre-converted character(s) and plot them immediately.

*PETSCII - the Commodore variant of the 1963 ASCII standard, developed for use in their PET computers and inherited by the VIC, C64, etc. It's different in a number of ways from the 1967 ASCII standard we know and love today. Wikipedia has a reasonable entry on it.

Trust Your Feelings, Luke

2010-06-30T15:49:00.000+01:00

I was tweaking CHARPLOT last night, and got variable-length non-repeated strings working (at a cost of a mere 5 bytes of new code!) and was thinking about the last feature the routine needed, which was to plot characters in reverse-video mode (RVS ON) if requested.

Sometimes I can look at a piece of code and get 'that feeling'. It's impossible to describe, but it essentially amounts to a nagging sensation that this is Not The Right Way to do something - that there is, in fact, a much better way to achieve the result, and that even though I might not know what that better way is yet, I already know that what I have isn't it. Well, as I was contemplating adding the logic for RVS ON, I got that feeling.

If I had to pick what it was that triggered it, it would have to be the Effect Byte logic in the drawing-phase of the routine, near the end. It just stuck out like a sore thumb - 12 little bytes of code that I know are going to get executed precisely 44 times, once per character over two 22-character lines, on the title screen. That's 12 bytes of code (including a branch around it that will execute every single time the routine is called, except for the first two occasions) sitting there right smack in the middle of the draw logic, doing bugger-all for 99.99% of the time.

I knew it had to go - far better to take that Effect code out of the core routine, and just have a bespoke overdraw loop after the first two calls to re-colour the characters. So out it came, and that meant I could turn off the Effect bit in the Control Byte for those first two plotted lines. Ah, hold on - so now, that bit is never ever used, which means we can drop it from the Control Byte. Which means in turn that we can drop the code in CHARPLOT that interprets that bit and then reads the Effect Byte. And that means we don't need the Effect Byte at all, so I can also re-sequence the bits in the Control Byte for greater efficiency. So I can re-write the logic that LSRs those bits and ... ah nuts, let's just start again from scratch.

I've standardised the data definition entries on 4 bytes, instead of a variable number between 3 and 5. That makes the CHARPLOT byte-reader code dead simple. I've re-sequenced the bits in the Control Byte (again!) so that I can use the BIT instruction to test bits 7 and 6 very quickly (since BIT loads the N and V flags with these two bits automatically) and then just mask them off to leave the plot colour value, which is stored discretely in ZP - once isolated - for speed during the draw logic. I've trimmed ZP usage overall as well, since there were several intermediate values being stored there that I don't need any more - and in trimming what was used, I've also trimmed (as in, hacked-out) a bunch of STAs in the code that were initialising ZP.

It might appear that I'm spending an inordinate amount of time perfecting this routine, when the whole of the rest of the game lies unwritten before me - but there is a method to my madness. When I described this routine back when I first started writing it, I mused that it might be useful as a more general-purpose plotting service later in the games' development process, and it has now evolved into a shape that is both small and fast enough to be utilised as the core of the main gameplay drawing code. By constructing all the on-screen objects as CHARPLOT definitions and then dynamically manipulating them, I'll be able to call this subroutine for all the on-screen activity, not just the static playfield elements.

I'm expecting to finish it, finally, this evening - at which point I'm hoping to be able to look at the result and know that I am at last doing it The Right Way.

Still Plotting

2010-06-28T15:08:00.000+01:00

Over the weekend I only had about four hours in total to work on CHARPLOT, but in that time it went through two significant revisions, mostly in the 'middle third' of the code. The first section mostly deals with setting-up whatever screen offset the entry is intended to be drawn at, the last section does the actual drawing, and the middle chunk is where various Control bits are processed to figure-out whether there are any Repeat or Effect bytes to be read, and if so what their function is.

The first revision was intended to optimise the code by making better use of the CPU registers, rather than repeatedly reading memory. It did the job, but was not particularly readable - there was a fair amount of logic which was only there to determine what was in a given register at any time, and to make use of register data in preference to a memory access. In practical terms, it wasn't great - and once I'd completed it and proved it was working, I decided I didn't like it; the code had swollen to 120 bytes, and in places the amount of work it was doing to identify register contents was taking much longer than just re-reading the memory location where the data was stored!

So I re-wrote that middle part again, but making more use of Zero Page memory to hold values whilst decoding the Control bits. This has worked very well, especially since I re-ordered the bits in the Control Byte to make the decoding process a matter of simply LSR-ing them sequentially into the Carry flag and branching on that. This had two significant consequences - first, the 'drawing' part of the code became simpler because it had to do less work (just reading ZP memory instead of querying the Control Byte over and over again), and second, the whole routine reduced in size to 105 bytes.

I've got a little more work to do on it so that it'll handle variable-content strings and reverse-mode characters, but these are tweaks to the last part of the code where drawing occurs - the knotty decoding has already been done, so now I just need a few instructions to read and act upon the resultant commands.

Bughunting

2010-06-24T10:37:00.000+01:00

I re-wrote CHARPLOT last night, as I could see a number of ways to optimise and improve the logic - I tend to follow the doctrine of this quote...

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.": - Antoine de Saint Exupery

...so having completed a working version, I could then sit back and view it with a critical eye, noting where I could do things a little differently and refine the routine. Doing this in 6502 Assembler often feels like a maths problem, where you're asked to reduce a complex fraction to its' simplest terms - as with almost all programming languages there are numerous different ways to achieve the same result, and when coding Assembler you're continually striving to use the fewest possible instructions to get the job done in the smallest number of clock cycles and bytes.

I managed to shrink the code by a dozen bytes or so, which doesn't sound like a lot but is actually about a 20% reduction in the overall size of the routine - it's looking like it'll be around 60 bytes by the time I apply the final tweaks.

I also took the opportunity to re-map my Zero Page usage - most of the locations from 0 - 255 are used by various BASIC and KERNAL routines as working areas and storage, and there's typically not much you can freely use; but since Meanies is a 100% Assembler game, I can appropriate large chunks of ZP for my own use because I don't care about interfering with most of the ROM routines that use it. So instead of my code trying to squeeze into the few genuinely free ZP locations, I'm now able to use much more of the available space - although at this point my ZP memory footprint is still only 17 bytes, so we're not exactly stressing the machine. ;)

During the remapping process I stumbled across a subtle bug in the BSOD routine, where in some cases the .SR bit readout went wrong - so that got fixed as I went along. I'm now debugging the new CHARPLOT routine, and applying the finishing touches to it - hopefully there's no more than an hours' work left to do on it.

Painting by Numbers

2010-06-21T12:35:00.000+01:00

The work on the character-plotting routine (CHARPLOT) is now well under way - the first few hours were spent defining and then refining what the data structure should look like. I think this is close to being the final revision, but it might still evolve a little as the code moves towards its' final form:

Control Byte
Offset Byte
Repeat Byte
Effect Byte
Character Byte

The bare minimum needed to plot a single character is three bytes - Control, Offset, and Character.

To plot a repeated sequence of a single character, you need four bytes - Control, Offset, Repeat and Character.

To plot a string of a given length, you need three bytes plus as many bytes as there are in the string - Control, Offset, Repeat and 'n' Characters.

You only need the Effect byte if you're using an auxiliary colour and/or a 'special effect' - i.e. some bespoke pre- or post-processing that has to happen to each character as it's plotted.

The CHARPLOT routine always reads the Control and Offset bytes, since these dictate what kind of plot it will do, and where on the screen to start. Two bits in the Control byte determine whether to read the Repeat and/or Effect bytes, so these may or may not be present. CHARPLOT then reads the Character byte, or a sequence of Character bytes if it's a string, and updates the screen and colour memory as appropriate.

As a general-purpose screen-painting routine, it serves its' purpose - I can encode a single character as three bytes (not especially efficient), or any repetition of that character up to 256 bytes long as four bytes (very efficient). If there's any kind of specific effect to be applied as the plot progresses, this is just one extra byte in the definition, plus a branch in the CHARPLOT code to whatever effect subroutine is needed (there are 15 effect 'slots' available).

The key thing, of course, is not so much that I can encode sequences of characters to paint to the screen in this way, but much more importantly that CHARPLOT is fast - much faster than the 'STROUT' routine in the BASIC ROM. It's working against a specific, predefined data structure that I create to enable stuff to appear on the screen, and it isn't doing anything in the way of making sure I've got it right - it'll just do what it's told, and if I've made a mistake somewhere then it'll splat junk to the screen. This is the big difference between CHARPLOT and STROUT - no hand-holding, no error-checking, and no forgiveness if I give it rubbish to play with - but, on the flipside, it absolutely blasts the screen with data as fast as it can.

This routine is good for drawing stuff like the static title screen and the 'playfield' structures on the main game screen. It might be fast enough to be used as a re-draw routine for 'scrolling' games, but I'm not testing that, as this game doesn't require it. It might also even be fast enough to draw (and re-draw) in-game characters like the Meanies themselves, the Repair Bot, and maybe the laser blasts and explosions - I'm anticipating writing custom code to handle the drawing of the dynamic stuff, but if it turns out that CHARPLOT is up to the task, then I'll use that instead. :)

In comparing the presentation of the games' title screen using the 'old' Assembly code which called STROUT, and the 'new' version using CHARPLOT, they look identical (as you'd expect). But what is immediately apparent is the fact that the update time to draw the whole screen using the second version is too small to measure by eye; it's instantaneous.

The Plot Thickens

2010-06-14T20:14:00.042+01:00

I've carried-on with the initialisation stuff for the game - in this version (the 'classic' incarnation) I'm literally converting lines of BASIC into pure Assembler, adding appropriate framework architecture as needed. So, for example, to get the title screen displayed fully, I reused a chunk of code I wrote for the BSOD routine to display the text, and It Just Worked. With a little self-promotion (and some minor text alignment tweaking) we have the BASIC and Assembler versions side-by-side:

BASIC Meanies Title Screen

Assembler Meanies Title Screen

After I got the title screen working, I felt pretty pleased with myself - after all, this is pure 6502 Assembly here, so getting a screen display (albeit a static one) working and waiting for a keypress was very satisfying. Enthused, I quickly moved on to the next phase, which is to draw the initial game playfield; essentially a giant square 'U' which comprises the 'walls' and 'floor' which the Meanies like to blow themselves up against:

At this point, I once again cloned the basic logic of the BSOD display code, and that's when some of the shine suddenly went off the product. The title screen is fairly sparsely-populated in terms of content, so it draws pretty quickly - certainly quicker than the BASIC original, which has perceptible visibility of the updates as they're applied to the screen. The problem was that, whereas I knew the BASIC playfield draw was perceptible, the Assembly playfield draw was also visibly doing the update, and to my eye was only fractionally faster than BASIC - certainly not up to the blisteringly-fast 'blink' into existence I'd been anticipating. Something was wrong, and I knew what it was.

Here's a snippet of the code that reads data from a table of lines and displays them on the screen. The magic happens at the call to STROUT, which is a BASIC ROM routine at $CB1E that takes the start-address of a zero-terminated string in .A and .Y and makes it appear on the screen - it's part of the code that the BASIC 'PRINT' command uses after all the interpretive parsing has been done:

          ; Display the title screen message lines
          ldx #20               ; Message address offset in .X
.msgloop  stx USRJMP            ; Save .X in ZP
          lda .msgaddr,x        ; Message address LSB in .A
          ldy .msgaddr+1,x      ; Message address MSB in .Y
          jsr STROUT            ; Call ROM print routine
          ldx USRJMP            ; Decrement counter for next message
          dex
          dex
          bpl .msgloop          ; Loop until all messages displayed

Now calling this routine in a BSOD display that essentially gets called once at program termination, when a BRK is hit, is fine. Even for some simple title-screen text display purposes, it's fine. But for drawing anything more complex, with more 'stuff' to get onto the screen, it is most assuredly NOT fine.

The problem is this: the VIC-20 ROM is a 16K chunk of finely-crafted (mostly) 6502 code, divided into two sections. At $E000 you have the KERNEL, the 8K of code written by the engineers who designed the computer - it's there to talk to the bare metal of the machine and get stuff done, and is consequently pretty efficient, fast, and good-quality; the equivalent of todays' BIOS bootcode ROM in your PC that handles all the really low-level stuff.

And then, at $C000, you have 8K of BASIC interpreter; code written by Microsoft as a generic 6502-based BASIC that could be (and was) licensed to computer manufacturers for inclusion into their products - usually with a little tweaking, although the core always largely remained the same. It too is pretty good-quality code, but it wasn't designed for the VIC-20 as such - it's general-purpose code, and thus has somewhat less of a demand to be lean and mean. Which is not a bad thing - I think Microsoft did a good job overall - but...

This 6502 BASIC had four underlying design goals, which were

that it should fit into 8K, making it attractive to buyers - a decent BASIC implementation in one 8K ROM? Yes please!
that it be general-purpose, so young Mr. Gates could sell the same core product to lots of different people
that it be user-friendly, because BASIC is supposed to be easy to learn and use
and finally, that it be fairly idiot-proof, so that invalid commands or parameters wouldn't crash the machine

This is all fine and dandy until you're writing Assembly and calling a BASIC ROM routine which does a whole bunch of user-friendly stuff (like handling special control characters for inverse video, colour, cursor movement, etc.) and which tests and checks everything before proceeding so you don't accidentally break anything. Because that all adds up to S-L-O-W.

To put it bluntly, unless there's something VERY specific and VERY useful in the VIC-20 BASIC ROM that you desperately need, you're probably better-off staying away from it if you're writing Assembly for speed - unless you're writing some sort of extension to BASIC itself, of course. All of which means I need a general-purpose character-plotting routine that'll be a tailored substitute for STROUT, because I don't want or need all the cotton-wool that the BASIC ROM comes wrapped in, and I certainly don't want the consequent decrease in speed.

To Business

2010-06-11T19:41:00.001+01:00

I thought I'd share this little snippet with you, even though it's hardly earth-shattering - I've actually started porting the original BASIC Blue Meanies code to Assembly. Here's an example - this is couple of lines from the beginning of the original program, concerned with initialisation (my annotation is prefixed with an '*' before each line):

* Clear keyboard buffer, clear screen, poke coloured blocks to top line, set screen colours to normal
1 poke198,0:print"{clr}{blu}":fora=0to21:poke7680+a,160:poke38400+a,(aand7):next:vi=36864:pokevi+15,27

* Set character memory pointer to normal, poke coloured blocks to bottom line, set volume to max
2 pokevi+5,240:fora=21to0step-1:poke8164+a,160:poke38884+a,(aand7):next:pokevi+14,15

And here's what it looks like in Assembly:

          ; VIC chip initialisation
          sei                   ; Disable interrupts
          jsr CINT1             ; Reset VIC

          ; Title screen
          lda #0                ; Clear keyboard buffer
          sta KEYCOUNT
          jsr CLRSCRN           ; Clear the screen

          ; Coloured blocks across top and bottom of screen
          ldx #21               ; 22 character positions
.block    lda #160              ; Inverse space character
          sta #SCREEN,x         ; Top screen line character
          sta #SCREEN+484,x     ; Bottom screen line character
          txa                   ; Move counter in .X to .A
          and #7                ; Mask for colour
          sta #COLOUR,x         ; Top screen line colour
          sta #COLOUR+484,x     ; Bottom screen line colour
          dex                   ; Next character position
          bpl .block            ; Loop until all done

          cli                   ; Re-enable interrupts
          rts                   ; Return to BASIC

We disable interrupts whilst we're doing the setup stuff for two reasons; firstly, we don't need any of the IRQ service routines ticking along in the background when we're just doing setup stuff; and secondly, I want to make sure that no other events occur during the call to CINT1 (the routine in ROM at $E518 which initialises the VIC chip during startup) which I use to quickly reset it to a known state.

We clear the keyboard buffer and call the ROM routine to clear the screen (which CINT1 has reset to the standard startup configuration and colours), and then do a simple loop to poke inverse spaces (PETSCII code 160) into each of the 22 character positions along the top and bottom rows - setting the colour memory at the same time.

Differences? Well, we didn't bother setting the text colour to blue (no point), or assigning 36864 - the VIC chip start address - to a variable (don't need it, as it's in a separate memory map file). We didn't set the screen colour combination to 27 (CINT1 takes care of that) or set the character matrix address to 240 (CINT1 again) or set the sound volume to 15 (because we're not making any noises yet).

Oh, the other main differences? The BASIC line structures occupy 197 bytes, and it takes just under a second to execute and draw those blocks. The 6502 Assembly code occupies 34 bytes and executes instantaneously.

Blue Screenies

2010-06-11T16:06:00.004+01:00

I was browsing Denial a week or two ago, and one of the regulars there was asking a question regarding the creation of a 'debug' dump screen that resembled the classic Windows 'Blue Screen of Death', or BSOD, that could be invoked if a VIC-20 Assembler program they were developing went rogue and crashed. There isn't an easy way to get the VIC to automatically do this, since the OS is a single-threaded kernel with no way of detecting when a 'process' goes bad - if things go pear-shaped in your code, there's little the 6502 can do to either recover from it or even provide much in the way of detail to describe what went wrong. Theoretically you could hook a 'watchdog' routine into the IRQ, but that's not much use if your program wants to use the IRQ for its own purposes - and even then, what would your IRQ watchdog watch for? How would it know your main program had gone AWOL - especially if it's in a tight infinite loop with no way for the watchdog to know it isn't supposed to be doing that? How do you make a 30-year-old monolithic single-threaded kernel OS do this:

The only real option is to hook into the BRK vector - this is a routine that gets called automatically by the processor when a BRK instruction ($00) is executed. What that means is that if you had BRK instructions dotted-around in your code that should never get executed, but one somehow does get hit, you can escape main execution and display some kind of debugging data. Equally, if you wanted to find out the status of the processor at some point during program flow, you can deliberately embed a BRK in the code to trigger the BSOD. I thought this would be a very useful aid in writing the game, so I resolved to implement something that would give me a useful diagnostic screen to look at when the inevitable problems arise as I progress.

Tying a BSOD handler to the BRK vector is a simple matter of loading the routine start address into the indirection pointers at $0316 and $0317; when the 6502 hits a BRK, it transfers program control through the hard-wired IRQ vector at $FFFE, which points to a ROM routine at $FF72 that figures-out if the interrupt is an IRQ or BRK. If it is a BRK, it then jumps to the routine pointed to by the address in $0316/$0317, which makes it easy to hook up a routine that will give us some meaningful information about what was going on when the BRK was hit. What I've ended-up with is something that does this:

I estimate it took a total of six hours to write, debug, optimise, and then optimise some more. The whole thing weighs-in at 377 bytes, of which around 30% is just formatting storage for the display - the code that actually extracts the debug data (Program Counter where the BRK occurred, register values at the time, stack contents) is tight and efficient, but constructing structures to pass to the ROM routine to display stuff on the screen is necessarily space-consuming. Nevertheless, my first working version occupied about 480 bytes, used 5 Zero-Page memory locations and didn't display any stack data; the final version is 22% smaller, uses just 3 ZP locations, and displays the top of the stack. I'm pleased with it. :)

(p.s. I know the VIC BSOD image above shows a bug - I slipped-up with a label and assigned a value to the wrong display location. It's fixed now, of course, but bonus points to anyone who can see what it was.)

Programming Framework

2010-05-12T20:32:00.021+01:00

The first step in creating the game is to set up the basics of the assembly process - I need a good set of VIC-20 memory layout tables, some DASM macros for generating pre-defined chunks of code, a subroutines library where I can keep common code, and of course the main game file itself.

To create the memory layout tables, I took a couple of the widely-available sets of documentation regarding the VIC-20 memory model and turned them into the appropriate 'ds' and 'equ' assembler mnemonics. In fact, I'd actually done this a couple of years ago when I first started writing the 6502 emulator, so that I could include annotated output in the debugging window to see what the processor was doing as it chewed through the VIC-20 ROM. So the main Blue Meanies game simply includes my 'VICMap' file, making it really easy to reference any memory location or ROM routine by name - here's a snippet from VICMap.6502:

         SEG.U vicmap_6522via2
         ORG $9120
V2PORTBO ds.b 1   ; VIA#2 Port B output register
V2PORTAO ds.b 1   ; VIA#2 Port A output register
V2PORTBD ds.b 1   ; VIA#2 Data direction register B
V2PORTAD ds.b 1   ; VIA#2 Data direction register A
V2T1LO1  ds.b 1   ; VIA#2 Timer 1, low byte latch
V2T1HI1  ds.b 1   ; VIA#2 Timer 1, high byte latch
V2T1LO2  ds.b 1   ; VIA#2 Timer 1, low byte counter
V2T1HI2  ds.b 1   ; VIA#2 Timer 1, high byte counter
V2T2LO1  ds.b 1   ; VIA#2 Timer 2, low byte latch
V2T2HI1  ds.b 1   ; VIA#2 Timer 2, high byte latch
V2SHIFT  ds.b 1   ; VIA#2 Shift register
V2AUX    ds.b 1   ; VIA#2 Auxiliary control register
V2PCR    ds.b 1   ; VIA#2 Peripheral control register
V2INTFLG ds.b 1   ; VIA#2 Interrupt flag register
V2INTENA ds.b 1   ; VIA#2 Interrupt enable register
V2PORTA2 ds.b 1   ; VIA#2 Port A output register

         SEG.U vicmap_basic_kernal
BASICVEC EQU $C000  ; Basic Restart Vectors [WORD]
CBMBASIC EQU $C004  ; 'CBMBASIC' [DATA]
STMDSP   EQU $C00C  ; BASIC Command Vectors [WORD]
FUNDSP   EQU $C052  ; BASIC Function Vectors [WORD]
OPTAB    EQU $C080  ; BASIC Operator Vectors [WORD]
RESLST   EQU $C09E  ; BASIC Command Keyword Table [DATA]

Next, there's at least one chunk of code that is essentially a pre-set block of data that I want to include in the game - the BASIC stub that incorporates the call to start the game itself. This block of code is really just a single line containing a 'SYS' command followed by the memory location of the start of the game - however, you can play some tricks with the BASIC interpreters' LIST command so that you can actually hide that SYS and replace it with something else. You do that by encoding some control bytes in the BASIC line structure so that when LIST tries to list the program, it actually executes the equivalent of some hidden escape characters and displays something else - which looks very cool, and also makes it a bit trickier for the casual user to hack the program.

My VICMacro.6502 file contains DASM macros for generating chunks of code like this - at the moment there's only one macro in there (BasicLine) which accepts a variety of parameters and builds the BASIC stub accordingly. This file is also included by the game - here's a snippet:

          ; Initialised segment for code generation
          SEG basicline_code
.LNDIGCNT EQU .SEGEND-.LNDIGITS  ; Count of digits in linenum

          ; Where should we generate the BASIC line?
          IF .VICMEM = 0 | .VICMEM = 3 | .VICMEM = 8
            IF .VICMEM = 0       ; Unexpanded VIC-20
              ORG $1000          ; Start of BASIC is at 4096
            ENDIF
            IF .VICMEM = 3       ; 3K expanded VIC-20
              ORG $0400          ; Start of BASIC is at 1024
            ENDIF
            IF .VICMEM = 8       ; 8K+ expanded VIC-20
              ORG $1200          ; Start of BASIC is at 4608
            ENDIF
          ELSE
            ECHO "BASICLINE: 'vicmem' parameter must be 0, 3 or 8"
            ERR
          ENDIF

          ; Check line number is valid
          IF .LINENUM LT 0 | .LINENUM GT 63999
            ECHO "BASICLINE: 'linenum' parameter must be 0-63999"
            ERR
          ENDIF

I also want a place to stash common or shared subroutines so that the main game file holds only core game-engine code - this is purely a stylistic preference, but I like to be able to look at subroutine code side-by-side with the calling code, and this helps me to do that. Here's a snippet of Subroutines.6502:

vidmode: lda RASTER   ; Get the raster line counter (upper 8 bits)
         cmp #1       ; Line 2? (updates every 2nd line)
         bne vidmode  ; Nope - keep looking

line268: lda RASTER   ; Found line 2, now poll counter again
         beq line0    ; Hit line 0 or 1 - missed 268, so this is NTSC
         cmp #134     ; Line 268? NTSC only has 261 lines, PAL has 321
         bne line268  ; If we hit 268 it's PAL, otherwise loop again

line0:   rts          ; .A holds video mode flag byte

And finally here's the very simple and unremarkable beginning to the game itself, containing little more than the include statements for the other files, an 'INCBIN' to pull in the original Blue Meanies UDG* data, and a little bit of test code to make sure everything is hanging together. From little acorns...

;-------------------------------------------------------------------------------
; Blue Meanies Revenge      Copyright (C) 2010 Jonners9
; A game for the VIC-20 (PAL/NTSC)

                    ; Assemble for 6502 CPU
                    processor 6502

                    ; Macros and map symbols
                    include VICMacro.6502
                    include VICMap.6502

                    ; Generate a BASIC line to invoke our code
                    basicline 0,2010,"","","Y"," BLUE MEANIES REVENGE                         (C) 2010  JONNERS9  "

                    ; Set memory symbols
                    setmemory 0                                    ; Unexpanded VIC

                    ; Let the games commence
                    jsr vidmode                                    ; Are we in PAL or NTSC mode?
                    sta wvidmode

                    ldx #$00
loop                txa
                    sta SCREEN,x
                    lda #$00
                    sta COLOUR,x
                    dex
                    bne loop

                    lda #$ff
                    sta CHARMEM
                    rts

                    ; Common subroutines
                    include Subroutines.6502

                    ; Working storage
wvidmode            ds.b 1

                    ; UDG binary data
                    ORG $1C00
udgdata             incbin "UDG Data.bin"

                    ; Endpoint marker byte
endpoint            dc.b $ff

Oh, you might be wondering why I'm using a '.6502' extension for my Assembler files, instead of the far more common '.asm'. The reason is that I have an existing file association for '.asm' which maps to Visual Studio and is used for the odd bit of x86 programming that I do from time to time. Since I want to work on Blue Meanies in Crimson Editor, I've set an association for it to open '.6502' files and use the appropriate syntax highlighting and command macro definitions. I guess if I ever publish the full sourcecode for the game, I'll rename everything to '.asm' so that it conforms to the usual naming convention.

* UDG - User Defined Graphics; simple bitmap data that the VIC-20 can be programmed to use as an alternate character set, and which in this case contains shapes representing the Meanies, explosions, laser turrets, the repair bot, etc.

The Tools of The Trade

2010-05-10T18:09:00.023+01:00

You might like to know what the development environment toolchain is these days for writing 6502 Assembly Language on a PC and then squirting it to the target machine. Broadly speaking, it's a text editor, a cross-assembler, some sort of linker or packager (if necessary) to wrap the object code up, and a transfer mechanism to physically push the product to the target. You may then conceivably need something on the target to execute the product - maybe a script or something like that. For VIC-20 development, my toolchain (download links on the right) breaks down as follows:

Text Editor

My preferred choice for a text editor is Crimson Editor, a nifty bit of freeware which is aimed at programmers who need something a bit slicker than Notepad, but without the massive overhead of a heavyweight IDE like Visual Studio (which, incidentally, I use for C# development). It supports multiple tabbed documents, macros, syntax highlighting, automatic backups, and a number of other little niceties which make it very comfortable to use. Here's an example screenshot from my desktop:

Cross-Assembler

There are two or three really good 6502 cross-assemblers out there, but my favourite is DASM - simply because I've been using it for years, know its' strengths and weaknesses, and understand how to make it do what I want. It's a multi-pass assembler with support for labels, macros, segments, and so on - and it generates a variety of object types for several CPU models. It's fast, and being commandline-driven means it slots into automated build scripts with no fuss.

Packager (Linker)

Since DASM largely handles combining object and binary code if you ask it to, there's no need for a separate link stage to bind the code together. However, you might find that you want to extend the build process to the point that it generates full-blown disk images which can be distributed as the Commodore equivalent of an install package (broadly speaking - I realise this not a true comparison). For that, you could use the 'c1541' utility that ships as part of the VICE suite, and which is designed to build a variety of Commodore disk image types.

Physical Transfer

Getting the finished software build to a real VIC-20 is not a simple matter, unless you have one of the various types of transfer hardware/software kits that exist - the fact that the target machine is pushing 30 years old means it has nothing in the way of the 'standard' interface connections that we take for granted today. So there are a few ways of effecting data transfer to and from the machine, but they all require some interface hardware to either be purchased from the specialists who make them, or to be built yourself if you're handy with a soldering-iron. Personally, though I have a VIC-20 in my collection, I just use the VICE emulation suite since it is sufficiently accurate that only extreme edge-conditions differ from the real hardware. The xVIC emulator in VICE looks like this:

References and Resources

Aside from the PC applications needed to make and test VIC-20 software, there are also a variety of online resources which are very handy for reference material regarding the target machine itself. Links to my favourites are on the right, with Denial and 6502.org being the two I hit the most frequently.

In The Beginning...

2010-05-10T10:21:00.003+01:00

...there was the word. And the word was Commodore VIC-20. Hmm, that's two words. Anyway, if you've never heard them before, follow this link to the Wikipedia article, which does a fair job of describing what the VIC-20 is. In summary, it was a popular microcomputer of the early '80s, laughably primitive by todays' standards (and in some respects even by the standards of the time) but with enough features, personality and expandability that it was a favourite amongst the boom generation.

One of the first things I did when I unwrapped my shiny new VIC on Christmas Day 1981 - along with a C2N Cassette Deck and an 8K Expansion RAM Cartridge - was load-up some programs from the tapes that came with it. One of these was a game called "Blue Meanies From Outer Space", a somewhat quirky Space Invaders variant requiring the player to master no less than 11 key controls to fire the laser turrets and walk the repair 'bot around - the objective being to defend a nuclear reactor from the Meanies as they suicidally threw themselves down the screen trying to impact their bodies into anything breakable. Check it out:

VIC-20 Boot Screen

Blue Meanies Title Screen

Blue Meanies Gameplay

Despite its' rudimentary gameplay and complex control system, I really enjoyed this game. Written in CBM BASIC V2 (the Commodore-licensed tweaked version of a standard Microsoft BASIC) it not only provided hours of entertainment, but also let the curious player have a look at the games' innards. I suspect this is why Commodore included it on the tape - it was pretty, interesting, and potentially educational. Win!

As far as I know, there's only ever been one remake of this game - the rather good Gaping Wolf version for the PC, which you can download from here and which looks like this:

I've been developing a 6502 emulator in C# for a couple of years now, and have been using the VIC-20 as the testbed to prove that the CPU emulation is good - essentially comparing the behavior of my emulated processor when dropped into a VIC memory model with that of the xVIC component of VICE, the excellent Commodore emulation suite. With that project drawing to a close, and having spent a lot of time replaying old VIC games when I should have been working on it, I thought it might be fun to remake Blue Meanies on the VIC itself, but in Assembler rather than BASIC, and with some up-to-date programming tricks and techniques to really make it shine on that old hardware.

This blog is where I'll post updates as the game progresses, alongside any other related items of interest. The intent is to first port the existing game to Assembler, and then rewrite it with a whole bunch of exciting bells and whistles - giving two basic playmodes, 'Classic' and 'Century 21'. The end result will be a game you can play either on the real hardware, if you have it, or in VICE.