johnnywc

I think you might be talking about Atari Guide. Hope this helps!!

Hello all, I'm knee-deep into my first 2600 game called RealSports Hockey (or something like that) and I'm quickly learning that 76 cycles is NOT alot of time... Since this is my first kernel, I had a few general questions that I was hoping someone could give some insight to: - first off, this game is a vertical scroller. I'm using PF1 and PF2 for the rink (PF0 is always 0xF0) to gain some cycles. The playfield is symetrical. - the complete length of the rink is 240 pixels, with 160 being displayed at once (32 pixels are used for score, clock, etc.). - I have tables for PF1 and PF2 data. Each table has 60 entries representing 4 lines of the rink (60*4=240 total rink length) - I am changing the background color to simulate the RED lines and the BLUE lines. I'm pretty sure I won't have the time to do this in the final release but for now it looks cool!!! For now, I have another 60-byte table holding the background color changes for each set of 4 scanlines. - I am using the ball sprite for the puck - I plan on having vertical separation for the players (like Activision hockey) except that there will be four sets of players instead of 2 - the goalie, 2 defensemen in tandem (2 copies medium), the center, and 2 wingmen in tandem (2 copies wide). The maximum number of sets of players that can be on the screen at once is 2 (per team). - I want to use P0 for team 1's players and P1 for team 2's players - I'm thinking of using M0 for team 1's hockey sticks (I think this is what is done in Activision's hockey) and M1 for team 2's hockey sticks. Like Activision, this will only be drawn for the player (or set of players) that are being controlled (based on puck location). - I know I'm asking for a lot here, but I would also want to be able to change the player colors on each scanline to simulate uniforms (much like Activision's Hockey) - I would like to fit this all into 4K but 8K is not out of the question. The good news: - I have the clock, period lights/indicators and score display working - I have the rink display working with full vertical scrolling via UP and DOWN - I have the puck displaying and moving (just up and down the screen for now) The bad news: - after optimizing, I only have a few cycles left (about 9) before cycle 28 (the cycle before PF1, the puck, players, missiles, etc.) need to be set up by. I can't see how I'm going to check for and display GRP0, GRP1, M0, and M1!!! I've heard people talk about VDEL, double-scanline resolution, even/odd scanlines etc. to try to accomplish something like this. Does anybody have a general direction that they would suggest? What I'm looking for is some proof-of-concept that someone might be able to offer up that might be able to be used. Here are some of my thoughts and observations. - I purposely made it so that each scanline in the rink has either a change to PF1, PF2 OR COLUBK, but never more than one. For example, the first scanline has a change in PF1 but PF2 is 0 and COLUBK is the default color of the ice. - With the above, it may make sense to divide the kernel up into sections in such a way to draw specific scanlines of the rink so that only one of the three registers (PF1, PF2 and COLUBK) needs to be updated. Is this feasible? I've only seen kernels (in demos) that step through all 192 lines and do the same thing on each line. Is this common? - I've already divided up the kernel into sections to display the clock, score, etc. but dividing up the main kernel would require a lot of code duplication since players, the ball, etc. would have to be drawn in each section also. Does this make sense? - Since the "resolution" of the playfield and the background color changes is 4 lines, it makes sense that I would only have to update these registers every 4th scanline, leaving the other 3 scanlines to do other things like draw the players, puck, do a RESP0 and HMOVE for repositioning the multiplexed sprites, set the player copy register, etc. Is this the common approach? - How would using a double-scanline kernel help with the cycles? I know it limits the sprite resolution to 2 scanlines (drawback) and the playfield too (not a big deal since the resolution is 4 scanlines anyway). Is this where VDEL for the sprites comes into play? - To all of the experts out there - does this even sound feasible? I'm really trying to make a good hockey game with emphasis on gameplay) so I'm willing to give up things like the COLUBK changes or the multi-colored sprites to make this work. - If you've made it this far - thanks!!! Any suggestions on the kernel (or even on gameplay ideas) is welcomed!!! JohnnyWC PS I've a attached a screen shot of the current build.

