Just Jeff

Couldn't figure it out so I just fixed it by rearranging the kernal. ArenaLoop4: sta WSYNC ; 3 0 ;---------------------------- start of line 1 of the 2LK DoDrawPills: ;lda (PillPtr),y ; 5 Moved to the end of line 2 ;sta PF2 ; 3 Moved to the end of line 2 lda #PLAYER0_HEIGHT-1 ; 2 2 dcp Player0Draw ; 5 7 bcs DDoDrawGrp0 ; 2 9 lda #0 ; 2 11 .byte $2C ; 4 15 ; DDoDrawGrp0: ; 10 lda (Player0Ptr),y ; 5 15 sta GRP0 ; 3 18 lda (PlayerColorPtr),y ; 5 23 sta COLUP0 ; 3 26 lda CoinColor,x ; 4 30 sta COLUPF ; 3 33 nop ; 2 35 nop ; 2 37 nop ; 2 39 nop ; 2 41 nop ; 2 43 nop ; 2 45 nop ; 2 47 nop ; 2 49 nop ; 2 51 nop ; 2 53 nop ; 2 55 nop ; 2 57 lda #PF_COLOR ; 2 59 sta COLUPF ; 2 61 dex ; 2 63 sta WSYNC ; 3 66 ;---------------------------- start of line 2 of the 2LK lda #PLAYER1_HEIGHT-1 ; 2 2 dcp Player1Draw ; 5 7 bcs DDoDrawGrp1 ; 2 9 lda #0 ; 2 11 .byte $2C ; 4 15 ; DDoDrawGrp1: ; 10 lda (Player1Ptr),y ; 5 15 sta GRP1 ; 3 18 lda (Player1ColorPtr),y ; 5 23 sta COLUP1 ; 3 26 lda CoinColor,x ; 4 30 sta COLUPF ; 3 33 nop ; 2 35 nop ; 2 37 nop ; 2 39 nop ; 2 41 nop ; 2 43 dey ; 2 45 Moved here for timing dex ; 2 47 txa ; 2 49 and #%00000011 ; 2 51 tax ; 2 53 lda #PF_COLOR ; 2 55 sta COLUPF ; 3 58 lda (PillPtr),y ; 5 63 Moved here for timing sta PF2 ; 3 66 Moved here for timing ;dey ; Moved up for timing cpy #10 ; 2 68 bne ArenaLoop4 ; 2 70 - 3 73 if taken BP1l.asm BP1.bin

Hmm... I did have a slight awareness of page boundaries, and considered it here, but discounted it because I removed a couple of NOPs from the kernal and still had the problem. I also thought that crossing the page boundary meant that if the operator and the operand were on different pages. But you are saying that during the LDA itself, the index causes the crossing. Right? So, as far as I can tell, my align 256 is keeping my graphics on a single page ($F5) And, I moved some stuff around with no effect. However, PillRAMGfx is stored in RAM. But I moved the defined space a bit with no effect. Is using LSB, MSB with zero page / RAM doing this? Am I on the right track?

I tinkered around with the arrangement a little bit but feel I need to figure this out first: Any idea why the player's position is affecting the timing of the color write? When Player 0 is above the coins, the glitch only appears when he is at the same elevation as the ball. All other times, the colors change in time. I can't figure out why, first, the player position would affect that at all, and second, why the many WSYNCs wouldn't iron the issue out before or during the coin drawing. When at other vertical positions, it writes in time. Why?

