Check sprite collisions and MSB range

In this section you are going to learn how to write your own kickstart system call, break down machine language games code, write your own sprite to background collisions, AND/EOR and bits are used, check for MSB of sprite at X position, create sprite boundary movement, and some tips with raster routine effects.

iggy returned to the project again. The development tool will be CBM Prg Studio. He wanted to start off talking about how the kickstart code works that loads in the program code into the VICE C64 emulator. It regenerates a SYS call.

This code is used to generate a SYS call automatically to the program on every start up of the VICE C64 emulator.  To set this up, click on the Tools menu and select Generate SYS() Call. CBM Prg Studio will open a window that says Start Address. In the ‘Enter Start Address (hex) field, type in the starting address where you want to generate the call from. By default it will be set to $0801. The options below for Decorated and Plain won’t be used in this project. After you click the OK button, it will create the bytes you see below.

Finishing out the SYS Generate bytes, the next byte is sequence is $00. This represents the end of the Basic line. Then there are two padded zeros. They are represented as a word (read as one entity).  In all simplicity it generates the code above (as seen by the CBM Prg Studio compiler or Basic compiler … if you are using that environment). Keep in mind that the 10 is needed to create line 10 for the Basic code. If you have ever loaded in a game file using LOAD “*”, 8 you will likely see similar code. Then all you have to do is type the RUN command to execute the game.

• $0801 10 SYS (2064)

Spelunky game code Disassembly

It is also important to mention that games contain the kickstart code within, which is why again you will see the SYS code when you execute the LOAD “*”, 8 command when running a software title. Siggy started dissembling the game Spelunky to learn from it. Earlier we agreed to create a Spelunky clone for the project. He used a tool called Regenerator so he could create his own embedded comments to understand the code better. I have attached some code samples here in a screenshot for observation.  To create a comment, just right click on a line and select the option for Insert/Edit Side Comment. There are more things you can do like changing lines to reflect .TEXT, .BYTE, etc, but we won’t go into detail with that here.

Spelunker Character Set Screens

Siggy discovered as he starting looking at the Spelunker code that there are three screens running. He was able to arrive at this by taking a VICE snapshot and loading the code into Infiltrator.  This could be identified by utilizing the Charsets and Screen dialogue box. He found out that the game is using Bank 3 and the screen memory at $cc00. He then showed where the title screen existed at using the tool. It uses a character set for the title screen. It also appears to be utilizing another screen found at $f800.

Next he loaded up Infiltrator’s Sprite Viewer to show that the game’s sprites were loaded in at $e000. Then he obtained a running VICE Snapshot and opened it in Infiltrator. Returning back to the Charsets and Screens viewer, he showed where the in-game graphics resided at memory location $f800. I have provided another screenshot so you can get a glimpse of what it looks like.  He found it interesting the the elevator that is used to navigation up and down through the screens was not actually a sprite, but instead made up of characters.

Clicking in the memory Screen area in Infiltrator, Siggy verified that memory locations $fc00 – $ffe7 was another screen for the game.  He says this is using something known as “double buffering”.  Further evaluation showed another part of the title screen contained within registers $cc00 – $cfe7. “This is the third screen”, he stated. It uses a raster interrupt for the character set graphics. There is a multi-color bottom control panel.

Then he clicked in the Charset area within the Charsets and Screen tool and showed where another part of the starting game screen began at memory location $c800. This is the part where is shows the message ‘Now entering the Elevator’ before the game begins. He has the character set ordered in such a way that when he has a character set displaying for the bottom panel, the characters for the top one is what reflects at the top (that shows the mini animation). Yet when the ‘entering the Elevator’ screen is shown, the characters around it are darkened out.

He went through the Spelunker character sets, but had difficulty ripping them. He showed however, that he had captured the character set and demonstrated this with the Character Editor in CBM Prg Studio. He stated that the programmers did not use the whole character set. He also demonstrated where the game used another character set to make up the title screen. Not bad for a game written in 1984.

After this, he loaded up the Sprite Editor to show the sprites taken from the snapshots. There are 64 sprites in the game. He credited that the animation was alright, but the sprites were very small compared to other games for the time. Siggy thinks this may have better detection for background collisions. The collision code for our remake of Spelunker is centered around Endurian’s code samples. So we can improve this by making the sprites much larger to add appeal to the revision.

Spelunker Clone collision analysis

