Bad Panda Bear

Is Crazy Balloon compatible with non-modified Superchargers? I just played this using a Supercharger and a NTSC light atari six switch console. I had many problems with the screen going crazy whenever there was a collision or the balloon popped. Usually this was the same effect one would see when the cartridge is removed from the console. At one point it actually reset me to the Supercharger loading screen, making me think maybe it was hitting the Supercharger's hot spots.

...and the first thing I did with those controls was to ignore the project for nearly a year. Man I suck. I blame KOTOR. And Civ 2. But I've finally managed to arrange things so that I can start working on this again. Who out there is still interested? Are any of the other volunteers still out there and willing to give this a try? Anyway, my next step is to try to get a smaller test program running to try to figure out the problem I had when the ships got close to the screen edges.

I always liked Sabatoge, where the paratroopers came from the sky to sabatoge your gun. There's nothing quite like shooting a paratrooper's paracute off, causing him to fall to the ground in a bloody mess that kills other paratroopers already on the ground. Of course, now that I've read Band of Brothers I feel guilty about that.

Sorry for posting late, but my gift arrived over the holiday break while I was visiting my parents. Unfortunately the Grinch also left me a kitchen full of ants over the holiday. Many thanks Secret Santa! You picked exactly the item I was hoping you would.

Ok, I'll join in.

I feel like I need some sort of official acceptance speech like "Ladies and Gentlemen of AtariAge, I humbly accept this honor..." But seriously, I always thought of you as providing guidance rather than telling me what to do. But you're right, by the sheer amount of time I've invested in this projected it seems that I have practically taken control of it anyway. So it makes sense that you'd want to make that official. That being said, this started out as a low pressure environment for newbies to participate in developing a game, and I'd like that idea to continue. Tom seems to still be on board, and was it Galaga_Freak who was doing the intro? Whoever it was you are still welcome to contribute if you wish. And there are still some jobs free for anyone else who wishes to join. Cybergoth, are you still willing to work on the networking code mentioned earlier in this thread? The game isn't really ready for it yet but I think it's a cool idea that I'd be willing to attempt to tackle if you don't want to. For the near future though, I think I need a little break from FireOne. I've been thinking about entering the Minigame competition, and I need to clean my apartment and organize my Atari 2600 collection. Plus I've been purchasing expensive modern games and not playing them. Which makes me a saaaaad panda. Yes, that seems to be the Achiles heel of this technique. As a trade off it may be neccessary to not scroll the ships onto the screen but instead to have them appear in full. But I hope that can be avoided. I had originally wanted to keep the full 160 pixels of horizontal position, but this may be another trade off that has to be made. But regardless of this the multi-NUSIZ sprites force me to keep the early HMOVE because I needed the -15 move to the left to center the quad-sized lines underneath the single and double sized line. Yes. I blanked out the other sprites and commented out their movement so that I could test scrolling of the player 0 sprites without interference. But the code is still there, and is still being used for the submarine which is a 16 bit sprite now.

