Kernel Problem

[Just Jeff]

Good Afternoon!

 

I'm trying to add some PF2 to a kernal but ran into an issue. I'm using RAM to hold variable play field graphics. (these will be like dots in Pacman that can be picked up) My DoDraw is working- sort of, but its spilling over into other RAM and a collision register I think. Right now it should be showing 8 lines of LFSR numbers. But its showing a lot more than that. I'm pretty weak on indirect addressing so I suspect I did something wrong there. I have 5 bands in the kernel and this is ArenaLoop3 located at line 535.Kernal5d.asm

 

If anyone can help, I'd sure appreciate it! .asm attached.

 

Thanks!

 

[Thomas Jentzsch]

Hm, ArenaLoop3 loops down from 80 to 20, that's 60 lines.

 

BTW: PF2 is not cleared afterwards.

Edited June 26, 2016 by Thomas Jentzsch

[Just Jeff]

Is 60 bad? According to Stella, my fps is only off a little bit right now. Thanks for mentioning the clearing. I forgot about that.

[Thomas Jentzsch]

Above you said you wanted 8 lines, but you display 60.

[Just Jeff]

OK.. I'm looking for 8 lines of dots. In other words there will be 15 or 20 dots in a pile located somewhere in the the play field- near the top, near the bottom, or near the middle. They will appear in random locations.

[Thomas Jentzsch]

Then your kernels seem to make no sense to me. Maybe it would help if you mockup some screenshots.

[Just Jeff]

Bands 1,2,4, and 5 aren't doing anything right now and are just duplicates. Line 1 of band 3 is supposed to display dots something like this:

 

[Just Jeff]

Hmm...

 

I think I've found at least part of the problem by stepping through the debug by scan line. This RAM doesn't reach zero when its supposed to stop putting in the graphics.

 

PrizeDraw: ds 1 ; track line where prizes will start to draw $96

[Just Jeff]

OK.. I've gotten RAM $96 to pass through zero by sticking in some immediate addressing here and there. But its only displaying one dot now- its a stable dot at least! The other stuff was skipping frames for some reason.

 

 

Now to figure out why its displaying one dot instead of RAM $8D through $95. .asm attached in case anyone cares to give it a shot.

Kernal5f.asm

Edited July 2, 2016 by BNE Jeff

[Omegamatrix]

Take a closer look at what you are doing here:

    ;   = ARENA_HEIGHT + PrizeHeight - PrizeY
        lda #50 ;#(ARENA_HEIGHT + PrizeHeight)

[Just Jeff]

Yeah that was my attempt to just bypass stuff and put a known value in so the dots would appear more or less in the middle of the screen vertically. I tinkered with it for a while until I came up with:

 

; = ARENA_HEIGHT + PrizeHeight - PrizeY
lda #(110) ;#(ARENA_HEIGHT + PrizeHeight)
sec
sbc PrizeY
sta PrizeDraw

 

But nothing worked. No progress in two weeks. Time to throw this one on the heap with the rest of them I think.

 

Thank you for trying to help though..

[Just Jeff]

So I tossed it and started over. I put the graphics in ROM instead of RAM, and copied the technique for displaying the players verbatim. I even duplicated the player graphics for the playfield graphics. I figured I'll start there and then try to switch to RAM and do the other things later. Its working better, except for 2 things For some reason the Y axis is different than the players so it started low and got cut off- so I put in different values until it showed up more in the center. (I just realized this is that same line that Omegamatrix told me to look at before- still having a problem there I guess.) The line works for the players so I don't know why its such a problem with the playfield. Also, as you can see, the bottom of the playfield player gets cut off and stuck on his head.

 

 

Edited July 3, 2016 by BNE Jeff

[+SpiceWare]

For some reason the Y axis is different than the players so it started low and got cut off

If you're basing it on Collect's Kernel then this bit from step 7 is pertinent:

The first change is we're using X as an index into the playfield graphic data. We're changing X every fourth time thru the 2LK, so each byte of playfield data will be used over 8 scanlines. This saves a bit of ROM.

So the Y values relate this way:

• playfield_y = player_y / 8
• player_y = playfield_y * 8

[Just Jeff]

Hi...

 

Close.. I'm using Collect Mini so that isn't in there. I did manage to figure it out though.. This program has 5 separate bands in the kernal which are mostly identical for now. This issue is in band (#3) where I added a DoDraw routine for the playfield. So this only appears in band #3:

 

lda #PILL_HEIGHT-1 ;
dcp PillDraw

 

My first 2 bands didn't dec PillDraw so it only started decrementing in band 3 and therefore thought it was at the top of the screen. This whole time I was thinking that since the Y register was decrementing in all of the bands I was fine. Thanks again!