Planet Bob - Discussing a Kickman Kernel

[RSS Bot]

Hi there!

 

Trying to get back to some active programming once again, I spent some time thinking about a possible Kickman kernel.

 

This is the goal to achieve:

 

My first thought was that at best the kernel can get "Space Invaderish with more colors".

 

Still, a first calculation will bring it down to earth:

 

The most elegant standard approach for one sprite (disregarding any timings) would be like this:

 

CODE

LDA (colorPtr), Y

STA COLUPX

LDA (shapePtr), Y

STA GRPX

 

 

So, that is 6*(5+3+5+3) = 96 cycles, out of the 76 we have

 

Uihjah... most obviously, the "load" time for the values is taking much too long.

(The "write" time is pretty much a godgiven constant.)

 

Now, for reducing reducing the load time... let's check available (faster) adressing modes:

CODE

1. LDA #Immediate 2 cycles

2. LDA $ZP 3 cycles

3. LDA $ZP,X 4 cycles

4. LDA $ABS 4 cycles

5. LDA $ABS,X 4 cycles

6. LDA $ABS,Y 4 cycles

 

 

First thing to notice is that with indirect adressing the zeropage is just as slow as normal RAM. That'll rule out using 3. Also 5. & 6. are interchangable as required.

 

Second thing to notice is, that to use any of these modes, "selfmodifying code" in RAM is required to allow anything as flexible as the originally desired (),Y adressing.

 

Out of that conclusion we can rule out 2. & 4.

If you think about it, those would require to get the absolute/zp argument modified line-by-line, so we'd end up with a striped display, as we'd need an extra line to modify our RAM code for the next line.

 

So, now this'd pretty much leave us with those 2 options:

CODE

1. LDA #Immediate 2 cycles

2. LDA $ABS,X(y) 4 cycles

 

 

Let's see what tasks we actually got to do in our kernel:

 

- Update the shapes every line

- Update the colors every row (AHA! )

 

So... how about building our RAM kernel with bits like this:

 

CODE

LDA #color

STA COLUPX

LDA shape,X

STA GRPX

 

 

So, the color is constant per row and the shape gets updated every line.

 

Let's calculate again: 6*(2+3+4+3) = 72 cycles

 

Phew... it's a lot better... yet still not good enough...

All timing issues aside, it's missing at least one cycle just for looping the code.

 

At this point I can see 2 ways out:

• Do only 5 objects per row
  
• At the cost of flexibility, have a set of rules to simplify the display (e.g. having the first GRP0 and GRP1 sprite always sharing the same shape (not color!) would save 4 cycles for one load.)
  

BTW: There's also numerous other issues complicating a port. I think the main problem is something completely different: Aspect Ratio. On a TV we have 4:3, while it seems the Arcade has it 2:3 or worse for the main game area. I fear on the VCS we simply don't have enough "height" required for this game.

 

BTW²: Need to check out the C64 version...

 

Greetings,

Manuel

 

http://www.atariage.com/forums/index.php?a...&showentry=1598