I've been silent about FireOne for the past several weeks, but not because I haven't been working on it. What happened is that I decided to try a simple little experiment that ended up being very complicated. As a consequence, this message is very long, and I apologize in advance for that. My goal was to make the sprites look better, and I thought that using a variable NUSIZx value for each scanline might allow more detail at the top while keeping the bottom portions large (important for battleships and carriers because they are supposed to be large). In implementing this I came across a series of problems that required me to do more and more complicated stuff to get things to work. Problem #1: There wasn't enough time in the horizontal blank to do two NUSIZx stores and two GRPx stores, along with the alternating missile enabling code. I solved this by setting VDELP1. This allowed me to set GRP1 on the scanline before. Problem #2: When you change NUSIZ, the sprite graphics were not aligned with the earlier portions of the sprite. To fix this, I had to set HMPx and do an HMOVE to align the bottom portion of the sprite. Problem #3: Doing an HMOVE on every scanline of the sprite ruined the left edge of the display. I considered just using a smaller screen, but decided to be ambitious and try the early HMOVE trick (See the Games that do bad things to HMOVE thread on the stella list). By doing an HMOVE at cycle 73 instead of after a WSYNC, I got rid of the HMOVE blank. Problem #4: I wanted the flexibility to choose different sizes at different points for the two player sprites. To do this I changed from using a spritePointer that points at each sprite, to using an 8 bit pointer from an assumed SpriteData table. Then in another 256 byte page in ROM called SizeData I have tables that control the HMPx and NUSIZx values to set for each scanline. The offset for each sprite is the same in SizeData and SpriteData, so I could use the same 8 bit pointer passed into DisplayMainStripe. The format I use has the HMPx data in the high nibble and the NUSIZx value in the low nibble. Here's an example from the first row (on the horizon) battleship sprite: ;; Row1BattleShip .byte %11011101 .byte %10000000 .byte %10000000 .byte %10000000 .byte %10000000 The sprite is still inverted, so the first few bytes have 0 movement (%1000 since HMOVE is being done at cycle 73), and single sized sprite data. On the last line, to make the sprite look longer, I used double sized sprite data. This requires a movement of 5 pixels of the left (%1101 in the high nibble) for the botton scanline to line up where I want it to. Also note that since bit 4 of the NUSIZx values aren't used by the TIA, I am using a 1 in this to indicate the end of the sprite. This saved me a few cycles in the display routine. It also means that I don't need to invert the sprites any more, but I haven't felt like changing that yet. Problem #5: When horizontally positioning the sprites, they line up differently because of the various HMOVEs done when drawing the sprites. So a sprite at position 0 may be mostly off the screen if the lower scanlines are moved to the left relative to the higher scanlines. To solve this I added another ROM table, called ShipTypeData, that has offsets for each sprite just as in SpriteData and SizeData. Right now ShipTypeData just has a horizontal offset that is applied to each sprite's X coordinate before horizontally positioning the ship (This is done in the VBLANK portion of the code right now). Eventually it could also store stuff like how fast a ship goes, and how many hits it can take before it sinks. But it is very inefficient in ROM usage because in order to use same offsets as SpriteData, the closer ships use many more bytes than the distant ships, even though they don't need to in ShipTypeData. I think this needs to be done differently in the future. Problem #6: Duplicating the sprites between the bottom two rows, and the top two rows didn't give the right pseudo-3D effect that the original game did. To fix this I made a version of each sprite for each of the four rows ships appear on. This of course requires much more ROM space. If the sprites are to fit into 256 bytes of memory, then I calculate that the game can only support four ship types, plus a blank sprite, an arrow sprite, and the submarine sprites. (I also ended up making the sprites a bit taller, so I had to remove the top sky slice). Problem #7: This is the one I haven't solved. When I position the ships towards the right hand side of the screen, the sprites go wacky. Now on my 2600jr I don't see this, so it might be an emulation problem. But my 2600jr looks like crap on my big screen anyway, so it's hard to see if there are any other problems with the code. Since I'm doing tricky things to HMOVE and NUSIZ, I really need to test this on my other 2600 console types (I have several) before I start blaming z26. Phew. For those of you brave enough to have read this far, I have the following question: Are the new sprites (see first screen shot below) good enough to warrant all this complexity and added ROM space? I kind of like them but I'm not very artistic and don't trust my judgement in this. fireone_src_and_bin.zip

What's the image quality like with you 2600 on you HDTV? With my 50" DLP (connected through RF) it looks kinda blurry and all of the interference is exagerated because of the way the image is strecthed to fill all the pixels.

And the number is... 118 Oesii was the closest at 101, but the rules clearly stated that the contenst ended at 12:00 am AtariAge time, and his post was at 12:25 am. Sorry. That makes Mr. FoodMonster the winner at 150. PM me with your address by tommorrow night and I'll get the prize shipped out to you Tuesday morning. I'm going on a business trip this Wednessday until the 30th, so if I don't get your address by then you'll have to wait a bit longer. I'm rather surprised at the low number. It leaves me wondering just how long I've been collecting empty 12 pack boxes. One of these days I should throw them away or something. I scare me.

My understanding is that burn in varies based on what type of TV you have. DLPs and LCDs are not very susceptible. Plasmas, CRTs, and Rear Projections (except LCD and DLP rear projection) are. Here are some FAQs I found that have more information: AVS Forum thread on burn in Another AVS forum thread HDTVArcade FAQ

Tommorrow marks my 29th and last official birthday. (Next year I shall deny any knowledge of this "birthday" concept). To celebrate I should probably throw a party at which I would receive lots of presents. Oh wait...that would involve interacting with other carbon based life forms...nevermind. Instead I'm going to give away a present. One NTSC Arcadia Supercharger, pictured below. This unit has been tested and cleaned with rubbing alcohol. (Although I couldn't get all the dust out of the corners). All you have to do is guess how many 12 ounce pop cans are strewn about my apartment. To help you make an educated guess I will give you the following hints. Hint # 1: Pictured below are the 12 packs that 99% of the cans came from. Hint # 2: I last cleaned my apartment of cans 3 to 4 months ago. I probably didn't clean up the corresponding 12 pack boxes however. Hint # 3: I average about 1.5 12 packs a week Hint # 4: Every work day I take a can into work, which usually doesn't make it back to the apartment. The person with the closest guess wins. I will ship anywhere my local US postal service will let me. If there is a tie the first guess wins. The contest will end Monday June 21st at 12:00 am AtariAge time. This gives me the whole weekend to get off my butt and find those cans.

