GeekyLink

Good idea. I just implemented command line switches. Here's the usage: BMPTo2600 image.bmp code.asm -p/s -r/n For flag three use -p if it is a playfield and -s if it is a sprite For flag four (Only really needed for playfields) use -r for reflected and -n for normal You can simply use the first three flags if you want, but note that if you use a playfield it will be set to normal (Non-reflected): BMPTo2600 image.bmp code.asm -p/s Same download as before.

You mean a Batari Basic version? I don't know how bB does graphics; I've just been playing with ASM. To be honest, I kind of thought they both used the same method... If you could send me an example of bB graphics I could probably implement it easily though.

Thanks, I'm glad you guys like it. I just edited it to support reflected and non-reflected playfields as an option. Not a very large update, but there really isn't much else to do with a program like this. (At least that I can think of) The download link is the same as the above, so if you want to give it a shot just click it again.

Here's a simple little program I threw together as a demo. I saw a javascript based program that worked like this, but I wanted to make something that could run off an actual image file (That way you can easily make changes to it later if necessary). Not sure how many people will find it useful, but I figured I'd post it in case it might help anyone. It takes a 24bit BMP and converts it to ASM code. It works with player graphics and playfields; it can also do a fullscreen playfield display. (Now supports reflected and nonreflected playfields) If you are making a player graphic the image must be 8 pixels wide and 192 pixels or less tall. Playfields must be 40 pixels wide and 192 pixels or less in height. The image you feed in needs to be white where you want a "0" and any other color where you want a "1". I can release the source code if anyone wants to take a look at it, but it currently resembles something along the lines of a train wreck. Hope somebody finds it useful/interesting. Update: Now supports command line switches. Here's the usage: BMPTo2600 image.bmp code.asm -p/s -r/n For flag three use -p if it is a playfield and -s if it is a sprite For flag four (Only really needed for playfields) use -r for reflected and -n for normal You can simply use the first three flags if you want, but note that if you use a playfield it will be set to normal (Non-reflected): BMPTo2600 image.bmp code.asm -p/s Download link: http://gekinzuku.com/members/download.php?...;File=BMPTo2600 Here's a demo of a result from the program in use. (Random title screen I threw together):

Awesome, thanks again. I managed to get it working perfectly with the insertion of an extra WSYNC and changing some variables. I'll definitely check out your kernel though; sounds like that'll be a better bet for more complex graphics.

Thanks a bunch guys. From what I understand, I'm using 16 too many cycles. I guess my method of drawing just isn't going to suffice. Would you by any chance have any recommendations for a faster graphical loop than the one presented in Kirk Israel's Moving Dot demo? Or am I simply using it the wrong way? From toying with my current code just a little, I removed the ball's height and changed a small aspect, which resulted in this. Only downside is that the ball is very tiny now... I'll keep messing around with it and see what I can come up with. Thanks again. ;;; Loop to handle graphics ScanLoop STA WSYNC ;3 --start counting-- ;;; Turn off the ball LDX #0 ;2 STX ENAM0 ;3 CPY BallY ; 3 BNE FinishBall ; 2 If BallLineCounter != 0 LDA #2 ;2 Load #2 STA ENAM0 ;3 Use it to activate ball FinishBall LDA #40 ;2 @25/37 ;;; Sets height of Paddle 0 CPY Paddle0Y ;3 Compare Paddle Y BNE SkipPaddle0 ;2 If PaddleY == Y STA Player0Line ;3 Store the height of paddle SkipPaddle0 ;;; Sets height of Paddle 1 CPY Paddle1Y ;3 Compare Paddle Y BNE SkipPaddle1 ;2 If PaddleY == Y STA Player1Line ;3 Store the height of paddle SkipPaddle1 ;;; De-activates Player 0 and 1 STX GRP0 ;3, 0 STX GRP1 ;3, 1 LDX #2 ;2 Use for activating Player 0 and 1 ;;; Paddle 0 LDA Player0Line ;3 Load the Paddle's line counter BEQ FinishPlayer0 ;2 If PaddleLineCounter != 0 STX GRP0 ;3 Activate Paddle with LDX above DEC Player0Line ;5 Decrease lines left in paddle FinishPlayer0 ;;; Paddle 1 LDA Player1Line ;3 Load the Paddle's line counter BEQ FinishPlayer1 ;2 If PaddleLineCounter != 0 STX GRP1 ;3 Activate Paddle with LDX above DEC Player1Line ;5 Decrease lines left in paddle FinishPlayer1 DEY ;2 Decrease Y BNE ScanLoop ;2 Loop till Y == 0

Hello, I recently decided to try out Atari 2600 programming. This is my first attempt at assembly so I'm assuming that I'm doing something stupid. (Actually, I'm assuming that I could probably have done a ton of things better.) After looking over a few examples, I wrote up my own Pong demo. Only problem is that the graphics seem to run a little glitchy. The code is somewhat based off of Kirk Israel's Moving Dot demo, but with plenty of my own code obviously. If you compile and run the bin file you'll see that the screen gets larger whenever the ball has the same Y value as one of the paddles. I "think" this has something to do with too many WSYNCS being called. My other idea is that my instructions are taking too long to execute. I'm really not sure either way, and I don't have the slightest idea how to fix it. If anyone could point me in the right direction, I'd greatly appreciate it. I've attached the source if anyone could take a look at it. Thanks in advance. Pong.asm.txt