I'm right-handed but when I first played Atari way back in 78, I rotated the joystick 90 degrees clockwise and controlled the stick with my left hand and the button with my right hand. Probably the only "righty" that had a hard time using the joystick because it WAS made for a right-handed person!!! Of course, today I still play it that way - it's the only way that feels comfortable. Weird stuff...

Thanks BP - I'll definitely be there next year. And thanks for the encouragement on the homebrew. RS Hockey is coming along well!!!

I think Double Dunk is a lot of fun. For an Atari 2600 game, it plays pretty well. The flicker is a bit annoying but I got used to it pretty quick. I agree that the computer can steal the ball too easily but I don't think it hinders gameplay too much. I always wanted to play this against a human opponent - I'm sure it would be even more enjoyable. Big Player - maybe next Philly classic we can play the game on one of the Atari's that are set up. I met you down there this year with Cafeman and Allan - we talked shop while we enjoyed a beer in the parking lot. Good times!!

bjk - how did you get the company name and separators there? what is the format for the menu.txt file to do that? I *scanned* the instruction manual but didn't see how to do it... thanks!! PS The CC2 is awesome!!! Thanks Chad!!!

I don't want to scare anybody, but I can tell you that changing the name doesn't protect you at all. They will generally get you on look and feel. This company made a bunch of clones for the PC and the whole "it's a different name" thing didn't fly with the boys down at Namco or Atari (JTS Corporation at the time). Of course, if they're not being sold for profit that may not provoke them into any legal action. So, my vote is call it "Burger Time" and sell it for cost in low quantities, keeping it under the radar. Good luck!!

Ze_ro - what game are we talking about anyway?