In a way both those statements are right. What BNE does is to branch when the Z flag is set to 0. Usually this happens when the result of an instruction is not zero. For CPY, the cpu flags are set the same as if a subtraction occurred. So if YPosFromBot does not equal Y, the result of subtracting the two will not be 0, so CPY sets the Z flag to 0. This triggers the branch. Alternatively code like this would also branch when YPosFromBot is not equal to Y: TYA ; Transfer Y to A SEC ; Set carry so it does not interfere with subtraction SBC YPosFromBot ; Subtract YPosFromBot from A BNE SkipActiveMissile In this case, if Y does not equal YPosFromBot the result of the SBC is non-zero. The Z flag will be set to 0 so the branch will be taken. Hope this helps.

It appears to be just the ships, I've attached two pictures of the TV screen. One is before play starts with only one row of ships. And the other is after I've reached 1000pts and all the torpedoes have turned to refueling cannisters.

I've been seeing something strange when playing seawolf with a supercharger. When I play the binary in z26 it seems fine, there 3 rows of ships to shoot at and refueling starts with one refueling container at 1000 pts. When I convert to a WAV and play on supercharger, I get only one row of ships. I invariably die once before reaching 1000 pts, and when I do reach 1000 pts I start to see multiple refueling containers, that never go away. It's as if the mines start turning into refueling containers. This makes the game rather easy at that point. This was on a NTSC Vader and an NTSC sears heavy sixer. But when I play the binary on a CC2, it works like it does in z26. So I started to think that I was doing something stupid, like using an old version of the binary to make the WAV file with. But I re-converted and double checked and I still had the same problem. I also tried changing the volume I use when playing the WAV but it didn't help. So has anyone else seen this?

Well I drew them, so of course they're ugly. But I do think using more rows of ships is a good idea, so I did a quick version of this (see screen shot below). My main concern was that the pseudo 3D effect of the game would be ruined. So I made the sprite for the horizon version of the tanker a scanline shorter to make it look more distant than the ships on the second row. For the foreground ships, I don't think it matters too much because they're closer and therefore should show less of a size difference due to distance. So what do you all thinK?

I was referring to the 12 cycle vertical positioning of the torpedoes, not the horizontal positioning. I coudn't get two torpedoes enabled based on their vertical positions within the horizontal blank of a single scanline. So I used the larger table lookup method of horizontal positioning so that I could enable/disable a torpedo on the same scanlines that the player sprites are horizontally positioned on. This allowed me to enable/disable the two torpedoes on alternate scanlines since I no longer had to avoid the scanlines where the player sprites are positioned. The horizontally positioning of the torpedoes is done in the VBLANK section of the code as you described. Your explanation of this was fine, it was my explanation of what I had done that was confusing. I think this is because I tend to refer to the enabling/disabling of torpedoes as vertical positioning, and I left out the word vertical. Sorry about that. I hope I was clearer up above. As far as what to do next, I would like to get flicker implemented. I'm worried that four torpedoes on the screen at one time isn't enough for good gameplay, and I'd like to get flicker implemented so we can try it and find out. Other things that need to be done before expanding the game world are that pesky direction arrow at the bottom, and expanding the enemy sub to use both player sprites.

Well I finally managed to get some time to work on the display kernel, and I had to make a fair number of changes. It quickly became apparent to me that I wasn't going to get two torpedoes positioned on one scanline. So I decided to try to alternate scanlines, i.e. position missile 0 on odd scanlines, and missile 1 on even scanlines. But that meant I had to find the cycles to position the torpedo vertically and the sprites horizontally on the same scanline. In searching through the stella archives, I found out about calculating sprite adjustments using a table. This allowed me to use positioning code like this: ;; Get fine adjustment into HMP0, and coarse adjustment into X LDA HorzTable,X ; (4,70) STA HMP0 ; (3,73) STA WSYNC ;; There are 16 cycles needed from the WSYNC ;; to the loop. In this case I used four for the ;; following code, and 12 for the positioning a ;; missile But the following four cycles could ;; also be moved to before the WSYNC if needed AND #$0F ; (2,2) TAX ; (2,4) VERT_POS_MISSILE 2, tempTorpedo2YPos, 1;(12,16) .loop1 DEX ; (2,18+5*X) BPL .loop1 ; (2,20+5*X) on final loop STA RESP0 ; (3,23+5*X), 73 cycles at most STA WSYNC STA HMOVE I had to use a different table than in the stella message linked to above, but this allowed me to position the torpedoes on alternate scanlines. The code is attached. fireone_torpedoes_may18.zip