For our game, Siggy said he extrapolated further with his own trim algorithmn and still kept some of Endurian’s collision detection intact. It expands it out depending on which way the game character is walking. He ‘trimmed’ it so it would be pixel perfect on the sides of the sprites. He chimmed in though that he hasn’t implemented this for Y variation since there are some ‘tricky parts’ to the logic. He loaded up the framework created to show this on exhibit. You can see this verified when the sprite bumps up against a center part of a character occupying that area.  He mentioned that if you ‘really fooled around the sprite could sink into the character in the center’, but there is no point in which it would be critical. A gamer would really have to work at it and that’s why he plans to implement a check to fix the trip in the top and bottom parts of any type of dilapidation.

Examining the Sprite Code

Siggy’s wanted to provide an explanation of how he implemented the sprite collision for our trial game. He started at the label called MoveSpriteLeft.  This deals with the X flag. It checks if the sprite has reached the 0 mark at 255 at close to the middle of the screen and then it sets the X flag. He says “if we move we increment a delta value”.  So every pixel is move the delta value is increased. When the delta reaches 7, it is reset back to zero. This checks for the pixels in character from 0 to 7. It tells that the space within the character is roughly around the center of the sprite. He claims that calculating this every frame could be done, but it seems like a lot of overhead. So instead he set the sprite in the label SpriteToCharPos. The next paragraph will explain that further.

In the label SpriteToCharPos here he sets the sprite to a character position. This is identified as PARAM 1 being equal to the X position and PARAM 2 being  equal to the Y position. It puts the sprite at a delta of 0, 0 to that character. This is to ensure that the delta value is always correct without any reason to calculate them. Every time the character moves, it is updated. If it moves right, it will be incremented and left decrements the value.  Up and down will increment and decrement as well.

The table example below shows how the SpriteToCharPos works when seen at the binary level. Just keep in mind that BIT_TABLE,x is searching for a X value that is passed, which represents the current Sprite (from 0-7) you want to detect for a collision against a tile on the screen. I’ll admit it took some deep diving to finally grasp what was going on here, and I’m still on the journey of getting better with utilizing the fantastic logical mnemonics, AND / ORA and EOR.

How the BIT_TABLE works

He then reviewed the next section of code to provide emphasis on the extended X flag. The extended X flag is stored in one byte, one bit for every single sprite, and its important to get that right. He stated “For this one sprite I’ve got to change 1 bit”. So in lda BIT_TABLE, x the bit is looked up that has to change. He mentioned that in the BIT_TABLE when he gives it the sprite number he then knows the bit he has to change. This is actually Boolean math. Parts of the code is listed here again for clarity

AND and EOR Explained

In the basic boolean operations are AND or EOR (exclusive or). The AND is used to make a mask to weed bits out. So if the bit found in eor #$ff is a one (00000001). Then the code will spit out a 1 if its an AND. With the EOR if either one is a 1, Siggy stated it will ‘spit out a 1’. The AND command can be used to replace bits (masking values out). He provided an example “I want to replace bit 4” then I ‘AND’ everything turned on except bit 4. Everything else will retain its value and bit ‘4’ will then be ‘0’. Then ‘EOR’ can be used to ‘or’ that bit in there. Then it must be saved. Exclusive (EOR) or flips every bit that its set for.

To go into an example, he stated, with the eor #$ff (binary – 11111111), he is taking the value of the bit table and flipping it. For instance if he is using sprite 1 it will return the value of ‘1’. After this every bit is turned on, except 1. Then he uses (and SPRITE_POS_X_EXTEND) as a ‘mask’ on the sprite x position. He is using exclusive EOR to create the mask. The AND is used to get the data out that has to remain intact and then it is stored (sta SPRITE_POS_X_EXTEND). All this does is  store the result back and just erased that sprite’s bit, so it’s zero. It’s about quickly erasing that bit.