Thank you all very much for your input. Robert M - thanks for the idea. The ships do look better in double resolution (they're more square) so I think that might work out even better. Cybergoth - good idea!! I forgot that you can update things before the scanline and only do the STA GRP0 after the WSYNC - makes sense!!! This should open up some opportunities. DEBRO - Thanks for the link on the source of Climber 5. It seems a little over my head right now but it's encouraging to know you're doing all of that updating in a single line kernel. To pull this game off, I'm going to need to multiplex P0, P1, the missiles and the ball, as well as display a asymetrical playfield (for the pods)!!! Thomas - as always thanks for the tips. I'm not exactly sure how VDEL works. Am I correct in thinking that if VDEL is set for an object and I load it's graphic register, it will be delayed until the *next* line? To all - I appreciate all the help getting this project off the ground. It's a great forum and seeing all the great games that have come out recently has been quite the inspiration!! Thanks,

Hello all, Well, I'm a week into my homebrew project for the 2600 - a conversion of the arcade game Rip Off!. So far, it's coming along well - I've managed to get one ship drawn, I've implemented rotation (for 16 directions), and I've implemented thrust and friction (special thanks to Kirk Israel for his cookbook on subpixels). Up next is player 2 (Rip Off is a one or two-player cooperative). I'm using Thomas J's SkipDraw routine to display P0. My question is: what is the standard way to display 2 players? Since 18 cycles are used to display player 1, my guess is that I would need the same to display player 2, resulting in 36 cycles used (which is way past the acceptable cycle 23 for full-scren). Is this why a double-resolution kernel is used so that P0 can be displayed on even scanlines and P1 on odd ones (using VDEL where appropriate)? Thanks!!!

My guess is that the timer still works as expected even when you do a STA WSYNC, meaning that the timer will still count down even when the mircoprocessor is halted. As for doing STA WSYNC's during the vblank - I believe this is common. It's done most often when reseting the horizontal position of sprites (RESP0, RESP1, etc). The calculation for this is generally done after a STA WSYNC and a certain delay so that you can calculate exactly where on the scanline the beam is. You are correct - it does waste machine cycles but sometimes it's unavoidable. Of course, you can place your STA WSYNC's as close to the end of the previous scanline to reduce the amount of wasted cycles. Hope this helps!!!

Thanks Tom - great resource!!!

Thank you all for the information. Is there a recommended resource that can explain all of this stuff - particularly addition and subtraction, signed numbers, flags affected, etc? Most of the resources I find on the net only give syntax information and what flags are affected, but don't explicitly say how or give good examples. Any help would be greatly appreciated.

I think having 2-player alternate would be cool and make the game complete. As for names, I recommend Burger Climb. It's what I was going to call my Burger Time clone but I never finished the game. Congratulations so far on what is turning out to be one of the best arcade ports for the 5200!!! Thanks,

Dennis, Thanks for the info. I'm still a bit confused on how the dcp/bcs combo will get the sprite to draw correctly: When is the carry set on a compare? I know it's doing an A-M, so it would make sense that the N flag is set when M>A, and the Z flag will be set when A=M, but when is C set or reset? It looks like A is initialized with the height of the sprite (minus 1), so I would guess the carry would be set when the value of M is between 0 and the height of the sprite, but why? I hope this makes sense. I'll do some more reading on these instructions to get a better understanding, but this one has me stumped. Thanks for your help!! PS Great job on Climber 5!! I was able to play it at PC5 and was really impressed!!

Hello all, I'm finally starting my 2600 game after 2 years of research and I came across this code on Kirk Israel's Cookbook page: Very interesting to say the least. I believe this is the famous SkipDraw routine made famous by Thomas J. Anyway, I'd like to use it in this game I'm making but I'd like to fully understand what it's doing first. Q: Exactly what does "dcp" do? Does it decrement the value at P0_Y and also do a CMP? In which case is the carry set so that the bcs in the next line evaluates to true? Q: What is the .byte $2c doing? I can see that it's putting inserting the opcode for the BIT instruction... why is it "skipping" the next two bytes? Is this because the assembler will read the next two bytes as the address and perform the BIT operation? I assume that we don't care what happens in this operation, but the Z, N and V flags will be affected. Is this true? Is this a *very* slick way of branching using the least amount of cycles??? Man - this stuff is great. I was counting cycles last night in my sleep... Thanks for any help,

Finally - a game I'm good at!!! First try - 15,400.

Thank you all for your input. I'm going to start small and get a ship on the screen, get it to rotate and move around, applying friction, etc. The more I think about the pods, the more I think I'm going to do them in playfield graphics, but I'll try to avoid the asymetrical playfield by utilizing a ventian-blinds technique if possible. I can also make sure that only one pod appears per 4 scan lines to avoid this issue also. When a pod gets picked up, I can use the ball sprite to represent the fine movement with the enemy tank, and when it's dropped (enemy tank is destroyed), position the pod in the closest 4-scanline area that is available. The ball can be mutliplexed when more than one pod is stolen at a time (usually only happens on the higher levels), but I can limit this to 2 max and use logic to make sure that each pod is taken in a seperate direction, again avoiding flicker. This will leave the 2 player sprites to represent (at max) 5 objects (4 in a one player game) and the two missiles to handle the player missiles and the enemy lasers. I know it's a lot to do in a kernel I'm sure - does it sound possible??? I'm going to start right away and hopefully will get something going in the near future. If you guys have any other suggestions they're more than welcomed!! Thanks again!!

Hello all, I just finished school yesterday and I'm ready to dive into a homebrew idea for the 2600. My idea is a 2600 version of Rip Off! I did a search on the Atari Age forums and found this thread about a guy who wanted to do it but there was never any discussion of *how* it could be done. Anyway, for those of you not familiar with the game, it's a fantastic 1 or 2-player cooperative game where you control a tank that can rotate 360 degrees (similar to combat/asteroids). The object is to protect 8 fuel pods in the center of the screen from being "ripped off" by up to 3 attacking enemy tanks. You protect the pods either by shooting missiles bullets at the tanks or ramming into them. The enemy ships do not fire missiles; they are armed with short range "lasers". Overall, a pretty simple game that is easy to play and addictive (at least the arcade game is) and is great with 2 players and I would love to be able to play it on a 2600. To make a reasonably complete version of Rip Off, the follow would have to be displayed simulataneously: - up to two player tanks displayed at once. - up to three enemy tanks displayed at once. - a number of pods. 8 is how many were in the arcade; 4 would be acceptable. - one bullet for each player - short range "lasers" for the enemy tanks. think of this as being just a link protruding from the tank in the direction that it is facing. For a simple game, it doesn't lend itself nicely to the 2600 programming paradigm, requiring up to 5 sprites to be displayed at once with no vertical separation. This assumes, of course, that the pods, missiles and the lasers are all rendered using the ball, missiles and playfield. So, the question is: is this game possible? If so, what is the best way to do it? What does everybody recommend? Here are my thoughts... be aware that I've never "finished" a 2600 game but I have dabbled enough in the programming to be aware of it's limitations (to an extent)... - for a one player game, multiplex player 1's tank and 1 of the enemy tanks using player 0. multiplex the other two tanks using player 1. - for a two player game, multiplex player 1's tank and 1 of the enemy tanks using player 0. multplex player 2's tank and the other 2 tanks using player 2. - player 1 and one of the tanks multiplex missile 0 for their missile and laser, respectively. - player 2 and the other two tanks multiplex missile 1 for their missile and laser, respectively. Only one of the two enemy tanks could fire a laser simultaneously. - the ball is multiplexed for the pods. this could also be the playfield graphics, but the course resolution wouldn't work and this would also force the playfield to be asymetrical. another thought is to have the playfied display the non-moving pods, and have the ball multiplexed to display moving pods (the pod would be 4 color clocks wide to accomodate the resolution of the playfield). I would love to hear everybody's thoughts on this and thank you for taking the time to read it!! PS I'm not doing this for the money either...

I've been attempting a Lady Bug game for the 2600. The mock up looks good, the tough things that I see are trying to get the walls different colors - there's just not enough time to do a color change and make the maze asymetrical. Basically, you need the following: - one player could be multiplexed to do the lady bug, the skulls and the bonus letters/hearts. You would have to make sure that at max one bonus letter/heart was on a line (or spaced out correctly using the player copy feature. Still, this is a lot to try to get out of one player. - the other player could be multiplexed to do the 4 enemies/bonus fruit in the middle - the playfield would have to be asymetrical. I'm not sure how the doors could be highlighted - probably not with a different color but with a flashing (like in 2600 mousetrap). Not pretty, but it would work. - the timer could also be the playfield, but it would be difficult to have it going around the maze. it might have to just go across the top (more slowly of course). It could be a different color too since this would be the only thing on the line (no worry about players) - special/extra/1x3x5x - not sure how this would be represented. it would have to be on it's own line(s), either on top or bottom (not on the side like the arcade). again, a combination of player(s) could do this - same for the score/ ladybugs left, etc. All in all, a tough feat to pull off regardless. I've dabbled enough to think it's possible, but I don't have the experience to look ahead and see any major pitfalls. I'm sure some of the experts around here would have a better insight... Maybe some day!!

Hello everyone, I've heard many great things about the 5200 paddle controller - does anybody know if a step-by-step guide (with pictures) is available or, even better, if anyone out there is putting these things together for a fee??? I have a couple gutted controllers and tons of 2600 paddles. I would love to play Kaboom! on the ol' 5200 the way it was meant to be played, and with Castle Crisis it's almost a must to get one now... Any help is greatly appreciated... Thanks,

I agree with Paul on this one - tougher variations would be great. For example, if you choose Space Invaders I would recommend game 8 - it's fun and quite a challenge! For now, though, it's off to play some Circus Atari!

Hello all, With the impending ship date of the CuttleCart2 approaching, I'm hoping there is some good news on the status of the S-Video upgrade to the 7800. Does anybody know the status of this project? I have the S-Video upgrade for the 2600 and the 5200, but something tells me the 7800 will be getting a workout in the near future... Thanks!

giddy up - I'm in!

I just read through this whole thread and only one thing came to mind. Where't the picture of Adrian?