How are you trying to move it? If you are trying to move it by setting the HMPx registery, then it won't move until you do a "STA HMOVE". (Note this should be done after an "STA WSYNC") If you are using a full horizontal positioning scheme like described here, then it's simply a matter of changing the horizontal position variable between frames. Hope this helps.

Yes. I got a splitter with my Gemini and I was able to control all four players in Warlords using it. (But not at the same time because I only have one splitter).

DOH! Testing revealed that I did not need to do the check for the STA WSYNC. It works fine if I do it right after the STA RESP0,X. Originally I had the STA WSYNC outside of the subroutine, where the RTS had pushed it onto the next scanline. When I cleaned up the code to move it into the subroutine, I missed the fact that the check was no longer needed. Thanks for pointing that out.

Well despite a fever, taxes, and a new digital camera I got some horizontal positioning code working in FireOne. I've sent off the code to Cybergoth but I thought I'd describe it here. I started with the code Andrew posted overe here and tried to modify it so that it would display position 0 at pixel position 0 (TIA clock 68 ). The original lookup table had Left 7 as the adjustment for -15. So to position 0 at TIA clock 68, the STA RESP0,X had to happen at TIA clock 68 - 5 + 7. This is TIA clock 70, which won't work because we can only strobe at multiples of 3 TIA clocks. So I changed the table to vary from Left 6 to Right 8. I then added a 2 cycle NOP to the positioning code. This allowed the STA RESP0,X to happen at TIA clock 69. 69 + 5 - 6 gives 68, which is exactly what I wanted. Finally I had a problem with the positioning code taking a variable number of scanlines based on the arguments passed in. To solve this, I used a suggestion from Eric Ball and I moved the table to avoid the 1 cycle penalty. This meant that I had 3 extra cycles at the start of the positioning routine. I used these cycles to save off the X position to a temporary variable while positioning. Then after positioning was complete, I added code to do a STA WSYNC if the X position was far enough to the left that the routine did not take up a scanline. So here it is: ; Positions an object horizontally ; Inputs: A = Desired pixel position (0-159) ; X = Desired object to be positioned (0-4). ; scanlines: If control comes on or before cycle 73 then 2 scanline are consumed. ; If control comes after cycle 73 then 3 scanlines are consumed. ; Outputs: X = unchanged ; A = Unchanged ; Y = the "remainder" of the division by 15 minus an additional 15. ; control is returned from 1 to 11 cpu cycles on the next scanline. ; Credits: Originally from a post on the Stella List from R. Mundschau. ; This was taken from the AtariAge 2600 Programming For Newbies forum ; where it was posted by Andrew Davie. It has been modified based ; on suggestions from Eric Ball to avoid a 1 cycle penalty when ; crossing a page boundary and to add a delay loop so that it takes a ; consistent amount of scanlines. PosObject SUBROUTINE sta WSYNC ; 00 Sync to start of scanline sta tempVar2 ; 03 Preserve position for delay loop after positioning sec ; 05 Set the carry flag so no borrow will be applied during the division. .divideby15 sbc #15 ; 07 Waste the necessary amount of time dividing X-pos by 15! bcs .divideby15 ; 09/10 14/19/24/29/34/39/44/49/54/59 tay ; 2 lda fineAdjustTable,y ; 4 cycles (Table setup guarantees no crossing page boundary) sta HMP0,x ; 4 sta RESP0,x ; 4 (23/28/33/38/43/48/53/58/63/68/73) ;; Double check Positioning: ;; If A = 0: ;; STA RESP0,X happens at 23 cycles ;; STA HMP0,X is Left 6 (-15 in lookup table) ;; TIA clock position is 23*3 + 5 -6 = 68 = correct ;; If A = 14: ;; STA RESP0,X happens at 23 cycles ;; STA HMP0,X is Right 8 (-1 in lookup table) ;; TIA clock position is 23*3+5 +8 = 82 = correct ;; If A = 15: ;; STA RESP0,X happens at 28 cycles ;; STA HMP0,X is Left 6 (-15 in lookup table) ;; TIA clock position is 29*3+5 - 6 = 83 = correct ;; If A = 159: ;; STA RESP0,X happens at 73 cycles ;; STA HMP0,X is Right 3 (-6 in lookup table) ;; TIA clock position is 73*3+5 +3 = 227 = correct ;; Now, whether the positioning algorithm goes past the scanline ;; or if a STA WSYNC to end the scanline, depends on the original ;; value of A. Experiment has shown that a STA WSYNC is needed ;; when A < 120 ;; Comments show time after scanline for A = 0, A= 120, and A =159 LDA tempVar2 ; (26,66,76) CMP #120 ; (28,68,02) BCS .notLessThan120 ; (30,71,05) STA WSYNC .notLessThan120 rts ; (6,1,11) ;; Returns Between 1 to 11 cycles on new scanline fineAdjustBegin DC.B %01100000; Left 6 -15 DC.B %01010000; Left 5 -14 DC.B %01000000; Left 4 -13 DC.B %00110000; Left 3 -12 DC.B %00100000; Left 2 -11 DC.B %00010000; Left 1 -10 DC.B %00000000; No movement. -9 DC.B %11110000; Right 1 -8 DC.B %11100000; Right 2 -7 DC.B %11010000; Right 3 -6 DC.B %11000000; Right 4 -5 DC.B %10110000; Right 5 -4 DC.B %10100000; Right 6 -3 DC.B %10010000; Right 7 -2 DC.B %10000000; Right 8 -1 fineAdjustTable EQU fineAdjustBegin - %11110001; NOTE: %11110001 = -15 And let me thank Andrew Davie, R. Mundschau, Cybergoth, Eric Ball, and the entire Atari 2600 homebrew community for putting so much information out there on this. Without such a community I would have given up on Atari 2600 programming as soon I got to horizontal positioning.

