johnnywc

Tempest, Congratulations on your acquisition. If all goes well and you plan on selling copies of this, you can count me in for one to help recoup some of that $$$ you put up for this. I'm sure I speak for many people here when I say "thank you" for all you do for this community. I must say that the occasional news of a new prototype being discovered keeps this hobby fresh, and your atariprotos.com website is a great resource for that part of the Atari community. Good luck with that proto - I hope you can get it to work!!

Spector, We had this discussion a while back (a couple years ago). Believe me - it's possible to get under 28.2. My personal best is 27.98. The only two tips that I can think of are to 1) keep your skis straight at ALL times!! and 2) cut the inside of the posts as CLOSE as possible. You can get pretty close without crashing!!! Remember - everytime you adjust the direction of your skis (you'll hear that scratching sound), you lose time. Good luck!!!

Modded 2600: Kaboom!! 7800: Cuttle Cart 2 5200: DK Jr.

That's so funny! I had my buddy convinced that if he "kept going left" on the downhill game in Skiing that he would find a ski lodge and a bear. I also told him that if he got to level 99 on Galaxian that he would find the dreaded "Galactic Planet"... Ah, the memories...

Yup - I started this thing way back in March of 2003 for about a month, one thing led to another, and it was almost 14 months before I started up again. ETA right now is Philly 6 (so March 2005), but maybe by December for HB of the year consideration (ha ha). I'm still in the proof-of-concept phase and I have many plans for this game but once I've decided on what I'll be able to squeak in (I'm thinking the game will be 8K right now - I've already burned 2K just implementing the rink and scrolling, the scoreboard/clock and the puck movement!). I'll keep you posted and thanks for the words of encouragement!

Well Stan, I'm not sure if it's *much anticipated* but I'm making good progress on my *not officially announced* RS Hockey game. PS It was nice finally getting to meet the legend (you) at Philly 5!

Paul, Thanks for the explanation. That's very similar to the way I used to do "fractional" positioning in my CHAMP games: if (!(FRAME%4)) - once every 4 frames if (FRAME%2) - twice every 4 frames if (FRAME%4) - 3 times every 4 frames The table seems pretty cool and definitely makes the math trivial compared to fractional math (and saves some bytes in RAM too!)... I'll have to experiment with both methods and see which suits my needs the best. Thanks again for all the help!

Thanks guys - that second way made a big difference (and it works!). I'm not sure which way I'll keep it - I'll see how the rest of the implementation goes. To be clear - should the first AND second ADC be ADC #0? Or is the SEC taking care of adding one to the inverse? Thanks again! This was a HUGE help and very insprirational!!