So now that we can see the individual bits for Sprites 0-7 (representing our table lookup for BIT_TABLE, x, we will next use eor #$ff to reverse all the binary bits in the accumulator. Therefore I have created another table so you can see this.

In the next snippet of code we  load the parameter of 1 (PARAM1). This represents the sprite’s x position. Then it is stored in a variable (SPRITE_CHAR_POS_X). The next sequence will compare it to 30. The value of 30 is the point when 255 clocks over.  The next part is branching to noExtendedX if the value is less then 30. BCC is just another way of using the less than operator.  There is a great chart that Siggy pulled up for further illustration. I have attached the screenshot here.  This is an overview of how the computer manages variables flags in the system. He told us how BCC works. He stated, “Zero if it is carried (an addition goes to the carry) and true if it is not.” This sets a flag the carry is true (cleared), otherwise it is set. So it BCC is less than 30 then the flag is set and the operation is carried out.  So bcc @noExtendedX is executed then we don’t need to set the extended bit.  The code is listed here for the comparison again as a refresher.

For the next line we AND SPRITE_POS_X_EXTEND to mask out the sprite’s X extended bit so this allows the sprite to flip across the MSB area (when the sprite has reached position 255), and then the high bit is set to allow uninterrupted movement across the screen. Here is the table that does that masking, and then finally the result is saved in VIC_SPRITE_X_EXTEND (memory location 53264).

Notice how all the logical math has resulted for everything showing as “00000001”. This will allow the SPRITE_POS_X_EXTEND (53264) to be set when the sprite crosses over into the high bit, which allows the sprite to continue across the screen. It also later checks in the code for the reverse direction, but I’ll let you do that binary math on that yourself to verify the results!

I have included the document file (below) I used when calculating the binary bits, which shows all the binary math using the eor #$ff and AND SPRITE_POS_X_EXTEND. You can look at this to get an overview of how all the tables fit together.

Assuming that you are rather a seasoned assembly language developer, and not new to this, you should be able to see the logic clearly.

PDF View Below

BIT_TABLE Math Results

Check MSB of Sprite X

Moving down to the next section of code we are loading our bit from the BIT_TABLE. Then we ‘or’  the sprite extended to it. Finally it is stored in a variable and in the VIC X extend register ($d010 – 53264).  So once again that bit is (ora) or’ed in. We are ora’ing in the bit we masked out and storing it. This code determines if the sprite has crossed the boundary or not.

Calculate center of sprite X

The next piece of code shows adc #24 – SPRITE_DELTA_OFFSET, X. The adc stands for ‘add with carry’ and is simply the processor doing basic addition. So here we are taking the value of 24 and subtracting it from the variable SPRITE_DELTA_OFFSET_X. This value gets you to the center of the sprite.  Looking at the website dustlayer.com, Siggy confirmed that it is the difference between sprite 0 which is off screen and the sprite that is visible on the screen. Darren realized that is where the sprite can disappear behind the screen border.  This equates to counting the pixels between the border edge and onto the screen where the sprite can be seen. Siggy believed that if you had the sprite at position 0, then that is the exact width of the border to the screen edge. It makes sense because a sprite is 24 pixels across at the X location.

Finally we are loading the accumulator with the immediate value of 0 (lda #0).  This clears out the variable for the x and y delta values (sta SPRITE_POS_X_DELTA, x) and sets the sprite position to 0 (sta SPRITE_POS_Y_DELTA, x). This is because we are flush with the screen coordinates.

Check if sprite can move left

The next thing involved is trimming the sprite.  Evaluating the code for CanMoveLeft we start with lda SPRITE_CHAR_POS_X to do a border test. If we can’t move left then we go to trimLeft (bne @trimLeft). This is because the character X is at 0 and the delta is also at zero. Siggy stated this is because we are ‘flush up against character X 0.  We are trying to move left so it decrements. This is because we are against the edge of the screen and therefore we will be stopped.

Trimming the Sprite’s Delta

The code below this is called trimLeft. The first part that shows lda SPRITE_POS_X_DELTA, x contains a delta value to tell the program if we are flush. This is the part he spoke about involving ‘trimming the edges around the sprite’.  The sprite can be wider then then we need to trim that delta. The next part shows adc SPRITE_DELTA_TRIM_X, x , which is used to add the delta trim for the X. Next the code sample masks for bits 0,1 and 2 using and #%111. The 111 in binary is equal to 7 (00000111). Every bit within 0-7 will be masked back. If it goes to bit 8 in binary, then bit 3 is set (=1) – (00001000). This is indicated by the 1 in the binary example seen here. If it goes to 8 and it is and ‘ed out, a zero is returned. If it goes to 9 and it executes and #%111 then it gives back a 1. It keeps the value between 0-7 and doesn’t allow for overflow.

Siggy exemplified further with this example. He stated, “Let’s suppose I got a value of 8” (binary = 1000).  What AND does is switches the bits on if a one is found in the comparison. However, if they are different then it returns a ‘0’ instead. Also keep in mind that if there are two 1’s, then the result will also return a 1. The result again (and #%111) adds the trim and adjusts the number between 0-7.

The next part shows beq @checkLeft. This is where they are becoming flush. If the delta evaluated in adc SPRITE_DELTA_TRIM_X, x is zero, then a branch is triggered for beq @checkLeft. If the value is anything except 0, a collision check is not done. This is because we are moving in the character. We are not at the character’s edge, and therefore don’t need to see what the character is yet.

However, if we are there and we are flush and the delta is 0 (along the X),  then we are flush up against the next character. Now we will need to do some checks.

Checking the Sprite’s Y Delta

Siggy mentioned that the first check we have to do is to check the Y delta. This is because if the Y delta is not zero, then we are not flush on the Y axis. That will affect the amount of characters we need to check on the left hand size. Yet if we are flush at x, y then we need to check the characters where the sprite’s foot is on a cross, one to the left of that, and we need to check one character above that position to cover the middle of our sprite. If we are not flush with delta, we are traveling up between characters upwards.  So we need to evaluate a check on 3 characters to make sure the entire sprite is covered.

Checking the Sprite’s Left Movement

Siggy says “the first thing we want to check is the sprite’s delta Y position”. If we are not on zero, we are not flush. This means that the sprite is spanning 3 characters. So we have to check to the left for 3 different characters. That’s what the delta is all about initially.

Examining the first line here which shows lda SPRITE_POS_Y_DELTA, x he confirmed that if the Y Delta is 0, we only need to check 2 characters. This is because we are flush with the Y axis with the character map. Yet if we are not flush, we have to check for 3. The line beq @checkLeft2 states if we are equal then jump to the label checkLeft2. If we have to check for 3 every time using calculations then cycles are wasted. Apart from the sprite direction they are moving in it is very identical to the Move Right routine.

The line that shows ldy SPRITE_CHAR_POS_Y, x is loading the sprite character’s Y position. The x here represents the sprite number. So it looks up SPRITE_CHAR_POS_Y plus the ‘x’. We use that to then look up the screen line offset table (lda SCREEN_LINE_OFFSET_TABLE_LO, y). Literally you give it the line you are on and it goes to the exact character we need in screen memory.

The screen memory is looked up in the table called SCREEN_LINE_OFFSET_TABLE_LO and SCREEN_LINE_OFFSET_TABLE_HI. The accumulator is then loaded with lda SCREEN_LINE_OFFSET_TABLE_LO, y the screen line offset and ‘y’ is holding the line. So Siggy utilized an example, “If the screen character position is 12, we want the 12th line down.” The value is inserted into y (y=12). Then the SCREEN_LINE_OFFSET_TABLE is looked up. It then stores the low and high bytes using the ZERO_PAGE_POINTER variable. The ZEROPAGE_POINTER is considered a word. After this the ZERO_PAGE_POINTER now holds the address to the line we are on.

Then we see the line for SPRITE_CHAR_POS_X, x. The carry flag is cleared and then we add 39 to it (adc #39).  It goes across one and then down one. The ’39’ is one character to the left of us and one character down.

If the results came up as ’40’ then it would be directly beneath us. This is because 40 is the length of a line in characters.  It is one character down and one character to the left. Siggy stated “this is in straight character blocks”. The ’39’ represents one block down and one to the left. Then the value is stored in Y using tay. Next the zero page pointer is used to obtain the value at the address. It goes to that actual address offset by y in lda (ZEROPAGE_POINTER_1), y.

The next routine executed is jsr TestBlocking. It compares to see if it is 128. If it is greater then we are blocking. Likewise if it is less than 128, we are not blocking.  The values between 128 – 255 identify it is blocking. If its not, the code lda #0 returns a zero and exits the subroutine using rts. If it is not blocked left then it returned a 1 it branches to the line @blockedLeft showing bne @blockedLeft.

In the subroutine called CanMoveRight, it takes a slightly different approach to using trim. It checks it on the other side. It is adding instead of subtracting.

Check Sprite Moving Up

Siggy mentioned here that “Up and down is the same thing only it works for a different axis. It’s checking the Y to see if we have to check it all. Its checking the X to see if we are flush.” However, he assured us that they are “all essentially the same regardless.”

The Raster Interrupt Simplified

The concept of the raster routine is providing a high/low byte address to the line of the first interrupt contained in the file called raster.asm. The code that contains the starting line is at lda $CA sta $d012 in the IrqTopScreen routine. Also Siggy stated it is best to keep the code routine short or bad things can happen. You can watch this in the video skipping to 1:13:35.