I must be missing something fundamental, because I just can't figure out how this horizontal positioning code works. Take two examples, a horizontal position of 0 and 66 (relative to the left edge of the screen). If A is 0, I would think that the sprite should display 68 TIA clocks into the scanline (i.e. after the horizontal blank). However in the code above, it looks like the the STA RESP0,X completes 21 cpu cycles after the STA WSYNC. This is 63 TIA clocks into the scanline. The Y value used for the table lookup is -15. After some research on the [stella] list, I also found out that there is a 5 pixel delay between when RESPx is set, and where the sprite is displayed. So it looks like the sprite will be displayed at 63+5-7 = 61 TIA clocks into the scanline. This is off the screen to the left. If A is 66, I would think the sprite should be displayed at 134 cycles into the scanline (66 cycles after the horizontal blank). However in the code above, it looks like 5 subtractions are done leaving -9 as the table lookup value. The STA RESP0,X is done 41 cpu cycles after the STA WSYNC. So it looks like the sprite will start at (41*3)+5-1 = 127 TIA clocks into the scanline. A bit left of where I thought it should go. So what am I missing here?

I considered that, but decrementing a memory location takes 5 cycles as opposed to the 2 it takes to decrement a register. That's 3 cycles the current version of the fireone code doesn't have. Of course right now there isn't enough cycles to actually use the scanline counter anyway. I think its long past time that I start looking at other games to see how they handle this sort of thing.

This week my main problem wasn't running out of RAM or ROM, but running out of cycles. I first tried to implement what Cybergoth suggested for the ship types, but I also had to preserve X as the scanline counter, as I figure we'll need it when whenever we get around to firing torpedoes. TXA ; Preserve line counter LDX #$00 LDY topShipType,X ; Get the type of our ship TAX LDA SizeTable,Y ; Get the actual size of this type STA NUSIZ0 Then I decided to do the same thing with the sprite pointers, using two tables for the high and low poritons of the addresses. LDA SpriteLowTable,Y; Set the sprite to use for the ship STA sprite2Pointer LDA SpriteHighTable,Y STA sprite2Pointer+1 But when I repeated this for both ships, and added in code to reset the sprite colors from the arrows, I ended up needing more than 1 scanline to prepare for the ships on the horizon. I thought this was unacceptable if additional scanlines are going to be taken up by the positioning code. So in the code I submitted this week, I decided to simplify the code to get the ship type like this: LDY topShipType ; Get the type of the first ship ... LDY topShipType+1 ; Get the type of the second ship But when we go to a flickering display, this will only work if we sacrifice some additional cycles (and possibly RAM) in the vertical blank code to shift those types around between frames. Doing this saved 14 cycles, which allowed me to barely fit everything in. But I suspect that this will have to be reoganized somehow because there won't be enough cycles to switch missile graphics on or off when it comes time to implement torpedoes.