Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    136,046

Two's Complement

Sign in to follow this  
cd-w

529 views

The Atari 2600 is a difficult machine to program, but the 6502 assembly language in which this programming is done is relatively easy to understand. Nonetheless, there are certain features of this language that I still don't completely understand. One of these is the indexed indirect mode that I taked about in a previous entry, but this is not a particularly useful feature. The other issue for me is two's complement binary arithmetic which I view as a necessary evil. Two's complement is not specific to the 6502, but this is the only context that I regularly come in direct contact with it. I undertand the principles behind the notation, but something always seems to go wrong when I attempt to put it into practice.

 

Two's complement notation allows you to represent numbers in the range 0->255 or -128 to +127. The numbers 0->127 are represented the same way in both schemes. Similarly, if you only need to deal with positive numbers then there is no real difficulty. However, negative numbers get a bit more tricky! In this case, the upper bit of the number represents the sign, e.g. 0xxxxxxx is a positive number and 1xxxxxxx is a negative number. You might think that -1 would simply be represented as 10000001, but this is not how things are done as there would be two zero values (+0 and -0). Instead, to convert a number into its negation you invert the bits and add 1, so -1 becomes 11111111, which is 255 in the normal way. This scheme is very clever as it does not require any extra hardware to cope with negative numbers, but can be a pain from a programming perspective.

 

The problem that I have with two's complement is that you have to be very aware of the ranges of your numbers or nasty things will happen, e.g. 130-5 can give you unexpected results if you are not careful! Also, if you try to mix numbers of both kinds, or do signed comparisons on unsigned numbers then you are likely to end up with a headache. In the past, I have usually avoided these problems by sticking to positive numbers, but in my Juno First project the complexities of two's complement have been unavoidable. In particular, the speed of the spaceship is represented as a number from -16->16, and the coordinates of the aliens are represented as numbers from 0->255 which wrap around. I have spent the last week trying to get the aliens to move forward and backwards properly. This has been significantly complicated by the fact that the aliens move at different speeds depending on where they are on the screen, i.e. aliens in the distance move slower than those in the foreground.

 

The results of my efforts are attached to this message. The aliens are stationary (for now), but move forward and backward according to the movement of the spaceship. In Juno First, the top of the screen acts as a kind of scanner which shows the aliens far in the distance. If you move backwards, then these aliens appear from behind, i.e. the play area wraps around. The movement of the aliens is slighly jerky, but I hope that the illusion of perspective is there. Let me know if you think this looks OK, or if this could be done in a better way, also let me know if the flicker is acceptable (using the phosphor option on Z26 or stella helps a lot).

 

 

 

The code for the alien movement is not yet complete. In particular, if you change direction some of the sprites will disappear for a bit until the flickersort code moves them back into the right order. I haven't yet figured out completely how to avoid this, but I think that it can be addressed using a circular buffer. I am still using a sprite index in this version, but I have implemented Manuel's cool suggestion, where the index values are the same as their positions within the index. Thanks for all the other suggestions - I still haven't completely decided on the final solution. However, the flickersort and index creation are now done by the same code which saves a lot of cycles. I realised that the values in the index were precisely those that were not swapped during the flicker sort routine :idea:

 

The game is still coming along nicely, but I really could use some extra memory! There are now just four main parts of that have to be done in the core before the game will become playable:

  1. Finish the sprite sorting/disappearing issue, so that the sprites are always drawn in the correct order.
  2. Implement collision detection, so that the aliens can be destroyed.
  3. Implement procedural movements for the aliens, so that each type of alien moves in a different way.
  4. Figure out how to spawn new aliens, so that they appear in the correct place at the right time.

Chris

 

 

 

:!: EDIT:

 

After various comments yesterday about jerky sprites I went back and looked at the alien movement code. A bit of searching revealed an implicit assumption that the sprite positions were in a strictly increasing order, though this is not always the case when using flickersort. I have now removed this assumption and posted the new version below. Unfortunately this change is rather computationally expensive, so there are less sprites on the screen. However, I hope that this now removes most of the jerkiness from the sprite movements? If so, then I will work on optimising this solution.

 

 

Sign in to follow this  


15 Comments


Recommended Comments

The movement of the aliens is slighly jerky, but I hope that the illusion of perspective is there.

A little too jerky, IMO - it looks odd that the aliens don't move smoothly with the gridlines. Maybe won't be as noticeable when the aliens are also moving relative to the gridlines. :thumbsup:

In particular, if you change direction some of the sprites will disappear for a bit until the flickersort code moves them back into the right order.

8)

It's possible to get the ship in certain positions where the aliens disappear and don't reappear! I stop the ship and the only things on screen are the particles and the very top of one alien at the bottom of the screen - all other aliens are gone, and don't come back until I start moving again. Kind of odd.

 

On the other hand, the flicker looks fine. The test will be on real hardware with the aliens all moving under their own power, though. 8)

Share this comment


Link to comment

A little too jerky, IMO - it looks odd that the aliens don't move smoothly with the gridlines. Maybe won't be as noticeable when the aliens are also moving relative to the gridlines. :thumbsup:

 

Yes, I was worried about this. The aliens should move with the gridlines (they are using the same calculations), but I must have messed up somewhere. It could be that the coordinate for the bottom of the sprite should be used, rather than the one at the top. I'm not sure what is causing the sprite disappearing problem - the code is clearly rather buggy at the moment 8)

 

Chris

Share this comment


Link to comment

Hi there!

 

From the old source code:

; Alien Sprites are 8 Pixels High (+ 2 Pixel Gap ???)
sbc #8+2

 

