jbs30000

OK, because I haven't quiet figured out how to do a two line, asymmetrical kernel I did the next best thing. I made an interlaced kernel. It works, except for one thing; The sprites.

What I did was make a kernel that draws sprites on the first line, and then every other line after that, with sprites being drawn on the second line, and every other line after that. File Interlaced_A.
I then made a kernel that did the opposite, drawing sprites on the first line and every other line, and then drawing the screen on the second line and every other line. File Interlaced_B.
Something I noticed was the sprites turned out the same in both programs. Seeing as how one program should have been reading every odd line and the program should have been reading every even line this shouldn't have happened, but for whatever reason, it did.

Anyway, I combined the two programs, Interlace_C and sure enough, while the playfield pixels (and background) are just fine, the sprites aren't whole. They still display every other scanline.

I try my best to solve my own problems, but this has me stumped. If anybody can help I'd really appreciate it. Thank you.

P.S. The joystick moves the smiley face.

 Interlaced_A.asm   11.17K   7 downloads  Interlaced_B.asm   11.76K   6 downloads  Interlaced_C.asm   16.78K   7 downloads
 Interlaced_A.asm.bin   4K   8 downloads  Interlaced_B.asm.bin   4K   10 downloads  Interlaced_C.asm.bin   4K   13 downloads

Out of curiosity, looking at a memory map of the 2600, what are the mirrored addresses for? Thank you.

OK, so I'm playing around with sprite positioning. Everything is OK, but at a certain point at the left side of the screen my sprite (player0) will shift up one pixel. So it's like a small vertical strip on the left-hand side is one pixel lower (for sprites) than the rest of the screen. Just curious. Thank you.
 Normal.png   50.05K   26 downloads -  Shifted.png   52.56K   21 downloads
 BlankB.asm   6.69K   12 downloads

Yar's Revenge question of course. I mean is it a sprite, missile, ball, or part of the playfield (or background)?

On levels with the the neutral zone it's a big multicolor block. On levels with the zone it's three lines. That just seems kind of weird.

Sorry to start three threads in such a short time, but once I get help figuring this out, I'll be good for while .

OK, for each scanline there are 228 TIA clock cycles or 76 CPU cycles.

According to this Website: lda zero page,x is four clock cycles and sta zero page is three clock cycles, so a pair is seven clock cycles.

For the basic routine to display a 40x192 image I have 6 pairs (three read/write for the left side of the playfield, and three read/write for the right side of the playfield. That makes 7 * 6 = 42 cycles.
I also have two SLEEP 4 statements so that's an extra 8 cycles so 50 cycles altogether.

The last part of the code is
sta WSYNC
inx
cpx #192
bne VisibleScreen

Now it seems to me that the since the last three opcodes are after WSYNC then they're inbetween scanlines and shouldn't count towards the 76 cycles, right?
If so then the sta WSYNC should be 3 cycles, so that's a total of 53 cycles and I should have 76 - 53 = 23 cycles left.
If those opcodes do count, then that's an extra 6 or 7 cycles, so at most 53 + 7 = 60 and 76 - 60 = 16 cycles left.

Yet, inbetween the last sta PF2 and sta WSYNC if use anything more than 11 cycles the screen goes wonky. So I am I incorrect about the timing, doing bad math, or...?

Thank you.