New Game / Kernel Time

[Just Jeff]

Good Morning,

 

I found a game called Amado that I think can be done in a reasonable amount of time. 

 

 

 

Originally thinking that the map on the right could not be displayed in the same horizon as the (full, top two rows of) playfield, I'm giving it a shot anyway and I think It might work.  Here's what I have so far.  (Note, the map on the right will only occupy 32 scanlines when finished): 

 

Spiceware showed me how to run a kernel in RAM, so I'm doing that here.  The shortcomings I still have are:

1. PF2 is symmetrical, so only one black square is available in that area via the ball. Being able to cram 2 more store PF2s would allow unlimited playfield designs and free up the ball.

2. I still have not represented the player's current position in any way.

3. I've deliberately made the last column red so I'd have red in the map on the right.  This won't work in a game, so I'll need another store #RED to the background crammed in there.

 

I've got a few ideas involving using missiles display two squares at strategic locations but I dunno..  Sounds like that might be overly complicated.  I feel like my handling of line index / a,x,y, and a is already needlessly messy.  Any ideas?:

 

    jmp ZProutineRAM   ;3  67  because will be in RAM eventually

RAMKernel: SUBROUTINE       ;

ZProutineROM:       ; This all is loaded and runs in RAM
.loop
    sta WSYNC           ;3  0   ;This can eventually be removed
    lda #%00100100      ;2  2   ;Vertical grid lines
    sta PF1             ;3  5

 ; Register Update        Allows for one register update per scan line
    lda MapSec1,x       ;4  9   ;New pattern for either P0,P1,or PF
    ldy MapReg1,x       ;4  13  ;Specifies which register to update
    sta 0,y             ;5  18  ;Store the map pattern to that register.  Can this be reduced to 4 cycles somehow?
    ldy #BLUE           ;2  20  ;Restore the colors to the registers
    ldx #YELLOW         ;2  22
    lda #RED            ;2  24
    stx COLUBK          ;3  27  1st column  These stores are changed in the black horizontal bands above so that loads are not needed.
    sty.w COLUBK        ;3  30  2nd column  Needs to be @ cycle 31 or 32
    sta.w COLUBK        ;4  34  3rd column  4 cycle stores keep them in line with the beam but 2 cycle ops could be used in some spots instead.
    stx.w COLUBK        ;4  38  4th column  Perhaps missiles could replace one or two of these but I still have nothing displaying a cursor that 
    sta.w COLUBK        ;4  42  5th column  will show what spot the player is on
    sty.w COLUBK        ;4  46  6th column  
    stx.w COLUBK        ;4  50  7th column 
MapOperand:
    ldx #%00001111      ;2  52  Represents the red in the map via PF1.  This operand is updated in the above register update.
    sta COLUBK          ;3  55  I'm cheating here because I forced red in the last column.  This will not work during a game.
    stx PF1             ;3  58  This won't match P0 and P1 changes verticlly.
    dec RAMKernelCount  ;5  63  
    ldx RAMKernelCount  ;3  66
    bne .loop           ;3,2    69,68

    jmp JumpOutofRAM    ;3  71
ZPsize = *-ZProutineROM

Note:  I still have plenty of time left to set stuff up in the black horizontal bands.

[Just Jeff]

Well I spent the past few weeks working on it here and there, and did ok taking care of the above issues with an elaborate scheme using the ball, missiles, playfield changes and more.  It was pretty functional, but with limitations. Then when I  started on a routine to populate the play field with the different colors from RAM, I stumbled upon an illegal opcode that made all that work completely obsolete, used no kernel time, none of the objects, and allowed 100% of all possible configurations, 100% of the time.

Random generated playfield arrangement.

I knew my routine would generate an illegal opcode, but thought it would be harmless.  In reality, it blew up the kernel with a 6 cycle code.  So I tweaked my routine, to give me a different, hopefully harmless code ($87).  The kernel ran, but I was getting some odd, mustard colored squares in addition to the red, yellow, and blue.  Once I read up on $87 (SAX), I thought hey, I can use this for a cursor color (rearranging what a,x. and y were holding would give me gray as the fourth color.  It took me a few more minutes to realize that my red and blue only had one bit in common, and a minor change to one could give me a black cursor (note the red is darker now).  It took a few more minutes to realize, my playfield limitations could be completely resolved this way as well. 

 

So, now it works better and the ball and missiles are free for other possible uses (Note the red divider line that appears in the original game is now there).

[Just Jeff]

Here's a little more progress for this week..  I think the top bands came out nice and I've started the map (right of the red line) in earnest.  You can see one of the two limitations of the red when it has to interact with black in the 4th row.  I just can't update two players and playfield all on that same line when the (game's) playfield is present on the same horizon.  You see it again on lines 4 and 5 but I'll be able to get rid of that the same way I did in rows 1 and 2.  

 

Right now the ball is drawing the red line, so I'm going to switch that out with P1 missile so the ball (VDEL on) can mitigate some of it.  I believe line 8 will be the most restricted, with the playfield unusable- Only the ball will be available for that color.  In any case, these are just patterns, and they can simply be designed around the issue so it won't show.

 

As always..  if anyone knows of another way, I'd love to hear it.