So are you absolutely certain that you only loose 2 scanlines inbetween 2 sprites? The Gap should match the the minimum number of lines you're needing inbetween, they sorta add up to a virtual height.

 

In Star Fire and C7 I lose 6 scanlines each, so adding just 2 seems a bit low to me.

Share this comment


Link to comment

So are you absolutely certain that you only loose 2 scanlines inbetween 2 sprites? The Gap should match the the minimum number of lines you're needing inbetween, they sorta add up to a virtual height.

 

Well spotted - I had forgotten about this assumption. Unfortunately this doesn't account for all of the issues in the current code though :thumbsup:

 

Tried with my Krok Cart and the flicker looks fine.

 

Thanks - this is good to know. Also, I'm glad that it actually runs on real hardware as I hadn't tested this yet.

 

Chris

Share this comment


Link to comment

A little too jerky, IMO - it looks odd that the aliens don't move smoothly with the gridlines. Maybe won't be as noticeable when the aliens are also moving relative to the gridlines. :thumbsup:

Yes, I was worried about this. The aliens should move with the gridlines (they are using the same calculations), but I must have messed up somewhere. It could be that the coordinate for the bottom of the sprite should be used, rather than the one at the top. I'm not sure what is causing the sprite disappearing problem - the code is clearly rather buggy at the moment 8)

 

OK, I have attached another version (juno5b.bin) which uses the bottom of the sprite (rather than the top) to determine the movement relative to the gridlines. Let me know if you think this is any smoother? This one still has the bugs when changing directions, so it is best just to move in one direction only.

 

Chris

Share this comment


Link to comment

It seems smoother to me.

 

The player's fire rate is a lot slower now than it was a couple of WIPs ago... is that just temporary?

Share this comment


Link to comment

It seems smoother to me.

The player's fire rate is a lot slower now than it was a couple of WIPs ago... is that just temporary?

 

I have just uploaded a new version (juno6.bin) which fixes a bug in the movement of the aliens and increases the speed of the laser beam. Let me know if this looks better to you? BTW, I like your new avatar :thumbsup:

 

It's possible to get the ship in certain positions where the aliens disappear and don't reappear! I stop the ship and the only things on screen are the particles and the very top of one alien at the bottom of the screen - all other aliens are gone, and don't come back until I start moving again. Kind of odd.

 

Thanks - this diagnosis revealed an incorrect assumption in my alien movement code. Let me know if the latest version looks better to you?

 

Thanks,

Chris

Share this comment


Link to comment

The movement does look better; smoother. Still a little jerky.

 

I am still able to find positions where, with my ship stopped, a bunch of the aliens disappear and do not reappear. :thumbsup:

Share this comment


Link to comment

The movement does look better; smoother. Still a little jerky.

I am still able to find positions where, with my ship stopped, a bunch of the aliens disappear and do not reappear. :thumbsup:

 

Darn - this seems to happen whenever a sprite wraps around from the top to the bottom of the screen 8) Oh well, back to the pen and paper again ...

 

Chris

Share this comment


Link to comment

Hmm, twos complement isn't hard once you realize that the numbers represent what you want them to.

 

Example: Let's say you have a sprite which has a X Position of 0-152, i.e. full side to side for 8 pixels. Every frame you move it -8 to +8 pixels. That would be done in 6502 as:

 

LDA XPOS

CLC

ADC XVEL

STA XPOS

 

Yes, you've just added a signed value to an unsigned value. The numbers mean what you want them to mean. The 6502 doesn't care whether the number is signed or unsigned, it does the same operation on everything.

 

Now, there's a problem, of course. How do you handle overflows? Okay, same code, but we'll add a check for overflows.

 

LDA XPOS

CLC

ADC XVEL

CMP #153

BCC 1$

handle overflow here

1$

STA XPOS

 

But, you say. That only handles the overflow, what about the underflow? Well, remember that -1 is the same bit pattern as 255, so the same comparison and branch handles both. (Another way would be to add a BCS after the ADC to handle the underflow.) Oh, and you can use BIT XPOS to check the sign bit of the original value.

 

Note: fractional (or any other multi-byte) arithmatic is a little trickier, but that's because you have to "sign extend" - i.e. use the most significant bit of the least significant byte to determine whether you need to use 0 or -1 for the most significant byte.

Share this comment


Link to comment

I have just uploaded a new version (juno6.bin) which fixes a bug in the movement of the aliens and increases the speed of the laser beam. Let me know if this looks better to you?

The laser's much better.

 

The aliens seem to "pop" from their smallest size to the next larger one. I think it'd look smoother if they stayed small until they got on top of the first line or two of the grid, instead of making the transition over them (if possible).

 

Also, it looks like the HMOVE bars are gone. :evil:

 

BTW, I like your new avatar ;)

Thanks. But it's not just an avatar, it's also a blog entry! (Well, it will be.) ;)

Share this comment


Link to comment

The laser's much better.

The aliens seem to "pop" from their smallest size to the next larger one. I think it'd look smoother if they stayed small until they got on top of the first line or two of the grid, instead of making the transition over them (if possible).

Also, it looks like the HMOVE bars are gone. :evil:

 

Thanks for the comments - I think it should be possible to move the small aliens a bit further up the screen and I will attempt this in the next version. The HMOVE bars are still there, but they don't seem to be too much of a problem when the aliens are moving. Based on this I have decided not to bother attempting to hide them further. The last couple of versions were rather buggy, so I am going to wait a bit longer before posting the next version ;) My next target is to make the game playable so that the actual game mechanics can be properly tested and refined.

 

Chris

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...