Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    136,062

Problem Solving

Sign in to follow this  
cd-w

367 views

I am often struck by the similarity between the activities of game playing and game creation. In both cases, there is generally a long sequence of problems to be solved with an eventual goal in mind. These problems can have complex dependencies, and finding a good solution can make the difference between reaching the goal and starting over. As I have previously noted, I actually gain more enjoyment from creating games than I do from playing them. According to some friends of mine in the games industry, this is not uncommon. Many of them suck at playing games, though they are experts at creating them :)

 

post-2859-1098142765_thumb.jpg

 

With this in mind, I have made some further progress on my Juno First project. To get this far, I have solved a very long sequence of problems, many of which I didn't think would be possible. Nonetheless, there remain many more problems that will have to be addressed if the game is to be completed. As time progresses, these problems are getting harder to solve as available resources on the Atari are diminished. The main changes to the game this time are:

  1. The aliens now move around the screen. They all use the same basic movement pattern at the moment, but I think this looks very cool!
  2. The game has now been expanded to an 8K ROM which has thankfully relieved many of the memory pressures. I eventually adopted the scheme that supercat posted last time (thanks!). I'm not quite sure that it will work if the game starts in the wrong bank, so I would be greatful if someone could check the code (just before SEG BANK2).
  3. The explosion sprites have been altered and there is now a flame effect when the spaceship moves forward and backwards. Also, the spaceship will explode and then reappear if you collide with an alien. I am very grateful to Nathan for all of his help with this.

There are still a few remaining issues in the code. In particular, the spaceship will explode if an alien hits the flame. This is because I am using harware collision between the aliens and spaceship. I think I will need to move to a software region-checking approach, but this is going to take a lot of cycles. If anyone has an efficient techniqe for checking if a moving sprite enters a fixed region then I would be very grateful. The next step is to go through the code carefully to spot possible optimisations as there are now very few cycles remaining anywhere.

 

Chris

Sign in to follow this  


9 Comments


Recommended Comments

I'm not quite sure that it will work if the game starts in the wrong bank, so I would be greatful if someone could check the code (just before SEG BANK2).

I think it should also work if the game starts in the 1st bank. It will jump to $xff9, which is the hotspot for bank 2. There it will hit a brk instruction (in both banks) and therefore jump to Start in bank 2.

Share this comment


Link to comment
I'm not quite sure that it will work if the game starts in the wrong bank, so I would be greatful if someone could check the code (just before SEG BANK2).

I think it should also work if the game starts in the 1st bank. It will jump to $xff9, which is the hotspot for bank 2. There it will hit a brk instruction (in both banks) and therefore jump to Start in bank 2.

Normally, code in hotspots is a bad idea because the two basic types of bankswitching hardware (using edge-triggered or level-triggered logic) may react differently. However, the only exception is this case ($FFF9) where they should both react the same.

 

With the above method, you are tied to starting up in the last bank. If you want to start up in the first bank instead, you can do so with a BRK at $FFF7, which doesn't put code in a hotspot, but instead relies on the fact that BRK fetches a dummy operand at PC+1 before fetching the IRQ vector at $FFFE-$FFFF.

 

Bank 1:

 

FFF7:BRK

 

FFFC:

.word start

.word start

 

Bank 2:

 

FFF7:BRK

 

FFFC:

.word $FFF7

.word $FFF7

Share this comment


Link to comment

Thanks for the explanation. Starting in the last bank is not a problem here, but it is good to know that there is an alternative.

 

Thanks,

Chris

Share this comment


Link to comment
With the above method, you are tied to starting up in the last bank. If you want to start up in the first bank instead, you can do so with a BRK at $FFF7, which doesn't put code in a hotspot, but instead relies on the fact that BRK fetches a dummy operand at PC+1 before fetching the IRQ vector at $FFFE-$FFFF.

 

I hadn't thought of the $FFF7 approach, but it may be a tiny bit better than the $FFF9 approach. If both banks hold $00 at $FFF9, it's unlikely anything could go wrong, but it's theoretically possible that a bank-switch cart with an unusually-long delay combined with a slow EPROM that glitches the output on any address change could cause the $00 at $FFF9 to be misread. Not a factor with modern carts, but an inelegant risk anyway. Using $FFF7 avoids this issue because the byte fetched from $FFF8 is ignored.

 

As for starting in the first or second bank, I see no particular advantage to one over the other since I would expect one would simply use something like:

KERNELBANK = $1FF8
MAINBANK = $1FF9

in which case swapping those labels would switch banks.

Share this comment


Link to comment
I hadn't thought of the $FFF7 approach, but it may be a tiny bit better than the $FFF9 approach. If both banks hold $00 at $FFF9, it's unlikely anything could go wrong, but it's theoretically possible that a bank-switch cart with an unusually-long delay combined with a slow EPROM that glitches the output on any address change could cause the $00 at $FFF9 to be misread. Not a factor with modern carts, but an inelegant risk anyway. Using $FFF7 avoids this issue because the byte fetched from $FFF8 is ignored.

 

The only downside that I see with this approach is that it will only work with 8K carts, while your original approach can easily be adapted for F6 and F4 bankswitching?

 

Chris

Share this comment


Link to comment
I hadn't thought of the $FFF7 approach, but it may be a tiny bit better than the $FFF9 approach. If both banks hold $00 at $FFF9, it's unlikely anything could go wrong, but it's theoretically possible that a bank-switch cart with an unusually-long delay combined with a slow EPROM that glitches the output on any address change could cause the $00 at $FFF9 to be misread. Not a factor with modern carts, but an inelegant risk anyway. Using $FFF7 avoids this issue because the byte fetched from $FFF8 is ignored.

 

The only downside that I see with this approach is that it will only work with 8K carts, while your original approach can easily be adapted for F6 and F4 bankswitching?

 

Chris

I think that either method can be adapted for any size cart. For the FFF9 method, you just place the startup vectors and the BRK at FFF9, FFF9, or FFFB, respectively, for F8, F6 or F4. For the FFF7 method, you use FFF7, FFF5, or FFF3.

 

If used in this way, both have the obvious disadvantage of tying up the IRQ vector. However, I sort of remember a method Supercat came up on [stella] with by putting a JMP instead of a BRK at $FFF9/B and it would free up the IRQ vector.

Share this comment


Link to comment
If used in this way, both have the obvious disadvantage of tying up the IRQ vector. However, I sort of remember a method Supercat came up on [stella] with by putting a JMP instead of a BRK at $FFF9/B and it would free up the IRQ vector.

 

The IRQ vector would only be lost for use in the startup page. Other pages could use the BRK vector just fine (each page could have its own)

Share this comment


Link to comment

BTW, I noticed that in some cases the last blue line will jump when enemies pass by it. This usually happens when you have two or more enemies clustered together.

 

This is while leaving your ship stationary.

Share this comment


Link to comment
BTW, I noticed that in some cases the last blue line will jump when enemies pass by it. This usually happens when you have two or more enemies clustered together.

This is while leaving your ship stationary.

 

I was hoping that this would go unnoticed! In the bottom section of the screen the gridline is delayed when sprite repositioning needs to be done. There is a clever scheme at the top of the screen to avoid this, but I haven't managed to adapt this to the lower section yet.

 

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...