Svetlana

Got it! That makes sense! The reason why I was getting a wonky scanline count though is I forgot the RTS instruction at the end of my kernel -- it was calling overscan twice I fixed and tweaked the code (now pushed) to go back to the NTSC linecount I had before, but I need to check if my Brazilian 2600 clone (Dactar) uses NTSC or PAL TIA. (Brazil uses PAL-M or PAL60, which is 60hz NTSC timing with PAL color freqs.) For some reason in my mind I had to call it somewhere in there because of how the scanlines worked, since I was thinking about visible space, but now I realize I can do it outside that. Thanks for the patience and big help!

I already use Notepad++ under Windows and gedit under Linux, which are the ones I'm most comfortable with at the moment. I made the change on my copy (not pushed to GitHub yet) but I didn't notice anything different visually. The weirdness I'm still getting is the colors are different than what I had before even though the values should be the same, and when the paddle reaches around the last quarter of the screen horizontally, the screen goes monochrome and shifts down one scanline. I'm sure it's something I'm doing wrong in the code, but I haven't looked much into it yet. This is just a hobby project anyway

sta HMOVE is exactly what I was missing, thanks. That sounds pretty difficult.. I think I might leave paddle for a later project, since I wouldn't even have a way to play it with an actual paddle anyway. I was calling it correctly but I was missing the HMOVE call, I got it to work now. Sorry I didn't look much into it at first, I was already getting kinda overwhelmed by the guide I was trying to follow but yours is much clearer. I started rewriting my code using your timer source as a template and I got everything to work more or less right, but I'm still getting some oddities I'll work out later. That code is on my GitHub now, I hope it's okay to use your code as a starting point. I've credited you in the comments. Thanks for the help so far, everybody!

I wanted to use the paddles but the paddle controller was never bundled with the Brazilian clones of the 2600, so it would make it impossible for me to try it on hardware if I ever managed to build an Atari cartridge. (I already built a homebrew SMS cartridge using an EEPROM once) So I'm still thinking on what input to use. If I'm using only paddle 1 to move a single object in the screen, why do you need to check it more than once per frame? EDIT: So I'm having the same trouble with the routine linked by ZackAttack as I was having with the other routines, wherever in the frame I put the routine in, it just glitches out the screen with some intermittent beeps. I guess I'm not too clear on how to put this function into my code? I replaced the area in my code labeled "WaitPos" with that snippet. EDIT 2: Nevermind, I fixed -that-, but the routine doesn't seem to be updating the horizontal movement properly. The code in the GitHub is updated with that routine, I'll include a binary here for convenience. brick.bin

That one looks much clearer than the ones I've found so far, thanks! I'll give that one a shot.

Hi everybody! I started playing around with 2600 assembly today, trying to make a breakout clone first for practice. I've been following the guide so far but I haven't had much luck with the horizontal movement of sprites. I understand the concept of it (waiting until the electron gun is at a certain X, resetting sprite position there, HMOVE for finer tuning), but I couldn't get any of the examples I've found to work, so I'm trying to figure it out on my own for now. My code is here: https://github.com/Lana-chan/break2600 I haven't implemented HMOVE yet but the current code is used as a test to see what delays I can use with RESP0 to get the paddle to move. I'd love to hear any comments and suggestions on my code! I've worked with Z80 assembly for Sega Master System before, though I never got too far with it, but it gave me a basic understanding of assembly programming in general.