Thanks! I've corrected the cycle count.. I did not realize that the debugger displayed them for you. I looked the counts up myself which was probably good practice for me anyway. A zero page,x takes an extra cycle over zero page.. I did see a timing issue with player 0 as well, but didn't mention it because the player 1 issue was more severe. Now that you mentioned it though, I see its nearly identical. When player 0 crosses the ball or the coins, the time increases, just like with player 1. So the issue is even clearer now- why do my player DoDraws take longer when the player is being drawn with the ball or coins, and not the missiles? Or, why is the DoDraw taking longer at all? Its supposed to be consistent whether or not its being drawn. Here's the updated code snippet. JEdit makes me tab twice sometimes to make everything line up, but when I paste here you see those double tabs. ArenaLoop3: ; ? - worse case time to get here sta WSYNC ; 3 ? ;---------------------------- start of line 1 of the 2LK lda #PLAYER0_HEIGHT-1 ; 2 2 - height of the player graphics, dcp Player0Draw ; 5 7 - Decrement Player0Draw and compare with height bcs CDoDrawGrp0 ; 2 9 - (3 10) if Carry is Set then player0 is on current scanline lda #0 ; 2 11 - otherwise use 0 to turn off player0 .byte $2C ; 4 15 - $2C = BIT with absolute addressing, trick that ; causes the lda (Player0Ptr),y to be skipped CDoDrawGrp0: ; 10 - from bcs DoDrawGRP0 lda (Player0Ptr),y ; 5 15 - load the shape for player0 sta GRP0 ; 3 18 lda (PlayerColorPtr),y ; 5 23 sta COLUP0 ; 3 26 Ball: lda #BALL_HEIGHT-1 ; 2 28 dcp BallDraw ; 5 33 bcs DoDrawBall ; 2 35 lda #0 ; 2 37 .byte $2C ; 4 41 DoDrawBall: ; 36 - from bcs DoDrawBall lda #2 ; 2 38 sta ENABL ; 3 41 sta WSYNC ; 3 44 ;---------------------------- start of line 2 of the 2LK lda #PLAYER1_HEIGHT-1 ; 2 2 - height of the player 1 graphics, subtract 1 due to starting with 0 dcp Player1Draw ; 5 7 - Decrement Player1Draw and compare with height bcs CDoDrawGrp1 ; 2 9 - (3 10) if Carry is Set, then player1 is on current scanline lda #0 ; 2 11 - otherwise use 0 to turn off player1 .byte $2C ; 4 15 - $2C = BIT with absolute addressing, trick that ; causes the lda (Player1Ptr),y to be skipped CDoDrawGrp1: ; 10 - from bcs DoDrawGrp1 lda (Player1Ptr),y ; 5 15 - load the shape for player1 sta GRP1 ; 3 18 lda (Player1ColorPtr),y ; 5 23 sta COLUP1 ; 3 26 Missile0: lda #MISSILE_HEIGHT-1 ; 2 28 dcp Missile0Draw ; 5 33 bcs DoDrawMis0 ; 2 35 lda #0 ; 2 37 .byte $2C ; 4 41 DoDrawMis0: ; 36 - from bcs DoDrawBall lda #2 ; 2 38 sta ENAM0 ; 3 41 Missile1: lda #MISSILE_HEIGHT-1 ; 2 43 dcp Missile1Draw ; 5 48 bcs DoDrawMis1 ; 2 50 lda #0 ; 2 52 .byte $2C ; 4 56 DoDrawMis1: ; 51 - from bcs DoDrawBall lda #2 ; 2 53 sta ENAM1 ; 3 56 dey ; 2 58 - update loop counter cpy #20 ; 2 60 bne ArenaLoop3 ; 2 62 - 3 63 if taken