Here is the binary with the 2nd method employed (H always positive, bit deciding whether to add or subtract). Joystick Up will increase the H component Joystick Down will decrease the H component (it doesn't check for 0 so unpredictable results happen when it goes negative!) The V component is constant. Be kind - this is my first attempt at 2600 programming... hockey3.zip

Chris - Thanks for the info. Unfortunately, it doesn't seem to work. Again, it works in the positive direction, but when it reverses the fractional part doesn't seem to have an effect on the speed. What's even more strange is that the speed seems the same if I compute the 2's complement of the fractional part or not! On the other hand, by just using positive values for H and V and having a bit to determine the direction and switching to ADC or SBC works well, and also reduces the code to reflect (since I just need to invert one bit) and for friction (since I always decrement or shift to the right). In the end, I think it will take less ROM space and cycles to do it this way. Paul - thanks for the idea of a velocity table. Unforuntately, I'm not exactly sure what you mean. Can you elaborate??? Thanks again for all the help!!

UPDATE: I implemented the solution as described above and it works very well, but seems pretty convoluted. I was even able to implement friction so the puck will slow down naturually on the ice and slow down even more when it hits the boards (I actually half the H and V components when it hits the boards by doing a LSR from the high byte to the low byte). If anyone else has a better solution, I'd love to hear it! Thanks for letting me ramble...

Hmmm... The more I think about this: Would it make more sense to store a bit that determines what direction the puck is moving (one each for the H and V components)? With this method, I would either add (for positive values) or subtract (for negative values). To "reverse" a direction, I would just invert the bit. To apply friction, I would be able to just decrease the H component using subtraction. Does this sound feasible? The pros are: - "reverse" code becomes very simple - friction becomes more simple (only have to subtract from one value) - it might actually work, as opposed to the way I'm doing it now Cons: - I need to add a check for the direction bit and jmp to either subtraction or addition code based on the value instead of always just adding unconditionally Any ideas are welcomed! Thanks,

Hello all, I'm working away on my hockey game and I'm trying to come up with a way to simulate the puck hitting the boards and reversing direction, but I think my 6502 arithmetic knowledge is a little weak... I'm trying to use fractional math for the X and Y coordnates, as well as the horizontal and vertical components: Puck_X ds 2 Puck_Y ds 2 Puck_H ds 2 Puck_V ds 2 In each case, the lower byte is storing the "fractional" part and the higher byte is storing the integer part (very much like Kirk Israel's method in JoustPong). To move the puck (let's focus on the X coord and the H component), I'm doing standard 16-bit math: CLC LDA Puck_X ADC Puck_H STA Puck_X LDA Puck_X+1 ADC Puck_H+1 STA Puck_X+1 I can then position the puck using the high byte (Puck_X+1). This works fine for the situation where the H component is positive. When the puck hits the wall, I reverse the H direction by calculating it's 2's complement: LDA Puck_H EOR #$FF TAY INY STY Puck_H LDA Puck_H+1 EOR #$FF TAY INY STY Puck_H+1 (is there a better way to compute the 2's complement of a number???) The behavior I see is: - the integral part seems to work fine (that is, if it's to "1", the object moves right, hits the boundary, the value is converted to -1, and the object starts moving left - the fractional part doesn't seem to be working in the negative direction. In my example, I set the fractional part to 127 (to simulate a 1.5 pixel motion). It doesn't seem to have any impact on the speed of the object in the negative direction. Does anybody have any ideas or a possible solution to this? I'm thinking I might have to subtract with negative values, but I would think there should be a way to just "add" a negative number to achieve the same result. Thanks for any suggestions,

I've destroyed Sinistar many times... http://www.atariage.com/forums/viewtopic.p...hlight=sinistar Incomplete or not, this game is still one of my favorites. A little more polishing and Atari would have definitely had a winner... [/url]

Dumb question #2: Now that I'm subscribed to the Stellalist, how do I post something? I assume I send an email somewhere, but I can't for the life of me find the address anywhere in the confirmation emails. Also - where are the archives? I know there are some at http://www.biglist.com/lists/stella/archives, but they only seem to go up to May. Where are all the new messages being saved? Any info is appreciated!! Thanks,

AtariLeaf - thanks for your interest in this. To answer your question - this is a work from scratch (not a hack of M-Network's Soccer). I have some big plans for this game and hopefully I can implement them all. If all goes well and the game doesn't stink , I definitely have plans on selling it in cart form in one way or another. Thanks again! Excellent. As you can tell by name username and avatar, I'm a big hockey fan (Toronto Maple Leafs). I've been hoping for a new 2600 hockey game. Please make one of the teams blue and white. As a Blue Jackets fan, I have to say that a blue and red team would look better on that rink surface. I can't wait to see the finished product. Wow - glad to see some real interest in this!! As for uniform colors, if all goes well you'll be able to select from a group of colors for your teams (ala Double Dunk) but I'll have to wait and see if I have enough cycles to do that. If not, expect a black and gold team (Go Bruins!!! )... I plan on posting in the Homebrew Discussion forum to get some ideas on gameplay, etc. I have a pretty good idea about what I want to do but I'm always open to suggestions... Thanks again,

AtariLeaf - thanks for your interest in this. To answer your question - this is a work from scratch (not a hack of M-Network's Soccer). I have some big plans for this game and hopefully I can implement them all. If all goes well and the game doesn't stink , I definitely have plans on selling it in cart form in one way or another. Thanks again!

Dennis - I figured it out. Just had to follow the "unsubscribe" links and I eventually was able to "subscribe"... BTW - great work on Climber 5! I played it for about an hour down at Philly 5 and that experience was very insprirational in my decision to finally start a game. I also had a nice talk with Kirk Israel (of JoustPong fame) and he convinced me to just get to work and shoot for Philly 6 (thanks Kirk!) Anyway - expect some posts about RS Hockey on Stellalist very soon! Thanks,

Dennis, Thanks for the link. Unfortunately, I still can't figure out how to actually sign in as a new user. The "new user" link seems to be only for getting a password confirmation email. I think my brain is fried from cycle counting... Am I missing something basic here? Thanks again for your patience and assistance.

*WARNING!!* DUMB QUESTION ALERT!!! *** Hmmm... I can't seem to figure out how to post something to stellalist. I subscribed to it a couple years ago, and then unsubscribed. When I go to http://www.biglist.com/lists/stella, it just says: "The stella mailing list is in the process of being migrated to new hardware and mailing list software and will return soon. Archives are available." When I browse the archives there doesn't seem to be a clear way to register, sign in, or post any messages. Am I missing something??? Any advice or direction is greatly appreciated. Thanks,

Thanks Thomas - I will!

*until the stella list is up and running, I thought I'd post this here* Hello all, As promised, here is the beginning of the kernel for my RS Hockey game. Right now it's not doing much - just dispalying the rink (with full vertical scrolling), clock, period and score. Next step is to display the puck. LDA PFData2,X ; [55] + 4 STA PF2 ; [59] + 3 all set for next section LDA PFData1,X ; [62] + 4 STA PF1 ; [66] + 3 ScanLoop LDA IceColor,X ; [69] + 4 STA COLUBK ; [73] + 3 end of line 4 ; ----------------------------------------------------------------------------------- ; START OF LINE 1 CPY BallY ; [0] + 3 BEQ EnableBall ; [3] + 2/3 LDA #00 ; [5] + 2 JMP DrawBall ; [7] + 3 EnableBall LDA #02 ; [6] + 2 NOP ; [8] + 2 DrawBall STA ENABL ; [10] + 3 DEY ; 2 STA WSYNC ; [13] + 3 end of line 1 ; ----------------------------------------------------------------------------------- ; START OF LINE 2 DEY ; 2 STA WSYNC ; end of line 2 ; ----------------------------------------------------------------------------------- ; START OF LINE 3 DEY ; 2 STA WSYNC ; end of line 3 ; ----------------------------------------------------------------------------------- ; START OF LINE 4 SLEEP 46 ; [0] + 46 INX ; [46] + 2 DEY ; [48] + 2 decrement the scanline we're on BEQ DoneLoop ; [50] + 2 LDA PFData2,X ; [52] + 4 STA PF2 ; [56] + 3 all set for next section LDA PFData1,X ; [59] + 4 STA PF1 ; [63] + 3 JMP ScanLoop ; [66] + 3 I'm using Y to count the relative scanline (0-159) and X as an index into the data for PF1, PF2 and COLUBK. I've divided the playing area (160 pixels) into 40 loops of 4 scanlines and I'm updating PF1, PF2 and the COLUBK at the end of the 4th scanline for the *next* group of 4 scanlines. This is leaving me with 74 cycles for 3 scanlines (since I DEY on each line, assuming I get rid of the WSYNC) and 46 for the 4th line (taken up by a SLEEP right now). I quickly put together some code to display the puck (ball) at the beginning of scanline 1 (it takes up 13 cycles). Of course, this will only display the puck when it's on scanline 0, 4, 8, etc. and keep it displayed for 4 lines (which isn't the desired result). I'm not sure how to proceed here - do I duplicate the ball-display code for each scan line? Is this the most efficient way to enable/disable the ball? Any suggestions would be very much appreciated. I hope this post isn't out of line for the Newbies forum - I've only been doing this stuff for a few months and consider myself a newbie, especially if I have questions about displaying the ball!! If there is a better forum for this (perhaps the Programming forum) I'll be more than happy to post there. Thanks again for any help!!

Thanks everyone for your input. Cool - should of caught this one myself. This code is taken from the score display routine from SCSIcide (thanks Joe!) and I just replaced the orginal lda (ptr0),y with lda champ0,y without thinking that I can just go straight to x now (ldx doesn't support indirect addressing with y I guess...). Good call. This one is for my hockey game so I don't have a 6-digit score, but I'm sure I'll need a subroutine for my next game. Wow - I thought I was *pretty* close... Anyway, I got this routine from Joe's SCSIcide code so I thought it was a good place to start. I think I'll take a look at how to do a 48-pixel sprite (which is really what I'm trying to do). Thanks - that makes sense. Is it safe to say that you cannot display a 48-pixel sprite *without* VDELPx? It just doesn't seem possible without it. I did search the Stella archives but I was searching for 6-digit routines and not 48 pixel sprites. I assumed they were one in the same, but they obviously are not. Thanks again to everyone for all the help!

Hello all, I've been working on my game and decided to take a break from the kernel and write the code for my logo at the bottom of the screen. The logo is 44 pixels wide, so I thought that the 6-digit display code would be helpful in accomplishing this task- I would just replace the graphic pointers with the ones from my image. Well, everything worked out well except for one thing. My logo is the name of my company (CHAMPGAMES) but the 'E' is getting messed up. It looks like the 'E' still has part of the 'G' in it - it's getting updated too late (looks like 1 pixel too late). I messed around with the positions of the sprites and was able to get the E to display properly (third copy of P1), but the 'H' gets messed up (first copy of P0) - it's being updated too early!!. Here's the code from the kernel, with cycle counts: lda #3 sta NUSIZ0 sta NUSIZ1;3 copies close sta WSYNC ldx #22 blah2 dex bne blah2 nop sta RESP0 sta WSYNC ldx #22 blah1 dex bne blah1 sleep 3 sta RESP1 sta HMCLR lda #%00000000 sta HMP0 lda #%10110000 sta HMP1 sta WSYNC sta HMOVE sta WSYNC LDA #$80; [0] + 2 STA COLUBK; [2] + 3 LDA #$00; [5] + 2 STA CTRLPF; [7] + 3 LDA #$44; [10] + 2 STA COLUPF; [12] + 3 LDA #$00; [15] + 2 ;LDA #$FC STA PF2; [17] + 3 ;draw score lda #5 ; [20] + 2 sta count1; [22] + 3 ldx #6 ; [25] + 2 pause1 dex ; [27] + 2 bne pause1; [29] + 3 SLEEP 4; [56] + 4 nop ; [60] + 2 nop ; [62] + 2 mainloop ldy count1 ; [64] + 3 lda champ0,y ; [67] + 4 sta GRP0 ; [71] + 3 nop ; [74] + 2 -> end of scan line ;sta WSYNC ; [73] + 3 lda champ1,y ; [0] + 4 sta GRP1 ; [4] + 3 lda champ5,y ; [7] + 4 tax ; [11] + 2 txs ; [13] + 2 lda champ2,y ; [15] + 4 sta tmp ; [19] + 3 lda champ3,y ; [22] + 4 tax ; [26] + 2 lda champ4,y ; [28] + 4 sleep 6; [32] + 6 ldy tmp ; [38] + 3 sty GRP0 ; [41] + 3 stx GRP1 ; [44] + 3 sta GRP0 ; [47] + 3 tsx ; [50] + 2 stx GRP1 ; [52] + 3 dec count1 ; [55] + 5 bpl mainloop ; [60] + 4 -> we cross a page boundary on the jump Does anybody know what I might be doing wrong here? The display worked fine for numbers, but it's possible that the first pixel in each number was always 0 and therefore the glitch wasn't visible. Any help is greatly appreciated!!! Thanks,

Thomas - Thanks for all the information and suggestions!!! I've already started re-writing my kernel and it's all starting to make a little more sense. I've changed it so that PF1, PF2 and COLUBK are all being updated just on the first scanline per every four. Much cleaner and now I have a ton of cycles (at least for the other 3 scanlines). I also made sure that I update PF2 after cycle 60 and PF1 after cycle 70 on the *previous* scanline (as you suggested) and I even have enough time to load up the COLUBK register too! Next step is to mess around with trying to get the ball (puck) displayed in the new kernel and then the players. One quick question: When you said that I could have 200 visible lines - does this mean I just add 8 more lines to my display kernel (for a total of 3+37+200+40=270) or do I need to keep a count of 262 (and take 8 away from the overscan)? Anyway, there should be a warning posted saying that once you get into this stuff it CONSUMES you!! I'm counting scanlines in what little sleep I'm getting!! I'll post my kernel (what I have so far) in a few days once I've hit the next of many brick walls. Thanks again for the suggestions and the encouragement - they are both very much appreciated!!