The Southsider

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.

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

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

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.

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

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)

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.

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