I worked on this a little more today but haven't figured it out yet. I tidied up the part of the kernal that has the biggest issue to make it easier to read and attached the asm & bin here. I also changed code so the right player is now controllable. If you move him vertically you can get a much better sense of the issue. The problem occurs when player 1 (on the right) passes the ball and the coins. After I cleaned up my cycle counts I didn't see where timing would be an issue. Though after doing this, I'm questioning whether I did my DoDrawBall, and DoDrawMissile routines are correct. The timing is different then it is for the players and I'm not sure .byte is skipping over the correct amount of code on those. In addition to the attached file, here is a paste (Also, how you all make such nice pastes? ): ArenaLoop3: ; ? - worse case time to get here sta WSYNC ; 3 ? ;---------------------------- start of line 1 of the 2LK lda #PLAYER0_HEIGHT-1 ; 2 2 - height of the player graphics, dcp Player0Draw ; 5 7 - Decrement Player0Draw and compare with height bcs CDoDrawGrp0 ; 2 9 - (3 10) if Carry is Set then player0 is on current scanline lda #0 ; 2 11 - otherwise use 0 to turn off player0 .byte $2C ; 4 15 - $2C = BIT with absolute addressing, trick that ; causes the lda (Player0Ptr),y to be skipped CDoDrawGrp0: ; 10 - from bcs DoDrawGRP0 lda (Player0Ptr),y ; 5 15 - load the shape for player0 sta GRP0 ; 3 18 lda (PlayerColorPtr),y ; 5 23 sta COLUP0 ; 3 26 Ball: lda #BALL_HEIGHT-1 ; 2 28 dcp BallDraw ; 5 33 bcs DoDrawBall ; 2 35 lda #0 ; 2 37 .byte $2C ; 4 41 DoDrawBall: ; 36 - from bcs DoDrawBall lda #2 ; 2 38 sta ENABL ; 3 41 sta WSYNC ; 3 44 ;---------------------------- start of line 2 of the 2LK lda #PLAYER1_HEIGHT-1 ; 2 2 - height of the player 1 graphics, subtract 1 due to starting with 0 dcp Player1Draw ; 5 7 - Decrement Player1Draw and compare with height bcs CDoDrawGrp1 ; 2 9 - (3 10) if Carry is Set, then player1 is on current scanline lda #0 ; 2 11 - otherwise use 0 to turn off player1 .byte $2C ; 4 15 - $2C = BIT with absolute addressing, trick that ; causes the lda (Player1Ptr),y to be skipped CDoDrawGrp1: ; 10 - from bcs DoDrawGrp1 lda (Player1Ptr),y ; 5 15 - load the shape for player1 sta GRP1 ; 3 18 lda (Player1ColorPtr),y ; 5 23 sta COLUP1 ; 3 26 Missile0: lda #MISSILE_HEIGHT-1 ; 2 28 dcp Missile0Draw ; 5 33 bcs DoDrawMis0 ; 2 35 lda #0 ; 2 37 .byte $2C ; 4 41 DoDrawMis0: ; 36 - from bcs DoDrawBall lda #2 ; 2 38 sta ENAM0 ; 3 41 Missile1: lda #MISSILE_HEIGHT-1 ; 2 43 dcp Missile1Draw ; 5 48 bcs DoDrawMis1 ; 2 50 lda #0 ; 2 52 .byte $2C ; 4 56 DoDrawMis1: ; 51 - from bcs DoDrawBall lda #2 ; 2 53 sta ENAM1 ; 3 56 dey ; 2 58 - update loop counter cpy #20 ; 2 60 bne ArenaLoop3 ; 2 62 - 3 if taken BP1e.asm BP1.bin

I've been trying to program a home brew for a while now. Here is a brief summary of where I am at this point. Here is a picture of my previous attempt at the point I gave up. The program became too disorganized and there was too much useless stuff that confused things further. Then I re-started with a more simple program that was much easier to keep track of. Here I'm using the same data to display both players and some playfield. Then I split the screen up into 5 bands. I'll use one for the score, two for the playfield top and bottom edges, one for the main playfield and one for a special area of the playfield. Here is the current version

Hello! Here's a game I've been working on for a couple of months, based on SpiceWare's Collect Mini. My plan from the beginning has been to get the kernal working as fully as possible before focusing on game logic. I'm almost at that point but think I could probably use a little help. Issue #1- Its getting kinda wobbly. I'm not so concerned with what happens with the players when they go out of bounds since I'll prevent that from happening at some point. I'm mostly concerned with all of the jittering and the strange things that happen to the coins at the bottom of the screen. I want to get it cleaned up a bit before attempting to work in Omegamatrix's score routine. If anyone could help I would definitely appreciate it! To be clear though, all input will be appreciated, not just kernal stuff. Thanks! BP1.asm BP1.bin

Awesome.. I'm going to finish cleaning up my messy code before I attempt to add it or the program will just get too out of control. Thanks!

Alright thanks.. It works!

I finally installed Fraps so I can now show my crazy kernal glitch: https://www.youtube.com/watch?v=ErUJAu-8q_A&feature=youtu.be

Take your time.. I can work on other parts of the game. Its starting to look sloppy just like my previous attempts. I have to figure out how to proceed.

Thanks! First of many questions.. Could you elaborate on what RAM_SCORE_HI_LO doing? Also it looks like you define it, but don't use it.

Yeah it's not a problem. I was just trying to get a better understanding of the stack and also just confirm it is where I thought it is. And I did. It never occurred to me that it was holding 16 bit numbers... But of course it does. So now I know the stack is twice as big as I thought. Still, three routines deep surprises me a little for this game.

Hey I just read your reply again. If you like the idea of me using what you wrote, It would be silly for me not to. Couple that with the other stuff I said, that I would still get alot out of it just by comprehending it and correcting whatever you say is still outstanding . So I would definitely appreciate if you send me what you have! Thanks! Jeff

Thanks.. Well, I would like to give it a shot, to be honest. But to be clear- and I think you can guess- I'm a novice with no programming experience (beyond Basic in high school and a one credit Q-Basic class in college.) So at this point reading someone else's code and over and over until I have a good grasp of it is useful as well- and frees up a lot of time. As you can see above, I'm also dealing with jitter caused by an HMOVE in the kernel. (I should just quarantine that player to the left and move on- but my game idea is so fluid I don't know if that would be ok- I think it would) Maybe I could try it with yours and/or Darrell' guidance? I could spell out what I think needs to be done and you could comment. What do you think- it might be too much to ask. Let me know.. (I hope I'm not being too presumptuous- I have a busy day ahead- just in a rush) Thanks!

Well no progress. I haven't even tried beyond contemplating how I would do it. I've been working on more straight forward parts of the kernal- just shrinking the list of outstanding items where I can. Every time I contemplate the score band, I get the feeling that I'll probably go into a dead end, or inefficient direction. Do you know of any well commented source code that might help me figure it out?

OK Thanks.. I looked through it for about 20 or 30 minutes and bits and pieces are making some sense to me, but not enough to even begin asking questions about it- except maybe one. It eliminates the extra scan line? You mention the comb line, but not the extra scan line as far as I saw. I played the demo and it didn't have the issue- so I'm assuming it does. Its pretty amazing. I've heard David Crane and other Atari, Activision programmers say how the comb lines annoyed them that there was nothing they could do about it.

Anybody know the answer to this?

Nice!.. I learned a few things.. Does the stack in Celery really get six layers deep? Am I looking at that right?

Ah... so .wx is forcing a 16 bit address, not a 16 bit word.. And in this case, the page will be zero, your just specifying it to waste time.. Thanks!

Good Morning! sta.wx HMP0,X ; 5 19 - (.wx)- Is this storing a 16 bit word into an 8 bit register? Is this indexing the accumulator?

Quick question.. What's a good way to capture Stella video?

Yup- I did realize that. So long as the playfield stuff will fit in between the existing kernal code- which I think is the case. The even more complicated code will be translating numbers into graphics I think. If I'm understanding my first read through that thread, it looks like each PF will hold three digits' vertical lines. I think Darrell was linking PF2 and PF1 together as LSB and MSB for some clever reason. I really have little idea of how to do that part yet.

Alright... VDELBL did the trick. And you're right about reflecting the player. I just disabled it for now and the score stays where it should. As far as turning on REFP1 on to make the score kernal more efficient, I wasn't understanding that thread fully- looks like alot of LSBs and MSBs and taking out an ASL LSR.. going to take some concentration. Is the extra scan line curable? That player is updated at the beginning of line 1, well before the beam reaches the end- so I'm not sure that it is.

Thanks, I have a few things going on that you can see here: 1. When player 0's previous move was left, the spacing of the score changes. 2. When player 0 is on the right edge of the screen, the bottom of the playfield shifts down a line. 3. Shearing of the ball. 4. I have one of those black (white here) lines on the left side of the screen. I'm kind of proud of that one- a mark of my advancing programming skill