======OCTOBER 1996 ======THURSDAY, 17 OCTOBER ======Jim Nitchals: What the DS instruction is.
SUBJECT: [stella] Random number generators POSTER: jimn8@xxxxxxxxxx (Jim Nitchals) DATE/TIME: Mon, 21 Oct 1996 08:05:28 -0700 (PDT) POST: Communist Mutants did it like this: RANDOM LDA RND ASL ASL EOR SHIPX ADC RND ADC FRAMEL STA RND RTS
It uses an ongoing seed (RND), and combines it with the ship's horizontal position and the current video frame number to produce a new seed. It's simple but relies a bit on the randomness of the ship's X position to yield good randomness in itself.
Suicide Mission uses a linear feedback shift register (LFSR). Here's the code: RND LDA RNDL LSR LSR SBC RNDL LSR ROR RNDH ROR RNDL LDA RNDL RTS
For simplicity of design, this approach is better but it requires 2 bytes of RAM. If the zero-page RAM is in short supply you could modify RND to use Supercharger memory instead.
======MONDAY, 21 OCTOBER ======Jim Nitchals: How Communist Mutants Generated Random Numbers.
SUBJECT: [stella] Matt's Top 48 POSTER: jvmatthe@xxxxxxxxxxxx DATE/TIME: Sat, 26 Oct 1996 12:07:01 -0400 (EDT) POST: The following is a post I made as soon as the list started up again at the new address. My friend Ruffin (Rufbo@xxxxxxx) said he didn't see it, so I thought maybe the rest of y'all didn't get it. I had hoped it would spark some discussion... so here goes.
If you got this before and didn't care, hit 'q' now. :^) ------Hi all!
Well, it looks like the list has died again. In the hope of stirring up a little discussion, I thought I would post my "Top 48" list. This is the list of Atari 2600 games that I couldn't do without. Sure, there are others that I might include, but these are the bare essentials. I have tried to rank games primarily on gameplay, graphics, and sound; I hope I left out the "sentimental" factor. Keep in mind: replay value and the ability to keep me coming back were big factors in choosing my favorite games. I included a description/reason for each of the Top 15. If you want me to comment on my choices for 16-48, just ask.
I know that there are some omissions below that many of you might find galling. For example, Adventure does not make my list. Neither does Yars' Revenge. And I suspect that my #1 will be no one else's. But here goes:
Matt's Top 48 Atari 2600 Game of All Time (of the ones he's actually played)
1. Pressure Cooker - Just an all around excellent game. The graphics are very well done for the Atari 2600. The gameplay (especially on the higher levels) is very challenging, both in physical demands and mental skills. Also, the tune is kind of catchy! 2. Jr. Pac-Man - Again, a winner in both graphics (fantastic scrolling maze) and gameplay. Despite a little flicker in the ghosts, this game is second only to 7800 Ms. Pac-man in great maze zipping fun on an Atari home console. 3. Frogger (Parker Bros.) - This game, despite being graphically inferior to its Supercharger version, is fantastic in gameplay. The music, some of the best on the 2600, is pleasant and catchy. The gameplay is also very frantic and challenging, especially on the higher levels. 4. Kaboom - Though I have yet to break 4,000 on this game, it keeps me coming back again and again. This game alone makes the paddles a necessary accessory for the Atari 2600. 5. H.E.R.O. - Activision was just pumpin' out the hits apparently. This game seems BIG for a 2600 game. Granted, many of the rooms are a variation of previous rooms, but they are all different enough to keep you coming back. The graphics are colorful and catchy for the 2600. Too bad they didn't have some cool music for this one. 6. Laser Gates - A recent aquisition for me, I couldn't stop playing it when I first got it. The graphics are fairly simple, but the action is pretty hot and the side scrolling is pretty smooth for teh 2600. It's main drawback is that the sound effects are pretty annoying. Has some of the most impressive explosions for the 2600. 7. California Games - Incredible game. Just freaking awesome. Though I can't say I really care for the Footbag event, I can school anyone in the other events. (Rufbo can school anyone else in the Footbag, just ask him.) The BMX and Surfing are *very* impressive for the 2600. If they had combined the gameplay of BMX Airmaster with the half-pipe event in California Games this game would have probably been number 3 or 4. 8. BMX Airmaster - Speaking of BMX Airmaster...this game has one really cool musical track and some great graphics. The control is dead on and it has some really nice touches like, like the whistle when you score over 3000 on one "stunt". Does anyone know if you can break 10000 on one jump? I once got 9988! 9. Circus Atari - Probably the most primitive of the Top 10 graphically, but almost one of the most fun in gameplay. When your men get flying around the screen at near light speed, this game just can't be beat! And who can say they don't enjoy the feeling of clearing out the whole top row of balloons on one jump? 10. Indy 500 - The only game (so far) that uses the driving controllers, but that means nothing. Even in the one player timed events, this game can eat up my time like nothing else. The graphics are fairly basic, but it just goes to show what you can achieve with good gameplay. 11. Ms. Pac-Man - Along with Jr., we can almost excuse Atari for the abomination which is Pac-man. This game captures the fun of the arcade, even if it doesn't have the same mazes or intermissions. A must have for any 2600 owner. 12. KLAX - I know this one is known in PAL form only (right?) and is fairly difficult to come by, but let me assure you: If you can ever get it for a decent price...DO IT! Believe it or not, I actually started to feel some of the feelings I used to get playing the arcade version. Any time the 2600 version can help you get that arcade feeling, you know they did right well! 13. Super Breakout - An improvement on Breakout, this game is a great way to pass time, or get some kicks late at night when you and your friend(s) have really tired reflexes. 14. Midnight Magic - A great improvement on Video Pinball, this game brings a realistic pinball game to the 2600 with good graphics and pretty decent music. But am I the only one that misses the ability to tilt the machine that you could do in Video Pinball? 15. Solar Fox - A great game with fast gameplay and a very simple goal. Now if I could only get all the pieces of the hidden message! (I already know what it is, but I want to get them all for myself. Rosebud.) 16. Millipede 17. Frogger (SuperCharger) 18. Warlords 19. Robot Tank 20. Montezuma's Revenge: Starring Panama Joe 21. Pitfall II: Lost Caverns 22. Escape From the Mindmaster 23. Dragonstomper 24. Gyruss 25. Road Runner 26. Star Wars: Return of the Jedi: Death Star Battle 27. Star Wars: The Empire Strikes Back 28. Subterranea 29. Enduro 30. Joust 31. Pole Position 32. Rampage 33. Ghostbusters 34. Snoopy and the Red Baron 35. Pitfall 36. Spy Hunter 37. Dolphin 38. Defender II 39. Demon Attack 40. Bridge 41. Star Trek Strategic Operations Simulation 42. Centipede 43. Star Raiders 44. Battlezone 45. Defender 46. Video Pinball 47. Combat 48. Missile Command
That's all for now. Happy gamin'! matt
======||| John V. Matthews, III | PO Box 50355 ||| NCSU Mathematics Graduate Student | Raleigh, NC 27650 / | \ http://www4.ncsu.edu/~jvmatthe/www/ | (919) 515 7324 ======
======SATURDAY, 26 OCTOBER ======Matt: Matt's Top 48 2600 Games.
SUBJECT: Re: [stella] to overscan or not to overscan? POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Mon, 2 Dec 1996 22:41:51 +0100 POST: >According to the Stella programmer's guide, a NTSC TV frame generated by >the 2600 consists of 3 VSYNC lines, 37 VBLANK lines, 192 TV picture lines >and 30 "overscan" lines.
I allways thought, that you have PAL TVs in Italy too. So the values would be 3 VSYNC lines, 45 VBLANK lines, 228 TV picture lines and 36 overscan lines.
>The question is: do we really need to do the "overscan" lines? > >I'm writing my first game for the 2600 and I didn't care about overscan (I >just draw more empty TV picture lines). After a lot of try-and-miss I could >get a steady picture, so I don't think it's really needed. What do you >think?
You have to do the overscan lines, because they are part of the TV frame. You can get a steady picture without them, but there is a high possibility, that you will get the wrong colours or no colours at all, if you don't do the right number of lines for all parts of the TV frame.
The overscan is the part from the end of the visible TV screen to the end of the actual TV tube. Since there is nothing to see there you can simply skip them by setting up a loop, that does STA WSYNC 30(36) times.
Or you could use it to do some game logic, because there is no time for game logic during the 'TV picture' part of the TV frame. To do so you would set up a timer for the same number of processorcycles, that would happen during the 30 lines. Then you could do some game logic. Now you would need to wait for the timer to expire, do a STA WSYNC and jump to the VSYNC routine.
LDA #35 ;30 lines * 76 cycles per line / 64 timercycles STA TIM64T ;=35,625 wich means ~2280 cycles to use do game logic here
WaitOverscan: LDA INTIM BNE WaitOverscan STA Wsync JMP VsyncLoop
You can use the same type of timerloop for the VBLANK part too, because it's not visible either.
Ciao, Eckhard Stolberg 2stolber@xxxxxxxxxxxxxxxxxxxxxxxxx
======DECEMBER 1996 ======MONDAY, 2 DECEMBER ======Eckhard Stolberg: You must turn off the frame during Overscan.
SUBJECT: [stella] MONDO PONG! game preview POSTER: p.cavina@xxxxxxxxxxxxx (Piero Cavina) DATE/TIME: Wed, 5 Feb 1997 19:59:14 +0100 POST: Hi everybody! In the best Supercharger tradition :) , please find enclosed a preview release of my very first game for the Atari 2600. You can download it to an unmodified Supercharger, burn an Eprom or run it on emulators (I tested it on PC Atari emulator 1.5 by John Dullea without problems). Remember that it's only a preview and it can't be played!
MONDO PONG! is currently PAL-only (thought it might work on NTSC machines, who knows) but will be hopefully convertd to NTSC for the final release. Any help from you in US with NTSC TV sets will be appreciated.
Comments etc. are welcome...
Ciao, P.
(uu-encoded) begin 0700 mndpngpr.zip MtdLcaap``@`h`fN
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======FEBRUARY 1997 ======WEDNESDAY, 5 FEBRUARY ======Piero Cavina: Mondo Pong Game Preview.
SUBJECT: Re: [stella] Maybe you can help... (fwd) POSTER: Greg Troutman <mor@xxxxxxx> DATE/TIME: Mon, 24 Feb 1997 11:41:55 -0800 POST: Glenn Saunders wrote: > My question is this: Since I'm using the ball to be those features, > and it > shares the register with the playfield, will any background also > change to > the hair (beard, etc) color? BTW: The background is always a back > wall, and two side walls, depending on whether or not there is an > available exit. Is there any visible remedy you see?
The COLUPF register sets the color of the playfield and the ball. You can change the color from one scan line to the next, and potentially in mid-scanline. But when the the ball and the playfield are both being drawn on the same line you have the potential for the two objects blending together. The easy way out is to make the playfield empty, so the character is never really on top of the playfield, but on top of the background. The COLUBK register sets the color for that, so it can be different than the ball. Use the playfield registers to fill in *around* the area where the player and ball graphics sit on top of the background to create the illusion of walls.
-- mor@xxxxxxx http://www.crl.com/~mor/
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======MONDAY, 24 FEBRUARY ======Greg Troutman: Pointers about COLUPF.
SUBJECT: [stella] say.uue POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Thu, 27 Feb 1997 16:16:06 +0100 POST: section 1 of uuencode 5.25 of file say.bin by R.E.M. begin 644 say.bin M=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W M>(B(B(B(B(B(B(B(B(B(B(B(B(B(B(=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W M=XB(B(B(B(B(B(B(B(B(B(B(B(B(B(B(B(B'=W=W=W=W=W=W=W=W=W=W=W=W M=W=W=W=W=W=W=W=W=W>(B(B(B(B(=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W M=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W M>(B(B(B(=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=XB(B(B(B(B(B(B(B(B( MB(B'AW=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W M=W=W=W=W=W=W=W=W=WB(B(B(B(B(B(B(B(B(B(B(B(B(B(B(B(=W=W=W=W=W M=W=W=W=W=W=W=W=WB'B(B'B'=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W M=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W>'>(>(>(B(>(B(B(B(B(B(B(B( MB(B(B(B(AXB'AX>'B'AW>(=XAW=W=W=WAWAW=W=X=W=WB'B'>(>(AX=WAW>' M=WAW=W>'=W>'=X=W=X=WAWAW=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W>'=W M=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=XB( MB(B(B(B(B(B(B(B(B(>'=W=X=XB(=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W=W M=W=W=W=W=W=W=W=W=W=W=W=W=W=XB'=W=W=WAW=W=W=W=W=W=W=W=XB(AX=W M>(>(AW=W=W=WAWB'>'>(=V9F9E0R)&B:J8=XJKET``>K_)
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======THURSDAY, 27 FEBRUARY ======Eckhard Stolberg: uuencoded Tetris clone.
SUBJECT: [stella] How to Draw a Playfield [long] POSTER: Nick S Bensema <nickb@xxxxxxxxxxxx> DATE/TIME: Mon, 3 Mar 1997 00:21:23 -0700 (MST) POST: ; ; How to Draw A Playfield. ; by Nick Bensema 9:23PM 3/2/97 ; ; Atari 2600 programming is different from any other kind of programming ; in many ways. Just one of these ways is the flow of the program. ; ; Since the CPU must hold tha TIA's hand through all graphical operations, ; the flow ought to go like this: ; ; Clear memory and registers ; Set up variables ; Loop: ; Do the vertical blank ; Do game calculations ; Draw screen ; Do more calculations during overscan ; Wait for next vertical blank ; End Loop. ; ; What I will do is create an outline, and explain everything I can. ; This program will display "HELLO" and scroll it down the screen. ; ; In writing this program, I will take the opportunity to show you ; how a few simple modifications can completely change a program's ; appearance or behavior. I will invite you to comment out a few ; lines of code, and alter others, so that you can observe the results. ; ; I will be using DASM for now. Conversion to A65 should be trivial. ; processor 6502 include vcs.h org $F000
Temp = $80 PlayfieldY = $90
Start ; ; The 2600 powers up in a completely random state, except for the PC which ; is set to the location at $FFC. Therefore the first thing we must do is ; to set everything up inside the 6502. ; SEI ; Disable interrupts, if there are any. CLD ; Clear BCD math bit. ; ; You may feel the need to use the stack, in which case: ; LDX #$FF TXS ; Set stack to beginning. ; ; Now the memory and TIA registers must be cleared. You may feel the ; need to write a subroutine that only clears out a certain section of ; memory, but for now a simple loop will suffice. ; ; Since X is already loaded to 0xFF, our task becomes simply to ocunt ; everything off. ; LDA #0 B1 STA 0,X DEX BNE B1 ; ; The above routine does not clear location 0, which is VSYNC. We will ; take care of that later. ; ; At this point in the code we would set up things like the data ; direction registers for the joysticks and such. ; JSR GameInit ; ; Here is a representation of our program flow. ; MainLoop JSR VerticalBlank ;Execute the vertical blank. JSR CheckSwitches ;Check console switches. JSR GameCalc ;Do calculations during Vblank JSR DrawScreen ;Draw the screen JSR OverScan ;Do more calculations during overscan JMP MainLoop ;Continue forever. ; ; It is important to maintain a stable screen, and this routine ; does some important and mysterious things. Actually, the only ; mysterious part is VSYNC. All VBLANK does is blank the TIA's ; output so that no graphics are drawn; otherwise the screen ; scans normally. It is VSYNC which tells the TV to pack its ; bags and move to the other corner of the screen. ; ; Fortunately, my program sets VBLANK at the beginning of the ; overscan period, which usually precedes this subroutine, so ; it is not changed here. ; VerticalBlank LDX #0 LDA #2 STA WSYNC STA WSYNC STA WSYNC STA VSYNC ;Begin vertical sync. STA WSYNC ; First line of VSYNC STA WSYNC ; Second line of VSYNC. ; ; But before we finish off the third line of VSYNC, why don't we ; use this time to set the timer? This will save us a few cycles ; which would be more useful in the overscan area. ; ; To insure that we begin to draw the screen at the proper time, ; we must set the timer to go off just slightly before the end of ; the vertical blank space, so that we can WSYNC up to the ACTUAL ; end of the vertical blank space. Of course, the scanline we're ; going to omit is the same scanline we were about to waste VSYNCing, ; so it all evens out. ; ; Atari says we have to have 37 scanlines of VBLANK time. Since ; each scanline uses 76 cycles, that makes 37*76=2888 cycles. ; We must also subtract the five cycles it will take to set the ; timer, and the three cycles it will take to STA WSYNC to the next ; line. Plus the checking loop is only accurate to six cycles, making ; a total of fourteen cycles we have to waste. 2888-14=2876. ; ; We almost always use TIM64T for this, since the math just won't ; work out with the other intervals. 2880/64=44.something. It ; doesn't matter what that something is, we have to round DOWN. ; LDA #44 STA TIM64T ; ; And now's as good a time as any to clear the collision latches. ; LDA #0 STA CXCLR ; ; Now we can end the VSYNC period. ; STA WSYNC ; Third line of VSYNC. STA VSYNC ; (0) ; ; At this point in time the screen is scanning normally, but ; the TIA's output is suppressed. It will begin again once ; 0 is written back into VBLANK. ; RTS ; ; Checking the game switches is relatively simple. Theoretically, ; some of it could be slipped between WSYNCs in the VBlank code. ; But we're going for clarity here. ; ; It just so happens that I'm not going to check any game switches ; here. I'm just going to set up the colors, without even checking ; the B&W switch! HA! ; CheckSwitches LDA #0 STA COLUBK ; Background will be black. RTS ; ; Minimal game calculations, just to get the ball rolling. ; GameCalc INC PlayfieldY ;Inch up the playfield RTS
; ; This is the scariest thing I've done all month. ; DrawScreen LDA INTIM BNE DrawScreen ; Whew! STA WSYNC STA VBLANK ;End the VBLANK period with a zero. ; ; Now we can do what we need to do. What sort of playfield do ; we want to show? A doubled playfield will work better than ; anything if we either want a side scroller (which involves some ; tricky bit shifting, usually) or an asymmetrical playfield (which ; we're not doing yet). A mirrored playfield is usually best for ; vertical scrollers. With some creativity, you can use both in your ; game. ; ; The "score" bit is useful for drawing scores with playfield graphics ; as Combat and other early games do. It can also create a neat effect ; if you know how to be creative with it. One useful application of ; score mode would be always having player 1 on the left side, and ; player 0 on the right side. Each player would be surrounded in the ; opposite color, and the ball graphic could be used to stand out ; against either one. On my 2600jr, color from the right side bleeds ; about one pixel into the left side, so don't think it's perfect. ; It's really far from perfect because PC Atari does not implement ; it at all; both sides appear as Player 0's color. A26 does, though. ; ; To accomodate this, my routine puts color values into ; COLUP0 for the left side, and COLUP1 for the right side. Change ; the LDA operand to 0 or 1 to use the normal system. The code in ; the scanning loop accounts for both systems. ; LDA #2 STA CTRLPF ; ; Initialize some display variables. ; ;There aren't any display variables! ; ; I'm going to use the Y register to count scanlines this time. ; Realize that I am forfeiting the use of the Y register for this ; purpose, but DEC Zero Page takes five cycles as opposed to DEY's ; two, and LDA Zero Page takes three cycles as opposed to TYA's two. ; ; I'm using all 191 remaining scanlines after the WSYNC. If you ; want less, or more, change the LDY line. ; ; This is a decremental loop, that is, Y starts at 191 and continues ; down to 0, as do all functions of Y such as memory locations, which ; is why the graphics at the end of this file are stored "bottom-up". ; In a way, one could say that's how the screen is drawn. To turn this ; into an incremental loop, change the number to 255-191 (65) and change ; the DEY at the end ot the scanning loop to INY. ; LDY #191 ; ; Okay, now THIS is scary. I decided to put the bulk of my comments ; BEFORE the code, rather than inside it, so that you can look at the ; code all at once. ; ; Notice the new method of cycle counting I use. I'll send an update ; to cyccount.txt RSN. ; ; This routine came out surprisingly clean. There are no branches, ; and most updates are made even before PF0 becomes visible at cycle 23, ; even though PF1 and PF2 don't become visible until, by my estimate, ; cycles 29 and 40, respectively. We could use this time to get player ; shape and colors from temp variables and sneak them in, but that's ; another file. In fact, at the last minute I re-arranged things ; and threw in some color changes. ; ; The playfield will only be moved up every 4 scanlines, so it doesn't look ; squished. I could have updated it every 2 scanlines, and that would have ; saved two cycles. I could have saved another two cycles by having it ; change EVERY scanline. Comment out one or both of the ASL's to see what ; this would look like. I realize that it updates the PF registers whether ; it needs it or not, but it would be pointless to branch around these ; updates. Better to know you're wasting cycles and have them counted ; than to get unlucky and have your code spill into the next scanline ; every time too many things get updated. ; ; This is going to be a moving playfield. For a stationary playfield, ; comment out the SEC and SBC lines. That's probably what most of you all ; are going to want, anyway. And for a really good moving playfield, ; like in River Raid or Vanguard, you'll need slightly more interesting ; code than I'm prepared to provide. ; ; I also could have made the playfield graphic 16 bytes high, or 32, or 64, ; by changing only my data and the AND line. AND can serve as a modulus ; for any power of two (2^n) up to 128, by ANDing a byte with that number ; minus one ( (2^n)-1 ). 8 bytes * every 4 scanlines == 32, which is ; a power of two, which is why this works. Try commenting out the AND line ; and see how the program interprets it. Remember that PlayfieldY goes ; up to 255. ; ; But you won't need to worry about that if you're drawing a stationary ; playfield where the graphics data is so large, it doesn't need to repeat. ; In that case, you don't need the AND line and you don't need to make sure ; your graphics are 2^n bytes tall. Comment out the AND, SEC and SBC lines, ; and add a third LSR to the block of two. It indexes a bit too far at the ; top of the screen, which explains the garbage. You can fix that problem ; either by adding more data to the end of each array, or by decreasing ; the resolution by adding a fourth or fifth LSR. ; ; And who's to say you'll need all three playfield registers? Perhaps ; you have a rather narrow playfield, or one that's always clear in the ; middle. Either choice will save you five cycles per scanline. ; ; As you can see, it can be trimmed down quite a bit, and I still have ; a lot of cycles left over. The maximum, if you recall, is 73 if you ; plan to use STA WSYNC, and I pity the fool who doesn't.
ScanLoop ; Result of the following math is: ; X = ( (Y-PlayfieldY) /4 ) mod 7 TYA SEC SBC PlayfieldY LSR ;Divide by 4 LSR AND #7 ;modulo 8 TAX LDA PFData0,X ;Load ahead of time. ; WSYNC is placed BEFORE all of this action takes place. STA WSYNC STA PF0 ;[0] +3 = *3* < 23 LDA PFLColor,X ;[3] +4 ;In a real game, I wouldn't be this redundant. STA COLUP0 ;[7] +3 = *10* < 23 STA COLUPF ;[10]+3 = *13* < 23 LDA PFData1,X ;[13]+4 STA PF1 ;[17]+3 = *20* < 29 LDA PFRColor,X ;[20]+4 STA COLUP1 ;[24]+3 = *27* < 49 LDA PFData2,X ;[27]+4 STA PF2 ;[31]+3 = *34* < 40 DEY BNE ScanLoop ; ; Clear all registers here to prevent any possible bleeding. ; LDA #2 STA WSYNC ;Finish this scanline. STA VBLANK ; Make TIA output invisible, ; Now we need to worry about it bleeding when we turn ; the TIA output back on. ; Y is still zero. STY PF0 STY PF1 STY PF1 STY GRP0 STY GRP1 STY ENAM0 STY ENAM1 STY ENABL RTS
; ; For the Overscan routine, one might take the time to process such ; things as collisions. I, however, would rather waste a bunch of ; scanlines, since I haven't drawn any players yet. ; OverScan ;We've got 30 scanlines to kill. LDX #30 KillLines STA WSYNC DEX BNE KillLines RTS
; ; GameInit could conceivably be called when the Select key is pressed, ; or some other event. ; GameInit LDA #0 STA PlayfieldY RTS
; ; Graphics are placed so that the extra cycle in the PFData,X indexes ; is NEVER taken, by making sure it never has to index across a page ; boundary. This way our cycle count holds true. ; org $FF00 ; ; This is the tricky part of drawing a playfield: actually ; drawing it. Well, the display routine and all that binary ; math was a bit tricky, too, but still, listen up. ; ; Playfield data isn't stored the way most bitmaps are, even ; one-dimensional bitmaps. We will use the left side of the ; screen only, knowing that the right side is either repeated ; or reflected from it. ; ; In PF0 and PF2, the most significant bit (bit 7) is on the RIGHT ; side. In PF1, the most significant bit is on the LEFT side. This ; means that relative to PF0 and PF2, PF1 has a reversed bit order. ; It's just really weird. ; ; PF0 | PF1 | PF2 ; 4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7 ; ; This is important to remember when doing calculations on bytes intended ; for the PF registers. Defender gives a good example of this. ; ; It will become necessary to write a program that makes this easier, ; because it is easy to become confused when dealing with this system. ; PFData0 ;H 4 5 6 7 .byte $00,$f0,$00,$A0,$A0,$E0,$A0,$A0 PFData1 ;EL 7 6 5 4 3 2 1 0 .byte $00,$FF,$00,$77,$44,$64,$44,$74 PFData2 ;LO 0 1 2 3 4 5 6 7 .byte $00,$FF,$00,$EE,$A2,$A2,$A2,$E2 PFLColor ; Left side of screen .byte $00,$FF,$00,$22,$26,$2A,$2C,$2E PFRColor ; Right side of screen .byte $00,$1F,$00,$6E,$6C,$6A,$66,$62 org $FFFC .word Start .word Start
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======MARCH 1997 ======MONDAY, 3 MARCH ======Nick Bensema: [TUTORIAL] How to Draw a Playfield.
SUBJECT: [stella] Combat programming POSTER: jimn8@xxxxxxxxxx (Jim Nitchals) DATE/TIME: Mon, 3 Mar 1997 16:31:58 -0800 (PST) POST: While it was well designed, I noticed a few inefficiencies. I offer them not as criticism of Combat, but as little hints on building better 6502 code: lda TheScore,X and #$F0 lsr lsr sta Temp1 ; * 4 lsr lsr clc adc Temp1 ; * 5
The clc isn't needed because the least significant bit is already 0 from the and #$F0 instruction.
There's an RTS instruction at $F507 that didn't need to be there - there were other RTS's that could've been branched to.
Near $F37B, there's code that reads: lda GameModeInformation bmi @not_invisible ; planes/jets are never invisible and #1 beq @not_invisible ; invisibility bit set?
The and #1/beq is less efficient space-wise than an lsr followed by a bcc in this case, because the code doesn't need to preserve the accumulator or the carry flag (if you read the rest of the code, you can see that.)
Last, there's definitely code in there to flash an LED wired to bit 4 of port B when the game is over. Presumably Atari ditched the LED to save money.
Overall, Combat *IS* an example of really good programming. There's very little wasted code, and what's there does a lot for being only 2K.
There should be plenty of time left during vblank to do AI for a one player mode. Does the computer get to cheat during invisible tank mode and know where the player is, though? ;)
- Jim
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Jim Nitchals: Commentary on Combat's Programming.
SUBJECT: [stella] re: Combat programming and LED's POSTER: jimn8@xxxxxxxxxx (Jim Nitchals) DATE/TIME: Mon, 3 Mar 1997 17:23:37 -0800 (PST) POST: Matt wrote: > So once when I was dreaming about what kinds of games to write, it > occurred to me that if I really wanted a cool version of Star Raiders, > you could make one that had a special keypad (instead of the one that > came packed with it) that had lights for the shields and other features. > E.g. when the shields were on, the light would go on. Or perhaps three > lights for each...green=good, yellow=ok, red=bad, none=off or nonexistent. > Is this possible with this kind of code (and a specially made control panel)?
If Star Raiders were reprogrammed to take advantage of a redesigned game controller, you bet! The joystick ports for up/down/left/right are really *bi-directional* which allows them to be used to *send* data as well as receive it. Nintendo's joysticks are serial devices, for example, that send the button data one bit at a time under control of the CPU. There's no reason a Star Raiders controller couldn't be designed to do the same, and use the leftover bits to drive LED's.
The hardware involved would be simple - all the parts could be bought at Radio Shack, probably. Modifying the software is the hard part, unless you already have the source code.
- Jim
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Jim Nitchals: The 2600's Controllers Can Send as Well as Receive Data.
SUBJECT: Re: [stella] let's go back to work! POSTER: Nick S Bensema <nickb@xxxxxxxxxxxx> DATE/TIME: Tue, 4 Mar 1997 11:44:42 -0700 (MST) POST: >As soon as there is need for more freedom in objects positions, some >flickering is likely to happen.
That's a good point. Many games simply choose to avoid the possibility of dealing with flickering by letting object move freely, but not letting them infringe on each other's vertical space, i.e. Berzerk. Other games use intelligent movement algorithms to allow what looks like free vertical movement which somehow can always be drawn with just two players, i.e. Moon Patrol.
>Example: the second screen of Imagic Dragonfire. > [clip] > >See also Telesys' Fastfood: player can be anywhere (first sprite), food has >only one-directional movement and there aren't two pieces of food in the >same vertical zone (second sprite repositioned). > >There can be many variations of this concept, for example in vertical >shooters the player loses one degree of freedom and is always alone at the >bottom so that the two sprites can be used for more aliens in the space >above. "Demon Attack" is very interesting from this point of view...
Also see River Raid, which draws all the enemies, fuel tanks, and scenery against the playfield with one player, while the other player is used for the ship.
>Conclusion: the next step from simple Combat/Adventure/Pong :-) games could >be to write games falling in this wide category: > >first sprite=player, second sprite (recycled)=many enemies. >Now we need a clear, well commented code for drawing this kind of screens. >Any idea?
We need to figure out how River Raid does it. I think this is a good idea, because Street Racer had a great many good ideas on variations of the now-old dodge-obstacles game, none of which involved shooting. If Street Racer could come up with those kinds of variations in 1977-78 (my Street Racer has a number label), then certainly we can find something interesting to do with it.
>P.S.: what do you think of my english? Is it clear enough for you? :-))
Better than my Spanish, German, or Japanese. And my Spanish is pretty good.
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======TUESDAY, 4 MARCH ======Nick Bensema: Comments on How Games Avoid Flickering.
SUBJECT: [stella] Sprites source code POSTER: Bob Colbert <rcolbert@xxxxxxxxxxxxxxx> DATE/TIME: Wed, 5 Mar 1997 15:33:35 -0600 (CST) POST: Well, here is some code to peek at. I had thought that the players were single height, but upon further inspection I found that they were alternating single/double height, well I changed the code to make them all double height. At any rate, you will get the idea. Compile them with dasm sprite.s -f3 -osprite.bin you will need the vcs.h file for this, which was posted earlier. That vcs.h file is different from mine, and if you need mine, you can get it from http://www.novia.net/~rcolbert, follow the okie dokie link, it is in the okie dokie .zip file.
The example puts 7 bouncing copies of player 0 on the screen using a fairly complex scheduling algorithm. They should only flicker when 2 sprites overlap, and only the overlapping sprites will flicker. 7 copies is about the max this code can handle, 4 is very easy on the eyes, so try that too. I have tried this method on a real 2600 and it looks better than most of the emulators, probably because of the slow response of the TV screen. I haven't tried this exact revision on a real 2600 yet, but it looks best with PC Atari. Even with 7 copies, there still is a lot of room for game logic, but you would have to make some tight code. This code obviously needs to be optimized, but I wanted to get the concept down first, now I will be totally rewriting it from scratch :)
Cut all of the lines NOT between BEGIN and END out to compile. Please feel free to comment, criticize, etc!
BEGIN ; Sprites - By Bob Colbert ; Shows 7 copies of player 0 bouncing around the screen ; Player 1 is not used yet, but could be easily added. ; Sorry about the lack of comments ; I will be using this code to make my next game, ; Of course it still needs to be heavily optimized ; The players are double height resolution and the ; Background is quad height resolution. I am fairly ; Sure that with some optimization, the players could be ; single resolution processor 6502 include vcs.h
MAXSPRITE = $05 hpos = $80 ; horizontal position of sprites 0 - 3 vpos = #hpos + #MAXSPRITE + 1 ; vertical position of sprites 0 - 3 vline = #vpos + #MAXSPRITE + 1 ; current vertical line being drawn sprvmot = #vline + #MAXSPRITE + 1 ; vertical motion for sprite (0 - 3) sprhmot = #sprvmot + #MAXSPRITE + 1 ; horizontal motion for sprite (0 - 3) sprtclr = #sprhmot + #MAXSPRITE + 1 ; list of sprite colors sprtlst = #sprtclr + #MAXSPRITE + 1 ; list of sprites to draw flglst = #sprtlst + #MAXSPRITE + 1 ; nxtsprt = #flglst + #MAXSPRITE + 1 ; curclr = #nxtsprt + #MAXSPRITE + 1 ; tempvar = #curclr + 1 ; temp variable tempvar2 = #tempvar + 1 ; another temp variable p0count = #tempvar2 + 1 ; number of lines left to draw for player 0 p1count = #p0count + 1 ; number of lines left to draw for player 1 sprtptr = #p1count + 1 ; pointer to current sprite spmvptr = #sprtptr + 1 ; pointer to sprite to move this frame frame = #spmvptr + 1 org $f000 isprvpos .byte $30,$32,$20,$28,$18,$10,$32,$20 isprhpos .byte $30,$40,$22,$28,$12,$50,$38,$28 isprvmot .byte $ff,$1,$1,$ff,$1,$ff,$1,$1 isprhmot .byte $1,$fe,$ff,$2,$ff,$1,$ff,$1 isprtclr .byte $0e,$73,$16,$33,$22,$12,$53,$63 Start LDA #$0 STA PF2 ; save into a pattern control register LDA #$01 STA CTRLPF ; set background control register ldx #$00 stx COLUPF ldx #MAXSPRITE stx spmvptr isprtlp lda isprvpos,x sta vpos,x lda isprhpos,x sta hpos,x lda isprvmot,x sta sprvmot,x lda isprhmot,x sta sprhmot,x lda isprtclr,x sta sprtclr,x txa sta sprtlst,x dex bpl isprtlp lda #$43 sta COLUPF SFRAME ldx #$0 stx sprtptr lda sprtlst,x tax LDA #$56 STA COLUP0 ; set right side color STA WSYNC ; wait for horizontal sync STA VBLANK ; start vertical blanking STA VSYNC ; start vertical retrace LDA #$2A STA TIM8T ; set timer for appropriate length
Loop1 LDY INTIM BNE Loop1 ; waste time STY WSYNC ; wait for horizontal sync STY VSYNC ; end vertical retrace period LDA #$24 STA TIM64T ; set timer for next wait sta WSYNC LDA SWCHB AND #$01 ; check for reset switch BNE NReset nop ; only interrupt available - must have vector set NReset ldx #MAXSPRITE mvlp jsr mvsprt dex bpl mvlp jsr srtsprt jsr pri0 jsr res0 jsr zrtsprt
Loop2 LDY INTIM BNE Loop2 ; waste time STY WSYNC ; wait for horizontal sync STY VBLANK ; end vertical blanking sty WSYNC LDX #$38 ; number of lines to draw on screen stx vline Loop3 STY WSYNC ; wait for horizontal sync Loop3a lda vline sta PF1 ; change a background pattern with each line loop3b ldy sprtptr lda nxtsprt,y bmi notstart tax lda sprtclr,x sta curclr lda vline cmp vpos,x bne notstart lda p0count bne notstart2 sta WSYNC lda #$8 sta p0count lda hpos,x jsr calcpos sta HMP0 lda #$0 sta GRP0 iny iny iny sta WSYNC resloop0 dey bpl resloop0 sta RESP0 sta WSYNC sta HMOVE dec vline bne Loop3a ldy #$10 ovrscn sta WSYNC dey bpl ovrscn jmp SFRAME notstart lda p0count notstart2 tay beq nodraw1 dec p0count lda curclr sta COLUP0 lda shape,y tay nodraw1 sta WSYNC sty GRP0 sta WSYNC nosync jsr drawplr cmp #$0 BNE Loop3 pagend jmp SFRAME drawplr lda p0count tay beq nodraw LDA #$0 sta tempvar dec p0count bne ndr2 inc tempvar ndr2 lda shape,y tay nodraw sta WSYNC sty GRP0 dec vline ldx sprtptr lda tempvar beq nxt inx cpx #MAXSPRITE+1 bne ndr1 ldx #$0 ndr1 lda nxtsprt,x tay lda vline cmp vpos,y bne endraw nxt stx sprtptr endraw ldx sprtptr lda vline rts mvright JSR calcpos STA HMP0 lda #$0 sta GRP0 INY ;2 INY ;2 INY ;2 STA WSYNC ;3 resloop DEY ;2 BPL resloop ;2 STA RESP0 sta WSYNC sta HMOVE RTS ;6 calcpos TAY ;2 INY ;2 TYA ;2 AND #$0F ;2 STA tempvar ;3 TYA ;2 LSR ;2 LSR ;2 LSR ;2 LSR ;2 TAY ;2 CLC ;2 ADC tempvar ;3 CMP #$0F ;2 BCC nextpos ;2 SBC #$0F ;2 INY ;2 nextpos EOR #$07 ;2 ASL ;2 ASL ;2 ASL ;2 ASL ;2 RTS ;6 srtsprt ldx #MAXSPRITE-1 lda #$0 sta tempvar srtloop lda sprtlst+1,x tay lda vpos,y sta tempvar2 lda sprtlst,x tay lda vpos,y cmp tempvar2 bpl noswtch lda sprtlst+1,x tay lda sprtlst,x sta sprtlst+1,x sty sprtlst,x lda #$1 sta tempvar noswtch dex bpl srtloop lda tempvar bne srtsprt rts zrtsprt ldx #$0 ldy #$0 zrtloop lda flglst,x and #$40 bne zrt1 lda sprtlst,x sta nxtsprt,y lda flglst,x ora #$80 sta flglst,x iny zrt1 lda flglst,x and #$8f sta flglst,x inx cpx #MAXSPRITE+1 bne zrtloop cpy #MAXSPRITE+1 beq zrt2 ; lda sprtlst,x lda #$ff sta nxtsprt,y zrt2 rts pri0 lda #$38 sta tempvar ldx #$0 stx tempvar2 pri1 lda sprtlst,x ; Get first sprite # tay lda vpos,y ; Get sprite y's vpos cmp tempvar ; Compare to current line bpl pri2 ; If there is a conflict go to pri2 sec ; Subtract height of sprite sbc #$7 sta tempvar ; Save as next possible vpos pri5 inx cpx #MAXSPRITE+1 bne pri1 ldx #MAXSPRITE pri5a lda flglst,x and #$bf sta flglst,x dex bpl pri5a rts pri2 lda flglst,x ; get sprite # ora #$20 ; Set "conflict" flag sta flglst,x bne pri5 res0 lda #$0 sta tempvar ; first conflicting sprite sta tempvar2 ; last sprite drawn ldx #MAXSPRITE res1 lda flglst,x ; get sprite # and #$20 ; check bit 5 bne res2 ; if conflict go to res2 ldy tempvar2 cpy #$1 bne res1a lda flglst,x and #$bf sta flglst,x jmp res6 res1a ldy tempvar ; was there a conflict before? beq res5 ; nope get otta here lda flglst,x ; get sprite # ora #$40 ; sta flglst,x ; set the "don't draw" flag ldy tempvar2 ; we're at the last conflicting sprite bmi res6 ; if a sprite has been chosen, get out ldy tempvar ; get first sprite w/conflict lda flglst,y ; and #$bf ; clear the "don't draw" flag sta flglst,y ; jmp res6 res2 lda flglst,x ; get sprite # ora #$40 sta flglst,x ; set "don't draw" flag ldy tempvar ; check to see if first conflict bne res3 ; nope, go to res3 stx tempvar ; yep, save table index in tempvar res3 and #$80 ; was it drawn? beq res4 ; nope, go to res4 lda #$1 sta tempvar2 ; found 1 drawn, next non-drawn is o.k. bne res5 res4 lda tempvar2 ; see if drawn sprite found cmp #$1 beq res4a ; yes jmp res5 res4a lda flglst,x ; get sprite # and #$bf ; clear "don't draw" flag sta flglst,x lda #$81 sta tempvar2 bne res5 res6 lda #$0 sta tempvar sta tempvar2 res5 dex bpl res1 ldx #MAXSPRITE res7 lda flglst,x and #$4f ; change to 4f sta flglst,x dex bpl res7 rts mvsprt lda hpos,x clc adc sprhmot,x cmp #$4 beq mmv1 cmp #$98 ; A0 is the limit bne mmv2 mmv1 lda #$0 sec sbc sprhmot,x sta sprhmot,x bne mvsprt mmv2 sta hpos,x mvsprt2a lda vpos,x clc adc sprvmot,x cmp #$8 beq chsprvmot cmp #$38 bne mvsprt2b chsprvmot lda #$0 sec sbc sprvmot,x sta sprvmot,x bne mvsprt2a mvsprt2b sta vpos,x rts bitpos .byte $01,$02,$04,$08,$10,$20,$40,$80 shape .byte $00,$81,$42,$24,$18,$24,$42,$81,$00 org $fffa .byte
END
Collector of Atari 2600 games - Want to write a game for the 2600? Check out http://www.novia.net/~rcolbert
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======WEDNESDAY, 5 MARCH ======Bob Colbert: 7 Bouncing Copies of player0.
SUBJECT: Re: [stella] Making carts POSTER: fedeedw@xxxxxxxxxxxxxxxxxxx (Edward Federmeyer) DATE/TIME: Wed, 5 Mar 1997 18:43:11 -0600 (CST) POST: On Tue, 4 Mar 1997 crackers@xxxxxxxxxxxxxxxxxxxxxx wrote: > Maybe Bob or someone else who's released a game on cart, can share with us > the process and cost they encoured.
Hi, I've just joined the list, so I'm kind of catching this conversation in the middle. But heres my $.02 worth anyway:
When I was getting ready to release "SoundX" (with an eye towards "Edtris 2600" shortly after), I looked into having new PC boards made that could take a standard 27xx EPROM and and 74xx NOT gate, using new plastic cases, nice manuals, nice glossy labels, etc. I forget what the cost would have been, but it was very prohibitive. I'd have to sell the carts for WELL over $30 to make it worth while. PLUS, I had no idea if I would sell 2-3 carts or hundreds, or even thousands. PLUS I would have to do all the soldering, packaging, mailing, etc myself.
I also polled the "usenet" readers to get an idea how much people were willing to pay. I got responses from $5 to $100. BUT, the average was less than $20.
A good solution I found was to have Randy Crihfield build the carts by taking old pacman's and combats, ripping out the ROM, putting in an EPROM with a 74xx NOT gate, and putting it back in the pacman/combat case with a new (plain) label. We chose $16 as the selling price. That gave us enough money to split to make it worthwhile, and it's also an attractive price to the buyers. (Lower than most people were expecting, judging by the poll). Randy takes care of all the manufactuing, parts procurement, manuals, labels, shipping, payments, etc. I can keep spending my time doing what I like doing (programming!). Randy told me he would be willing to strike up a similar deal with other developers. You can contact him at: randyc@xxxxxxxxxxxxxxxxxxxx
The only down side to producing carts this way is that it's only practical for games of 4K or less. BUT, from other threads I read in this list, it will be a while before games get that complicated. Perhaps by then, we can get together on a design for a "generic" 8K/16K/whatever board, and make enough for everyone, so that the per-board costs are lower. (ie, if I have a run of 200 made, and you do, we'll each pay $1000 each ($2000 total). If we get together and have a run of 400 made it will cost us only a total of $1500, or $750 each!- I just made up these numbers, but you get the idea I hope.) This will become feasable only after q good number of us are making games >4K.
Personally, I favor producing actual carts. There is nothing like being able to hold a cart in your hand and say "see this, I made it!". Doing that with a floppy disk of .BIN files just isn't the same, and that is one of the things that attracted me to programming consoles in general. Otherwise, I might just as well program a PC. (err, actually thats what I have been doing lately but you get the idea I hope!)
Plus, there are a lot more people with Atari's and NO Supercharger than there are with Atari's AND Superchargers. This will always be the case, so it makes sense to make your target market as large as possible. Only if you specifically need Supercharger features does it make sense to limit your target market.
Which brings me to another point. Although we are all in this for "fun" as a hobby, it is darn hard work. We all should be proud that we are able to hack on a system as tough as the Atari 2600! There really are not *that* many people who can do what we can. As long as its so demanding, we might as well make it worth the trouble. I don't favor a "freeware" 2600 strategy. I might as well do freeware for the PC, which is much easier. That is not to say that I favor charging *alot* for carts, since most of us grumble about $4 carts in thrift stores :-) $16 was a price that was accepted favorably by the 2600 collector community. Maybe I could have charged more, but then I don't know if I would have bought one of my own carts myself :-)
Anyway, what all this boils down to is that I feel that releasing .BIN files of demos and such is fine, but I would rather see actual carts remain as the main 2600 disrtibution method.
Ed Federmeyer fedeedw@xxxxxxxxxxxxxxxxxxx
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Edward Federmeyer: Frustrations About Making New Carts.
SUBJECT: [stella] discovering the tricks (maybe) POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 6 Mar 1997 14:11:41 +0100 POST: I suspect that a common technique for putting more objects on the screen must be based on the multiple copies feature of Atari 2600 sprites.
Think about Activision Plaque Attack enemies (or a lot of other shooters), where you have groups of three aliens:
X X X
They must be done whith a sprite in three copies/close mode (NUSIZ=xxxxx011), as they are identical and move together on the same pattern.
You say: ok, but what happens when one or two aliens are destroyed?
Well, if the rightmost alien is hit, set that sprite to two copies/close mode (NUSIZ=xxxxx001): X X
If the leftmost alien is hit... set the sprite to two copies/close and shift it 16 color clocks to the right!
-->X X
And if only the center alien must die?? Set the sprite to two copies/med (NUSIZ=xxxxx010)!
X X
When only one alien survives, just set the sprite to one copy only (NUSIZ=xxxxx000) and shift it to the appropriate position.
There might be another way to do this: the sprite is always in three copies mode, but its pattern is blanked just before drawing the missing alien. That seems much more difficult to me, as it involves cycle counting, and in the same scanline you might have to update the background and take care of the other sprite and missiles.
And what about explosions? If you want to use the same sprite for a group of aliens and their explosions, I think that a pattern change "on the fly" is needed, as said above. Or maybe you might use the other sprite to draw the exploding alien. Or just let them disappear... :-)
Please note that these are only my thoughts, I haven't checked the code of any game.
Ciao, P.
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======THURSDAY, 6 MARCH ======Piero Cavina: Comments on 2600 Sprite Copy Function.
SUBJECT: Re: [stella] Sprites source code POSTER: Nick S Bensema <nickb@xxxxxxxxxxxx> DATE/TIME: Thu, 6 Mar 1997 13:53:35 -0700 (MST) POST: >- Do you think that a different way of storing X coordinates might lead to >a more efficient code during screen drawing? For example: > >7 6 5 4 3 2 1 0 >f f f f c c c c > >bits 0-3 = course position, to be used in a DEY-BPL loop for course positioning > > LDA XPOS > AND #$0F > TAY >loop: > DEY > BPL loop > >bits 4-7 = fine motion value, to be stored to HMPx > > LDA XPOS > STA HMP0
The real X-value, according to you, would be 15*fine + coarse. Considering the nature of the horizontal motion registers, where bit 3 equals -8, it would be far from linear in nature without a few adjustments.
Unmodified, 0 stays 0, and 1 stays 1, but 15 becomes -1 and 14 becomes -2 and so forth. The values would go like this.
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 <-XPOS 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 15 15 15 15 15 <-coarse +0 +1 +2 +3 +4 +5 +6 +7 -8 -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 <-fine 0 1 2 3 4 5 6 7 -8 -7 -6 -5 -4 -3 -2 -1 15 16 17 18 19 20 <-Position
Though it could be as simple as this:
LDA XPOS LSR LSR ;You forgot to shift the bits LSR ;to where Hmove will see it! LSR EOR #8 ;Toggle bit 3 STA HMP0
00 01 02 03 04 05 06 07 08 09...0D 0E 0F 10 11 12...1E 1F 20 21 <-XPOS 08 09 0A 0B 0C 0D 0E 0F 00 01...05 06 07 18 19 1A...16 17 28 29 <-EOR 8 0 0 0 0 0 0 0 0 0 0... 0 0 0 15 15 15...15 15 30 30 <-coarse -8 -7 -6 -5 -4 -3 -2 -1 +0 +1...+5 +6 +7 -8 -7 -6...+6 +7 -8 -7 <-fine -8 -7 -6 -5 -4 -3 -2 -1 0 1... 5 6 7 7 8 9...21 22 22 23 <-Position
Brilliant! It works.... sort of.
It still sort of "trips over" that 15 there, but it's accurate enough for most purposes. There certainly isn't much danger of erratic jerking around, it'll just snag on every 15 pixels. In real life, the left side of the screen is 0 and the right side of the screen is 152 (160-8). Here, the left side of the screen is 8 (eight), and the right side of the screen... uh, I'll figure it out later.
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Nick Bensema: Discussion About Coarse and Fine X Movement.
SUBJECT: playing with copies (was:Re: [stella] discovering the tricks(maybe)) POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 6 Mar 1997 22:42:07 +0100 POST: At 13:00 -0700 6-03-1997, Nick S Bensema wrote:
>> >>I suspect that a common technique for putting more objects on the screen >>must be based on the multiple copies feature of Atari 2600 sprites. >> >>Think about Activision Plaque Attack enemies (or a lot of other shooters), >>where you have groups of three aliens: >> >> X X X > >Space Invaders, and I think Galaxian, used groups of six, or rather, >two groups of three. uh, Galaxian maybe more that 6 if I remember correctly (creeps...)
> >This is a perfect opportunity to make your life simpler through tables. yeah!
>It would probably take 16 bytes; 14 if you take it as given in your >code that 000 means nothing shows up... very wise, since there is no >NUSIZ register for "nothing shows up". hmm, not really, as 000 means one copy only (see stella reference guide). we need a way to say that a sprite is missing. (see below)
>>is needed, as said above. Or maybe you might use the other sprite to draw >>the exploding alien. Or just let them disappear... :-) > >Or the missile. Of course, Space Invaders did id the hard way, and I >suggest you check the source code to figure out how they pulled >that one off. thanks no, I've enough for this week and there's Bob code to study :-)
Here we go: a routine to handle collisions between a sprite in multiple copies and a missile. The result will be a sprite with the appropriate configuration shifted in the correct position.
; WARNING: UNTESTED CODE!! ; ;MXPOS: missile X position. Missile must have width=1 clock. ;SXPOS: sprite position. Sprite must be in "med" mode, note that the second copy position will be ;SXPOS+16 and the third SXPOS+32.
;SCONF: index to sprite configuration, 5 possible values (see table below). $4 means that the sprite ;does not exist! ; ; NUSIZ sprite ;SCONF register mode ; ; 0 xxxxx000 X.... ; 1 xxxxx001 X.X.. ; 2 xxxxx010 X...X ; 3 xxxxx011 X X X ; ; 4 ------.....
;we suppose that a collision between the sprite and a missile has been detected.
;1 - find out which copy has been hit. ;hint: MXPOS>=SXPOS, as the copies as drawn left to right from the first @ SXPOS
LDA MXPOS SEC SBC SXPOS LSR A LSR A LSR A LSR A ; divide by 16 so that A=0..2, index to the hit copy
;2 - find the index to the table values for the new configuration/offset: ; X = index to hit copy * 4 + index to sprite configuration
ASL A ASL A ; whoops! that's stupid after four LSR, I've left all otherwise the code might be obscure
CLC ADC SCONF TAX
;3 - get the new configuration
LDA newconftable,X BMI error ; this situation is impossible, don't do anything STA SCONF
;4 - get the offset and add it to get the new position
CLC LDA SXPOS ADC offsettable,X STA SXPOS error: RTS
;done. will it work? newconftable byte $4, $0, $0, $1 byte $FF, $0, $FF, $2 byte $FF, $FF, $0, $1 offsettable byte $0, $10, $20, $10 byte $FF, $0, $FF, $0 byte $FF, $FF, $0, $0
; $FF means "ERROR" - a table value that should never be accessed.
; example ; ;SCONF=3 "X X X" ;SXPOS=120 ;MXPOS=138 ; ;MXPOS-SXPOS=18 ;[18/16] = 1 so the second copy was hit. ; ;X = 1*4+3 = 7 ; ;The indexed value of sconftable is 2 = "X X", now the second copy is missing. ;The indexed value of offsettable is 0, thus the X position doesn't change.
Ciao, P. -- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Piero Cavina: Attempt at Collisions Between Hardware Copied Sprites.
SUBJECT: [stella] Playfield Graphics.... ideas. POSTER: crackers@xxxxxxxxxxxxxxxxxxxxxx DATE/TIME: Fri, 7 Mar 1997 02:19:31 -0500 (EST) POST: I've decided to forgo studying Japanese this weekend in order to actually attempt to write some original 2600 code. I'm not going to be doing anything fancy. I'll just be drawing a picture with playfield graphics.
So I was prepairing for this work tonight by making myself some graph paper for plotting the graphics on.
Now, correct me if I'm wrong, but the resolution for playfield graphics would be 40x192. But, since one half of the screen is identical or a mirror image of the other half (without getting into fancy tricks like changing the playfield in mid scan) then I only need to have a graph that is 20x192. So I made that.
But then I remembered what I had recently been told about most programmes only updating the scan lines every two lines. This basically cuts the vertical resolution in half. So I made myself a nice 20x96 grid.
But then I got thinking, "Hey, if I only change the playfield graphics every x number of lines, I can save on memory. If I change it every 4 lines I'll only use 20x48 bits. If I change it every 6 lines I'll only use 20x32 bits. And if I change it every 8 lines I'll only use 20x24 bits." Not bad, but of course the vertical on my playfield gets blockier and blockier.
So I made myself 20x48, 20x32, and 20x24 grids.
Looking at a lot of the early games it looks like they probably went with the 20x24 method. You could go with updating it every 16 lines but then you only get a 20x12 grid. Not much you can do with that.
Anyways, I eventually refined all these grids down to one grid using different colours for the lines on the grid to represet different graphic modes.
Two things have occured to me...
1) It might be possible to set up a chunk of ram in the Supercharger as psuedo-video ram for the playfield graphics if you have a game that modifies the playfield graphics a lot with player interaction.
2) It might be possible to write a PC-Programme specifically for editing playfield graphics.
It would have a 20x192 grid on it. You select from a menu if you want to do graphics in 20x192, 20x96, 20x48, 20x32, or 20x24 mode. It then modifies the grid to the selected graphic mode. You click on the squares of the grid and it will toggle that bit on or off. When you finish editing you can preview the playfield either in either normal or mirror mode. The playfield graphics could then be saved as a text file looking something like this
(example of for a 20x24 mode graphic)
LLLLL byte, $xx ; PF0 byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; LLLLL byte, $xx ; PF1 byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; LLLLL byte, $xx ; PF2 byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ; byte, $xx ;
You could maybe even include a binary representation of the data in the rem segment. In anycase this text file could be cut and pasted into your source code. You'd just have to go in and change the LLLLL to whatever the actual location in your source code is, but that's not that difficult. And it would sure as heck save on graph paper when it comes to editing graphics.
Is this a doable thing? Would this be a helpful utility? Would it work good for generic graphic purposes? Or am I just completely screwed up in my understanding of playfield graphics.
Also, a PC sprite editor might be an option. Something where you specify the vertical resolution of a sprite and then it gives you a grid of 8x??. You click on the grid squares to toggle them and then you can preview the sprite in the different width modes. When you're done it saves the data similar to the playfield editor so that you can easily cut and paste the data into your source code.
I could probably sit down and write a programme to do this on the C-64... That is, if my C-64 still works. But I don't think it would be that terribly useful to any of us since I'm sure most of us are using PCs for our 2600 coding. unfortunately I know SFA about programming a PC. Does anyone out there think they can do it? (that is, if it's even a worthwhile idea).
It seems to me that it would eliminate some of the tediousness from programming 2600 graphics. I hate plotting stuff on graph paper and then converting the binary images into hex.
So am I on to something or am I just talking out my ass?
CRACKERS (buried under homemade graph paper from hell!!!!!)
--
Accordionist - Wethifl Musician - Atari 2600 Collector | /\/\ http://www.freenet. hamilton.on.ca/~ad329/Profile.html | \^^/ Bira Bira Devotee - FES Member - Samurai Pizza Cats Fan| =\/=
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======FRIDAY, 7 MARCH ======Crackers: 20 Pixel Versus 40 Pixel Playfields.
SUBJECT: [stella] Carts vs Tapes vs CDs vs BINs... POSTER: crackers@xxxxxxxxxxxxxxxxxxxxxx DATE/TIME: Fri, 7 Mar 1997 04:15:42 -0500 (EST) POST: This isn't meant to be an argument. I'd just like to state my opinions on the subject and be done with it.
1) Personally, I would much rather have a game on Cartridge than on any other media. Of course, if it's a multi-load supercharger game, then tape or CD will have to do. 2) Judging from the demand for Okie Dokie, I'd say that releasing a .BIN doesn't affect the sales of the official release. Infact, it may be a good idea to release a .BIN of your game (with at least one or two fully playable levels) just to get people interested in aquiring the game. Plus this way you don't have to worry about buying a new game only to discover it's crap.
3) Of all the concrete (non .BIN) release methods, the cassette tape is the cheapest in terms of material. Plus there's no overhead you make your product as you receive your orders.
4) Releasing a work on cartridge isn't all that hard, or expensive. From what I now understand, there is at least one person who goes "partners" with you. You send him the source code, he takes care of everything else. You wait for your cheques to come through the mail. Not a bad deal.
5) Even though not "everybody" has a Supercharger, lots of people do. How many supercharger CDs were sold? 300? How many orders were turned away? Every week there's one or two "Will trade my left one for a Supercharger CD". Plus, that Dan fellow has a considerable stock of the wee beasties at only $17 each. I think there are enough Supercharger owners out there to make it worth your while to support that market exclusively. Plus the number of Supercharger owners is growing.
6) Wether a product should be released in a Limited Run or on demand is up to the programmer and the programmer alone. I don't see anything unethical about making a product as a limited release, especially if a supercharger loadable .BIN of the game is available for download. The advantages of the limited run are... A) Those people who support the programmer by purchasing the release are rewarded later when the value of their purchase increases in collectable value. B) If the programmer wants to continue to make money from the hobby s/he will have to continue to write new games. This means more new games for all of us. The disadvantages of the limited run are... A) Not everyone who wants an official release will get one. B) If no .BIN is available to the public, then a lot of people will not even get to see the game. This would really suck. C) If people don't at least release demo .BINs of the games, it could lead to a lot of crappy games being sold as collectables. This will cause fewer people to be interested in Home-Spun 2600 games. This will mean the machine will suffer a second Crash.
7) Supercharger CDs are the most expensive release option. But in a few years when CD burners come down in price, it may be as feasable as doing cassette releases. While CDs are more expensive, there's no doubt in my mind that people would prefer a Supercharger CD over a cassette.
8) Ultimately how you release your product is your decision and you don't have to justify it to anyone. If you want to build a punched card reader for the 2600 and release your games on it, go ahead (did I mention I got my start in computer machine language programming on punched cards, very similar to your binary 'vapourators in many respects).
9) If you don't have a Supercharger grab one while you can. It makes testing the game on a real live 2600 very easy. Plus it'll let you move beyond the 4K limit that we currently face with carts. And the darn things only cost $17. Just post a message on R.G.V.C. with the title. "Hey Dan! I want to buy a Supercharger!" and you're sure to get his attention. Just like a shark can smell a drop of blood in a cubic mile of water. Dan can spot the word "Supercharger" in the sea of R.G.V.C. Plus it's worth it for Supercharger Frogger alone. Think about it, for the moment a supercharger only costs a dollar more than a home-spun 2600 cartridge.
10) Since the retail disappearance of the 2600, we have had Home-spun cartridges released, home-spun Supercharger CDs release, and home-spun .BINs released. The carts sell well, the Supercharger CD went like hotcakes, and there's really no way to tell what kind of action a .BIN gets on the internet (maybe 5 people downloaded "Rescue Bira Bira"... I really don't know). So far the only media that hasn't been revived has been the Supercharger Cassette. For this reason I will release my first original game (I don't think "Rescue Bira Bira" would be a fair indication of how well a SC Cassette would sell (or a cartridge for that matter)) on Supercharger Cassette and share the results of the experiment with everyone on the mailing list (this is, unless someone beats me to it).
CRACKERS (Comments welcome from hell!!!)
--
Accordionist - Wethifl Musician - Atari 2600 Collector | /\/\ http://www.freenet. hamilton.on.ca/~ad329/Profile.html | \^^/ Bira Bira Devotee - FES Member - Samurai Pizza Cats Fan| =\/=
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Crackers: Cartridges versus ROMs.
SUBJECT: [stella] 6502 reference POSTER: Dan Boris <dan.boris@xxxxxxxx> DATE/TIME: Fri, 07 Mar 1997 08:07:43 -0600 POST: I just found another good 6502 reference on the net. It was written specifically for the Atari 8-bit computers, but most of it still applies.
http://www.xmission.com/ ~trevin/atari/atari.html
Hope this helps people out.
Dan Boris
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Dan Boris: Still Working Link to Atari Technical Info.
SUBJECT: Re: [stella] Two triple-copy sprites for 48 horiz. pixels hi-res? POSTER: Bob Colbert <rcolbert@xxxxxxxxxxxxxxx> DATE/TIME: Sat, 8 Mar 1997 09:18:38 -0600 (CST) POST: Greg wrote: > Is this even possible?
YES! actually this is even possible: p0 p0 p0 p1 p1 p1 p0 p0 p0 p1 p1 p1 on alternating frames to give the appearance of 12 characters. I did this in the easter egg for Okie Dokie to put a 12 character wide scrolling message on the screen, I will dig out the source and get it to ya!
> Anyone know for sure? If you can find code that does this, I'd > appreciate it if you sent it to me, since I'm still without a > disassembler (and really tired of trying something that seems actually > like it might be impossible).
For the 6 character code, get the source for Okie Dokie from my homepage:
http://www.novia.net/~rcolbert
The Distella disassembler is also there, along with an html version of a 6502 timing chart (new), and the 2600 programming guide in .pdf format (much smaller than the .doc format without losing any data).
Take Care, Bob
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======SATURDAY, 8 MARCH ======Bob Colbert: Updating Playfield Registers on Alternating Frames for High-Res.
SUBJECT: [stella] NTSC - PAL porting guide POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Sat, 8 Mar 1997 19:51:43 +0100 POST: Hello there,
I would like to play all your new NTSC games also on my PAL system. Therefore I have decided to write a little conversion guide.
Things to keep in mind when writing 2600 games:
1. Do a Vsync in every frame. This way NTSC games will atleast display a stable picture on PAL systems. Early games only did the Vsync once and then went on counting 262 lines for each frame. While this works on NTSC systems and saves 3 lines for game logic, it only produces rolling pictures on PAL VCSs.
2. Have the Overall Lines/Vblank lines ratio right. NTSC normally has a ratio of 262/37 while PAL has 312/45 (plus 3 lines of Vsync for both). It is possible to reduce the number of overall lines, if you don't want to use them for game logic or display and therefore you can have a smaller number of Vblank lines. But if you get the ratio just a little bit wrong, there is the risk of loosing the colour signal. Because of this, I think, it is best use the normal number of lines for both TV systems. If you use a Tim64T timer loop for Vblank and overscan, converting between both systems should be as easy as just changing the timer value.
3. When converting from PAL to NTSC, you should take into account, that NTSC systems can only display a smaller number of lines. Therefore you should limit yourself to 192 lines of displayed graphics in PAL mode too. Or you should create your graphics in a way that allows you to remove enough lines to fit on a NTSC screen.
Also the number of lines that can be used for gamelogic is smaller on NTSC systems. That is why you should do cycle counting for the worst case, if you are using any timeconsuming calculation loops.
4. NTSC systems operate at 60hz while PAL systems use 50hz. Because of this you have to redo all frame based timing. For example: if you are moving your spaceship in NTSC 5 pixel in every frame you need to move it 6 pixel per frame on a PAL machine. Or if you are doing anything every 6th frame on NTSC, you have to do it on every 5th frame on PAL to get the same speed.
5. This is not in the programmer's guide. PAL systems use a different form of colour encoding than NTSC ones do. The TIA chip seems to be the same on both systems, which leads to two totally different palettes. Based on Ed's SoundX source code for NTSC and on my own observation for PAL they are:
NTSC PAL grey grey gold grey orange gold red orange yellow green pink orange brown purple green blue purple pink - red blue blue green blue2 purple light blue turquoise turquoise lilac green blue light blue green purple blue yellow green blue orange green grey light orange grey
I am not very good at discribing colours with words, so it would be nice, if someone else with a PAL system can verify or correct this.
I hope to see a PAL Okie Dokie or a PAL EdTris soon. :-)
Thanks, Eckhard Stolberg
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Eckhard Stolberg: NTSC to PAL porting guide.
SUBJECT: [stella] Crackers' Easy Playfield Graphics Code POSTER: crackers@xxxxxxxxxxxxxxxxxxxxxx DATE/TIME: Sat, 8 Mar 1997 15:33:43 -0500 (EST) POST: Okie Dokie... (no pun intended Bob).
I figured out why my first attempt at compiling my code didn't work. It was just a I had figured... 5:00 in the morning is no time to still be up writing code. I had made typos and some errors which where just out an out whacky. Chalk it up to programming while sleepy and not having written anything in machine language since the early 80's. (Brian Mulruney was Prime Minister, Ronald Regan was President). Having slept in until 2:00pm and taking another look at my code the errors jumped out and slapped me in the face.
Anyways... do you remember that playfield graphics editor idea I proposed not long ago (i.e. babbled on about). Well here's a routine that would be able to take the data from that hypothetical editor and display it on a 2600 as playfield graphics.
This routine is very simple, the other programmers will probably laugh and call it names. They'd never let my source code, be in any video games. But then one foggy christmans night....
Like I was saying. All this does is draw a playfield, simple and straight forward. I don't know what modifications would need to be done to make it work in a game environment. I don't want to think about that right now. With this code I've now officially lost my 2600 cherry ("Rescue Bira Bira" was just 'heavy petting'). And just like the real thing, it was a little painful at first, and was over before I knew it. And it left me wondering what all the fuss was about.
Special thanks to Nick Bensema's "How To Draw A Playfield" tutorial code. I will always think of you as my slutty friend who's done it many times and sat me down in the school cafeteria to tell me what to expect during my first time and how to handel it. In otherwords you're like Pheobe Cates in "Fast Times At Richmond High". ;)
And with no further delay, here is my simple (probably laughable simple) source code to draw a playfield (using data generated from a hypothetical playfield graphics editor that doesn't exist). ;)
------processor 6502
VSYNC = $00 ;this tells assembler what VBLANK = $01 ;the locations of all those funky WSYNC = $02 ;2600 codes are COLUPF = $08 ; COLUBK = $09 ;you can see that this demo doesn't really do CTRLPF = $0A ;much. PF0 = $0D ; PF1 = $0E ;I had also made some stupid 5:00 in the morning PF2 = $0F ;errors here that wouldn't let my first attempt CXCLR = $2C ;compile. Make sure you are well rested before you INTIM = $284 ;attempt to programme the Atari 2600 or you risk TIM64T = $296 ;losing your sanity. org $F000 start SEI ;setting up the 6507 CLD LDX #$FF TXS LDA #$00 zero STA $00,X ;zeroing out all the locations DEX BNE zero main JSR vertb ;this is the main loop of the programme JSR scrnvar ;starts with vertical blank then loads the screen JSR draw ;variables then draws the screen, then does the JSR oscan ;overscan, then does it all over and over again JMP main ;until you terminate the programme. scrnvar LDA #$00 ;make the playfield graphics black STA COLUPF LDA #$4F ;make the background pink STA COLUBK LDA #$01 ;reflect the left half of the playfield on the STA CTRLPF ;right RTS vertb LDX #$00 ;thank you Nick Bensema for teaching us all LDA #$02 ;how to do a vertical blank. STA WSYNC ;who knows if I could have figured out this one STA WSYNC ;on my own. I want to have your baby! STA WSYNC STA VSYNC ;<- here was one of my 5:00 in the morning errors. STA WSYNC ;I had typed WSYNC instead of VSYNC. Bleary eyes STA WSYNC ;and programming make a deadly combination! LDA #$2C STA TIM64T ;much like cheese burgers an loneliness. LDA #$00 STA CXCLR ;<- don't know why I left this in... but what the STA WSYNC ;heck it looks cute. STA WSYNC RTS draw LDA INTIM ;getting ready to draw the screen BNE draw STA WSYNC STA VBLANK LDY #$08 ;how many scanlines is each block? LDX #$17 ;number of blocks of data. LDY * LDX = 192! load LDA playf0,X ;load in the data for playfield 1 STA PF0 LDA playf1,X ;load in the data for playfield 2 STA PF1 LDA playf2,X ;load in the data for playfield 3 STA PF2 grfx STA WSYNC ;draw the scanline DEY ;decrease the block number BEQ block ;if it's zero it's time for a new block JMP grfx ;if not then repeat the previous scanline block TXA ;another 5 A.M. error had "LDA X" what was I on? BEQ clear ;checks to see if you've reached the last block. DEX ;if not then got ot the next block number. LDY #$08 ;set up for a new block. JMP load ;go load your new block of data in. clear LDA #$02 ;all done the screen. Now let's clear everything STA WSYNC ;and get ready for the next exciting screen. STA VBLANK ;which in this case, just happens to be the same LDX PF0 ;as the first. LDX PF1 ;isn't this fun? LDX PF2 RTS oscan LDX #$1E ;now we're getting ready to do the 30 lines of ;overscan waste STA WSYNC ;and in this demo we're just going blow them all DEX ;off. But in a real game you wouldn't waste all BNE waste ;these valuable cycles. Not unles you want a RTS ;really dull game. org $FF00 playf0 .byte $00 ;and here are the graphics for each block. My programme .byte $00 ;draws 24 blocks each is 8 scan lines high. 24*8=192 .byte $00 ;so by changing the values for LDY and LDX up in the .byte $00 ;draw routine you can alter your vertical resolution for .byte $00 ;your playfield graphics. Just make sure that both values .byte $00 ;multiply together to make 192. This will let you draw .byte $00 ;1*192=192 .byte $00 ;2*96 =192 .byte $00 ;4*48 =192 .byte $00 ;6*32 =192 .byte $00 ;8*24 =192 (also makes nice square blocks!) .byte $20 ;16*12=192 .byte $20 ;32*6 =192 (okay, we're getting rediculous) .byte $70 ;64*3 =192 .byte $f0 ;96*2 =192 .byte $f0 ;192*1=192 .byte $f0 ; .byte $e0 ;Anyways... also note that the graphics data here .byte $e0 ;is stored upsidedown. Trust me, it's much easier .byte $c0 ;to load it this way. .byte $80 ; .byte $00 ;Using this kind of drawing routine would make it easy .byte $00 ;to create a playfield graphics editor that will auto .byte $00 ;generate the playfield data in a text file. Then you playf1 .byte $00 ;can just cut and paste the data into your source code. .byte $00 ;But I honestly don't know how well my playfield drawing .byte $00 ;routine can be adapted to work in a game. Maybe our .byte $00 ;resident "2600 Gods" Nick Bensema or Bob Colbert can .byte $00 ;offer some criticism. .byte $00 ; .byte $00 ;Well that's about all I've got to say on the subject. .byte $00 ;It was actually a lot of fun figuring this stuff out .byte $00 ;and now that I've actually written my own code to draw .byte $00 ;a screen, the 2600 is a lot less scary now. .byte $10 ;But don't expect a game from me anytime soon. What i've .byte $10 ;just done now is the equivalent of a .byte $11 ;10 PRINT "HELLO" .byte $3b ;20 GOTO 10 .byte $7b ;basic programme. It's simple and probably silly, and no .byte $ff ;doubt the real programmers will look at it and laugh at .byte $ff ;me and say something like. "Feh! I could have done that .byte $ff ;whole thing with three lines of code!" .byte $ff ;But hey, we've all got to start somewhere. .byte $ff ;Anyways, feel free to muck about with this and draw your .byte $ff ;own playfield pictures by editing the data. Maybe we .byte $ff ;could have an informal "2600 playfield graphics art .byte $7c ;contest." .byte $30 ; playf2 .byte $00 ;incidently... if you don't know what this is supposed .byte $00 ;to be a picture of, try singing "Nanana nanana Nanana .byte $80 ;nanana" over and over while looking at the picture. .byte $80 ; .byte $c0 ; .byte $c0 ; CRACKERS .byte $c0 ; (Baby's first code from hell!!!!!!) .byte $e2 ; .byte $e2 ; .byte $f2 ; .byte $fa ; .byte $ff ; .byte $1f ; .byte $5f ; .byte $5f ; .byte $9f ; .byte $df ; .byte $cf ; .byte $af ; .byte $93 ; .byte $71 ; .byte $38 ; .byte $0c ;This code is PUBLIC DOMAIN. .byte $04 ;By Chris "Crackers" Cracknell, March 8, 1997 org $FFFC .word start .word start
------
Please please please give me lots of comments, and tips.
CRACKERS (Toweling off from hell!!!!!!!!)
--
Accordionist - Wethifl Musician - Atari 2600 Collector | /\/\ http://www.freenet. hamilton.on.ca/~ad329/Profile.html | \^^/ Bira Bira Devotee - FES Member - Samurai Pizza Cats Fan| =\/=
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Cracker's Easy Playfield Code.
SUBJECT: [stella] RGB monitor colors vs. Composite or Y/C POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Sat, 8 Mar 1997 15:27:01 -0800 (PST) POST: On Sat, 8 Mar 1997, Nick S Bensema wrote: > Huh? Uh, WHY? I'm just interested in which value makes a good yellow, > or a good blue. There's not much else to it.
For you maybe.
As someone who has done my share of computer graphics, knowing the actual RGB value of a color vs. a subjective name for that color is useful (as well as vice-versa). Just as graphic arts professionals know the difference between how colors look on a computer monitor vs. the printed page, developers should know the difference between a computer monitor and composite video.
> The truth about Atari hue-luminance video is that the luminance controls > saturation, not brilliance. $20 makes a deep red, which could easily > fade to white by incrementing to $2E and shifting to $0E. But you cannot > fade to black from it.
Okay, but it would be just as useful to have a table of the 128 color values the 2600 can produce just as it is useful to have a table of notes and their cent values.
If anyone is going to write a game exclusively on an emulator, for instance, get ready for a shock when your colors come out oversaturated and washed out on a real 2600 when they looked fine on your PCs monitor. That's why it is important to know the difference in look between an internal HSV or RGB value when sent to a composite or Y/C monitor and an RGB computer monitor.
Ultimately developers should pick colors based on how they look on a composite system. Knowing beforehand what it's going to look like without trial and error is useful.
I know I have yet to see a 2600 emulator where the colors truly looked _right_.
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
Glenn Saunders: Pointers on How TIA Controls Saturation of Colours and Not Luminance.
SUBJECT: [stella] Following up lots of threads POSTER: slapdash@xxxxxxxxxx (Russ Perry Jr) DATE/TIME: Sun, 9 Mar 1997 03:02:30 -0600 POST: [fedeedw@xxxxxxxxxxxxxxxxxxx (Edward Federmeyer), Re: Making carts]
>The only down side to producing carts this way is that it's only practical >for games of 4K or less. BUT, from other threads I read in this list, it >will be a while before games get that complicated. Perhaps by then, we can >get together on a design for a "generic" 8K/16K/whatever board, and make >enough for everyone, so that the per-board costs are lower.
Actually, I know someone else who's been tinkering with a board design, but a recent technical snag has slowed him down a little. He may subscribe to the list here; don't know. He'd sell boards to whoever needed them when the time came.
>Unfortunatly, they key to bank switched carts is inside the ROM chip >itself. No EPROM would have that kind of bank-switching built in.
>Ideally, we would have a "blank" board capable of taking a 74xx NOT gate >and standard 1/2/4K EPROM, or a few standard 74xx chips that impliment >bank switching, and a standard 8/16/32/64K EPROM.
It would be nice to have a board that could handle ANY size EPROM up to at least 64K. If a couple 74xx chips go unused because the board only has a 2K EPROM in it won't matter too much. ["Mike St. Clair"
>Based on the sample of responses so far, it seems that.
>a) The majority of the people on this list prefer carts, and believe that > the collecting clientele prefers carts.
At least over .BINs, that's for sure. But .BINs are better than nothing.
> As I stated once before, based on the response to Okie Dokie, I bet a > thousand carts could have been sold if it were even publicised on the > net and snailmail 'zines
I don't know about a thousand... EdTris got fair coverage even outside the net and hasn't sold half that many.
>2) Glenn is on the anti-cart side. Glenn may have what might be called a > conflict of interest, because [...] he'd like to see the fruits of > everyone's labor on this list end up on his next compilation CD.
I don't think Glenn is ANTI-cart. It's just that we went through a lot of trouble to put dev tools on the CD rather than just the games, and Glenn would like to see something happen with that. The truth is, making carts ISN'T that hard, but not everyone will be able to do it. Glenn is trying to point out that BINs are a convenient way to distribute games, and he is encouraging people to use that method of distribution over not doing anything.
>Just remember this, dear reader. YOU are the creator. You have ownership >rights over what you create.
Absolutely. The more the merrier.
[Glenn Saunders
>A good compromise would be to start out making carts (or tapes or CDs) >exclusively, and then only when the demand dries up or you've hit your >"maximum", release it as a .BIN, esentially making it P.D.
This isn't a bad idea. With carts, you can keep making them as long as you want, but it's a little harder with CDs, as you have a definite minimum order.
[Glenn Saunders
>I don't really concern myself with the non-connected public because it's a >pain in the ass to get the word on the street compared to the internet.
Except where the 2600 Connection and Digital Press are concerned. They have many readers who aren't wired but are exactly the people who you'd want to reach. And it doesn't take much effort. Beyond that, and maybe offering carts to various cart sellers, it's too hard, I agree.
[Carol Shaw,
>You've got the basic idea on River Raid: draw a sprite, move the player, >draw the next sprite, and so on. As I recall, the kernel was fairly >lengthy. There is the vertical scrolling, and there are places where two >players or a player and a missile must be drawn. I think I had several >successive loops. I always wondered if there was a more efficient way of >doing it. Sorry I can't be of more help.
[Note: Carol generally seems too busy, so I didn't go much beyond just forwarding the question someone had about River Raid. I won't forward any questions to her unless they are particularly interesting, as in general, she won't help.]
[Nick S Bensema
>I suggest that we turn the B&W switch into a PAL/NTSC switch
I like this idea a lot. As others have pointed out, it shouldn't be that difficult, especially not in Supercharger-only games.
//*======++ || Russ Perry Jr 1750 Lombard Ave #7 Oshkosh WI 54901-4135 || || 414-232-8246 slapdash@xxxxxxxxxx VIDEOGAME COLLECTOR! || ++======*//
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======SUNDAY, 9 MARCH ======Russ Perry Jr: Some Useful Correspondence from Carol Shaw on River Raid Down the Bottom.
SUBJECT: Re: [stella] NTSC - PAL porting guide POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Mon, 10 Mar 1997 12:39:06 +0100 POST: >But it could be calculated mathematically. If you establish that there >are 16 hues, and 8 luminances per hue, then you should be able to convert >HSV to RGB to get at the internal values the 2600 is attempting to >generate. I could probably do it if noone else wanted to.
It would be nice, if you could do this, because I don't know enough about colour systems to do it.
>> orange gold >> orange green grey >> light orange grey > >What seems odd about this is that the 16 hues on the left table do not >match up with the right table. There seem to be more hues available in >NTSC... For instance, there are no orangy hues in PAL, as these tend to >come out "grey". >
All the grey values might actually be a little bit different. That is why I wanted someone else to confirm this, because I am a little bit red-green blind.
The brighter versions of orangebrown look orange.
>Shouldn't the 2600 be able to generate all the same hues in PAL as it can >on NTSC?
No, while NTSC uses YIQ as it's colour space, PAL uses YUV. Since the TIA produces the same coordinates on both TV standarts, they result in different colours. Because the VCS only has 16 hues, they might not all have a corresponding hue in the 16 on the other TV system.
Thanks, Eckhard Stolberg
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======MONDAY, 10 MARCH ======Eckhard Stolberg: Why the 2600 Produces Different Colours on PAL and NTSC Systems.
SUBJECT: [stella] The TIA sound hardware POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Mon, 10 Mar 1997 12:39:11 +0100 POST: Hello there, yesterday I mentioned a text, that explains the TIA sound hardware. The file can be found in Ron Fries' TIASND10.ZIP, a TIA sound emulator engine. I have included the relevant parts here and hope it helps finding a frequency table.
Thanks, Eckhard Stolberg
======TIASOUND.C - TIA SOUND EMULATION V1.0 ======
As I'm sure you've already discovered, the Stella manual isn't always correct. My observations show what I believe to be several discrepancies in the description of the distortions. Of course, I could be wrong on a few of these, so if some of the games don't sound right, please let me know which ones. If possible, it would be best if you could send me a wave file of what it is supposed to sound like, preferably at 44 KHz. Only a few seconds should be necessary.
TIA AUDIO CIRCUITRY ======
THE HARDWARE ------
In general, the sound hardware can be described as follows:
Selecting the Clock Modifier - Bits D0 and D1 ------
Bits D0 and D1 select the output clock modifier:
D1 D0 ------0 0 - direct clock (pure) 0 1 - direct clock (pure) 1 0 - divide by 31 1 1 - 5-bit polynomial
The 'divide by 31' isn't simply the input clock divided by 31. It is, in essence, a 5-bit polynomial with only two bits set. The resulting square wave actually has a 13:18 ratio. This may be implemented in the hardware as a pair of traps on a 5-bit counter.
Selecting the Source Pattern - Bits D2 and D3 ------
Bits D2 and D3 select the source to be clocked:
D3 D2 ------0 0 - 4-bit polynomial 0 1 - pure (Q') 1 0 - 5-bit polynomial 1 1 - pure (Q')
The 'pure' tones are generated by toggling the output. Whenever a clock tick is received, the output will change states. I've used the notation Q' to indicate the 'logical NOT of the last output'. Note that since the output toggles, this can be thought of as a divide by 2 since the output frequency will be half of the input frequency. This is only true for the pure tones.
Selecting the Source Clock - Bits D2 and D3 ------
When bits D2 and D3 are both set, it affects the source clock. I believe the '30KHz' clock is actually the 3.58MHz clock divided by 114. When bits D2 and D3 are set, the input source is switched to the 1.19MHz clock, so the '30KHz' source clock is reduced to approximately 10KHz.
Exceptions - Selecting No Output or the 9-bit Polynomial ------
There are two exceptions that occur when bits D0-D2 are all 0. If AUDC is zero (0000), then I believe the output is set equal to the volume. If AUDC is equal to 8 (1000), the 9-bit polynomial is selected as the source to be clocked.
Updated Detailed Functions for AUDC ------
>From my observations, I would describe the distortion selections as follows:
HEX D3 D2 D1 D0 Clock Source Clock Modifier Source Pattern ------0 0 0 0 0 3.58 MHz/114 -> none (pure) -> none 1 0 0 0 1 3.58 MHz/114 -> none (pure) -> 4-bit poly 2 0 0 1 0 3.58 MHz/114 -> divide by 31 -> 4-bit poly 3 0 0 1 1 3.58 MHz/114 -> 5-bit poly -> 4-bit poly 4 0 1 0 0 3.58 MHz/114 -> none (pure) -> pure (~Q) 5 0 1 0 1 3.58 MHz/114 -> none (pure) -> pure (~Q) 6 0 1 1 0 3.58 MHz/114 -> divide by 31 -> pure (~Q) 7 0 1 1 1 3.58 MHz/114 -> 5-bit poly -> pure (~Q) 8 1 0 0 0 3.58 MHz/114 -> none (pure) -> 9-bit poly 9 1 0 0 1 3.58 MHz/114 -> none (pure) -> 5-bit poly A 1 0 1 0 3.58 MHz/114 -> divide by 31 -> 5-bit poly B 1 0 1 1 3.58 MHz/114 -> 5-bit poly -> 5-bit poly C 1 1 0 0 1.19 MHz/114 -> none (pure) -> pure (~Q) D 1 1 0 1 1.19 MHz/114 -> none (pure) -> pure (~Q) E 1 1 1 0 1.19 MHz/114 -> divide by 31 -> pure (~Q) F 1 1 1 1 1.19 MHz/114 -> 5-bit poly -> pure (~Q)
For the most part, this follows the Stella manual, but there are a few differences. Probably the most notable are hex entries 'A' and 'B', which are listed in the Stella manual as 'div 31: pure tone' and 'set last 4 bits to 1'.
On entries 'A' and 'B', both the data source and the clock have the same number of entries (31). Because of this, they will always align in the same way. Entry 'A' will then reduce to a pure 'div by 31' output which is identical to entry '6'. On 'B', both the source and the clock align in such a way that the output will always be 1.
THE POLYNOMIALS ------
The 4-bit, 5-bit, and 9-bit polynomials are essentially tables containing a random series of bits (they are implemented in hardware as shift registers). Because the tables are fixed in length, the 'random' pattern will repeat periodically.
The size of the table is described by its name. The actual size of the table is 2^x - 1, where x is either the 4, 5 or 9. The 4-bit polynomial has 15 entries, the 5-bit polynomial has 31 entries, and the 9-bit polynomial has 511 entries.
I've performed some analysis on the output of the actual Atari 2600, and believe I have the actual 4-bit and 5-bit polynomials used by the Atari. These have been encoded as byte arrays in my routines. For the 9-bit polynomial, I use a random number generator which should produce approximately the same results.
THE CLOCK ------
I believe the input clock for the audio is a division of the main system clock. With this assumption, I determined that the input clock for the audio is equal to the 3.58MHz system clock divided by 114. Note that this produces an actual audio clock of 31.4 KHz. This value closely matches the frequencies I recorded from my unit. The Stella manual describes the Audio Clock as approximately 30KHz, which I suppose is correct if you consider 5% to be approximate.
If both bits D2 and D3 of the AUDC register are set, I believe the TIA chip uses the 1.19MHz clock for the base audio clock instead of the 3.58MHz. This, of course, produces the 'divide by 3' functionality described in the Stella manual.
TiaSound is Copyright(c) 1996 by Ron Fries
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx Eckhard Stolberg: Information on TIA Sound.
SUBJECT: Re: [stella] unidentified short black lines POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Tue, 11 Mar 1997 11:43:57 +0100 POST: >I'm doing experiments with sprite reuse during the screen loop. >When I reposition a sprite, there's that short black line at the very left >of the screen. It must be impossible to avoid, as it appears in any game >that uses this technique (unless you've a black background of course). >Why does this happen?
Just a thought:
The manual says not to change the horizontal motion registers 24 cycles after a HMOVE. 24 plus 3 cycles for the STA is 27 cycles or 81 pixels. 81 minus 68 pixels for the horizontal blank is 13 pixels, which is about the length of the black lines on the left screen side. So it seems, that a HMOVE command halts all screen output untill it has finished updating its internal registers.
Ciao, Eckhard Stolberg
-- To unsubscribe, send the word UNSUBSCRIBE in the body of a message to stella-request@xxxxxxxxxxx
======TUESDAY, 11 MARCH ======Eckhard Stolberg: Speculation on Why There Are Short Black Lines.
SUBJECT: RE: [stella] Displaying scores - how? POSTER: Robert "A." Colbert <colbertb@xxxxxxxxxxxx> DATE/TIME: Tue, 11 Mar 1997 08:41:07 -0600 POST: Hi,
You may want to check out the source code for Cheetah. It uses the 6 digit code necessary. Please note that I wrote this code before I knew what I was doing so the movit routine is missing since it is ugly. It is basically just a delay loop and then a RESP0 and a RESP1. Here is an excerpt from the code: drawit lda #$03 ; set both players to 3 copies sta NUSIZ0 sta NUSIZ1 lda #$01 ; set vertical delay on for both players sta VDELP0 sta VDELP1 ldx #$6 ; move players 12 columns over ldy #$0 jsr movit lda #$f0 ; set player 0 to move left 1 pixel sta HMP0 sta WSYNC sta HMOVE ; move player 0 sec lda SCANLINE ; adjust scanline count sbc GRHEIGHT sta SCANLINE loop2 ldy GRHEIGHT lda ($AA),y ; get player0 copy1 data sta GRP0 sta WSYNC lda ($AC),y ; get player1 copy1 data sta GRP1 lda ($AE),y ; get player0 copy2 data sta GRP0 lda ($B0),y ; get player1 copy2 data sta $E9 lda ($B2),y ; get player0 copy3 data tax lda ($B4),y ; get player1 copy3 data tay lda $E9 sta GRP1 stx GRP0 sty GRP1 sta GRP0 dec GRHEIGHT bpl loop2 ; loop until done lda #$00 ; clear player graphics sta GRP1 sta GRP0 rts
>Reply to your message of 3/11/97 7:54 AM >Before I spend a week barking up the wrong tree, can someone reveal how >2600 games display scores? (not playfield like Combat, I mean high-res >like Missile Command, Millipede, Defender, Pac-man, etc.) I suspect its >three copies of each player, rewriting GRP0 and GRP1 between display of >each copy.. am I right? This would account for the six-digit limit on >all 2600 games I've seen except Dark Cavern, which had three dummy zeroes >anyway. > >If I'm right, is there any easy way to rip the font used in one of those >games so I don't have to reinvent the wheel? (also, using the same >typeface might lend an air of classic-game credibility to the program.) >End of message
Your Name Father Flanagan's Boys' Home Your E-Mail address Your phone and fax number (optional)
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Bob Colbert:Â High Resolution Scores.
SUBJECT: Re: [stella] Displaying scores - how? POSTER: Greg Troutman <mor@xxxxxxx> DATE/TIME: Tue, 11 Mar 1997 08:03:18 -0800 POST: Erik K Mooney wrote: > > Before I spend a week barking up the wrong tree, can someone reveal how > 2600 games display scores? (not playfield like Combat, I mean high-res > like Missile Command, Millipede, Defender, Pac-man, etc.) I suspect its > three copies of each player, rewriting GRP0 and GRP1 between display of > each copy.. am I right? This would account for the six-digit limit on > all 2600 games I've seen except Dark Cavern, which had three dummy zeroes > anyway.
I've been looking at this and yes, triple-copy sprites in both player graphics registers are rewritten before the duplication of the image takes place. Here's a section from Nick's annotated Defender disassembly, which I've added to:
;======
;// ;We've just scanned down toward the bottom of the screen and will set ;up to draw the score. ;//
LDA #$03 ;triple copy sprites STA NUSIZ0 STA NUSIZ1 ;for both player objects LDY #$06 ;Y=6 which is the height of the graphics (BPL ;makes 7) STX VDELP0 ;X=1 turn on vertical delay for both players STX VDEL01 STY $93 ;memory variable to store current scanline ;during draw STY WSYNC ;newline, start counting
;// ;I'm not sure about the actual pixel locs here. The Stella text is ;confusing on this issue and I need to do some more trial and error to ;really get this down. I'm only noting the real positions without any ;assumption on TIA re-loading cycles. I'm counting pixel locs from ;the beginning of WSYNC, including the 68 off the left side of the ;screen. Any correction/clarification would be of great help to me ;here... ;//
LF805: DEY ;14 BPL LF805 ;20 NOP ;2 ;loop totals 36 cycles
STA RESP0 ;P0 at pixel 108? STA RESP1 ;P1 at pixel 117? LDA #$F0 ;shift P0 one posn to the right (109?) STA HMP0 ;load the motion register for P0 STA WSYNC ;newline STA HMOVE ;reset both players to new horizontal positions
;// ;If the TIA only processes RESP0 every 15 pixels as has been stated, ;then the above numbers would not make sense to me. P0 would end up at ;121, and P1 would be 120... ??? ;//
LDY #$FE ;preload new pattern for PF2 LDA $E8 ;playfield color STA COLUPF ;load it STA WSYNC ;newline ;// ;Use center 14 bits of playfield (56 pixels) as a backdrop for the ;score) ;//
STY PF2 ;by placing %11111110 here (in reflect mode) LDX $EC ;color for the digits STX COLUP0 STX COLUP1 ;loaded into each player
;// ;Here's the meat and potatoes. ; ;$EF through $FA is a 12 byte RAM area that holds a sequence of 6 16bit ;pointers to the digit graphics. This section of memory can be reused ;for other 6 byte (48 pixel) graphics that want to use this routine by ;reloading it with the necessary pointers. The Y index reads into the ;graphics to get the bits for the current line being drawn. ; ;You can see this technique in Okie Dokie, where Bob reloads the game ;title and the Retroware logo (and presumably the score) into a buffer ;that works just like this--though Defender seems to load that buffer ;in reverse order from Okie Dokie. ; ;The font is at the end of the source listing and you would use it by ;translating the score and loading the appropriate pointer for each ;digit into the buffer at $EF. I didn't notice where Defender does ;that, but it's in there somewhere ;) ;//
LF825: LDY $93 ; (61) +3 ;current line LDA ($F9),Y ; p0 p1 (64) +5 ;indirect indexed STA GRP0 ; F9 (69) +3 STA WSYNC ; Cycle count begins LDA ($F7),Y ; (0) +5 STA GRP1 ; F7 (5) +3 LDA ($F5),Y ; (8) +5 STA GRP0 ; F5 (13) +3 LDA ($F3),Y ; (16) +5 STA $94 ; (21) +3 LDA ($F1),Y ; (24) +5 TAX ; (29) +2 ;preload X LDA ($EF),Y ; (31) +5 TAY ; (36) +2 ;and Y LDA $94 ; (38) +3 ;and A STA GRP1 ; F3 (41) +3 ;reload GRP at pixel ;123? STX GRP0 ; F1 (44) +3 STY GRP1 ; EF (47) +3 ;reload GRP at pixel ;141? STA GRP0 ; F3 (50) +3 DEC $93 ; (53) +5 BPL LF825 ; Branch taken, so (58) +3 ; End six-digit loop
;// ;Wow. The above loop just drew the score with no cycles to spare. ;// LDA #$00 STA VDELP0 ;Clear vertical delays STA VDEL01 STA GRP0 ;Clear players STA GRP1 STA HMP0 ;Clear missiles. ;======
After resetting stuff, it's done. This code is re-used by lots of games and is one of those amazing "tricks" that allowed 2600 games to step up to the next level in appearance... I'm not exactly sure how it all works, but it does, and I've managed to twiddle it to work with different pixel locs, though I'm still trying to break it down into some kind of formula that has eluded me so far. It's pretty impressive stuff, IMO. What I really like about this routine is that you don't have to limit yourself to 6 digits. You could do some bit diddling and stuff a sort of proportional font into your 48 bit pixel pattern to print as many as 8-10-12 characters/digits.
> If I'm right, is there any easy way to rip the font used in one of those > games so I don't have to reinvent the wheel? (also, using the same > typeface might lend an air of classic-game credibility to the program.)
This is a nice font that anyone should recognize, so go for it.
-- mor@xxxxxxx http://www.crl.com/~mor/
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Greg Troutman: More on High Resolution Scores.
SUBJECT: [stella] Etch-a-sketch source code POSTER: Robert "A." Colbert <colbertb@xxxxxxxxxxxx> DATE/TIME: Tue, 11 Mar 1997 10:37:47 -0600 POST: Hi, I promised you this a while back! This is my Etch-a-sketch emulator for the 2600! Please feel free to comment on it. It only works on PC Atari 1.4 and above or a real Supercharger since it uses supercharger RAM. Compiling this code creates an 8448 byte .bin. If you want to try this on a regular 2600, try removing all of the lines from "org $e800" on (near the end) and the "org $c800 / .byte $00" lines (at the beginning), these were included to make an acceptable .bin for the emulator, but I'm not sure if the checksums are o.k. for a real SC. At any rate, removing those lines will give you a 4096 byte file that you can then use with makewav to create a good .wav.
Bob Colbert
---- Begin of code --
; Here is my Etch-a-sketch emulator ; Please do not distribute this code ; As I plan on finishing it up sometime soon! ; The joysticks are used right for various reasons ; Sometime I would like to use the Paddles, but that ; would take some serious coding. ; the reset button clears the screen, and the select button ; changes the drawing mode. ; ; This only works on a real SC and PC Atari Emulator right now!!! ; ; HAVE FUN!!! ; ; Code Copyright 1997 by Bob Colbert! (It will be freeware when I'm done!) ; ; Compile using DASM etch.s -f3 -oetch.bin ; processor 6502
VSYNC = $00; VBLANK = $01; WSYNC = $02; RSYNC = $03; NUSIZ0 = $04; NUSIZ1 = $05; COLUP0 = $06; COLUP1 = $07; COLUPF = $08; COLUBK = $09; CTRLPF = $0A; REFP0 = $0B; REFP1 = $0C; PF0 = $0D; PF1 = $0E; PF2 = $0F; RESP0 = $10; POSH2 = $11; RESP1 = $11; RESM0 = $12; RESM1 = $13; RESBL = $14; AUDC0 = $15; AUDC1 = $16; AUDF0 = $17; AUDF1 = $18; AUDV0 = $19; AUDV1 = $1A; GRP0 = $1B; GRP1 = $1C; ENAM0 = $1D; ENAM1 = $1E; ENABL = $1F; HMP0 = $20; HMP1 = $21; HMM0 = $22; HMM1 = $23; HMBL = $24; VDELP0 = $25; VDEL01 = $26; VDELBL = $27; RESMP0 = $28; RESMP1 = $29; HMOVE = $2A; HMCLR = $2B; CXCLR = $2C;
CXM0P = $30; CXM1P = $31; CXP0FB = $32; CXP1FB = $33; CXM0FB = $34; CXM1FB = $35; CXBLPF = $36; CXPPMM = $37; INPT0 = $38; INPT1 = $39; INPT2 = $3A; INPT3 = $3B; INPT4 = $3C; INPT5 = $3D;
SWCHA = $280; SWACNT = $281; SWCHB = $282; SWBCNT = $283; INTIM = $284; TIM1T = $294; TIM8T = $295; TIM64T = $296; T1024T = $297;
page equ $81 tempvar equ $82 char1 equ $84 char2 equ $86 char3 equ $88 char4 equ $8a char5 equ $8c char6 equ $8e char7 equ $90 char8 equ $92 char9 equ $94 char10 equ $96 char11 equ $98 char12 equ $9a charx equ $9c tmpadrlo equ $9e tmpadrhi equ $9f enable equ $a0 xpos equ $a1 ypos equ $a2 sclin equ $a3 temp2 equ $a4 mode equ $a5 lastmode equ $a6 pgcount equ $a7 temp equ $a8 hknob equ $a9 vknob equ $aa hkdata equ $ab vkdata equ $ac org $c800
.byte $0 org $d000 cld clc lda $80 ora #$02 sta enable ldx #$17 loop5 lda table1,x sta char1,x dex bpl loop5 restart lda #$0 sta page sta pgcount sta xpos sta ypos sta hknob sta vknob sta mode Start ldy #$10 jsr junk Start1 inc page inc pgcount lda #$00 ;get contents of memory sta PF0 sta PF1 sta PF2 ;save into a pattern control register sta COLUBK lda #$01 sta CTRLPF ;set background control register lda #$42 sta COLUPF lda #$04 sta COLUP1 ;set right side color sta COLUP0 ldy #$57 sty WSYNC ;wait for horizontal sync lda #$02 ora INPT0 sta VBLANK ;start vertical blanking sty VSYNC ;start vertical retrace lda #$2A sta TIM8T ;set timer for appropriate length Loop4 ldy INTIM bne Loop4 ;waste time sty WSYNC ;wait for horizontal sync sty VSYNC ;end vertical retrace period lda #$24 sta TIM64T ;set timer for next wait
Loop3 ldy INTIM bne Loop3 ;waste time sty WSYNC ;wait for horizontal sync lda #$00 sta VBLANK ;end vertical blanking sty WSYNC sty WSYNC lda #$e4 sta sclin sta WSYNC lda #$00 sta PF0 sta PF2 sta REFP0 sta HMP1 lda #$03 sta NUSIZ0 sta NUSIZ1 loop6 stx WSYNC ldx sclin cpx #$e4 bne bb1 lda #$7f sta PF1 lda #$ff sta PF2 bb1 cpx #$D0 beq b2 dec sclin bne loop6 b2 lda page and #$01 tax jsr drawit lda #$7f sta PF1 lda #$ff sta PF2 lda #$0 ldy #$5 jsr junk sta NUSIZ0 sta NUSIZ1 lda #$7 sta COLUP0 sta COLUP1 sta WSYNC ldy #$2 jsr delay sta RESP0 ldy #$2 jsr delay sta RESP1 sta WSYNC ldy #$6 jsr drawknobs ldy #$8 jsr junk lda #$0 sta PF1 sta PF2 ldy #$1 jsr junk lda mode sta PF1 ldy #$08 jsr junk lda #$0 sta PF1 lda INPT4 and #$80 beq ckjoystk ldy mode nojoy lda pgcount cmp modespeed,y beq ckjoystk lda modewait,y tay jsr junk jmp z1 ckjoystk lda #$0 sta pgcount sta temp lda SWCHA and #$f0 eor #$f0 bne joymovd ldy #$4 jsr junk jmp z3 joymovd eor #$f0 ldy mode cpy #$1 bne mode2 pha jsr plot pla mode2 ldy #$2 jsr junk rol bcs joy1 ldy xpos cpy #$5f beq joy1 inc xpos dec hknob joy1 rol bcs joy2 ldy xpos cpy #$0 beq joy2 dec xpos inc hknob joy2 ; sta WSYNC rol bcs joy3 ldy ypos cpy #$0 beq z1 dec ypos inc vknob joy3 rol bcs z1 ldy ypos cpy #$77 beq z1 inc ypos dec vknob z1 jsr plot z3 ldy #$0 lda SWCHB ror bcc reset ror bcc select lda mode cmp #$5 beq reset sty lastmode jmp Start reset lda mode cmp #$5 beq reset0 lda #$5 sta mode lda #$77 sta ypos reset0 lda #$5f sta xpos reset1 jsr plot lda xpos clc sbc #$7 sta xpos bpl reset1 dec ypos bmi reset2 jmp Start1 reset2 jmp restart select iny cpy lastmode beq oldsel sty lastmode dey sty pgcount inc mode lda mode cmp #$4 bmi oldsel sty mode oldsel jmp Start junk sta WSYNC dey bpl junk rts drawknobs lda #$1 sta temp dk ldy temp lda hknob,y cmp #$14 bne dk0 lda #$0 sta hknob,y dk0 cmp #$ff bne dk1 lda #$13 sta hknob,y dk1 tay ldx #$8 lda knoblist,y bmi dk1a ldx #$0 dk1a ldy temp stx REFP0,y stx temp2 and #$ff clc adc #$0 sta hkdata,y dec temp bpl dk sta WSYNC dk1b lda #$6 sta temp dk2 ldx #$1 dk2a lda hkdata,x sta temp2 and #$7f clc adc temp tay lda knobs,y ldy temp2 bpl dk2b clc ror dk2b sta GRP0,x dex bpl dk2a sta WSYNC dec temp bpl dk2 lda #$0 sta GRP0 sta GRP1 sta REFP0 sta REFP1 sta WSYNC rts subtim sty temp lda sclin clc sbc temp rts delay dey bpl delay rts drawit lda #$01 ldy #$05 sta WSYNC loop1 dey bpl loop1 txa sta RESP0 clc ror ror tax nop nop sta RESP1 adc #$70 sta HMP0 txa clc adc #$40 sta HMP1 sta WSYNC sta HMOVE lda #$77 sta tempvar tay lda #$70 sta PF1 lda #$00 sta PF2 lda #$04 cpx #$0 bne loop2b loop2 lda (char11),y sta charx sta WSYNC lda (char5),y tax lda (char1),Y sta GRP0 lda (char7),y sta GRP1 nop cmp tempvar lda (char3),y sta GRP0 nop stx GRP0 nop nop lda (char9),y sta GRP1 lda charx sta GRP1 dey bpl loop2 sty tempvar lda #$00 sta GRP1 sta GRP0 rts loop2b lda (char12),y sta WSYNC sta charx lda (char6),y tax lda (char2),Y sta GRP0 lda (char8),y sta GRP1 nop cmp tempvar lda (char4),y sta GRP0 NOP stx GRP0 nop nop lda (char10),y sta GRP1 lda charx sta GRP1 dey bpl loop2b sty tempvar lda #$00 sta GRP1 sta GRP0 rts table1 .byte
----End of Code----
Wanna write a game for the Atari 2600? Check out http://www.novia.net/~rcolbert
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Bob Colbert: Etch-a-Sketch for 2600.
SUBJECT: [stella] More playfield graphics (thanks Nick!) POSTER: emooney1@xxxxxxxx (Erik K Mooney) DATE/TIME: Tue, 11 Mar 1997 17:42:28 EST POST: Got a chance to spend most of today sitting down and hacking out some code.. I started from Nick's "How to Draw a Playfield", and modified some stuff. The scrolling is the most difficult part to understand about Nick's code (there's a lot of math in there to process the scrolling, that you wouldn't need in a real game), and the reversed storage of the playfield patterns is also confusing, so here's a simplified version for anyone who had trouble with the first one.
This works on PC Atari for me.. I don't have a Supercharger yet (ordered one, though) so I'd appreciate it if someone with a 'charger could test it for me. thanks!
BEGIN ;How to Draw a Playfield II, by Erik Mooney (emooney@xxxxxxxxxxxxxxxx) ;Heavily indebted to Nick S. Bensema's "How to Draw a Playfield" (thanks!) ;I removed most of Nick's comments.. refer to the original for more ;complete documentation. ; ;This program draws a bunch of colorful vertical stripes on the screen ;using the playfield. It also does some minimal joystick reading, ;to demonstrate how to do that. ;Use DASM to assemble. ; ; A diagram of the entire frame output by the TIA: ; ------; | VSYNC period (3 scanlines, 3*76 = 228 machine cycles | 3 ^ ; | Set VSYNC=1 at beginning, VSYNC=0 at end | | ; +------+ | ; | Vertical Blank time (37 scanlines, 2812 cycles) | | ; | Set VBLANK=0 at end | 37 2 ; | | 6 ; | | 2 ; +------+------+ ; |Horizontal | | ^ s ; |Blank | Actual TV Picture | | c ; | | <----160 pixels (53 cycles)----> | | a ; |68 pixels | 192 scanlines (pixels) tall | 192 n ; |(23 cycles) | | | l ; |wide, 192 | | | i ; |scanlines | | V n ; |tall | | e ; +------+------+ s ; | Overscan (Set VBLANK=1 at the beginning) | | ; | 30 scanlines (2280 cycles) | 30 | ; | | | ; +------+ V ; ; <------228 pixels, 76 machine cycles------> include vcs2600.h ;same as Nick's posted vcs.h except the directive org $F000 ;"processor 6502" was moved into vcs2600.h
Score0 = $80 ;RAM locations Score1 = $81 Joystick0 = $90
Start
SEI ; Disable interrupts, if there are any. CLD ; Clear BCD math bit. LDX #$FF TXS ; Set stack to top of RAM.
LDA #0 ;Zero everything except VSYNC. B1 STA 0,X DEX BNE B1
; At this point in the code we would set up things like the data ; direction registers for the joysticks and such.
JSR GameInit
MainLoop JSR VerticalBlank ;Execute the vertical blank. JSR CheckSwitches ;Check console switches. JSR GameCalc ;Do calculations during Vblank JSR DrawScreen ;Draw the screen JSR OverScan ;Do more calculations during overscan JMP MainLoop ;Continue forever.
VerticalBlank ;Beginning of the frame - at the end of overscan. LDA #2 ;VBLANK was set at the beginning of overscan. STA WSYNC STA WSYNC STA WSYNC STA VSYNC ;Begin vertical sync. STA WSYNC ; First line of VSYNC STA WSYNC ; Second line of VSYNC.
; Atari says we have to have 37 scanlines of VBLANK time. Since ; each scanline uses 76 cycles, that makes 37*76=2888 cycles. ; We must also subtract the five cycles it will take to set the ; timer, and the three cycles it will take to STA WSYNC to the next ; line. Plus the checking loop is only accurate to six cycles, making ; a total of fourteen cycles we have to waste. 2888-14=2876. ; ; We almost always use TIM64T for this, since the math just won't ; work out with the other intervals. 2880/64=44.something. It ; doesn't matter what that something is, we have to round DOWN.
LDA #44 ;Set timer to activate during the last line of VBLANK. STA TIM64T ; ; Now we can end the VSYNC period. ; LDA #0 STA WSYNC ; Third line of VSYNC. STA VSYNC ; Writing zero to VSYNC ends vertical sync period. RTS
CheckSwitches LDA #0 ;Clear collision latches STA CXCLR ;In a real game, we'd probably check the collision ;registers before clearing them. LDA SWCHA ;Read joystick 0 STA Joystick0 ;Store for later use RTS
GameCalc LDA #0 STA COLUBK ;Background will be black.
LDA Joystick0 ;Load the joystick switches AND #$F0 ;Only care about top four bits, which is joystick 0 CMP #$F0 ;If top four=1111, stick centered, don't change BEQ NoStick LDA #$88 ;otherwise, make the background medium blue STA COLUBK NoStick
LDA #$55 ;Alternate pixels: 01010101 = $55 STA PF0 STA PF2 ;Store alternating bit pattern to the playfield registers ASL ;Because PF1 displays in the opposite bit order from PF0 STA PF1 ;and PF2, we need 10101010 instead of 01010101. LDA #1 STA CTRLPF ;Let's reflect the playfield just cause we feel like it =) RTS
;To refresh your memory: ; PF0 | PF1 | PF2 ; 4 5 6 7|7 6 5 4 3 2 1 0|0 1 2 3 4 5 6 7 ;This pattern is the left half of the screen; it's then either repeated ;or reflected depending on bit 0 of CTRLPF. For a playfield that doesn't ;repeat or reflect, you'd have to alter the playfield registers in the ;middle of each scanline. DrawScreen LDA INTIM BNE DrawScreen ;Loops until the timer is done - that means we're ;somewhere in the last line of vertical blank. STA WSYNC ;End the current scanline - the last line of VBLANK. STA VBLANK ;End the VBLANK period. The TIA will display stuff ;starting with the next scanline. We do have 23 cycles ;of horizontal blank before it displays anything.
LDY #192 ;We're going to use Y to count scanlines.
;Everything is already set, so let's just count scanlines. ;We're at the beginning of WBLANK of the first TV line right here. ScanLoop STY COLUPF ;Keep changing the playfield color every line for some ;neat-looking stripes. STA WSYNC ;Wait for end of scanline DEY BNE ScanLoop ;Count scanlines. RTS
OverScan ;We've got 30 scanlines to kill. LDX #30 ;In a real game, we'd probably be doing calculations here, KillLines ;possibly using the timer again to tell us when overscan STA WSYNC ;is done instead of counting the scanlines. DEX BNE KillLines RTS
GameInit ;Usually called to start a new game.. we're not using it yet. LDA #0 ;Just example code to show what could be done here. STA Score0 STA Score1 RTS
;Starting positions for PC org $FFFC .word Start .word Start
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Erik Mooney: How to Draw a Playfield II.
SUBJECT: [stella] counting time instead of lines (was: Re: More playfield graphics(thanks Nick!)) POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Wed, 12 Mar 1997 15:57:48 +0100 POST: At 17:42 -0500 11-03-1997, Erik K Mooney wrote:
> LDY #192 ;We're going to use Y to count scanlines. > >;Everything is already set, so let's just count scanlines. >;We're at the beginning of WBLANK of the first TV line right here. >ScanLoop > STY COLUPF ;Keep changing the playfield color every line for some > ;neat-looking stripes. > STA WSYNC ;Wait for end of scanline > DEY > BNE ScanLoop ;Count scanlines. > RTS
I'm currently working on a demo program that includes sprite reuse and multiple copies. I have a lot of problems with the kernel (the 192, or >200 for Pal, scanlines loop) because it's not obvious to know how many lines I've already drawn and how many are still to be drawn. This happens because the screen is divided into zones of different height which change according to various game parameters. I think this is a common problem as soon as games becomes complex, and you haven't planned everything from the beginning (tell me which Atari 2600 programmer ever planned everything...? :-) )
The consequence is that almost every time I improve the program, I lose the color or vertical sync (or both!) because I haven't drawn the correct number of lines before overscan and vblank. This is very annoying and slows down the developement.
Now I have this idea: why don't we handle the kernel loop with a timer, like we do for Vblank?
In practice:
- start a timer for 192*76 cycles - begin the scanlines loop
- draw the lines
- close the loop, we must be sure that we've drawn no more than 192 lines - wait until the timer is expired, thus drawing the missing lines
This way the correct number of lines will always be drawn regardless of what happened during the inner loop, where we could have drawn 188, 190 or so lines.
A possible problem could be that TIM64 isn't enough for so many cycles, so we could have to use TIM1024 followed by TIM64. I hope I've been clear enough. I'll try this idea this evening :-) - let me know what you think.
Ciao,
P.
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======WEDNESDAY, 12 MARCH ======Piero Cavina: Counting Time Instead of Lines.
SUBJECT: [stella] 21 objects for the price of 1 (demo - binary) POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 13 Mar 1997 11:48:31 +0100 POST: This demo shows some ideas discussed on this list put in practice, in particular:
- sprite reuse - multiple copies with independent control - pal/ntsc option using the bw/color switch (limited to screen size, not colors) (ok, this was a Nick's idea!)
This program will likely be the ground for a game I'm planning (- thought it won't be a vertical shooter as you might think after seeing the demo!). I must say that I've stolen a little piece of code from "Air sea battle". It's the routine that converts X coordinates to the FC_X format (fine+coarse nibbles): I don't even know how it works, but it works very well! :-) Thanks to everybody on this list for the help given. Comments are welcome.
Ciao, P.
======THURSDAY, 13 MARCH ======Piero Cavina: 21 Objects for the Price of One.
SUBJECT: 6.3 -->
[no subject]
From: Glenn Saunders <krishna@xxxxxxxxxxxx> POSTER: te: Thu, 13 Mar 1997 11:56:03 -0800 DATE/TIME: tr> |
With all this talk of sound lately, I thought I'd repost this.It's a utility found on Dennis Caswell's source disk for Escape from the Mindmaster which was salvaged and cleaned up by Jim Nitchals after the CD was mastered.
It uses paddles to test the sound.
Attachment: 2600demo.bin POST: Description: Binary data
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| [stella] 21 objects for the price o, Piero Cavina | Thread | [stella] Supercharger Bankswitches , Chrissalo |
| [stella] 21 objects for the price o, Piero Cavina | Date | [stella] Supercharger Bankswitches , Chrissalo |
| Month |
Glenn Saunders: Sound Utility for 2600.
SUBJECT: Re: [stella] Supercharger Bankswitches and RAM access! POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Sat, 15 Mar 1997 14:37:12 +0100 POST: I should have send this to the group instead of email!
>I need to know what kind of instructions will be used for value >specification, >so far I take absolut, absolut-x, absolut-y, indirect-x and indirect-y.
Instructions don't matter. All accesses of addresses between $F000 and $F100 cause an internal write register to be set to: accessed address minus $F000. >What kind of instructions will be used for poking? >(absolut, absolut-x, absolut-y, indirect-x and indirect-y) >I know for sure CMP,AND,BIT,LDA, are there any others?
Again intructions don't matter. The value is stored to the address that is accessed 3 or 4 processor cycles after the access to $F0xx. I am not sure about the timing though. But indirect accesses work too and they first have to read the address from the zeropage, which takes some cycles. Also in my programm I have to put a NOP between the two accesses, like
CMP $F000,X NOP CMP $FFF8 or otherwise the programm would crash, because it writes to a wrong address.
>How is the value determined using indirect-x and indirect-y? >How is the address determined using indirect-x and indirect-y?
The value is accessed address minus $F000 The address to write to is the address that is accessed 3 or 4 cycles after the access to $F0xx.
>Which instruction preserve the value, which instructions don't? >(All implied instruction?) (for sure I know: NOP,TAX,TAY)
I don't know for sure, but I think, that the Supercharger behaves as if an address containing $00 was accessed by the intruction, that caused the write. So all registers and flags should be set accordingly.
>Since address fields below 0xf000 initiate a poke, what about addresses in >that >region that are poked to, is it possible, if so can a poke follow directly?
I don't know if it is possiblbe, but I think it is unwise to try it, because the access that finishes the write would initiate another write.
Also you should keep in mind, that the controll byte at $FFF8 allways is write enabled.
>PS. My stella now runs Frogger, Dragonstomper, Rabbit and a few others > It doesn't run (well) Suicide Mission, Phasor Patrol, Communists...
Does this include the load capability of Dragonstomper or do you mean only the first part?
Ciao, Eckhard Stolberg p.s.: This is only my theory about how the writing mechanism works. Please correct me, if I am wrong.
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======SATURDAY, 15 MARCH ======Eckhard Stolberg: Answering Question about Supercharger Bankswitching and RAM Access. SUBJECT: Re: [stella] Displaying scores - how? POSTER: emooney1@xxxxxxxx (Erik K Mooney) DATE/TIME: Sat, 15 Mar 1997 19:11:12 EST POST: Argh, stupid mailer.. ah well.. here's a resend of that message that got completely garbled. Direct private replies to emooney@xxxxxxxxxxxxxxxxxxxxxxx, because that's where I'll be. (I'm on spring break this week)
>LF805: DEY ;14 > BPL LF805 ;20 > NOP ;2 ;loop totals 36 cycles > > STA RESP0 ;P0 at pixel 108? > STA RESP1 ;P1 at pixel 117? > LDA #$F0 ;shift P0 one posn to the right (109?)
>;If the TIA only processes RESP0 every 15 pixels as has been stated, >;then the above numbers would not make sense to me. P0 would end up >;at 121, and P1 would be 120... ???
I'm pretty sure the TIA processes a write to RESP0 as soon as it gets it (when the instruction completes), but it can take up to five cycles (fifteen pixels) to write the register. A standard STA RESP0 takes three cycles, but STA allows indexed indirect addressing, which takes five. In this case, the players end up at pixels 109 and 117 as stated in your comments.
I suspect the _real_ reason for HMP0, though, is that a DEY/BNE loop takes five cycles (fifteen pixels) per iteration, making it easy to use such a loop and HMxx to position an object at any position.
>LF825: LDY $93 ; (61) +3 ;current line > LDA ($F9),Y ; p0 p1 (64) +5 ;indirect indexed > STA GRP0 ; F9 (69) +3 > STA WSYNC ; Cycle count begins > LDA ($F7),Y ; (0) +5 > STA GRP1 ; F7 (5) +3 > LDA ($F5),Y ; (8) +5 > STA GRP0 ; F5 (13) +3 > LDA ($F3),Y ; (16) +5 > STA $94 ; (21) +3 > LDA ($F1),Y ; (24) +5 > TAX ; (29) +2 ;preload X > LDA ($EF),Y ; (31) +5 > TAY ; (36) +2 ;and Y > LDA $94 ; (38) +3 ;and A > STA GRP1 ; F3 (41) +3 ;reload GRP at >pixel ;123? > STX GRP0 ; F1 (44) +3 > STY GRP1 ; EF (47) +3 ;reload GRP at >pixel ;141? > STA GRP0 ; F3 (50) +3 > DEC $93 ; (53) +5 > BPL LF825 ; Branch taken, so (58) +3 > ; End six-digit loop
Is this right: $EF = ones digit, $F1 = tens digit, $F3 = hundreds digit, ... , $F9 = hundred-thousands digit? And the digits begin at pixels 109, 117, 125, 133, 141, and 149 (cycles 36, 39, 41, 44, 47, and 49.) Writes to registers take effect when the instruction completes, so your "Reload GRP1 at 123" actually executes at 132, in time for the hundreds digit... the next STX GRP0 finishes at 141, just in time for the tens digit, and your "Reload GRP1 at 141" takes effect at 150, apparently one pixel too late, but my guess is that the leftmost bit of the displayed byte is always 0 (to provide at least a one-pixel gap between digits) so it still works.
I see what's going on here, especially the tricky STA $94 and then loading it again because we need to use A to load the other bytes because LDX and LDY don't permit indexed indirect addressing. I don't quite understand what the last STA GRP0 is for, though (at cycle (50)+3 ) .. it completes at cycle 53 = pixel 159, which is after the score is done displaying on that line. I also don't see how the STA GRP0 at cycle (69)+3 helps either.. it looks like its preloading GRP0 for the hundred-thousands digit on the next scanline (its executing before WSYNC), but GRP0 gets rewritten with the thousands digit ($F5) at cycle (13)+3, pixel 48 of the next line.. that's within horizontal blank, before the hundred-thousands digit gets displayed.
I'm pretty sure the last digit of Defender's score is always 0.. it doesn't look like it's hardcoded to display 0, though. I forget at the moment if it displays a hundred-thousands digit (the code would seem to indicate it doesn't), and I don't feel like playing the game that long just to see =) Other games like Missile Command and Millipede display six unrestricted digits, though, so it's gotta be possible.
One more thing - you list BPL as taking three cycles if the branch is taken.. my 6502 reference says conditional branches take 4 cycles, though...? PC Atari's debugger adds nine pixels for a taken branch, so I guess it is three, but I'd like to know for sure.
>;// >;Wow. The above loop just drew the score with no cycles to spare. >;//
That says it all =) I'll try disassembling a couple other games and see if I can figure anything else out.
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Erik Mooney: Confused about Displaying High Res Scores.
SUBJECT: [stella] Trick to avoid black line on screen after HMOVE ? POSTER: kingkong@xxxxxxxxxxxxxxxx DATE/TIME: Tue, 18 Mar 1997 16:28:18 +0100 POST: There is always a short black line at left of screen after HMOVE (when not done in Vertical Blank) following a WSYNC.
Some games like HERO, Decathlon and Enduro just 'skipped' the first two bits of PF0, so it is not visible any more. But they used the last two bits of the screen (on right side), so PF0 must be updated twice every scanline, right ? (Quite a lot of cycles wasted just to avoid this problem).
I want to use this trick, too. The thing is that PC Atari does seem to have problems with this type of code so I cannot test my program properly. Anyone with a solution to this problem ? I could skip the last two bits as well, so I do not waste time by updating PF0 all the time, but this reduces the size of the display too much. thanks, Marc.
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======TUESDAY, 18 MARCH ======Marc "King Kong": Short Black Lines, and HERO etc Skipping First Two Bits of PF0
SUBJECT: Re: [stella] 2600 rpg POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Sat, 22 Mar 1997 03:14:02 GMT POST: >I heard a rumor that there was a group of people working on a rpg >for the 2600, but they stopped/gave up/whatever. Anyone know anything >about this?
They had storyboards and some other stuff ready, but couldn't find a programmer who knew how to implement the bankswitching (16k minimum would be needed and probably Superchip RAM, possibly more) and was willing to do it.
>I think one problem might be storage. I've just started dabbling in >programming, so I don't know any tricks to fit all that info into a cart. >I've seen it done, but haven't a clue. But if more space is needed, I >finally completed the design for my super cart. 128K ROM and 32K RAM. Woohoo! >The entire address space is accessable by software. No kludgy dip switches. >This cart was designed with use by a single program in mind. Just waiting >for parts! Yeah, it's only a paper design, but you have to start somewhere!
What sort of bank switching do you use? However addressable by software the cartridge might be, the 2600 is limited to 4K (12 address lines) of ROM address space and 128k of RAM... even performing writes to the ROM address space, like the Supercharger allows with its 6k RAM, is tricky.
For a full-blown RPG, you'd need a *lot* of RAM if you're maintaining a list of, say, what treasures in which dungeons have been taken (a la NES Zelda or Final Fantasy.) I suppose a Gauntlet-style game, with lots of levels in ROM but not a lot of RAM needed wouldn't be too difficult, and a linear RPG structured like NES StarTropics could be done similarly (once you complete an area, you can't go back.) Or, you could cheat and do it like the NES Ultima series, which kept track of what stuff the characters had but restocked all the dungeons whenever you entered one. Also, do your specs include a battery back for the RAM? If not, a password-to-continue wouldn't be too hard to do, as in pseudo-RPGs like NES Willow and (arguably) Metroid, Metal Gear, etc.
If I remember correctly from a FAQ I read some time ago, about half of a standard NES cartridge was taken up by bitmapped graphics.. this would be considerably less on the 2600 because the graphics (playfield) are natively monochrome and any significant color would to be handled with code. Text, though, is an important part of RPGs, and the 2600 really huffs and puffs to do that both in storage and on screen. Using a 4-pixel wide font (when playfield graphics are used for numbers, they're typically three blocks wide with a one-block space between characters, so this isn't too thin but I don't know how readable it would be) and three copies of each player drawn on alternating frames, a 24-character wide and arbitrarily high text matrix is possible.. this isn't too far from the 40-column standard of the NES.
Other possibilities... what other genres didn't exist in the 2600's heyday but could be implemented now? A two-player fighter would be possible with monochrome graphics, but I suspect most classic fans wouldn't be interested =) Myst-like puzzle games would be quite possible with limited graphics (arguably, Okie Dokie already fits this type). Tetris has been done, but every other system has many Tetris clones (especially the PC), so why can't we do it for the 2600? =) I'd also love to see some of the early post-crash games like Bubble Bobble (very doable), Arkanoid (I may try this one myself) and Galaga ported to the 2600.
Sidescrollers of any kind are still difficult, though. (Anyone know exactly how RSYNC works? .. could it be used to shift the playfield left or right in single-pixel increments, allowing smooth scrolling?)
Sorry Crackers, but I have to say this: (Brainstorming from hell!) =)
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======SATURDAY, 22 MARCH ======Erik Mooney: Answering Questions about 2600 RPG Rumour
SUBJECT: [stella] Random number generation on 2600? POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Mon, 24 Mar 1997 02:17:04 GMT POST: Any hints on how to go about creating a pseudo-random number generator on the 2600? True random numbers seem pretty difficult if not impossible (as with most assembly languages), but one can get a seed and plug it into an algorithm to get pseudo-random numbers. On the PC, it's easy to use the current time for the seed (all BASIC programmers know RANDOMIZE TIMER), but that's not there on the 2600.. anyone have a good method for getting a seed and/or a good algorithm that works well on the 6502? thanks!
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======MONDAY, 24 MARCH ======Read the Whole Erik Mooney Thread on Random Number Generation.
SUBJECT: [stella] Random number generation on 2600 POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Mon, 24 Mar 1997 21:02:50 GMT POST: Being a computer science major, I'm interested in this random number problem.. I don't like the approach of relying on the 2600's quasi-random state at powerup, especially because that doesn't work on the emulators. With some research, I found a few algorithms of the type: Random(n) = (m*Random(n-1)+c) mod z, where m, c, and z are "magic" numbers that give a sequence of 2^32 terms before it repeats. Problem is, m tends to be a number like 25173 that is difficult for the 6502 to manipulate, let alone multiply by it. (my kingdom for a multiply instruction =) ).
I did find the following algorithm: it uses a 31-bit register initialized to any nonzero value. A random bit is generated by XORing bits 27 and 30 of the register, then shifting the entire thing one bit to the left and placing the new bit on the right. If you want a random byte, simply call the algorithm eight times and read the lowest 8 bits of the register. This algorithm produces a sequence of (2^31 - 1) random bits before repeating. To seed the register, you can generate one random bit every frame whether you need it or not; then, your register can have at least 200 different values by the time the user presses Reset.
Some code for the procedure: ;Rand1, Rand2, Rand3, Rand4 are RAM locations, initialized to any nonzero ;value at program start (I use $6D) ;RandomBit generates one random bit. ;RandomByte generates one random byte and returns it in the accumulator.
RandomBit lda rand4 asl asl asl eor rand4 ;new bit is now in bit 6 of A asl asl ;new bit is now in carry rol rand1 ;shift new bit into bit 0 of register; bit 7 goes into carry rol rand2 ;shift old bit 7 into bit 8, etc. rol rand3 rol rand4 rts
RandomByte ldx #8 RandomByte1 jsr RandomBit dex bne RandomByte1 lda rand1 rts
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Another Erik Mooney Thread on RNG.
SUBJECT: [stella] another demo (don't say I'm not trying!) POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 27 Mar 1997 18:01:25 +0100 (MET) POST: Here's a demo program (NTSC or emulators only) that shows how sprite 1 can be reused to draw up to 11 horizontally moving objects, together with sprite 0, which has full freedom of movement. The step from this demo to a full game (maybe not even too crap) shouldn't be very wide... do you remember "Asterix"? ;) Thought this demo works very well on PC Atari Emulator, I haven't been able to test it on the real thing, and I suspect that there might be some minor problem "filtered" by the emulator. If you can try it on a real 2600 please let me know how it works.
Source code available on demand :)
Ciao, P.
======THURSDAY, 27 MARCH ======Piero Cavina: 11 Horziontally Moving Sprites.
SUBJECT: [stella] some little 6502 questions POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Fri, 28 Mar 1997 18:13:24 +0100 (MET) POST: Thought my 6502 is good enough for what I'm doing, I'm not a guru and there are some things that I would like to do in a more efficient way, if possible. So, if you can help me...
Is there a faster way than this to get the absolute value of the accumulator?
(...)
BPL plus EOR #$FF CLC ADC #1 plus:
(...)
...and a better way to check when A is between two values (#amin <= A < #amax):
(...)
CMP #amin BCC outrange ; I don't like... CMP #amax BCS outrange ; ...all this jumping...
(..do what is needed when A is in range..)
JMP done ; ...isn't there an alternative? outrange:
(..things to do when A is out of range..) done:
(...)
Grazie, Piero -- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======FRIDAY, 28 MARCH ======Piero Cavina: Request for Advice About Economising Code.
SUBJECT: [stella] PRECISE 2600 sound chart POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Wed, 2 Apr 1997 03:24:33 -0800 (PST) POST: ------ATARI 2600 VCS PRECISE SOUND VALUES------AND DISTORTION BREAKDOWN------BY GLENN SAUNDERS------LAST REVISION 4/2/97------
The Atari 2600 (and the Atari 8-bit) produces tones based on polynomial counters. Because of this, a great many of the notes are "out of tune" (although it's a lot worse on the 2600 than the 8-bit, which is why 7800 Ballblazer has POKEY on board, for instance.) N ot only that, but there are some intervals between notes in all of the distortions at the upper- register which will make slim pickings up there, and some of the notes are spread between two different distortions like a jigsaw puzzle. These charts were created for programmers to consult so that they can compose music that only uses notes that are in tune. To my ears, this means no more than 10 "cents" off perfect pitch (relative to other notes).
One important thing I have to add is octave values, but I don't have a keyboard and no way of knowing what "C1" is so this will have to wait unless someone else would like to revise it.
The process by which music can be composed is tricky. It will require you to build additional charts off this one that group notes based on how "in tune" they are in relation to eachother. For instance, you could sort out all the notes that are between +40 and +50 cents out of tune. Then you will figure out which group of notes provides you with the largest variety of notes. Then you will attempt to take your standard notation and transpose it as best you can to conform it to the available notes without resulting in "unattainable" notes. The only analogy I can think of is a DULCIMER, which is fretted so that only the major diatonic scale can be played, which limits you to only one key. You can't play a chromatic scale with a dulcimer, and you aren't likely to be able to play many well-tempered notes close to eachother on the 2600 either.
Another thing that makes it tricky is the crossover between X# -50 and X +50. Just be aware that the two notes in this example are VERY close in pitch when sorting and building new charts. If you do build a chart that crosses over like this, you'll probably have to convert one to the other in order to make workable music.
Music that will translate well to the 2600 will probably use lots of octaves and fifths, since there are plenty of those (in tune) in all pitches.
REVISION HISTORY
4-1-97 First revision. There is a good chance some of the notes may be off due to the chromatic tuner returning the value of overtones and not the fundemental. I did the best I could with it. There is some room for improvement as well as picking some more notes out of the bassy "rumble" areas.
--Glenn Saunders
------CHART KEY------
COLUMNS=Distortion value (decimal) and variation from perfect pitch in CENTs. Values containing ? = unknown. Values qualified with an additional ? means best-guess.
ROWS=Note values (decimal).
======THE 2600 NOTE CHART======
NOTE 1 1 CENT 2 2 CENT 3 3 CENT ------00 C -5 C# -50 C# -50 01 C -5 C# -50? C# -50? 02 F -5 F# -50? F# -50? 03 C 0 C# -50? C# -50? 04 G# +11 B -50? B -50? 05 F -5 D# ? D# ? 06 D +30 C# -50? C# -50? 07 C 0 B? ? B ? 08 A# -8 C# -50? C# -50? 09 G# +10 MED RUMBLE G# +40? 10 F# +50 RUMBLE G 0? 11 F -5 RUMBLE F 0? 12 E -50 RUMBLE E -40? 13 D +30 RUMBLE D +30? 14 C# +10 RUMBLE C# +50? 15 C 0 RUMBLE C# -50? 16 B -10 RUMBLE B +25? 17 A# -10 RUMBLE A# +10? 18 A 0 RUMBLE A +30 19 G# +10 RUMBLE G# +40 20 G +30 RUMBLE G +50 21 F# +50 RUMBLE G -20 22 F# -30 RUMBLE F# 0 23 F -5 RUMBLE F +20? 24 E +30 RUMBLE F -50? 25 E -50 RUMBLE E -30? 26 D# -10 RUMBLE D# -20? 27 D +35 RUMBLE D +30 28 D -32 RUMBLE D 0? 29 C# +10 RUMBLE C# 0? 30 C# -50 LOW RUMBLE C# -30? 31 C1? 0 C#? -50? C# -50?
NOTE 4 AND 5 4&5 CENTS 6 AND 10 6&10 CENTS 7 AND 9 8 ------00 SILENT B +40 SAME AS 6 WHITE NOISE 01 B ? B +40 DIFF DIST HIGH 02 E ? E +40 HIGH 03 B ? B +40 HIGH 04 G ? G# -50 HIGH 05 E ? E +40 HIGH 06 C# ? D -30 HIGH 07 B ? B +40 HIGH 08 A ? A +40 HIGH 09 G ? G# +40 HIGH 10 F +50 F# -10 MED 11 E -20 E +40 MED 12 D 0 D# 0? MED 13 C# +20 D -40 MED 14 C -5 C# -40? MED 15 B -15 B +40? MED 16 A# -20 A# +50? MED 17 A -20 A +50? MED 18 G# -15 G# +50 MED 19 G 0 G# -50? LOW 20 F# +15 G -40? LOW 21 F +40 F# -20? LOW 22 F -50 F 0? LOW 23 E -20 E +30 LOW 24 D# +15 E -50? LOW 25 D +50 D# -20? LOW 26 D -20 D +30? LOW 27 C# +20 D 0? LOW 28 C# -50 C# +30 LOW 29 C 0 C# -20? LOW 30 B +50 B 0? LOW 31 B -15 B +40 LOW
NOTE 12 AND 13 12&13 CNTS 14 14 CENT 15 ------00 A -20? E +40 SAME AS 14 01 E -40? E +40 DIFF DIST 02 A -20 A +40 03 E -10? E +40 04 C 0? C# -50 05 A -40 A +40 06 F# +10 G -50? 07 E -20 E +40 08 D -20 D +50? 09 C 0 C# -50 10 A# +30 B 0? 11 A -20 A 0? 12 G +50 G# 0? 13 F# +20 G -20 14 F 0? F +20? 15 E -20 MED BUZZ 16 D# -20 BUZZ 17 D -20 BUZZ 18 C# -15 BUZZ 19 C 0 BUZZ 20 B +15 BUZZ 21 A# +32 BUZZ 22 A# -50 BUZZ 23 A -20 BUZZ 24 G# +10 BUZZ 25 G +50 BUZZ 26 G -25 BUZZ 27 F# +15 BUZZ 28 F# -50 BUZZ 29 F 0 BUZZ 30 E +50 BUZZ 31 E -20 LOW BUZZ
ATARI 2600 VCS DISTORTION DESCRIPTIONS (XX & YY = exactly the same notes&dist.) ------
DECIMAL DISTORTION VALUE WHAT IT SOUNDS LIKE ------00 & 11 TOTALLY SILENT 01 Buzzy tones 02 Carries distortion 1 downward into a rumble. 03 Flangy wavering tones, like a UFO 04 & 05 Pure tones 06 & 10 Inbetween pure tone and buzzy tones (Adventure death uses this) Maybe filters off the highs here 07 & 09 Reedy tones, much brighter, down to Enduro car rumble 08 White noise/explosions/lightning, jet/spacecraft engine 12 & 13 Pure tones, goes much lower in pitch than 04 & 05. 14 Electronic tones, mostly lows, extends to rumble. 15 Electronic tones, mostly highs, extends to rumble.
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======APRIL 1997 ======WEDNESDAY, 2 APRIL ======Glenn Saunders: PRECISE 2600 Sound Chart.
SUBJECT: [stella] MultiSpriteDemo update (source+binary) POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 3 Apr 1997 21:15:00 +0200 (METDST) POST: Here's my latest demo debugged and updated. I've put comments in the most interesting parts of the code. I'm going to write a new game based on this code, so please ask before using this for yours...
; PCMSD11.ASM ; Atari 2600 MultiSprite Demo 1.1 ; (c)1987 Piero Cavina ; NTSC version processor 6502 VSYNC = $00 VBLANK = $01 WSYNC = $02 NUSIZ0 = $04 NUSIZ1 = $05 COLUP0 = $06 COLUP1 = $07 COLUPF = $08 COLUBK = $09 REFP0 = $0B PF0 = $0D PF1 = $0E PF2 = $0F RESP0 = $10 RESP1 = $11 RESM1 = $13 RESBL = $14 AUDC0 = $15 AUDF0 = $17 AUDV0 = $19 GRP0 = $1B GRP1 = $1C ENABL = $1F HMP0 = $20 HMP1 = $21 HMM1 = $23 HMBL = $24 HMOVE = $2A HMCLR = $2B CXCLR = $2C SWCHA = $0280 SWACNT = $0281 SWCHB = $0282 SWBCNT = $0283 INTIM = $0284 TIM64T = $0296 CXPPMM = $7
NUMGRP = 11 GRPHEIGHT = 7 XMIN = 8 XMAX = 150
GRPCOUNT = $80 TEMP = GRPCOUNT+1 FC_XPOS = TEMP+4 XPOS = FC_XPOS+NUMGRP XMOT = XPOS+NUMGRP GRPY = XMOT+NUMGRP PLYPOS = GRPY+1 NXTGRPY = PLYPOS+1 PLYMOT = NXTGRPY+1 PLXPOS = PLYMOT+1 FC_PLXPOS = PLXPOS+1 PLXMOT = FC_PLXPOS+1 COLL = PLXMOT+1 NOCC = COLL+NUMGRP FRAMEC = NOCC+1 PLGRD = FRAMEC+1 PLOFF = PLGRD+1
ORG $F000
START: SEI CLD LDX #$28 LDA #$00 LF006: STA NUSIZ0,X DEX BPL LF006 LDX #$FF LF00D: STA VSYNC,X DEX BMI LF00D LDX #$FF TXS STA SWBCNT STA SWACNT
LDA #$FF STA COLUP0
; Initialize objects positions and motion
LDX #NUMGRP-1 INILP: TXA ASL ASL ASL CLC ADC #10 STA XPOS,X TXA LSR CLC ADC #1 STA XMOT,X DEX BPL INILP
; Player initialization
LDA #40 STA PLXPOS LDA #1 STA PLXMOT LDA #10 STA PLYPOS LDA #1 STA PLYMOT
; Here's 'game logic'. Don't waste too much time on that, as it's just ; standard 6502 programming. Go to "kernel" for more interesting things...
MAIN: INC FRAMEC ; Count frames... LDX #0 ; Do Vsync, start Vblank... LDA #$02 STA WSYNC STA VSYNC STA WSYNC STA WSYNC STA WSYNC STX VSYNC STA WSYNC STA VBLANK
LDA #$2C STA TIM64T
; Move objects horizontally, handle collisions
LDX #NUMGRP-1 MOVLP: LDA XPOS,X CLC ADC XMOT,X STA XPOS,X CMP #XMIN BCC SWPX0 CMP #XMAX BCS SWAPX JMP OKMV SWPX0: LDA #XMIN SEC SBC XPOS,X CLC ADC #XMIN STA XPOS,X SWAPX: LDA XMOT,X EOR #$FF CLC ADC #1 STA XMOT,X OKMV: LDA XPOS,X JSR CNV STA FC_XPOS,X
LDA NOCC BNE NOCL
LDA COLL,X BPL NOCL1
LDA XMOT,X EOR PLXMOT BMI DOSW LDA XMOT,X STA PLXMOT JMP NOTSW
DOSW: LDA PLXMOT EOR #$FF CLC ADC #1 STA PLXMOT
NOTSW: LDA #64 STA NOCC NOCL: DEC NOCC NOCL1: LDA #0 STA COLL,X DEX BPL MOVLP
; Player0 vertical motion
LDA PLYPOS CLC ADC PLYMOT STA PLYPOS CMP #6 BCC SWAPPLYM CMP #[[1+GRPHEIGHT]*NUMGRP]-12 BCS SWAPPLYM JMP OKPLYM SWAPPLYM: LDA PLYMOT EOR #$FF CLC ADC #1 STA PLYMOT
; Player0 horizontal motion
OKPLYM: LDA PLXPOS CLC ADC PLXMOT STA PLXPOS CMP #25 BCS OKX0 LDA #25 STA PLXPOS JMP SWAPPLXM OKX0: CMP #154 BCC OKPLXM LDA #154 STA PLXPOS SWAPPLXM: LDA PLXMOT EOR #$FF CLC ADC #1 STA PLXMOT OKPLXM:
LDA PLXPOS ; Convert Player0 X position JSR CNV ; to FC format. STA FC_PLXPOS
STA WSYNC ; Prepare to position Player0 STA HMP0 ; remember, we're still doing Vblank now AND #$0F TAY PLPSL: DEY BPL PLPSL STA RESP0 STA WSYNC STA HMOVE
LDA #0 STA GRPCOUNT ; Initialize group counter STA GRPY ; First line of first group LDA #GRPHEIGHT+1 STA NXTGRPY ; First line of next (second) group LDA PLYPOS STA PLGRD
LF20C: LDA INTIM ; Finish Vblank BNE LF20C STA WSYNC STA VBLANK STA HMCLR
; We're going to draw #NUMGRP groups, each made of: ; 2 scanlines for Player1 positioning with Player0, plus ; #GRPHEIGHT*2 scanlines with Player1 and Player0.
KERNEL: LDA PLGRD ; Distance between Player0<->top of group CMP #GRPHEIGHT+1 ; Is Player0 inside current group? BCC DOPL ; Yes, we'll draw it... LDX #0 ; No, draw instead a BEQ GOPL ; blank sprite. DOPL: LDA NXTGRPY ; We must draw Player0, and we'll start SEC ; from the (NXTGRPY-PLYPOS)th byte. SBC PLYPOS TAX ; Put the index to the first byte into X GOPL: STX PLOFF ; and remember it.
LDY GRPCOUNT ; Store any collision between Player0 and LDA CXPPMM ; Player1 happened while drawing the ORA COLL,Y ; last group. STA COLL,Y
LDA FC_XPOS,Y ; Get Player1 position LDY PLPTN,X ; Get Player0 pattern
LDX #0 STA WSYNC ; Start with a new scanline. STY GRP0 ; Set Player0 pattern STX GRP1 ; Blank Player1 pattern to avoid 'bleeding' STA HMP1 ; Prepare Player1 fine motion AND #$0F ; Prepare Player1 coarse positioning TAY POSLP: DEY ; Waste time BPL POSLP STA RESP1 ; Position Player1
STA WSYNC ; Wait for next scanline STA HMOVE ; Apply fine motion
; Now prepare various things for the next group
LDA NXTGRPY ; Updade this group and next group STA GRPY ; top line numbers CLC ADC #GRPHEIGHT+1 STA NXTGRPY
LDA PLYPOS ; Find out which 'slice' SEC ; of Player0 we'll have to draw. SBC GRPY ; We need the distance of Player0 BPL DPOS ; from the top of the group. EOR #$FF ; CLC ADC #1 ; A = ABS(PLYPOS-GRPY) DPOS: STA PLGRD ;
LDX PLOFF ; Pointer to the next byte of Player0 INX ; pattern. Use X while drawing the group
LDA #0 ; Clear collisions STA CXCLR
LDY #GRPHEIGHT-1 ; Initialize line counter (going backwards) GRPLP: TYA ; Find the shade of Player1 color ASL ; to be used in the next line ORA #$40 STA TEMP ; ...and remember it.
LDA #$51 STA WSYNC ; Wait for a new line STA COLUBK ; Set background color LDA PLPTN,X STA GRP0 ; Set Player0 shape LDA GRPPTN,Y STA GRP1 ; Set Player1 shape LDA TEMP STA COLUP1 ; Set Player1 color
STA WSYNC ; Wait for a new scanline
INX ; Update the index to next byte of Player0 DEY ; Decrement line counter BPL GRPLP ; Go on with this group if needed
INC GRPCOUNT ; Increment current group number LDA GRPCOUNT ; CMP #NUMGRP ; Is there another group to do? BCS OUTKERNEL ; No, exit JMP KERNEL ; Yes, go back. (Using JMP because a branch ; would be out of range).
OUTKERNEL: STA WSYNC ; Finish current scanline LDA #0 ; Avoid bleeding of Player1 STA GRP1 LDA #$C0 ; How many scanlines are missing...? SEC SBC #[1+GRPHEIGHT]*2*NUMGRP+2 ; It's clear, isn't it? TAY FILLER: STA WSYNC DEY BNE FILLER ; draw them.
LDA #$02 ; Overscan STA WSYNC STA VBLANK LDA #$1D TAY LF305: STA WSYNC DEY BNE LF305 JMP MAIN ; Go back for another frame
GRPPTN: .byte %00111100 ; Pattern for Player1 .byte %01111110 .byte %11111111 .byte %11111111 .byte %11111111 .byte %01111110 .byte %00111100
PLPTN: .BYTE $00 ; Pattern for Player0. Please note .BYTE $00 ; the leading and trailing 0's .BYTE $00 .BYTE $00 .BYTE $00 .BYTE $00 .BYTE $00 .BYTE $00 .BYTE $00 .BYTE %01111110 .BYTE %11111111 .BYTE %11111111 .BYTE %11111111 .BYTE %11111111 .BYTE %11111111 .BYTE %01111110 .BYTE $00 .BYTE $00 .BYTE $00 .BYTE $00 .BYTE $00 .BYTE $00 .BYTE $00 ; Straight from "Air sea battle", here's the routine ; to convert from standard X positions to FC positions. ; Could a good man explain me how it works?
CNV: STA TEMP+1 BPL LF34B CMP #$9E BCC LF34B LDA #$00 STA TEMP+1 LF34B: LSR LSR LSR LSR TAY LDA TEMP+1 AND #$0F STY TEMP+1 CLC ADC TEMP+1 CMP #$0F BCC LF360 SBC #$0F INY LF360: CMP #$08 EOR #$0F BCS LF369 ADC #$01 DEY LF369: INY ASL ASL ASL ASL STA TEMP+1 TYA ORA TEMP+1 RTS
ORG $FFFA
.byte $00,$F0,$00,$F0,$00,$F0
Ciao, P.
======THURSDAY, 3 APRIL ======Piero Cavina: Latest Multi-Sprite Demo (debugged and updated).
SUBJECT: [stella] 6502 question POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Fri, 04 Apr 1997 06:58:53 GMT POST: Question for you 6502 gurus (both of you =) ). Suppose I have a number between $90 and $9F stored in $80. What's the fastest way to get the number at the address in $80 into the accumulator? (that is, if the value in location $80 equals $94, I want the accumulator to have the value in $94.)
It looks like I need to zero Y and then do LDA ($80),Y which is indirect indexed for 5 cycles plus clearing Y, or zero X and then LDA ($80,X) which is indexed indirect for 6 cycles plus clearing X. These would work on the zero page, right? Would the "zero page-ness" decrease the number of cycles as it does for direct addressing?
Thanks again to everyone for the help I've gotten with this project.
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======FRIDAY, 4 APRIL ======Erik Mooney thread on indirect addressing data in memory. Read whole thread.
SUBJECT: [stella] Authorship questions POSTER: Songbird <forhan@xxxxxxxxxxxxxxxxxx> DATE/TIME: Fri, 4 Apr 1997 06:32:32 -0600 (CST) POST: Hi, folks, I'm figuring some of you (Glenn, et al.) can answer this one... how many of the original 2600 games (as opposed to the newer games created within the last yaer or two) are currently owned by their authors? Any? Or are you always stuck going back to a parent company to negotiate the rights for a game, like with the SuperCharger CD?
Just curious if any older games could be easily republished with the author's consent...
Thanks,
Carl Forhan <>< Vindicator Online: http://www.millcomm.com/~ forhan/vindicator.html
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Songbird Thread on Intellectual Property of 2600 games.
SUBJECT: [stella] Boy, are my arms tired... POSTER: Greg Troutman <mor@xxxxxxx> DATE/TIME: Sun, 06 Apr 1997 20:47:55 -0700 POST: Okay, here's the final beta version of the Z26 text adventure game. I'm not sure where to go from here. I think there's enough ROM left to add a *couple* more rooms/puzzles in 4K, but not much really. Then what about sound? I've never even written a bit to the AUDXX registers... Try it out and let me know if there are any glaring bugs or yucky things about the way it works.
And please, no hints posted to the list... There's so little to it, don't spoil what there is ;)
-- mor@xxxxxxx http://www.crl.com/~mor/ ======SUNDAY, 6 APRIL ======Greg Troutman's Z26 text adventure.
SUBJECT: [stella] Uses for PHP POSTER: jimn8@xxxxxxxxxx (Jim Nitchals) DATE/TIME: Wed, 9 Apr 1997 05:50:47 -0700 (PDT) POST: Piero write: > Uh, maybe the correct question was: had the _6502_ designers that trick in > mind? Afer all, what's the use of PHP if not for tricks like that?! (BTW, > how many years before the 2600 was the 6502 designed?)
I believe it was designed in 1974 and shipping either then or 1975.
PHP is most commonly used in interrupt routines (which the 2600 doesn't have, obviously) to save and restore the status of the CPU flags.
Operating systems find it useful to use PHP to create universally useful procedures that don't mess with the CPU status any more than necessary.
BopBuggy.asm from Party Mix for the Supercharger uses it to do a test, but save code by loading some registers before branching:
MANOUV LDA PUSHMI,X PHP LDA WHICHWHEELY,X LDY WHEELYNUM,X PLP BEQ MANUV2
And last, if you need to delay for 7 cycles, a PHP/PLP is a code-compact way to do it.
Given COMBAT's twiddling of that port's unused bit (that I'm back to being sure is for a console LED), it's entirely possible they built the missile enable bit that way deliberately. The inner loops of COMBAT are sloppy speed-wise but very tight on code efficiency. Without many bytes to spare it was probably cheaper to do a last minute remask of the TIA than to sacrifice game features or add ROM.
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======WEDNESDAY, 9 APRIL ======Jim Nitchals: Uses for the PHP instruction.
SUBJECT: [stella] Alpha version of my game POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Thu, 10 Apr 1997 02:26:20 GMT POST: Attached in MIME format is the current state of my game. It's a Space Invaders clone, using playfield graphics to display an 11x5 matrix of invaders instead of the 6x6 of the Space Invaders we all know and hate =) In its current state, Game Select toggles between single-player and two player simultaneous modes, and Game Reset begins a game.. the B/W and difficulty switches are not yet used. And there's no sound yet.
Try this out and let me know what happens. It works fine on PC Atari and on a Supercharger attached to my 4-switch NTSC 2600. I'd appreciate it if someone would tell me what it does on PAL systems. (I'll probably implement the B/W switch as a PAL/NTSC switch eventually.)
Please don't distribute the game beyond here yet, though.
Tech notes: It uses simple player graphics to display the players, and repositions them with multiple copies (if necessary) to display the number of lives remaining (idea stolen from Defender.) The missiles are used for the players' missiles, naturally enough... the ball is used for the invader bombs, and it can be recycled up to 5 times to display 5 bombs simultaneously (as always, no two bombs in the same vertical zone.) Everything is displayed every frame - there's no alternating-frames logic for anything.
Known bugs/limitations: I don't yet check for collisions between enemy bombs and players.. that's cause playing the game would be just too hard in its current setup.. suggestions welcome =)
I haven't implemented scores yet either.. I plan to use the playfield to do that, at the top of the screen. I'm going to add a saucer, too, as all Space Invaders games should have =)
When the second player's missile should be disabled, it gets displayed at the top of the screen instead... this will be fixed when I add score display. Does not affect gameplay.
When an invader bomb is due to begin its display on the same scanline as an invader is being displayed, it gets skipped for that frame. This is because there's no time to set RESBL during a scanline in which I'm writing to the playfield registers six times. This is hardly noticeable, though.
The bombs change color on different scanlines along with the invaders.. this gives a very nice 2600 feel to it (see Super Breakout), so I don't plan to change it =)
Each successive wave begins lower down than the previous; there is no limitation on this, so eventually the waves will start so the bottom row of invaders is at the level of the players.. this will screw up the scanline count so the display will lose sync if you play long enough.
There are no "shields" above the players, nor will there be.. they would be extremely difficult to implement with the setup of my screen kernel.
======THURSDAY, 10 APRIL ======Alpha version of Erik Mooney's Space Invader Clone.
SUBJECT: [stella] demo update: PCMSD20.BIN POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 10 Apr 1997 15:40:49 +0200 (METDST) POST: Here's a major update of my current demo. There's a much more here, first of all a backround grid of tiles that must be turned on in order to... (watch carefully what is going on :) Again, it was tested only on the three emulators I have, but since there's some very time-dependent code in it there might be some bad surprise on the 2600.
Now the question is: can it become a good game?! I'm not sure yet... please send your advices now! Source code has become a mess after the last changes so I won't be able to post it for a while. Anyway, I will send some explaination about how I've stored the tiles in memory.
Major update to Piero Cavina's demo. Includes Background Grid of Tiles.
SUBJECT: [stella] Linking 2600 consoles? POSTER: Songbird <forhan@xxxxxxxxxxxxxxxxxx> DATE/TIME: Fri, 11 Apr 1997 11:15:41 -0500 (CDT) POST: OK, here's a dumb question from somebody who admittedly just glances over most posts to this list...
I've seen bits here and there about the potential (I think) for LEDs on the controllers. This means the ports are bidirectional? Would it be possible to "link" two 2600 consoles together using a 9-pin cord connecting, say, the second joystick port on both systems?
Or to make network ID assignment even simpler, what if one console used port #1, and the other used port #2? Then you'd automatically know which console was which.
Just curious if we could ever have a networked 2600 game... :-)
Thanks,
Carl Forhan <>< Vindicator Online: http://www.millcomm.com/~ forhan/vindicator.html
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======FRIDAY, 11 APRIL ======Pointless thread, but an interesting dicussion: Songbird on linking consoles.
SUBJECT: [stella] Graphics POSTER: jimn8@xxxxxxxxxx (Jim Nitchals) DATE/TIME: Fri, 11 Apr 1997 22:58:32 -0700 (PDT) POST: Chris,
The data you see is probably in hexadecimal. The coding is: 0 -> 0000 1 -> 0001 2 -> 0010 3 -> 0011 4 -> 0100 5 -> 0101 6 -> 0110 7 -> 0111 8 -> 1000 9 -> 1001 A -> 1010 B -> 1011 C -> 1100 D -> 1101 E -> 1110 F -> 1111 In my XP2 assembler for the Mac, included on the Supercharger CD, I allow binary data to include "." as 0 and option-8 (solid bullet) as a 1. The graphics really stand out well and are suitable for editing without a separate tool.
At a minimum, I suggest that graphic data be converted & posted as binary, i.e. dc.b %...1.... dc.b %...1.... dc.b %...1.... dc.b %..111... dc.b %.11111.. dc.b %1111111. dc.b %1111111. dc.b %...1....
(or substitute 0 for the . if your assembler isn't so kind.)
- Jim
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Jim Nitchals: Answering Chris Pepin's Question About Hexadecimal Graphical Data.
SUBJECT: [stella] Weird horizontal positioning? POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Sat, 12 Apr 1997 06:00:57 GMT POST: For whatever reason, it seems that player graphics display one pixel further right than missiles and balls when identical code for positioning and identical HMOVE values is used for both. After RESPx, there's a five-pixel delay before the player serial graphics begin, but a four-pixel delay for missiles and the ball. This seems to be reproducible both on PC Atari and the Supercharger, and happens both with the Air-Sea Battle fine-coarse convert routine and a standard subtract-15 convert. Anyone else notice this? (For that matter, has anyone else written anything using missiles and balls, or is everyone just working on sprites?)
Also, I discovered a flaw in PC Atari's emulation.. if missile 0 is one-copy single-width, hitting RESMP0 resets the missile's horizontal position to line up with the fourth bit of the player.. on the real Stella under the same conditions, the missile's horizontal position becomes even with the _fifth_ pixel of the player. Both the fourth and fifth pixels can be considered the "center" of the 8-bit wide player, so this inconsistency does kinda make sense =)
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======SATURDAY, 12 APRIL ======Erik Mooney: Player Graphics Display 1 Pixel Further Right Than Missiles and Balls. SUBJECT: [stella] IT'S A CONTEST... POSTER: Greg Troutman <mor@xxxxxxx> DATE/TIME: Sat, 12 Apr 1997 00:38:21 -0700 POST: ...And you're already a winner! Attached is a brand new game for your Supercharger, called DARK MAGE. It's big and beefy, and chock full of good stuff (other than sound). To play it, you'll need the special access code of "MAKEWAVE -C09 -SF000 DM.BIN DM.WAV"
In addition, anyone who plays and solves the game, sending me the super secret code displayed on the final screen, along with reports of any bugs (other than the bit about pressing reset during the latter stages) will receive, absolutely free, the entire source code for this game.
As an added bonus, you can download the simplified 2600/4K version of DARK MAGE complete with _heavily_commented_source_code_ at:
http://www.crl.com/~mor/z26.zip
- OR -
http://www.primenet.com/~nickb/z26 .zip
But wait, there's more! An F8/8K version of DARK MAGE that runs on your favorite emulator also exists, with still more thrills and chills, and you are likely to be the first to see it. Happy? Wait till you hear about the multiload version ;)
Now how much would you pay?
-- mor@xxxxxxx http://www.crl.com/~mor/
Greg Troutman: Dark Mage.
SUBJECT: [stella] Larger games... brainstorming POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Sat, 12 Apr 1997 20:14:55 GMT POST: As we know, the 6507 address space between 297h (T1024T) and 1000h is unused on the 2600. The cartridge address space is supposed to be 4k, but all 13 address lines do connect to the cart slot, so the entire 8k could be addressed on the cart.
Suppose one used a 2764 8K EPROM, with the chip enable tied to a logical OR of A11 and A12 (and inverted if necessary - I think it would be), and the EPROM's 13 address lines simply connected to the cart slot's 13 address lines. Would this allow access to ROM data between addresses 0800h and 0FFFh, reclaming 2k of address space and allowing 6k carts with no bankswitching?
The only problem I can see is if the TIA only checks address lines 0-5 (address), 7 (select between Stella and RIOT) and 12 and ignores the others - meaning it would respond to writes to addresses $00 - $2C (the highest register - CXCLR), and map to the registers any writes to $40 - $6C, $100 - $12C, $140 - $16C, ... , $800 - $82C, $840 - $86C, etc.
Even in this case, it might be feasible to map a 4k RAM chip on the cart between $000 and $FFF (chip enable A12), and only use addresses $30 - $3F, $70 - $7F, $130 - $13F, etc. Stella shouldn't respond to those addresses, so no conflicts would happen. This would provide an extra 512 bytes of RAM, or 256 bytes if separate read-write addresses must be used like on Superchip and other programs with cart-based RAM. One definite advantage of this is it can be done to an existing board, recycled with a new EPROM... it doesn't affect the function of the EPROM, and it involves adding nothing but the RAM chip (no bankswitching hardware.)
Even if I'm completely wrong about all of this, is there any way to reclaim any of the lower 4k address space and direct it into the cart slot?
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Erik Mooney: Speculation About 2600 Being Able to Address 8K ROM.
SUBJECT: [stella] invaders idea POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Sat, 12 Apr 1997 16:06:19 -0700 (PDT) POST: Hmm.. I may have an idea!
The big problem with these invaders isn't so much the lack of definition, it's that they don't "march" at all. If you can at least get the shapes to animate, even if they are blocky, it will work a lot better.
Would it be possible to manipulate the playfield graphics so that the blocks alterate like so: xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx
Frame 1 xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx <--- legs, one playfield graphic pixel wide
Frame 2
By manipulating playfield graphics at the pixel level this way and animating them, you can even get a few variants on the shapes. By alternating color on a scanline by scanline basis instead of just an invader row by invader row basis you can also increase the apparent detail on the invaders. In this way you may be able to get five truly different invader rows. xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx
Variant 1 xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx
Variant 2 xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx
Variant 3 Frame 1 xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxx
Variant 3 Frame 2 (pumping animation)
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
Glenn Saunders: Making Space Invaders "March" Across the Screen
SUBJECT: [stella] The scores / 48-pixel highres routine explained! POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Tue, 15 Apr 1997 03:01:56 GMT POST: In a burst of frustration at my invaders program (can't find the cycles to make the invaders look like anything but Super Breakout rejects), I figured out the scores routine. I dunno if this has been done before, but the lack of comments on the code to draw the text in Greg Troutman's game (everything else is highly commented) and in the 48-pixel highres routine in Okie Dokie's source indicate that nobody quite understands it yet.
The key is the vertical delay registers, and the fact that they don't do vertical delay at all. As the "big file" says, there are actually TWO graphics registers for each player.. I'm going to call them GRP0, GRP0A, GRP1, and GRP1A. Again as the "big file" says, bit 0 of VDELP0 toggles between whether GRP0 or GRP0A is used for the player 0 display, and VDELP1 toggles using GRP1 or GRP1A for the player 1 display. For this routine, both vertical delay registers must be set, so GRPxA will always be used.
The tricky part lies in when GRP0A and GRP1A load. When GRP0 is written to (with any value), GRP1A receives the contents of GRP1. When GRP1 is written to, GRP0A becomes equal to GRP0.
You're "supposed" to write GRP0 and GRP1 at the beginning of alternating lines, so when the vertical delay register is set, any write to GRP0 does not take effect until a write to GRP1 occurs, which occurs on the next scanline. Here's the code for it again (from Okie Dokie). GRHEIGHT is the number of scanlines for which we want to do this. Player 0 has been set to pixel 123 (including horz blank) and Player 1 has been set to pixel 131. So the digits begin at pixels 123, 131, 139, 147, 155, 163. A series of six 16-bit pointers to the digits reside at GRTABLE, in RAM. In the table on the right, D# means digit number # of the score. (if you're using a windows mail reader, make sure to use a fixed-width font or the table will be even messier than most 2600 code)
Cycles Pixel GRP0 GRP0A GRP1 GRP1A loop2 ldy GRHEIGHT ;+3 63 189 lda (GRTABLE),y ;+5 68 204 sta GRP0 ;+3 71 213 D1 ------sta WSYNC ;go lda (GRTABLE+$2),y ;+5 5 15 sta GRP1 ;+3 8 24 D1 D1 D2 -- lda (GRTABLE+$4),y ;+5 13 39 sta GRP0 ;+3 16 48 D3 D1 D2 D2 lda (GRTABLE+$6),y ;+5 21 63 sta TEMPVAR ;+3 24 72 lda (GRTABLE+$8),y ;+5 29 87 tax ;+2 31 93 lda (GRTABLE+$A),y ;+5 36 108 tay ;+2 38 114 lda TEMPVAR ;+3 41 123 ! sta GRP1 ;+3 44 132 D3 D3 D4 D2! stx GRP0 ;+3 47 141 D5 D3! D4 D4 sty GRP1 ;+3 50 150 D5 D5 D6 D4! sta GRP0 ;+3 53 159 D4* D5! D6 D6 dec GRHEIGHT ;+5 58 174 ! bpl loop2 ;+2 60 180
At the *, the value written to GRP0 does not matter.. what does matter is that this write triggers GRP1A to receive new contents from GRP1. A "!" indicates that that register is being used for displaying at that moment.
Looking at it a different way: sta GRP0 ;digit 1 -> GRP0 WSYNC sta GRP1 ;digit 2 -> GRP1, digit 1 = GRP0 -> GRP0A sta GRP0 ;digit 3 -> GRP0, digit 2 = GRP1 -> GRP1A *Digit 1 (GRP0A) begins displaying *Digit 2 (GRP1A) begins. One pixel later, the next instruction completes. sta GRP1 ;digit 4 -> GRP1, digit 3 = GRP0 -> GRP0A *Digit 3 (GRP0A) begins. Two pixels later, the next instruction completes. stx GRP0 ;digit 5 -> GRP0, digit 4 = GRP1 -> GRP1A *Digit 4 (GRP1A) begins. 3 pixels later, the next instruction completes. sty GRP1 ;digit 6 -> GRP1, digit 5 = GRP0 -> GRP0A *Digit 5 (GRP0A) begins. 4 pixels later, the next instruction completes. sta GRP0 ;any value -> GRP0, digit 6 = GRP1 -> GRP1A *Digit 6 (GRP1A) begins.
The basic idea is that we preload GRP0A, GRP1A, and GRP0 for the first three digits well ahead of time, then load the last three digits into our three registers and fire them off in rapid succession at the correct time.. then one more GRP0 strobe is needed to make GRP1A update one more time. Using the "A" registers lets us preload three digits instead of two, so that we have enough registers to hold the rest of the digits. Note that we always update GRP0A while GRP1A is being displayed, and vice versa.
My hat's off to the programmers who came up with this thing - "Wow. The above routine just drew the score with no cycles to spare." Now that we know how it works (did it in fact make sense to anyone?), it could be modified to display at different horizontal positions.
Ouch, my brain hurts now.. I think I'll go play Super Breakout =)
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======TUESDAY, 15 APRIL ======Erik Mooney: The 48 Pixel High-Res Routine Explained.
SUBJECT: [stella] Source (fwd) POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Thu, 17 Apr 1997 21:09:46 -0700 (PDT) POST: Here is the source file to Activision's Freeway, which was reconstructed by hand and extensively commented by "Burger" Bill Heineman. He assures me this is legal, and although I'm not going to go out of my way to distribute this, I feel that the subscribers of the mailing list should study it.
======THURSDAY, 17 APRIL ======Glenn Saunders: The Source Code to Freeway.
SUBJECT: RE: [stella] Running code in RAM? POSTER: Robert "A." Colbert <colbertb@xxxxxxxxxxxx> DATE/TIME: Fri, 18 Apr 1997 08:43:20 -0500 POST: Hi, Code runs o.k. in the RAM. I used that method in Cheetah to switch the banks and write the changes to the code before starting the game.
Later, bob
-- >Reply to your message of 4/17/97 2:24 PM >I could try this, but I'd rather check with you guys before I go tearing my >hair out for an hour figuring this out myself: is it possible to run code >in the 128 RAM bytes of the 2600? I don't see any theoretical problems >with the 6507 running code in zero-page, but theory doesn't always apply >around here =) Running code in Supercharger RAM works (and self-modifying >code is at least a theoretical possibility), so running code in regular RAM >should work, as long as you set up stuff like a jump back to the ROM code >once you're finished. If this can be done, it would greatly simplify >(maybe make not impossible) something I'm trying to do. > >-- >Archives available at http://www.biglist.com/list s/stella/archives/ >E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed. >End of message
Wanna write a game for the Atari 2600? Check out http://www.novia.net/~rcolbert -- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======FRIDAY, 18 APRIL ======Bob Colbert: Confirms you can run code in 2600 RAM.
SUBJECT: [stella] suckyzep demo POSTER: Nick Bensema <nickb@xxxxxxxxxxxx> DATE/TIME: Sun, 20 Apr 1997 18:25:41 -0700 (MST) POST: this demo sucks so far. I did it last week and THOUGHT I sent it out.. but apparently Eudora likes to pretend its sending things out when it really isn't.
======SUNDAY, 20 APRIL ======Nick Bensema: "Suckyzep" demo.
SUBJECT: Re: [stella] Cosmic Ark stars POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Sat, 10 May 1997 18:17:52 +0200 POST: >How did they do those nice blinking background stars in "Cosmic Ark"? >They're not correctly emulated by PC Atari, and it's even more interesting >that they look very different when I run Cosmic Ark on my Atari 2600 hacked >for composite video output: instead of looking like stars in the sky, they >seem to follow some strange, changing patterns... > >For greater fun, please answer without looking at the code :)
OK, I cheated. I looked at the code, but it still took some experimentation to figure it out.
Actually the answer is right in the programming manual. It says:
'WARNING: These motion registers should not be modified during the 24 computer cycles immediately following an HMOVE command. Unpredictable motion values may result.'
And who would have predicted an effect like that. :-)
Cosmic Ark uses missile0 for this and I am not sure if it would work with other moving object too. The trick is to do a HMOVE command, then wait 18 cycles and finally write a different value into HMM0 again.
If you use the right values for both writes to HMM0, then the TIA gets confused, moves the missile about 15 pixels away and keeps doing so in every line until you do another HMOVE command, even if you change the motion registers before. My little demo program uses $07 and $06 for this. Several other values, that I tried, had no effect.
The rest of the effect is just changing the initial position of missile0 every couple of frames to get a moving starpattern effect and changing the colour in every line to make the stars sparkle.
This little program displays a similar starpattern as cosmic ark does. It should work on PAL as well as on NTSC. I hope it has enough comments to understand how it works. Ciao, Eckhard Stolberg ======;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; TIA (Stella) write-only registers ; Vsync equ $00 Vblank equ $01 Wsync equ $02 Colup0 equ $06 Colubk equ $09 Ctrlpf equ $0A Resm0 equ $12 Enam0 equ $1D Hmm0 equ $22 Hmove equ $2A Hmclr equ $2B ; ; RAM definitions ; Note: The system RAM maps in at 0080-00FF and also at 0180-01FF. It is ; used for variables and the system stack. The programmer must make sure ; the stack never grows so deep as to overwrite the variables. ; RamStart equ $0080 RamEnd equ $00FF StackBottom equ $00FF StackTop equ $0080 ; ; 6532 (RIOT) registers ; Swcha equ $0280 Swacnt equ $0281 Swchb equ $0282 Swbcnt equ $0283 Intim equ $0284 Tim64t equ $0296 ; ; ROM definitions ; RomStart equ $F000 RomEnd equ $FFFF IntVectors equ $FFFA ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; Ram definitions ; ORG $80 tablePTR DS 1 colour DS 1 counter DS 1 colourcounter DS 1 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; Data Area ; ORG $F800 table: DB 4,5,6,7,8,9,10,11,12,11,10,9,8,7,6,5 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Program initialisation ;
Cart_Init: SEI ; Disable interrupts.: CLD ; Clear "decimal" mode.
LDX #$FF TXS ; Clear the stack
Common_Init: LDX #$28 ; Clear the TIA registers ($04-$2C) LDA #$00 TIAClear: STA $04,X DEX BPL TIAClear ; loop exits with X=$FF
LDX #$FF RAMClear: STA $00,X ; Clear the RAM ($FF-$80) DEX BMI RAMClear ; loop exits with X=$7F
LDX #$FF TXS ; Reset the stack
IOClear: STA Swbcnt ; console I/O always set to INPUT STA Swacnt ; set controller I/O to INPUT
StarsInit: LDA #$03 STA colour ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; Main program loop ; Start: LDA #$02 STA Wsync ; Wait for horizontal sync STA Vblank ; Turn on Vblank STA Vsync ; Turn on Vsync STA Wsync ; Leave Vsync on for 3 lines STA Wsync STA Wsync LDA #$00 STA Vsync ; Turn Vsync off
LDA #43 ; Vblank for 37 lines STA Tim64t ; 43*64intvls=2752=8256colclks=36.2lines
LDA #$00 ;black STA ColuBK LDA #$0e ;white STA ColuP0 LDA #$02 ;turn missile0 on STA ENAM0 LDX tablePTR ;reposition missile0 every couple of ;frames for starpattern movement LDY counter INY CPY #10 BNE @1 LDY #0 INX CPX #16 BNE @1 LDX #$00 @1: STX tablePTR STY counter LDA table,X TAY STA Wsync @2: DEY BPL @2 STA ResM0 LDA #$70 ;this value is important for the effect STA HMM0
STA Wsync STA HMOVE JSR Trick ;waste 18 cycles and load move value STA HMM0 ;this is the tricky part
LDX colourcounter ;change colours for spakling stars INX STX colourcounter CPX #3 BNE VblankLoop LDA colour CLC ADC #$10 STA colour
VblankLoop: LDA Intim BNE VblankLoop ; wait for vblank timer STA Wsync ; finish waiting for the current line STA Vblank ; turn off Vblank
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Screen: LDA colour LDY #192 @1: STA Wsync ;change the colour every line for ;sparkling stars - otherwise do what ;you want here CLC ADC #$03 EOR #$A0 STA ColuP0 DEY BNE @1 LDA #$02 STA Vblank ;turn on Vblank LDX #30 @END: STA Wsync DEX BNE @END JMP Start
Trick: NOP ;the tricky subroutine NOP LDA #$60 RTS ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; Set up the 6502 interrupt vector table ; ORG IntVectors NMI dw Cart_Init Reset dw Cart_Init IRQ dw Cart_Init END
-- Archives available at http://www.biglist.com/list s/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
======MAY 1997 ======SATURDAY, 10 MAY ======Eckhard Stolberg: How Cosmic Ark Does its Twinkling Stars.
SUBJECT: Re: [stella] BIG news! MultiSprite game 2.0! (binary) POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Wed, 9 Jul 1997 21:41:51 +0100 POST: >The Binary file that I got from this message is 20 bytes too long. I have >not tried it on any emulator yet. Will it still work? > >+++++++++++++++++++++++ ===== Matt VIGOR ++++++ ======
Sorry, something must have gone wrong from the PC to the Mac to the Internet. Here it is again, please note that the last 6 bytes should be 00 F0 00 F0 00 F0.
P.
======JULY 1997 ======WEDNESDAY, 9 JULY ======Piero Cavina: Multi-Sprite Game Version 2.0.
SUBJECT: Re: [stella] BIT and... AND POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Tue, 22 Jul 1997 15:07:37 +0200 POST: >I remember that it can be used to test bit 7 and 6 without touching the >accumulator content (this can be useful), and that it sets the zero flag >according to the result of the logical AND between the accumulator and the >memory. >This last thing is less clear to me, I mean are these things the same...: > > LDA #mask > BIT memory > BEQ ... (BNE ...) > >or > > LDA memory > AND #mask > BEQ ... (BNE ...) > >How should I choose between the two solutions?
The BIT command is basicly the same as the AND command. There are only two differences. First the BIT command doesn't change the content of the accu. And second the BIT command only supports absolute and zeropage addressing, while AND supports all addressing modes. The flags are set the same with both commands. Both of the above examples are identical in memory and processor usage, so whitch to choose depends on the context. If you have the value already in the accu, because you just calculated it or if you need the ANDed value after the branch, you should use the AND version.
If you have to check several memory locations in a row for the same bit to be set, than the BIT version is faster, because you have the mask already loaded. This could be usefull in collision detection, for example.
Also you could store the masks in memory (or zeropage RAM if possible), load the value in the accu and BIT it with the masks. This is usefull for joystick checking, because you don't have to reload SWCHA for every direction you want to check.
Ciao, Eckhard Stolberg
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======TUESDAY, 22 JULY ======Eckhard Stolberg: Explaining the BIT and AND instruction.
SUBJECT: Re: [stella] Color-cycling POSTER: Nick S Bensema <nickb@xxxxxxxxxxxx> DATE/TIME: Thu, 24 Jul 1997 16:13:04 -0700 (MST) POST: IT'S SOFTWARE, I TELL YOU! SOFTWARE!!!!
Most games use an EOR or ADC on every write to color registers against a memory location in RAM which holds zero when there's no attract mode, and some pseudorandom number when there is. I've seen the source code to Combat, Defender, and Pitfall, and this is the method used in each of them.
Not all games use the color cycling method as an attract mode. Some games have a "demo game" running, while others run a cute animation sequence. See Joust, Ms. Pac-Man, and Moon Patrol.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======THURSDAY, 24 JULY ======Nick Bensema: Attract mode and colour cycling is in software.
SUBJECT: [stella] Remember this game? POSTER: Greg Troutman <mor@xxxxxxx> DATE/TIME: Fri, 25 Jul 1997 10:24:06 -0700 POST: This isn't playable, but I thought I'd send you guys a demo to gawk at. I put this together over the past couple of days, and maybe I'll find a month or two of free time to finish it! Don't worry about the source. Other than a first draft of a multi-sprite kernel there isn't really much of interest. Maybe after I get P0 to pass through a mess of P1's without jittering ;)
-- mor@xxxxxxx http://www.crl.com/~mor/
======FRIDAY, 25 JULY ======Greg Troutman: Rescue Demo.
SUBJECT: [stella] New project - RPG engine POSTER: emooney1@xxxxxxxx (Erik K Mooney) DATE/TIME: Wed, 30 Jul 1997 03:41:24 -0400 POST: I still can't force myself to go any further on the Invaders clone, but I can start a whole new project: the engine for an RPG.
Obviously, the biggest problem is space: how to cram a game the size of NES Zelda or Final Fantasy into 4k.... well, first off I'm aiming for a 16k bankswitched game. I can fit the world maps and their display kernel into one 4k bank, text messages, allowing for a reasonably deep plot, into a second bank, the monster graphics and code for battles into a third bank (think separate screens for monster battles, a la Final Fantasy, Dragon Warrior, or Ultima 3-4, not realtime like Zelda), and everything else (status bar display kernel, processing player movement/console switches, etc) into the last bank.
For the world, I'm using a "screens" paradigm, where I can re-use a screen over again for 22 bytes of ROM. Each screen consists of 14 rows, broken into three blocks of four rows each separated by two "special" rows. Each three-row block is 12 bytes and can be reused as often as I want.. so it's not hard to make a generic "forest" block with a few trees and reuse that, or a block with a few houses as a "town" block. The two special rows are used for stuff like shops, talking to townspeople, initiating specific monster battles, and so on. The bottommost four-row block can be skipped, and four (or more) lines of text could be displayed in its place.
Each row consists simply of a sprite type, a horizontal position, and a NUSIZ/ REFP value... so a complete tiling engine like the NES does is undoable, but I can do some pretty convincing fakes with multiple copies of sprites. Think outdoor Zelda 1 scenes minus the monsters, and that's pretty much what I'm aiming for.
In addition to the sprites (player 1 is used for all the background objects, leaving player 0 for the player), I'm set up to use a playfield. Because of various factors involving storage space and cycles, I need to fit the entire playfield data into one page, limiting me to six different playfields used throughout the game. This is enough, I think... if you look closely at Legend of Zelda's dungeons, Nintendo did quite a bit of floor pattern reuse without being extremely obvious. Each of my screens can use any of the six maze types, and any three of the 42 block types, allowing quite a number of combinations.
Space: as I said, the world will fit into 4k (16 pages.) Two pages for the display kernel, one for the maze data, two for sprite data (each sprite takes 15 bytes - 10 GRP1 lines plus a color every other line - this allows 34 different sprites, should be enough), two for the block data, eight for the screen data, one for tables and other misc data. I have 2kb reserved for screen data... each screen takes 21 bytes of that plus one in the tables page, so I can fit 97 screens in the world. By comparison, Legend of Zelda is 128 screens in the overworld and about 150 total in the dungeons, so I'm not too far behind. Also, each of Zelda's screens is 16 x 12 tiles, while mine are 20 x 14. I have room for a 32-line status bar at the top of the screen, again similar to Zelda.
I'm aiming for a Dragon Warrior-style game, with one player character (not a party), with Zelda-style outdoor scenes and dungeon maps, and Final Fantasy-style battle scenes.
Anyways, I obviously can't do this entire game myself. This could become a real team project here, if you guys are willing to help. A text-display routine would be helpful... graphics design would be nice (the sprites are 10 lines, with a color change allowed every other line, and any NUSIZ value is allowed for the sprites... the player also will be 10 lines, but allow a color change every line) and so on. I don't want any plotlines or storyboards yet, though a world map would be usable. I hope to be able to release the game as a 16k cartridge, likely with password savegames... "Superchip" RAM doesn't (yet) seem necessary.
Attached is the current state of the kernel.. it doesn't do much yet, but the infrastructure is there. Don't be fooled by how chaotic it looks.. the code is definitely there. I'm just using that short name cause it's easy and quick to type :) I gotta clean up those HMOVE lines, and I've only drawn one sprite so far =) but put a little imagination into it. begin 644 r.bin M>-BB_YJI`)4`RM#[J?^-@0*-@P(@6?$@+/`@0O`@0_`@1/`@7/`@2/%,%_"I M`H4"A0"%`H4"J2R-E@*I`(4"A0!@8&"@`(2&J?2%A[&&A8"@`[&&A8+(L8:% M@V"MA`+0^X4"A0&%"(4)A1R%!Z(?RH4"$/N@`80*L8:%",BQAH4)(,'PI888 M:06%@J6':0"%@R#-\*`(L8:%@LBQAH6#(,'PI888:0J%@J6':0"%@R#-\*`- ML8:%@LBQAH6#(,'P8*D$A8D@S?#&B=#Y8(4"IH"]`/.%#;T!\X4.O0+SA0^@ M`(0
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======WEDNESDAY, 30 JULY ======Erik Mooney: RPG Engine.
SUBJECT: [stella] Would it be possible... POSTER: emooney1@xxxxxxxx (Erik K Mooney) DATE/TIME: Sat, 2 Aug 1997 20:07:39 -0400 POST: for 2600 games to use closed-captioning to display stuff? The captioning is just data sent during vertical blanking, and we've got pretty much full control over the TIA's output during vertical blanking... if the specifics are on the internet somewhere, it could be possible... I don't mean to display stuff like large text messages, or to substitute for sound effects (heh - picture Pac-man displaying [WAKA WAKA WAKA] or Missile Command displaying [PBXSCHISHHCHHXTR] ), and not all TVs support it, but it would make for a neat Easter egg, definitely not available on emulators... whaddya think?
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======AUGUST 1997 ======SATURDAY, 2 AUGUST ======Erik Mooney: Interesting thread on using the 2600 to trigger Teletext.
SUBJECT: [stella] Cubis beta 2 POSTER: Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx (Eckhard Stolberg) DATE/TIME: Tue, 5 Aug 1997 14:10:19 +0200 POST:
======TUESDAY, 5 AUGUST ======Eckhard Stolberg: Cubis beta 2.
SUBJECT: [stella] Minesweeper for 2600, please test POSTER: Sören Gust <sgust@xxxxxxxxxxxxxxxx> DATE/TIME: Fri, 8 Aug 97 18:27 MET DST POST: This is my first attempt at programming the 2600: Minesweeper. This is not a final version, but it is complete enough for some compatibility tests. As I live in Germany, I can only test it with real PAL Atari's and NTSC Emulators. I use the TV type switch to switch between pal and ntsc (color=PAL). If you live in some NTSC Country, please test it and tell me what happens.
Some hints how to play: You have to find some mines/bombs hidden on a 6x6 field. If you step on a field it shows you how many bombs are in the 8 surrounding fields. To help you remember, where you think the bombs are, you can set flags on every field. To set a flag steer the cursor to the border of the field and press the trigger button. The border changes the colour from red to green. Now you can set/clear flags. Do the same procedure again to go back to "search the bomb" mode. You cannot step on a flag, you have to clear it first. If you step on a bomb, you lose and the background flickers. If all but 5 fields are visible, you win and the playfield flickers. The white area under the playfield shows, how big the display is. The final version will show there how many bombs are hidden. Press reset to start a new game.
Missing features: - After Powerup you get always the same field. - No sound. - You can't choose the number of bombs, there are always 5. - No source release yet, final version will be freeware. - Better documentation. - Better win/lose display.
Soeren Gust, sgust@xxxxxxxxxxxxxxxx
======FRIDAY, 8 AUGUST ======Soren Gust: 2600 Minesweeper Version 0.9
SUBJECT: [stella] It flies POSTER: Greg Troutman <mor@xxxxxxx> DATE/TIME: Sat, 09 Aug 1997 21:18:26 -0700 POST: Here's another update. This one is interactive. Complete with turbo rocks to give your brain something to worry about. Plenty glitchy, just a sketch really, but if you want to use pad and paper to keep score, it's kinda like a game ;) Don't bother trying to land on the medium and small platforms, it only likes the big center one and the two side strips. Check out the way the lander sorta bounces when it hits the platform. I planned it that way
Enjoy.
-- mor@xxxxxxx http://www.crl.com/~mor/
======SATURDAY, 9 AUGUST ======Greg Troutman: New Version of Rescue Demo.
SUBJECT: [stella] PCMSG 2.3 (almost FINAL!, now I need a NAME) POSTER: "Piero Cavina" <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Sun, 10 Aug 1997 21:42:25 +0200 POST: Here's the game: now I don't want to change it very much, so if it's a decent game it will remain a decent game, otherwise... :)
- Press "Select" to choose a skill level (1-8). Higher levels = more enemies, less asteroids The current level number is displayed in the bottom right corner.
- Press "Reset" to start.
- In the lower part of the screen you can find: An horizontal bar that shows you how far you've gone in the current level. Blinking bar= danger, the Boss is coming! Your score (display routine stolen from "Dead Duck", thanks ;), it is interesting because it's a variant of the well known 6-digits from 2 sprites routine) Number of ships left (up to four) Number of available bombs (zero at the beginning).
- How to play: Shoot the asteroids and eventually they will turn into crystals. Collect the crystals and drop them in the left part of the screen. Push the button to drop a crystal, the ships starts blinking when you have crystals and you can drop them. When a row of 8 crystals is completed you will gain a bomb. You can't use bombs now, they're for the boss. Shoot the enemies to defend your crystals: the enemies that reach the far left of the playfield can steal the dropped crystals. Some will steal one and go away, others will act in a more dangerous way... When the last wave of enemies has passed, the boss will enter. From this moment you can't use the normal shoots, instead you can drop bombs pushing the button. The boss must go over a bomb to die; then, the game will start over with an higher skill level.
What is missing:
- a NAME... please help!
- title screen
- some sound effects
- ROM space... :) there are about 200 bytes left.
What can still be improved: - "balance" of game elements...: does the difficulty increases too fast/slow? are the enemies/your ship too fast/slow? are the asteroids too hard to destroy? ....and so on..
- colours; I need to find a set of colors that look decent in PAL and NTSC.
- ???
Try it!
Ciao, P.
======SUNDAY, 10 AUGUST ======Piero Cavina: Multi-Sprite Game Version 2.3.
SUBJECT: [stella] 6532 spec POSTER: Dan Boris <dan.boris@xxxxxxxx> DATE/TIME: Mon, 11 Aug 1997 12:22:05 -0400 POST: Last week someone asked for some more info on the 6532 RIOT chip.
This information comes from a book by Rockwell about thier AIM Microprocessor trainer.
RAM Addressing ------RS=0 RW=1 to read, RW = 0 to write A0-A6 select RAM address
I/O Addressing ------RS=1, A2=0 RW=1 to read, RW=0 to write
A0 A1 0 0 PA data 1 0 PA data direction (1=Output/0=Input) 0 1 PB data 1 1 PB data direction (1=Output/0=Input)
Write Edge-Detection Control ------RS=1, A2=1, RW=0, A4=0
A1=1: Enable interrupt from PA7 A1=0: Disable interrupt from PA7 A0=1: Positive edge detect A0=0: Negative edge detect
Read and Clear Interrupt Flag ------RS=1, RW=1, A2=1, A0=1
Bit 7 = Timer IRQ flag Bit 6 = PA7 IRQ flag
Write Count to Interval Timer ------RS=1,A4=1,A2=1, RW=0
A0 A1 0 0 Divide by 1 1 0 Divide by 8 0 1 Divide by 64 1 1 Divide by 1024
A3=1 Enable timer interrupt A3=0 Disable timer interrupt
This table did not saying anything about reading from the timer but the text of the book does mention it. From experience with the Atari 2600 I think the timer can be read at:
RS=1,A4=1,A2=1,RW=1 (Timer start registers) and RS=1,A2=1,A0=1
The only thing I saw in here that could be potentiolly useful is the Interrupt flag register. When the timer reaches zero bit 7 of this register is set to 1 and stays that way until it is read. This seems to be an easy way to tell when the timer has expired, surprised no one (to my knowledge) has used it.
Dan Boris
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======MONDAY, 11 AUGUST ======Dan Boris: 6532 RIOT Chip Specifications.
SUBJECT: [stella] Generating Random Numbers POSTER: danboris@xxxxxxxxxxxxxxxx (Dan Boris) DATE/TIME: Mon, 11 Aug 1997 12:57:54 -0400 POST: When I was at Electronicon I talked to Howard Warshaw (Yars Revenge, Raiders of the Lost Ark, etc). He said the the way he would generate random number was a pseudo-random number, but he had a neat trick for constantly re-seading it. He would use some sort of counter the measure the time between moves of the joystickand use this to re-sead the random number gernerator, the user being the only truely random thing in the system.
Dan Boris
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html Dan Boris: Howard Warshaw's Method for Re-Seeding Random Number Generators.
======WEDNESDAY, 13 AUGUST ======Dan Boris: Broken Link to Archive of US Patents.
SUBJECT: [stella] Another 2600 game idea POSTER: combee@xxxxxxxxxxxx (Ben Combee) DATE/TIME: Thu, 14 Aug 1997 09:42:50 -0500 (CDT) POST: Well, driving to work this morning provoked another idea for a 2600 game, one that I had not seen implemented on the platform yet.
This game would be an adaptation of the mine cart sequence in Super Mario RPG for the Super NES. You'd have a character in a cart that stays near one edge of the screen like in Moon Patrol. Using playfield graphics, you'd have four or five levels of platform, with higher platforms disappearing sometimes. Your controls would let you slow down, speed up, or jump, and a jump would be sufficient to get from one level to the next highest.
Periodically, groups of 1, 2, or 3 coins would appear floating over a platform such that you would have to be on the platform and jump to grab them. Coins from higher platforms would be worth more points as they would be easier to grab. Occasionally, there would also be blocks on a platform such that hitting one would derail your cart. There could also be holes in the bottommost platform through which falling would be bad.
If you used playfield graphics for the platforms, a player for the cart and occupant, a duplicated player for the coins and blocks, and maybe a missile to add color to something, I think this wouldn't be too hard to implement.
This might even work as a two player game, using a split screen like in Sonic 2 on the Genesis. This could be a timed game, like Freeway.
Anyone have any thoughts on this... I might try this as my first 2600 project, if I ever get the time to work on it.
-- Benjamin L. Combee (combee@xxxxxxxxxxxx)
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======THURSDAY, 14 AUGUST ======Ben Combee: Idea for 2600 Adaptation of Minecart Sequence from Super Mario RPG.
SUBJECT: R: R: [stella] New project - RPG engine POSTER: "Piero Cavina" <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 14 Aug 1997 21:14:39 +0200 POST: > >I had proposed the idea of a multi-4k game with parts linked by an > >access > >code, have you thought about it? > > I think I missed that message.. can you run it by me again?
Break the game in a number of 4k parts that could be put on single carts, but subordinate the playing of any part >1 to the entering of an access code that is revealed at the end of the previous part. The code should also be a packed representation of various game parameters (strenght, weapons, inventory...) that have to be transferred to the new part of the game. Survival Island worked more or less this way. I don't really know if this would be feasible, but I think it's worth some thoughts.
Ciao, P.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
Piero Cavina: Explanation of Access Code Between Multi-Cart RPGs.
SUBJECT: R: R: [stella] Status: RESCUE.BIN POSTER: "Piero Cavina" <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 14 Aug 1997 21:18:13 +0200 POST: > Da: Nick S Bensema
(Nick mailed this to me privately, or maybe he forgot to do a "reply to all", but I think it's interesting for the whole list...)
> This brings to mind another 2600-esque trick played on the Commodore 64, > this time not to make up for a lack of sprites but a lack of color. The > game "Creatures" created "grayish" versions of colors by interlacing them. > Perhaps you could do the same to certain objects in order to make up for > the shortfalls of the 2600's palette; there is also no grayish-purple > in the TIA. Though on emulators, the difference in sync rates would > "give it away".
Ciao, P.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html Piero Cavina: Interlacing Technique for Making "Grayish" Versions of Colours.
SUBJECT: [stella] RPG kernel, currently POSTER: emooney1@xxxxxxxx (Erik K Mooney) DATE/TIME: Fri, 15 Aug 1997 15:00:02 -0400 POST: I added the player and his movement.. also, I changed the landscape so it looks more like a real game and less like a mess :) I didn't do collision-checking or bounds-checking yet, so you can move through trees and off the screen. The player gets a little screwed up when he moves to the left side of the screen.. this is cause my kernel isn't updating GRP0 and COLUP0 in time. Other than that, the main landscape kernel is pretty much done. begin 644 rpg.bin M>-BB_YJI`)4`RM#[J?^-@0*-@P*I#(6*A8L@R?$@,O`@2/`@=_`@>/`@J_`@ MN/%,'?"I`H4"A0"%`H4"J2R-E@*I`(4"A0!@QHP0*JD`A8RB"JV``J@P!.:* MAHPI0-`$QHJ&C)@I(-`$YHN&C)@I$-`$QHN&C&!@H`"$AJGSA8>QAH6`H`.Q MAH6"R+&&A8.EBX7YIHJ%`KT`_X4KA2`I#ZK*$/V%$(4"A2I@K80"T/N%`H4! MA0B%"84
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======FRIDAY, 15 AUGUST ======Erik Mooney: Updated Version of RPG Kernel. Read the whole thread.
SUBJECT: [stella] JMP(indirect) vs. CMP/BNE/JMP POSTER: "Piero Cavina" <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Sat, 16 Aug 1997 00:10:40 +0200 POST: Here's a thing about 6502 assembly I've learned writing my game... some of you might find it interesting.
Suppose you've to write a subroutine that executes a piece of code according to an index value - the kind of thing that you would do with a CASE SELECT-type of statement in an high level language or maybe with something else in C (I don't know C, I'm still at 6502 assembly level, ok? ;)
Here's the first, obvious, solution, the same I had first put in my program.
CHOOSE1: LDA VALUE CMP #1 BNE NOT1 JMP DO1 NOT1: CMP #2 BNE NOT2 JMP DO2 NOT2: CMP #3 ......
DO1: ...... RTS
DO2: ...... RTS and so on.
Later, when I was running out of ROM memory and I had to optimize the code, I found a better way of doing that. So I've used JMP (indirect) for the first time, wee! :)
CHOOSE2: LDA VALUE ASL TAX LDA JMPTABLE,X STA TEMP LDA JMPTABLE+1,X STA TEMP+1 JMP (TEMP) ......
DO1: ...... RTS
DO2: ...... RTS
JMPTABLE: WORD DO1 WORD DO2 ...... Please note these numbers: Let's say that n is the number of possible choices, then the first solution takes 2+8*n bytes of ROM on the 2600, while the second 17+3*n bytes. Hence the JMP() approach is better that the first in terms of memory when 17+3*n<2+8*n, that is when n>3... My n was 12 so I saved 45 bytes!
Exercise for the reader: which program is faster? ;)
Ciao, P.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======SATURDAY, 16 AUGUST ======Piero Cavina: Using JMP (indirect) to economise CMP/BNE/JMP.
SUBJECT: Re: [stella] a thing that doesn't let me sleep... POSTER: emooney1@xxxxxxxx (Erik K Mooney) DATE/TIME: Sat, 23 Aug 1997 11:35:47 -0400 POST: >...how could they put seven aliens per row in Atari Galaxian?
Short answer: lots and lots of code :) It's an 8k game... disassembling the code shows about half of the second bank to be mostly the same section of code repeated over and over, except with small differences. May even be as much as a different routine for each possible combination of aliens present on any particular row.... either that or a different routine for each possible number of pixels for the leftmost alien to be offset from the left edge of the screen.
All the aliens are done with player 0, leaving player 1 to draw the aliens that have left the formation and are attacking the player, and to draw the explosions when the player hits an alien. Looks like the ball is used for the player's missile within the alien formation, and the invaders cannot drop missiles until they are below the lowest line of the formation. Here's a snippet from Distella:
LF2DB: LDX #$FC ;2 STA WSYNC ;3 LDA ($80),Y ;5 STA GRP0 ;3 LDA ($82),Y ;5 STA GRP1 ;3 LDA $86 ;3 STA $0110 ;4 this is just STA RESP0 but adds an extra 1-cycle delay STA NUSIZ0 ;3 Player 0 first gets positioned at pixel 74 from WSYNC LDA $87 ;3 NOP ;2 STA RESP0 ;3 pixel 107 STA NUSIZ0 ;3 LDA $88 ;3 INY ;2 STA RESP0 ;3 pixel 140 STA NUSIZ0 ;3 LDA $89 ;3 NOP ;2 STA RESP0 ;3 pixel 177 STA NUSIZ0 ;3
After playing the game for about 20 seconds and exiting into PC Atari's debugger, the values at $86, $87, $88, and $89 were 2, 3, 3, and 0 respectively. So, apparently, hitting RESP0 every 11 cycles and writing different values to NUSIZ allows multiple copies of objects (?) The vertical delay is also set, if that matters.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======SATURDAY, 23 AUGUST ======Erik Mooney: Answering Piero's Question About How Galaxian Used 7 Aliens Per Row.
SUBJECT: [stella] stock routines POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Wed, 3 Sep 1997 09:33:25 -0700 (PDT) POST: On Wed, 3 Sep 1997 crackers@xxxxxxxx wrote: > I've been wondering about things like building a selection of generic > routines and sub-routines that can be incorporated with different > variables to make 2600 games (kind of like Activision's "Game Maker" > for the C-64).
Generic routines are out there, but they are relatively few and far between.
For instance, most score routines can be ripped out and reused from game to game, and placed anywhere you want it.
I suppose the Dragster and Dragonfire "movable huge sprite" routine is portable.
These are portable because usually there is nothing going on but this stuff at the offending scanlines.
When you have funky stuff going on with sprites and playfield dynamically changing, you pretty much have to roll your own routines.
Another thing that might be portable is the sprite sharing algorithm of, let's say, Stargate, if you wanted to do any game that had a lot of independently moving multicolored single-line-res sprites over a simple or nonexistent background.
Once you add a non-reflected background the kernel is going to have to be changed a lot.
> Or even creating a new and simple programming language that will compile > efficiently into 2600 6507 code.
Reusable code could easily be turned into macros. But the fact that you have to cycle count to keep the screen properly updated works against writing a basicish or cish language for the 2600.
The language would have to actually keep track of your cycle counts and maybe give you a WYSIWIG computer display that traces through what the code generates on a 2600 very faithfully. I think some emulators support this sort of thing.
It would be nice if the language could actually oversee the kernel and tell you you have used X too many cycles for the scanline or the screen or have automatic functions for throwing "NOP"s in to fix this.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======SEPTEMBER 1997 ======WEDNESDAY, 3 SEPTEMBER ======Glenn Saunders: Preliminary Suggestions About Using Horizontal Movement Routines From Older Games.
SUBJECT: Re: [stella] Horizontal Positioning and Movement POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Tue, 02 Sep 1997 23:14:04 GMT POST: >Could someone please give me some assistance with horizontal moveable >object positioning and horizontal movement. > >I could really use a simple example of how it's done. Or at least a plain >english explanation of the process. I can't make heads or tails out of what >the Stella Programmer's guide is telling me and my experiments in such >matters are not meeting with great success.
Ok... Each object: the two players, the two missiles, and the ball has a horizontal-position coordinate. The coordinate is set by writing to the appropriate register (RESP0, RESP1, RESM0, RESM1, or RESBL). The value written to these registers does not matter; the object gets placed at the horizontal position from WSYNC at which the RESxx finished, plus six pixels. Say you want an object 22 pixels from the left edge of the screen. That's 90 pixels from WSYNC. So, because of the six-pixel delay, your RESP0 must end at pixel 84. Each CPU cycle counts off three pixels on the screen, so your STA RESP0 must end on cycle 84/3=28. Since STA RESP0 takes three cycles, the instruction must begin on cycle 26. Note: the object will not be displayed until the line *after* you do the STA RESP0, and then only if GRP0 and COLUP0 are nonzero and VBLANK is zero. The common method of displaying players (think Combat) is to calculate and perform the RESP0 during vertical blank, and then leave GRP0 zero until the appropriate time during screen-drawing. Once a RESP0 is done, the object remains at that horizontal position until further notice.
That allows you to put an object at any 3-pixel interval. But what if you want your object at pixel 89? The STA RESP0 has to end on cycle 25 2/3... that can't be done. For single-pixel resolution, you must use the fine motion registers, aka the horizontal motion registers. These are HMP0, HMP1, HMM0, HMM1, and HMBL. These registers accept values of -8 to 7, with positive values meaning leftward movement and negative values indicating rightward movement. These values must also be in the top four bits of the byte. Once you write a value to HMxx, it doesn't take effect until you write to HMOVE, which must be done immediately after a WSYNC.
>Damn it! Why couldn't they handle horizontal movement the same way the >C-64 did. You divide the screen into 256 horizontal locations, you stick >a number between 0 and 255 into the sprite's X register and that's where >it ends up on the screen. Arrrrgggg!!!! Would that have been too much to >ask for?
Apparently so :)
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
Erik Mooney: More Detailed Comments on Horizontal Positioning.
SUBJECT: RE: [stella] If it's not one thing it's another. POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 4 Sep 1997 12:15:17 +0200 (MET DST) POST: crackers@xxxxxxxx wrote:
> Here's the code....
I've no time to examine the details of your code, but here are some advices...
- I would recommend to write a demo with a sprite alone first, then try to add other things like a playfield. That may be easier than adding a sprite to a playfield-only program, so that you can concentrate on the sprite-related probles.
- your code seems too hmmm.... "spaghetti" :), please try to avoid the branches in the kernel: in my game there are some of them, but usually very "compact" and avoiding the "back and forth" things, ie:
CPX something BCS not very far LDA something else EOR #$FF INY not very far: STA ...
- it is usually very useful to have to deal with powers of two... so a good height for a sprite is 8 scanlines. This isn't really true for the following demo, but it's a wise choice in general.
The following picture will help you to understand the code. A key point is that the variable with the sprite Y position refers to the LAST line of the sprite.
------start of tv screen ^ ! ! border, blank, score scalines... ! ! V ------first scanline -> 100 099 098 ... 072 72-64 = 8>=8 -> draw the blank sprite 071 !------| 71-64 = 7<8 -> draw the 1st slice 070 ! ! 70-64 = 6<8 -> draw the 2nd slice 069 ! the ! ... 068 !sprite! 067 ! ! 066 ! ! 065 ! ! sprite y pos. -> 064 !------! 64-64 = 0<8 -> draw the last slice 063 63-64 = -1 = $FF >= 8 -> draw the blank sprite 062 ... 001 last scanline -> 000 ------^ ! ! border, blank, score, etc... ! ! V end of tv screen ------
Here's how could be the code... let's suppose an 8 lines height sprite. SCANLINE is the current scanline in the kernel loop, and YSPRITE the sprite Y position.
LDA #100 STA SCANLINE ... LOOP: STA WSYNC ;3 (0) LDX #0 ;2 (2) LDA SCANLINE ;3 (5) SEC ;2 (7) SBC YSPRITE ;3 (10) CMP #8 ;3 (13) BCS NOSPR ;2 (15) TAY ;2 (17) LDX SHAPE,Y ;4 (21) NOSPR: STX GRP0 ;3 (24) (worst case) ... 24*3-68= pixel 2 DEC SCANLINE BPL LOOP ...
As usual, the data for the sprite shape will be upside-down...
SHAPE: BYTE %11111111 BYTE %10000001 ... BYTE %11111111
Please notice that I've done the cycle/pixel counts above in a hurry, so they might be wrong :) But it seems that the routine will write to GRP0 when the beam is about to draw the second pixel on the scanline, so your sprite can't stay too near to the left edge.
And now, the $1.000.000 question...:
"but if it must be a single scanline thing, where can I find the cpu time for another sprite, missiles, background..."
Hints: - Greg's "Rescue" is a single-scanline game, and uses a completely different approach to draw the lander. - My game is a double scanline resolution program, and uses a complex variant of the example above.
Hope this helps...
Ciao, P.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======THURSDAY, 4 SEPTEMBER ======Piero Cavina: Advice to Erik Mooney to Write A Sprite-Alone Game First.
SUBJECT: [stella] $F000 or $1000 or what? POSTER: Robin Harbron <robinh@xxxxxxxxxxxxxxx> DATE/TIME: Thu, 04 Sep 1997 10:03:00 -0400 POST: It seems to be the standard for Atari 2600 code to run from $F000 - $FFFF... I've read that this is actually the same as addressing $1000, $3000, and so on. Is there any problem with assembling code to, say, $1000? Will it run on the SC just as well as if it was assembled to $F000? Because the 6507 is missing some addressing lines, does the memory map truly just go from $0000 to $1FFF? I'd find that alot easier to cope with :) I'm used to having the full 64K addressable... uniquely addressable, I guess.
Robin.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
Robin Harbron's Thread on the Addressing Space of the 2600's 6507. Read the Whole Thread.
SUBJECT: [stella] PCMSG26 (I almost hate my baby... :) POSTER: "Piero Cavina" <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Sat, 6 Sep 1997 22:42:33 +0200 POST: Ok, 2.5 had to be the last, so here's 2.6... :)
_There_ _is_ _no_ _space_ _for_ _anything_ _anymore_ . Don't even say that, I've already done a lot of optimization. I'm saving 10 bytes or so to fix eventual bugs.
***************************** *I can't add any new feature* *****************************
What can still be done is some fine-tuning. I'm starting to hate this project and I really need a vacation from 2600 programming... :) so I'll hear the last comments and it will be released. But there may be something to do for you... read below!
Gone: - the remaining bombs count-down after you've killed the boss. - now the dots that limit the pearls-zone don't blink - uh, what else...?
News in 2.6:
- background "music" - one free ship for each 10,000 points! :) - nicer inset pearls - new life indicator - in the higher levels, pearls can mutate into enemies - in the highest levels, the player may destroy the pearls - 1 missile clears one line, 2 missiles clear 1 line+another random chosen line, 3 missiles wipe out 1 line+2 random ones. Ok, not really what Nick suggested... - changed behavior of the red enemies, now they need multiple shots and change direction when hit - the way that game variations work is changed (see table) - you can use Select and Reset while playing - you can start a new game pushing fire. - some little bugs fixed
The following table explains how the difficulty level is increased. V L (1) (2) (3) (4) (5) (6) 1-->1 2 2 1 never 2 no 2 2 2 1 never 2 no 3 3 2 1 never 2 no 4 3 2 1 never 2 no ------2-->5 4 4 2 50% 2 no 6 4 4 2 50% 2 no 7 5 4 2 50% 2 no 8 5 4 2 50% 2 no ------3-->9 6 4 3 50% 3 no 10 6 4 3 50% 3 no 11 7 4 3 50% 3 no 12 7 4 3 50% 3 no ------13 8 8 4 always 3 yes 14 8 8 4 always 3 yes 15 8 8 4 always 3 yes 16 8 8 4 always 3 yes
V = game variation L = level
(1) = max. no. of rows with enemies (not counting oysters) (2) = average no. of hits needed to destroy an oyster (3) = no. of hits needed to destroy a type 2-3 enemy (4) = pearls mutate into enemies (5) = max. no. of enemies in a formation (6) = player's shots may destroy pearls
And now some work for you... do you like the colors I've choosen for this game? I don't. So get PCAE 2.0, and color-it-yourself! Help me to find the best set of colors! With PCAE 2.0 you can poke values in memory while a game is running. Enter the debug mode ("D" from F10 menu), run the game ("G"), halt it (esc). Press "E" and write something like "FE38=45" in the dialog box. This will put $45 in the memory location $FE38. Press "G" to restart the game. When you've chosen a color, remember to try it also with the PAL palette (press F3)...
Here are some useful addresses:
$1FCF - $1FD3: inset pearls color gradients (and one of the two player's shots color!) Default values: $38, $34, $30, $34, $38 change the left digit to change the color.
$1126: player's color.
$1EB9 + enemy id: enemy color. Change the first digit only. The second must always be "D".
Here are the enemy id's:
Uh, now that I'm thinking... I don't have the names for most of the enemies. Please help me to find some stupid names!!! :) id=1, "Blorb"
XXXX XXXX XXXXXX XX XX XXXXXXXX XX XX XXXXXXXX XX XX XXXXXXXX XX XX XXXXXX XX XX XXXX XXXX id=2,3 ???
X X X X XX XX XXXXXX XXXXXXXX XXXX XXXXXXXX XXXX XXXXXXXX XXXX XX XX XXXXXX X X X X id 4 and 5 are explosions id=6 ???
XXXXXXXX XXXXXXXX X X X X X X X X X X X X X X X X X X X X X X X X X XXXXXXXX XXXXXXXX id=7 is the "trail" that id=6 leave behind. id=8 is the pearl id=9, "Oystron"
X X X X X X X X X X XXXXXXXX X X X X X X X X X id=10, "Oysteroid"
XXXXX XXXXXXXX XX XXXX XXXXXXXX XXXXXXX XXX XX XXXXX id=11 ???
XX XX XX XX XXXXXXX XXXXXXX XX X X X XXX X X XXXXXXX XXXXXXX XX XX XX XX id=13 ???
XXXXX X XXXXX X XXXXXXX XXXXXXX XXXXX X XXXXX X
Ok, that's all folks...
Ciao, P.
======SATURDAY, 6 SEPTEMBER ======Piero Cavina: Oystron 2.6.
SUBJECT: [stella] missile bitdepth POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Sun, 7 Sep 1997 10:14:16 -0700 (PDT) POST: On Sun, 7 Sep 1997, Erik Mooney wrote: > Fine... it is I that's doing this. The "never done before" part (to > the best of our knowledge) is to have four independent detailed > player-controlled flickerless objects on the same scanline. In single > resolution. With color changes every scanline. We're using the > missiles to display two player objects, and the players for the other > two. Video Olympics had four such objects, but they were undetailed > pong bars, and according to 'kickass', that doesn't count. :) Ditto
Aren't the missiles too narrow to be anything but undetailed? You can snazz up the color but they are only what, 1 or 2 bits wide? The only way to get around this is to alter their horizontal as well as color down the screen so they can become diagonal slashes and animate the changes so although they are a line, they are a COLORFUL line that seems to dance back and forth. If it's possible to alter the missile width register on the fly as well maybe you can get shapes like:
- red - grey - light grey ---- white <-- width register set to quad - light grey - grey - blue
A shape like this kinda looks like an airplane.
When the 2600 was designed, the choice of having two players, two missiles, and a ball was carefully chosen so that both Combat (where the missiles are used as missiles) and Video Olympics (where they are used as players) would be possible (in which case, the ball would come in to complete things). (Also, the strobing function for 3 copies was done to be able to pull off the 3 biplanes/jets function in Combat, which I believe was also there in the Jet Fighter arcade game. It wasn't a high priority item but since it was easy for them to implement, they did it.)
Anyway, it was assumed that since the only way to get 4-player simultaneous play was via the paddles, that you'd only have to pull off pongish games, hence no need for the missiles to be 8-bit width.
Despite that, there were, of course, 4-player games that got around this by just not having four player-controlled objects on the same diagonal. Party Mix and Warlords are perfect examples.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======SUNDAY, 7 SEPTEMBER ======Glenn Saunders: Comments on Missile Bitdepth.
SUBJECT: R: [stella] ethics POSTER: "Piero Cavina" <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Sat, 13 Sep 1997 18:44:19 +0200 POST: > I once though of a software "wrapper" to be used to prevent piracy. It's > something to think about. Most shareware requires a registration key to > enable its full features. If you wrapped your .BIN in a special version > of makewav that contains a decrypter with registration-key encryption, > then you could enable your copy (permanently) and when you double click on > it, it would then automatically load into your Supercharger. You'd never > get a BIN to copy. It would also link to your drive so that if you > attempted to copy it it would go dead hmmm... couldn't a pirate could buy a copy, record/sample the audio signal and turn this into a .bin again...?
> Piero should consider going that way if he makes a 6K enhanced version of > Oystron. The game is commercial quality and I see no reason why he > shouldn't ask to be paid for his hard work. Noone is going to go bankrupt > from having to keep up with the constant flow of new 2600 software.
Sincerely, I like what Bob Colbert has done with Okie Dokie. It's free, and the .bin is easily available, but there have been also carts (not free I think :) In this way Bob has made his program available to the largest public, and (I hope :) he didn't lose any money to have the carts manufactured. Who owns a Supercharger can enjoy the real game, otherwise there's the cart. And those that like the game, don't have a SC and are so lazy to buy the cart or a SC, can still play it on the emulators.
This is exactly the opposite of Ed's choice, which I respect but don't really agree with. I may be wrong, and this is especially a matter of preferences, but I prefer the fact that my game can be enjoyed by the largest number of classic videogames enthusiasts, to the money I could make from it if it wasn't free.
There's also another problem with commercial-only projects...: how could one share with the other people on this list the code he's working on, if it can't be distributed? All our .bins are currently available to the world from the "biglist" archives... so Oystron would be already burned anyway :-)
Ciao, P. -- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======SATURDAY, 13 SEPTEMBER ======Piero Cavina: A thread about the ethics of intellectual property for homebrews.
SUBJECT: [stella] Multi demo - the latest version POSTER: Robert "A." Colbert <colbertb@xxxxxxxxxxxx> DATE/TIME: Mon, 15 Sep 1997 08:52:48 -0500 POST: Hi, Here is the latest version of my multi-sprite demo. It may not look all that different, but there are some MAJOR changes. These include: playfield changed every 2 lines instead of every 4. Player can be placed every 2 lines instead of every 4. Nasty bug removed that made sprites "disappear" sometimes. All sprites are the same color, this is only because I am modifying the code to allow using different shapes for the sprites, and the colors will not be based on the sprite number as they were before, but rather on the shape and the current line of the shape. There are only 5 sprites here, though I have had 9 on screen, I compiled this version with 5 just so you could study it a bit.
And the biggie:
Move the joystick RIGHT to move the sprites! This was added so I could examine the behavior of the sprites in different situations. The sprites start out in a "worst-case" scenario... that is they are all conflicting with eachother, so they will flicker. Move the joystick to the right and they will move around for ya...
Now that I have this perfectly functional, I will be working on optimizing it and adding the other player and hopefully at least 1 missle (or ball). Let me know if you find any bugs in this!
Have Fun, Bob
Wanna write a game for the Atari 2600? Check out http://www.novia.net/~rcolbert
======MONDAY, 15 SEPTEMBER ======Bob Colbert: Latest Version of His Multi-Sprite Demo.
SUBJECT: Re: [stella] is "disassembly" legal? POSTER: jimn8@xxxxxxxxxx (Jim Nitchals) DATE/TIME: Mon, 15 Sep 1997 11:27:03 -0700 (PDT) POST: > > My main question is, can companies say that it's illegal to disassemble > software, when courts have ruled in favor of the "first sale doctrine" which > states that the owner of a product can do any darn thing they wish to it?
I can't answer that (IANAL), but I can offer you some advice regarding the act of disassembling software. Practically speaking: since nobody can stop you from doing it, why not? There's only one good reason not to. Sorry, this answer takes some explaining.
If you do so, then write a program of your own that competes in any way with the code you disassembled, you're wide open to copyright infringement lawsuits. Back in the 2600 days, programmers regularly disassembled and stole ideas from each other. Nobody sued because everyone was guilty to some extent, even if subconsciously ;)
At Electronic Arts, where I reverse engineered the NES and Sega Genesis, two teams were at work on the problem. One team would disassemble code then pass abstract descriptions of what they learned about the machine to a land shark, umm, I mean lawyer. The lawyer then reviewed it and gave it a clean bill of health before passing it to the other team, who would attempt to write software from scratch based on those descriptions. There was never *any* direct communication between sides, and those who were exposed to disassembled code were NOT allowed to later work on games for those systems. This way there was never a question of theft of code, even if unintentional.
The same legal team supervised Compaq's BIOS development. It all comes down to why you're doing the disassembling, and how serious your opponent might be if you're developing competing products.
> Sorry if this is off topic, but its a question that affects alot of us in one > way or another.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
Jim Nitchals: Advice to Richard Kennehan About Legality of Disassembly.
SUBJECT: Re: [stella] TIA writes to overscan POSTER: Greg Troutman <mor@xxxxxxx> DATE/TIME: Tue, 16 Sep 1997 07:53:21 -0700 POST: Glenn Saunders wrote: > > On Mon, 15 Sep 1997, Robin Harbron wrote: > > 2) Why is overscan differentiated from the main 192 line > > display? Can you not display graphics there? Should > > you blank the screen for that area? Is there anything > > special you should do in that area?
When your game gets big, you may need the processor time during overscan to do off-screen calculations. In Rescue, there is not enough time during VBLANK to perform everything and I'm doing quite a lot in overscan now. Anyway, you don't need to do anything special, other than count the scanlines to make sure you VSYNC at the right time.
> As far as I know, this is just a LCD convention to insure that a game will > be fully visible on all TVs. It should be possible to extend your display > a few pixels below and above the conventional 2600 display. IMHO, most > TVs have more visible bandwidth available than they did 20 years ago.
Yes, if you continue to write graphics during overscan, most of the extra lines will display on all the televisions I've used for testing. In fact, the main set I use will display 222 lines, if I include all of overscan in the display kernel. Possibly even more, if I shorten VBLANK, but I haven't tried that.
> The whole debate over 2600s generating closed captioning has to do with > writing to the overscan area, for instance.
I didn't quite follow this thread. Does anyone know of a web resource for specs or overview on closed-captioning?
-- mor@xxxxxxx http://www.crl.com/~mor/
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======TUESDAY, 16 SEPTEMBER ======Greg Troutman: It is Possible to Extend the Display into Overscan.
SUBJECT: [stella] Colour Display Programme POSTER: crackers@xxxxxxxx DATE/TIME: Tue, 16 Sep 1997 19:27:01 -0400 (EDT) POST: Well gang. I'm starting work on my Virtual Pet for the 2600 now. But the colours of the 2600 just seem kind of abstract to me. I mean just how does 11011010 look? So here's a simple, very simple, damn simple programme that let's you cycle through the colour pallet, one at a time and gives you a binary representation of what colour you are on with the PF2 register.
Maybe someone can use this programme to actually assign some RGB values to the 2600's pallet.
I've only tested it out on an emulator so far. Here's the programme.
------processor 6502
VSYNC = $00 VBLANK = $01 WSYNC = $02 COLUPF = $08 COLUBK = $09 PF0 = $0D PF1 = $0E PF2 = $0F CXCLR = $2C SWCHA = $280 INTIM = $284 TIM64T = $296 COLOUR = $80 ;the value for the colour DELAY = $81 ;the value for the joystick delay org $F000 start SEI CLD LDX #$FF TXS LDA #$00 zero STA $00,X ;looks familiar, right? DEX ;typical zeroing routine BNE zero sta COLUBK sta PF0 sta PF1 sta PF2 sta COLUPF main JSR vertb ;main loop JSR draw JSR oscan JMP main vertb LDX #$00 ;vertical blank, We all know what this is about LDA #$02 STA WSYNC STA WSYNC STA WSYNC STA VSYNC STA WSYNC STA WSYNC LDA #$2C STA TIM64T LDA #$00 STA CXCLR STA WSYNC STA VSYNC RTS draw LDA INTIM BNE draw sta WSYNC sta VBLANK ldx #$C0 ;192 scanlines lda COLOUR ;loads the colour sta COLUBK ;into the playfield background sta PF1 ;also displays a binary representation to PF1 lda #$0F sta PF2 ;just to help the binary number look clear. doit STA WSYNC ;not much going on here, just repeat the dex ;same scanline 192 times beq done jmp doit done rts oscan jsr joy ;go check the joystick LDX #$1E waste STA WSYNC ;no game logic so let's blow the overscan DEX BNE waste RTS joy lda SWCHA ;check the joystick ports cmp #$7F ;see if it's moved right (joystick 1) beq right cmp #$BF ;see if it's moved left (joystick 1) beq left rts right inc DELAY ;our joystick delay timer is increased lda DELAY cmp #$1E ;check to see if we've had enough delay (30 frames) bpl clrup ;yep. Let's increase the colour rts left inc DELAY ;joystick timer increased lda DELAY cmp #$1E ;30 frames yet? bpl clrdwn ;yep, decrease colour rts clrup lda COLOUR cmp #$FE ;check to see if we've hit the maximum colour bne upit ;nope, then let's increase it lda #$00 sta DELAY ;reset joystick delay timer rts upit inc COLOUR ;okay... this is sloppy, but it works inc COLOUR ;increases the colour value to next setting lda #$00 sta DELAY ;reset joystick delay rts clrdwn lda COLOUR cmp #$00 ;see if we've hit minimum colour bne dwnit ;nope, then let's decrease it lda #$00 sta DELAY ;reset the joystick delay rts dwnit dec COLOUR ;yeah, I know, not exactly eligant, but dec COLOUR ;it increases the colour value to next setting lda #$00 sta DELAY ;reset joystick delay rts org $FFFC .word start .word start
------
I'm sorry I have to post my work as source code, but you see I'm a freenet user. So while I get the advantage of very inexpensive internet access, some of the frills like being able to attach a binary to a text message are unavailable to me.
Incidently, colour appearance varies greatly between an emulator and a real 2600. So you'll want to check your colours on both systems to make sure they're okay.
Now that I know what the colours look like for each value it will be easier to assign specific colours for different elements in my future projects.
I know I could have made this programme more useful by drawing a hex representation of the colour with sprites, but I just wanted to whip this off quickly so I could get to work on my real programme. If someone else wants to fix this up then be my guest.
CRACKERS (A fine capitalist tool from hell!!!!!)
--
Accordionist - Wethifl Musician - Atari 2600 Collector | /\/\ *NEW CrAB URL* http://www.hwcn.org/~ad329/crab.html ***| \^^/ Bira Bira Devotee - FES Member - Samurai Pizza Cats Fan| =\/=
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
Crackers's Colour Cycling Programme.
SUBJECT: [stella] I'm a mountain man and I'm okay... POSTER: crackers@xxxxxxxx DATE/TIME: Wed, 17 Sep 1997 19:41:55 -0400 (EDT) POST: Well, I've been working a little bit on my virtual pet game today. Most of it on paper (drawing sprites, flowcharts, etc) but I did do the background graphics for the game.
I now know why all those activision games use mountains and a sunset... it looks cool, and it's easy to do.
Infact, from this experience I now have another insight into why something odd about the 2600 turns out not to be so odd after all.
Have you ever wondered why PF0 reads from bits 4 to 7, PF1 from 7 to0, and PF0 from 0 to 7?
Well, if you reflect the playfield, any value you stick into all three PF locations makes a nice symetrical playfield. It never dawned on me before that that would be why it was done. If you don't want a symetrical playfield it can be a pain in the ascii, but if you do then only one byte is needed for all the PF registers. Neat huh? I'm sure all the more experienced programmers were already aware of this, but it was a "great enlightening" to me. Yes, suddenly something about the 2600 makes sense. It's really cool when you have one of these experiences.
I have a question now for the more experienced programmers...
One could really easily create a symetrical horizontally scrolling playfield by using ROL and ROR the only problem is the Carry Bit. How can I easily remove the problem of the Carry Bit and just have Bit 7 rotate into bit 0 and vice versa?
CRACKERS (Tickled pink from hell!!!!) --
Accordionist - Wethifl Musician - Atari 2600 Collector | /\/\ *NEW CrAB URL* http://www.hwcn.org/~ad329/crab.html ***| \^^/ Bira Bira Devotee - FES Member - Samurai Pizza Cats Fan| =\/=
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======WEDNESDAY, 17 SEPTEMBER ======Crackers Having an Epiphany About Why the PFX Bits are Arranged the Way They Are.
SUBJECT: [stella] Idea I just had POSTER: Nick S Bensema <nickb@xxxxxxxxxxxx> DATE/TIME: Sun, 21 Sep 1997 03:16:04 -0700 (MST) POST: Those of you who have seen South Park will know what I'm talking about. Those who haven't, check out http://www.ugcs.caltech.edu /~ttant/SouthPark/
A "Kenny Dies" video game.
For the South Park impaired, Kenny is one of the four main characters in the show. He wears a huge hooded coat that obscures most of his face and speech. Since the audience can't understand him, he can say all those things that most people can't say on TV. And he dies in every single episode.
Now, a million classic games involved evading some monster that was chasing you. In this game, you'd have to avoid a much sneakier obstacle: fate.
Ways to die would include: getting between the hunter (Jimbo) and a rabbit, stepping on a springboard while the microwave, ceiling fan, etc. above it was open or operating. The possibilities are limited only by... well, the hardware I guess.
Kenny would be relatively easy to render, I guess, as a 2600 sprite. When facing left or right, he's practically a single color thanks to that giant hood. When facing the camera, his clothing remain monochrome, while what little of his face we can see can be represented by the ball if the playfield isn't being used at his eye level, or by the opposite missile, though the best results would be by the opposite player. In any case, it would be one scanline of forehead, three scanlines of eyes, and one scanline of "nose", or something similar.
If you can create a sound effect with the RIOT that resembles muffled speech, that'd help too.
Think it's doable on the 2600? If not, I'm sure someone would do it. Perhaps Dondcila would make it his next Vectrex game. I know Glenn's been hounding him to make something original... this could be it. Kenny seems Vectrex-friendly too, and the other fthree main charactes would probably not look too god on the 2600, though feel free to prove me wrong. (It's almost not worth it if you can't work Cartman in somehow) So, I'm CC'ing it to PC John.
Good night everybody.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======SUNDAY, 21 SEPTEMBER ======Nick Bensema: Weird Idea to Make a "Kill Kenny" 2600 Game.
SUBJECT: [stella] Virtual Pet (demo 1) POSTER: CRACKERS <crackers@xxxxxxxx> DATE/TIME: Fri, 26 Sep 1997 23:49:39 -0400 (EDT) POST: Well if this works I should have a binary attatched to the end of this message. (fingers crossed)
In anycase, I already explained this in a previous message. It doesn't actually do anything right now, but it'll give you an idea of how it will look when finished.
Let me know if anyone experiences anything weird when they try to run it. So far it runs fine on my emulator and 2600.
CRACKERS (Hope this works from hell!!!!!)
======FRIDAY, 26 SEPTEMBER ======Crackers: Virtual Pet Demo 1.
SUBJECT: [stella] Short BCD time routine POSTER: Jim Nitchals <jimn8@xxxxxxxxxx> DATE/TIME: Fri, 3 Oct 1997 10:58:47 -0700 (PDT) POST: If the adds/subtracts and compares are wound into a loop, it's shorter. Slower? Yes, but it'd be done in vblank time anyway. ldx #5 ; years, months, days, hours, minutes, seconds for example ; yes, months are fixed at 30 days apiece. sed loop: lda time,x clc adc #1 sta time,x sec sbc time_max,x bne loop_end sta time,x dex bpl loop loop_end: cld and the table: time_max: dc.b $99,$12,$30,$24,$60,$60 ; max. years, months, etc.
If you prefer a decrementing time count, just rewrite a little: ldx #5 sed loop: lda time,x sec sbc #1 sta time,x bcs loop_end lda time_max,x sta time,x dex bpl loop loop_end: cld and the table changes to: time_max: dc.b $99,$11,$29,$23,$59,$59 as the values cycle downward from time_max to 0.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======OCTOBER 1997 ======FRIDAY, 3 OCTOBER ======Jim Nitchals: Short BCD Time Routine.
SUBJECT: [stella] 2600 Digital Clock (Demo 3) POSTER: CRACKERS <crackers@xxxxxxxx> DATE/TIME: Sat, 4 Oct 1997 17:30:25 -0400 (EDT) POST: Okay gang, I think I got it nailed this time. Rather than mucking around trying to figure out what exactly was causing the clock to lose a second every minute and a minute ever hour I decided to employ the "Bigger Hammer" method (when something doesn't work, hit it with a bigger hammer).
I was on the right trail last night but I'd made a stupid mistake. Since it was losing a second every minute, when the minute counter changed I just did a DEC SECS to gain a second at the begining of the minute. Should have worked but it didn't. I took another look at it this morning and discovered why, I did the DEC SECS right after the STA MINS when it should have been before so as not to confuse the BEQ.
Fixed that and tried it out and the clock was much more accurate. However, I noticed that it then gained a second every hour. No problem, "Bigger Hammer" time again. did an INC SECS every time the hour changed. So far so good. It might gain or drop a second every 60 hours now, but I've had pocket watched that kept poorer time so I can live with this. So here is the third incarnation of my clock programme. Everyone is welcome to employ and distribute this clock as they wish. And when I get more time, after my V-pet is finished, I'll see if I can't make a fancier clock out of this, but for now it's good enough for my virtual pet programme.
CRACKEERS (Whew! Glad that's overwith from hell!!)
======SATURDAY, 4 OCTOBER ======Crackers: 2600 Digital Clock.
SUBJECT: [stella] Oystron 2.8.5 POSTER: "Piero Cavina" <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Sun, 5 Oct 1997 16:02:09 +0200 POST: A very minor update, mostly bug fixes... please trash the previous version.
Ciao, P.
======SUNDAY, 5 OCTOBER ======Piero Cavina: Oystron 2.8.5.
SUBJECT: [stella] 2600 Digital Clock (source code) POSTER: crackers@xxxxxxxx DATE/TIME: Sun, 5 Oct 1997 14:31:50 -0400 (EDT) POST: Here's the source code for that final digital clock programme. Feel free to employ and distribute this code however you may wish. Both the source code and the binary are public domain.
------processor 6502
VSYNC = $00 VBLANK = $01 WSYNC = $02 NUSIZ0 = $04 NUSIZ1 = $05 COLUPF = $08 COLUBK = $09 PF0 = $0D PF1 = $0E PF2 = $0F SWCHA = $280 INTIM = $284 TIM64T = $296 CTRLPF = $0A COLUP0 = $06 COLUP1 = $07 GP0 = $1B GP1 = $1C HMOVE = $2a RESP0 = $10 RESP1 = $11
;RAM
TEMP = $80 ;2 bytes for temporary data SECS = $82 ;seconds counter MINS = $83 ;minutes counter HOURS = $84 ;hours counter JOYDEL = $85 ;joystick delay variable JOY1ST = $86 ;joystick first move variable SPRITEA = $87 ;8 bytes for the first sprite SPRITEB = $8F ;8 bytes for the second sprite RMINS = $97 ;real minutes RHOURS = $98 ;real hours FRAMES = $99 ;frames counter org $F000 start SEI CLD LDX #$FF TXS LDA #$00 zero STA $00,X ;looks familiar, right? DEX ;typical zeroing routine BNE zero lda #$01 ;now we set up all our variables sta CTRLPF lda #$0C ;set our starting time at 12:00 sta HOURS ;just like a VCR, eh? Except it doesn't blink lda #$3C ;00 minutes sta MINS lda #$ca ;nice pretty green for our sprites sta COLUP0 sta COLUP1 lda #$07 ;make them good and fat sta NUSIZ0 sta NUSIZ1 lda #$3C ;initialize the frame and seconds counters sta FRAMES sta SECS main JSR vertb ;main loop JSR time JSR draw JSR clear JMP main vertb LDX #$00 ;vertical blank, We all know what this is about LDA #$02 STA WSYNC STA WSYNC STA WSYNC STA VSYNC STA WSYNC STA WSYNC LDA #$2C STA TIM64T LDA #$00 STA WSYNC STA VSYNC RTS time ldy #06 ;just load Y ahead of time for #of sprite lines lda #$3C ;60 sec sbc MINS ;subtract the clock minutes from 60 to get the sta RMINS ;real minutes since clock counts down cmp #$00 ;see if it's 00 minutes beq min0 cmp #$32 ;see if it's more than 50 minutes bpl min5 cmp #$28 ;see if it's more than 40 minutes bpl min4 cmp #$1E ;see if it's more than 30 minutes bpl min3 cmp #$14 ;see if it's more than 20 minutes bpl min2 cmp #$0A ;see if it's more than 10 minutes bpl min1 min0 lda zeros,y ;minutes must be less than 10 so load 00 sprite and #$F0 ;strip the first 4 bits sta SPRITEA,y ;store it to sprite A memory dey bpl min0 ;get next sprite line lda #$00 ;less than 10 minutes jmp minload ;go to where we load the first 4 bits of sprite min5 lda fives,y ;minutes must be 50+ so load 55 sprite and #$F0 ;strip 1st four bits sta SPRITEA,y ;store it to sprite A memory dey bpl min5 ;get next sprite line lda #$32 ;50+ minutes - you'll need this number later to jmp minload ;load the second half the sprite data min4 lda fours,y ;minutes must be 40+ and #$F0 sta SPRITEA,y dey bpl min4 lda #$28 ;40+ minutes jmp minload min3 lda threes,y ;minutes must be 30+ and #$F0 sta SPRITEA,y dey bpl min3 lda #$1E ;30+ minutes jmp minload min2 lda twos,y ;minutes must be 20+ and #$F0 sta SPRITEA,y dey bpl min2 lda #$14 jmp minload ;20+ minutes min1 lda ones,y ;minutes must be 10+ and #$F0 sta SPRITEA,y dey bpl min1 lda #$0A ;10+ minutes minload STA TEMP ;the accumulator had the 10s of minutes LDA RMINS ;now we subtract the 10s minutes from the real sec ;minutes to get the 1s minutes to act as a pointer SBC TEMP ;for the data tables for 2nd half of sprite ASL ;double the number TAX LDA numblk,x ;load the first half of the sprite data address sta TEMP lda numblk+1,x ;load the second half of the sprite table address sta TEMP+1 ldy #$06 ;number of lines in the sprite (-1) msload lda (TEMP),y ;get the sprite data and #$0F ;strip off the last 4 bits ora SPRITEA,y ;combine the 1st half with the 2nd half sta SPRITEA,y ;put it back in the sprite memory dey bpl msload ;get the next line of data ldy #$06 ;preload number of sprite lines (-1) lda #$18 ;24 hours sec SBC HOURS ;subtract the counter hours to get STA RHOURS ;the real hours value cmp #$00 ;see if it's 12:00 am beq hour0 cmp #$14 ;see if it's 20+ hours bpl hour2 cmp #$0A ;see if it's 10+ hours bpl hour1 hour0 lda zeros,y ;load the zeros sprite data and #$F0 ;strip the 1st four bits sta SPRITEB,y ;store to the 2nd sprite memory dey bpl hour0 lda #$00 ;same deal as with the minutes jmp loadhrs ;but now we load the second half of the hours data hour1 lda ones,y and #$F0 sta SPRITEB,y dey bpl hour1 lda #$0A jmp loadhrs hour2 lda twos,y and #$F0 sta SPRITEB,y dey bpl hour2 lda #$14 jmp loadhrs loadhrs STA TEMP LDA RHOURS sec SBC TEMP asl tax lda numblk,x sta TEMP lda numblk+1,x sta TEMP+1 ldy #$06 hsload lda (TEMP),y and #$0F ora SPRITEB,y sta SPRITEB,y dey bpl hsload rts numblk .word zeros ;where all the sprites are at .word ones .word twos .word threes .word fours .word fives .word sixes .word sevens .word eights .word nines draw LDA INTIM ;check to see if it's time to draw a frame BNE draw sta WSYNC sta HMOVE sta VBLANK ;turn the screen on!
;insert display kernal ldx #$3F ;okay, this display kernal sucks, but I'm not doing blow1 sta WSYNC ;much here so I didn't go for anything fancy since dex ;this is just a demo. This wouldn't be the way you bpl blow1 ;do things in a game, but it works for this. sta WSYNC nop ;See... you'd never do something weenie like this nop ;in a real programme nop ; nop ; nop ;but when I was experimenting with this programme nop ;I just had a whole bunch of ";nop" lines here nop ;and I removed the ";" until I got the spacing more nop ;or less where I wanted it nop nop nop nop nop nop nop sta RESP0 nop nop nop nop nop nop nop sta RESP1 ldy #$06 sload lda SPRITEB,y sta GP0 lda SPRITEA,y sta GP1 sta WSYNC ;you wouldn't do something weenie like this sta WSYNC ;either in a real programme, but it was an sta WSYNC ;easy way to make each sprite 8 lines high sta WSYNC ;and I was more concerned with making a working sta WSYNC ;and accurate clock than a nice display. sta WSYNC sta WSYNC sta WSYNC dey bpl sload lda #$00 sta GP0 sta GP1 ldx #$48 blow2 sta WSYNC ;now we just blow the rest of the unused scanlines. dex bpl blow2 rts clear LDA #$24 ;set timer for overscan STA TIM64T LDA #$02 ;clear the screen and turn off the video STA WSYNC STA VBLANK LDA #$00 STA PF0 STA PF1 STA PF2 sta COLUPF sta COLUBK
LDA #$3C ;this is the clock routine itself. it counts DEC FRAMES ;down from 60 frames, and then decreases the bne joy ;seconds, which count down the minutes and then lda #$3C ;the hours.. etc. For whatever reason my 2600 STA FRAMES ;wasn't running at exactly 60 frames a second DEC SECS ;so there were two lines inserted to correct bne joy ;timing accuracy problems STA SECS DEC SECS ;here's one. Kept me from losing a second every DEC MINS ;minute bne joy STA MINS LDA #$18 INC SECS ;here's the other. It kept me from gaining a DEC HOURS ;second every hour. bne joy STA HOURS ;now my timing inaccuracies may have been caused ;by either my V-blank, V-sync, Overscan, or ;display being a few scanlines too long or short. ;theoretically if all my lines were bang on, ;I wouldn't have needed those two seconds counter ;corrections. But with them inplace, it allows me ;to be a little looser with my code which works for ;me. It may still gain or lose a second every 60 ;hours, but I can live with that. And since I'll ;be employing this clock in a virtual pet game and ;not a swiss made olympic time piece, a little ;inaccuracy won't matter. joy lda SWCHA ;load joysticks ora #$0f ;strip the data for player #2 joystick cmp #$ef ;up beq up cmp #$df ;down beq down cmp #$bf ;left beq left cmp #$7f ;right beq right lda #$00 ;no movement sta JOYDEL ;reset the joystick delay variable lda #$01 ;reset the first move variable sta JOY1ST jmp oscan ;finish off the overscan up lda HOURS ;check to see if we've run out our hours cmp #$01 beq oscan ;yep, then ignore the movement inc JOYDEL ;increase the joystick delay variable lda JOY1ST ;check to see if this is the first move in this cmp #$01 ;direction. beq now1 ;if it is then change the variable now lda #$1E ;nope then see if there's been enough of a delay cmp JOYDEL ;to change the variable yet. bne oscan now1 lda #$00 ;reset the joystick delay and set the first move sta JOY1ST ;indicator to "no" sta JOYDEL dec HOURS ;decrease the hours counter jmp oscan down lda HOURS cmp #$18 beq oscan inc JOYDEL lda JOY1ST cmp #$01 beq now2 lda JOYDEL cmp #$1E bne oscan now2 lda #$00 sta JOY1ST sta JOYDEL inc HOURS ;increase the hours counter jmp oscan left lda MINS cmp #$01 beq oscan inc JOYDEL lda JOY1ST cmp #$01 beq now3 lda #$1E cmp JOYDEL bne oscan now3 lda #$00 sta JOY1ST sta JOYDEL dec MINS ;decrease the minutes counter jmp oscan right lda MINS cmp #$3c beq oscan inc JOYDEL lda JOY1ST cmp #$01 beq now4 lda #$1E cmp JOYDEL bne oscan now4 lda #$00 sta JOY1ST sta JOYDEL inc MINS ;increase the minutes counter oscan lda INTIM ;see if the timer has run out BNE oscan STA WSYNC RTS zeros .byte %11100111 ;sprites are stored upsidedown, and there .byte %10100101 ;are two copies of each number in each sprite .byte %10100101 ;location. The unwanted number is stripped .byte %10100101 ;with the AND command (AND #$0F for the right .byte %10100101 ;number stripped, AND #F0 for the left) .byte %10100101 ;then any two numbers can be combined with an .byte %11100111 ;OR command. Neat huh? ones .byte %11100111 .byte %01000010 .byte %01000010 .byte %01000010 .byte %01000010 .byte %11000110 .byte %01000010 twos .byte %11100111 .byte %10000100 .byte %10000100 .byte %11100111 .byte %00100001 .byte %00100001 .byte %11100111 threes .byte %11100111 .byte %00100001 .byte %00100001 .byte %11100111 .byte %00100001 .byte %00100001 .byte %11100111 fours .byte %00100001 .byte %00100001 .byte %00100001 .byte %11100111 .byte %10100101 .byte %10100101 .byte %10000100 fives .byte %11100111 .byte %00100001 .byte %00100001 .byte %11100111 .byte %10000100 .byte %10000100 .byte %11100111 sixes .byte %11100111 .byte %10100101 .byte %10100101 .byte %11100111 .byte %10000100 .byte %10000100 .byte %11000110 sevens .byte %10000100 .byte %10000100 .byte %10000100 .byte %01000010 .byte %00100001 .byte %00100001 .byte %11100111 eights .byte %11100111 ;This code is (c)1997 by Chris "Crackers" Cracknell .byte %10100101 ;and is placed in the Public Domain by the author. .byte %10100101 ;Anyone is free to employ and distribute this code .byte %11100111 ;as they see fit. .byte %10100101 ; .byte %10100101 ; .byte %11100111 ; ; nines .byte %00100001 ;Well... if you're going to use this code in a .byte %00100001 ;"Doomsday Machine" to destroy the world, then .byte %00100001 ;I would rather you didn't. But otherwise, knock .byte %11100111 ;yourself out with it. .byte %10100101 ; .byte %10100101 ;Actually... if the "Doomsday Machine" is just in .byte %11100111 ;a game, then it's okay to use the code. ; org $FFFC ;Unless it's like the movie "War Games" where the .word start ;computer running the game is hooked up to a real .word start ;"Doomsday Machine" then it wouldn't be a good idea.
------
CRACKERS (Anti-Doomsday Machine from hell!!!)
--
Accordionist - Wethifl Musician - Atari 2600 Collector | /\/\ *NEW CrAB URL* http://www.hwcn.org/~ad329/crab.html ***| \^^/ Bira Bira Devotee - FES Member - Samurai Pizza Cats Fan| =\/=
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
Crackers: Source Code for Digital Clock.
SUBJECT: [stella] Platform Game - First Exposure POSTER: David Conrad Schweinsberg <david@xxxxxxxxxxxxxxxxxxx> DATE/TIME: Thu, 9 Oct 1997 19:20:21 +0100 POST: Hi
Well, since it's been a bit quite here, I'm posting the platform game BIN in its current form - with some pretty obvious rough edges.
The playfield displays eight floors - use the left joystick to scroll up/down to view all 32 floors. Nothing is animated at present, and the sprites are merely placeholders.
Let me know what you think - I'll be releasing the source code when it is all a bit more polished, and the 'enemy' graphics are in place.
Have fun, David.
======THURSDAY, 9 OCTOBER ======David Schweinsberg: Platform Game "Droid" Demo.
SUBJECT: Re: [stella] Multiloads POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Tue, 21 Oct 1997 14:19:33 +0200 POST: >By the way, how is RAM within a cart able to be used, since there is no R/W >line on the cart port - I imagine some convoluted thing writing to 'magic' >addresses.
That depends on how the RAM has been implemented in hardware. Atari's Superchip RAM for example uses seperated addresse for read and write. You would write to $F005 and read from $F085 in the 128 byte Superchip.
Supercharger RAM is a bit more difficult to write to. First you have to enable writing by writing the right value to the control byte at $FFF8.
Then you can access address $F000+X, where X is the value to be stored. You have to access the address to be written to at a given number of processorcycles after the access to $F000+X.
For more info on the Supercharger you can check out Christopher Salomon's text on Nick Bensema's Atari page at http://www.primenet.com/~nick b/atariprg.htm
Ciao, Eckhard Stolberg
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======TUESDAY, 21 OCTOBER ======Eckhard Stolberg: How to Use RAM on a Cartridge.
SUBJECT: [stella] Progress on my multi-sprte game... POSTER: Robert "A." Colbert <colbertb@xxxxxxxxxxxx> DATE/TIME: Tue, 21 Oct 1997 08:27:03 -0500 POST: Hi, Well, I figure it is about time to post the latest source code to my multi- sprite engine. The code still needs a LOT of optimization. You will notice that I have cut the number of sprites down from previous versions. The way it is now, the code to move and schedule all 5 copies of player 0 fits in the VBLANK. This leaves the entire overscan for game logic. That may not sound like a lot, but when you realize that you don't have to worry about sprite movement, it is plenty. I figure that if I run out of cycles in the VBLANK, I can duplex the code there to effectively double the cycles available.
This version has 5 multi-color copies of player 0, each with a different size, shape and speed. It also has 1 copy of player 1, and 1 copy of missle 1. In addition, it has PF1's value set different every-other line. This isn't very useful right now, and I need to optimize my drawing kernel to allow me to load at least 1 background register with useful values.
I just eliminated a nasty bug that sometimes caused a sprite to mysteriously disappear. It turns out that when I modified my code to allow for variable height sprites, I neglected to modify a portion of the conflict detection routine. At any rate, that is fixed.
While the demo is running, you can hold the joystick to the right to stop all copies of player 0 and see how the flickering looks for any given situation.
Any suggestions on the code are welcome, I will not be offended, guaranteed! One note though, you may notice repetition, or worse, in my sort routine I don't check to see if the items are sorted prematurely. Well, I did this on purpose, let me explain: As far as the repetition goes, sometimes it is better to repeat a section of code in a time-critical area, eliminating a branch eliminates 3 cycles! With the sort routine, I previously used a flag to determine if any swaps were used in the last run through the list of sprites. Well, in most environments, this is o.k. Of course the 2600 is a bird of a different feather. I came to a very enlightening realization that with the 2600, you need to assume that every routine will execute the WORST-CASE SCENARIO every time, so checking for better than that actually is a waste of time! If you do check for better than worst-case, you may be in for a surprise later when conditions are such that the worst-case occurs, or worse yet - two of your routines encounter the worst-case in the same frame...
Sorry to babble on...
Bob
Wanna write a game for the Atari 2600? Check out http://www.novia.net/~rcolbert
Bob Colbert: Source Code to Multi-Sprite Game. SUBJECT: [stella] Oystron 2.9 POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Sun, 02 Nov 1997 16:12:26 +0100 POST: A bug-fix release, but they were really bad bugs.. found thanks to Jim's "heavy" testing and optimization. Now I think that the program is ready to be released.
Fixed bugs list...: - I had forgotten to set the decimal mode before adding to the score to beat to win the next ship, whith the results that you can imagine... :-/ - A pearl could mutate into another Oystron... :-) - Completing a row immediately after another could lead to strange things...
Enjoy.. :)
P.
======NOVEMBER 1997 ======SUNDAY, 2 NOVEMBER ======Piero Cavina: Oystron 2.9.
SUBJECT: [stella] IEEE Specrum POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Fri, 14 Nov 1997 18:02:17 +0100 POST: Let's break the silence... :-)
I've finally obtained a copy of the March 1983 IEEE Spectrum article on the Atari VCS. Thanks! ;)
First of all, I must say that it's a very interesting article, and any 2600 enthusiast would love to read it.
Here are some interesting points:
<
So they must have been working on a talking ET game... :-/
<
Weee! :-)
<
In the following section they say that the "change player objects on the fly" trick was first used by Whitehead when he designed Blackjack.
Also, Whitehead created the Chopper Command chopper with background graphics only! I've never noticed this! And Kaplan first rewrote color on the fly to get a multi-color player figure in Bowling. Another Whitehead's trick explained at page 50 is the boxer's arm in Boxing: the arm extends into a punch with a change in player size. Hmmm, this isn't very clear to me.
Btw, they say that David Crane was known in the industry as "a coding machine". He he :)
Finally, I was wondering if IEEE would let us type and distribute the article for free.. after all, it's an old article without many technical details. Who knows...
Ciao, P.
-- Archives updated once/day at http://www.biglist.com/list s/stella/archives/ Unsubscribing and other info at http://www.biglist.com/li sts/stella/stella.html
======FRIDAY, 14 NOVEMBER ======Piero Cavina: Interesting Comments on IEEE Spectrum Article on the 2600.
SUBJECT: [stella] Who we are POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Fri, 14 Nov 1997 22:14:31 -0800 (PST) POST: Here is the output of the WHO command. 91 people subbed so far. A few dead Email addresses I need to prune out.
I think this is of general interest to the list because we are a very exclusive club and I know I'm curious to see who's here and where they come from. Some people are very much LURKING and not posting and I'm very curious again to know which of you are writing games in secret (smile) and how many are just here to lurk.
I'd like to know if I can expect any other polished and completed games beyond Rescue and Oystron by the time we have to decide on a winner for the contest. Time is certainly flying by. Now is the time to start cranking out code if you can. I may be able to come up with a secondary prize for a novice category. Novice would comprise any game that doesn't maximize the hardware of the 2600, but does manage to deliver some decent bare-bones gameplay. Just remember that originality always counts, even in the novice category, so if you must do a well-worn genre, please give it some distinction.
Members of list 'stella': krishna@xxxxxxxxxxxx jvmatthe@xxxxxxxxxxxx jimn8@xxxxxxxxxx (Jim Nitchals) gkomatsu@xxxxxxxxxx tspigp@xxxxxxxxxxx Songbird
91 subscribers
-- Stella list is Administered by krishna@xxxxxxxxxxxx
Glenn Saunders: Read the Whole Thread to See Stella Members Introducing Themselves.
SUBJECT: [stella] Domino POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Sat, 15 Nov 1997 20:53:03 +0100 POST: This is nothing original and I havn't had much time lately to do the finetuning, but, hey, it's better than nothing. :-)
It's a Ishido clone and I couldn't come up with a good replacement name for that. That's why it is called Domino at the moment.
Push reset to start a new game. Now you have to place the 66 hidden stones near the stones, that are already on the board: To place it near one stone, the new stone has to have the same topcolour or the same bottomcolour as the existing one. (1 point) To place it near two stones, one of them has to have the same topcolour and the other has to have the same bottomcolour as the new stone. (2 points) To place it near three stones, two of them have to the same topcolour and one has to be the same bottomcolour as the new stone, or vice versa. (4 points) To place it in the center of four stones, two of them have to have the same topcolour and two have to have the same bottomcolour as the new stone. (double score + 8 points) Try to maximize the score. :-)
The colours are chosen for PAL. On the emulator in NTSC mode the six colours are a bit hard to tell apart. It would be nice, if someone can try the game out on a real NTSC VCS and tell me, if I have to change them.
What's missing most is a better random generator for the initial board setup. Other suggestions or bug reports are very wellcome.
Thanks, Eckhard Stolberg
======SATURDAY, 15 NOVEMBER ======Eckhard Stolberg: "Domino", an Ishido clone.
SUBJECT: RE: [stella] Technologies POSTER: Robert "A." Colbert <colbertb@xxxxxxxxxxxx> DATE/TIME: Thu, 20 Nov 1997 13:49:36 -0600 POST: >Dark Mage utilizes SC bank-switching, but does not use RAM. I've not >been able to successfully use SC RAM at all yet. It always crashes.
Check the source code for Stell-A-Sketch - there is a nifty little routine I have in there to move a chunk of memory. Feel free to use it, but be warned that moving a chunk of memory is time consuming :)
Bob
Wanna write a game for the Atari 2600? Check out http://www.novia.net/~rcolbert
-- Stella list is Administered by krishna@xxxxxxxxxxxx
SUBJECT: Re: [stella] lines POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Wed, 03 Dec 1997 18:19:43 GMT POST: >Atari 2600 games with oblique or curved lines, like Laser Blast, Missile >Command or Fishing Derby have always puzzled me. What is obvious on any >other system becomes a challenge on the 2600. >I was wandering if there's a more or less "standard" way to draw such >lines. What do you think?
Well, you'd have to use an object for the Missile Command or Laser Blast lines. I'd imagine you'd RESMx at the beginning of the frame, and keep a counter during the frame, incrementing it by a certain amount each scanline (the amount determines the angle of the line), and when it overflows, do an HMOVE by one pixel one way or the other.
Like, assume we have a Missile Command missile, STA RESM0 has set the missile to its starting position, and you've already set NUSIZ, COLUP0, etc.
Eachline: sta WSYNC sta HMOVE ;apply the motion lda MissileCounter ;the counter clc ;could probably omit this if you need the cycles adc MissileOffset ;the larger this is, the faster the missile angles sta MissileCounter ;store the new value lda MissileHmove ;this has been preinitialized to $F0 if the missile ;is moving right, $10 if the missile moves left bcs MoveMissile ;if counter overflowed, move the missile lda #0 ;if this line is reached, the counter didn't ;overflow, so we want to write 0 to HMM0. MoveMissile sta HMM0 dec Scanline bne Eachline
With this, 256/MissileOffset is how many scanlines elapse between moves of the missile. If MissileOffset=$40, the missile moves every fourth scanline: X X X X X X X X and a MissileOffset of $AA will result in funky lines like: X X X X X X X X X Of course, I've no idea if this is how the game actually does it, but it's how I'd do it.
-- Stella list is Administered by krishna@xxxxxxxxxxxx
======DECEMBER 1997 ======WEDNESDAY, 3Â DECEMBER ======Erik Mooney: Describes How Missile Command Drew Curved Lines.
SUBJECT: [stella] Latest version of my new game POSTER: Robert "A." Colbert <colbertb@xxxxxxxxxxxx> DATE/TIME: Thu, 04 Dec 1997 09:09:20 -0600 POST: Hi, Well, here is what I have so far. I have been pretty happy with how this project has been going! The latest version has the following features added:
A gun that "rotates" via the joystick Background graphics Ability to shoot the gun with the fire button Ability to have up to 3 shots on screen at once
This has been tested on PCAE and a real VCS with no problems, but on Stella, it wiggles a little bit upon startup (I think I didn't initialize something correctly), anyway, the wiggling goes away, and I will address that issue shortly.
I have found an emulation problem with PCAE 2.0 but haven't zeroed in on it yet. I believe it has to do with the timing of a 6502 instruction when it branches across a page boundry (you need to add 1 cycle), but I haven't found the culprit yet. My kernel has at least 1 scan line that uses EVERY cycle in it, and if I add code before my kernel (moving the kernel to a higher address) then my screen jumps a scanline occasionally on a real VCS. On PCAE, the screen is stable. I will zero in on this problem and let the author of PCAE know about it asap. At any rate, after a couple hours of pulling my hair out, I got the screen to stay stable on the real 2600 :)
Take Care, Bob
Wanna write a game for the Atari 2600? Check out http://www.novia.net/~rcolbert
======THURSDAY, 4 DECEMBER ======Bob Colbert: Multi-Sprite Game Update Version.
SUBJECT: Re: [stella] Bounds test? POSTER: Ruffin Bailey <rufbo@xxxxxxxxxxx> DATE/TIME: Sat, 6 Dec 97 13:25:39 -0500 POST: >Rescue does both collision tests. If the 2600 doesn't report the type >of collision I'm testing, it just skips along, but if it does, then I >bounds test to isolate which sprites/platforms are involved.
What is a bounds test? Right now (though it's all on paper), I'm trying to determine the best method to figure which copy of several "non-co-[horizontally]-linear" copies of plyr1 plyr0 is bumping into when a collision is detected. Does a bounds test help with that, or only with the "plyr0-plyr0" collisons I thought (as in, "I thought, but wouldn't be suprised if I was wrong,") Bob was talking about.
Thanks,
Ruffin Bailey rufbo@xxxxxxxxxxx
-- Stella list is Administered by krishna@xxxxxxxxxxxx
======SATURDAY, 6 DECEMBER ======Ruffin Bailey: Thread on Software and Hardware Collision Detection.
SUBJECT: [stella] Christmas program POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 25 Dec 1997 23:28:47 +0100 POST: Hi! I hope you've spent a nice Christmas. I had to make a gift to my 2600, so I've put together this little hypnotic demo program. :) I hope you'll like it, but why don't you work a little on the source code to see if we can turn it into something really wild..?
Ciao, Piero
; Piero Cavina's "it's Christmas and I can't leave my 2600 alone demo v 0.1" ; 25/12/1997 processor 6502 VSYNC = $00 VBLANK = $01 WSYNC = $02 NUSIZ0 = $04 NUSIZ1 = $05 COLUP0 = $06 COLUP1 = $07 COLUPF = $08 COLUBK = $09 CTRLPF = $0A REFP0 = $0B REFP1 = $0C PF0 = $0D PF1 = $0E PF2 = $0F RESP0 = $10 RESP1 = $11 RESM0 = $12 RESM1 = $13 RESBL = $14 AUDC0 = $15 AUDF0 = $17 AUDV0 = $19 AUDC1 = $16 AUDF1 = $18 AUDV1 = $1A GRP0 = $1B GRP1 = $1C ENAM0 = $1D ENAM1 = $1E ENABL = $1F HMP0 = $20 HMP1 = $21 HMM0 = $22 HMM1 = $23 HMBL = $24 RESMP0 = $28 RESMP1 = $29 HMOVE = $2A HMCLR = $2B CXCLR = $2C CXM0P = $30 CXP1FB = $33 SWCHA = $0280 SWACNT = $0281 SWCHB = $0282 SWBCNT = $0283 INTIM = $0284 TIM8T = $0295 TIM64T = $0296 CXPPMM = $7 INPT0 = $8 INPT3 = $A INPT4 = $3C
COUNT = $80
ORG $F000
CLD LDX #$FF TXS INX TXA LPC: STA VSYNC,X INX BNE LPC
STA SWBCNT STA SWACNT
MAIN: LDX #0 LDA #$02 STA WSYNC STA WSYNC STA WSYNC STA VSYNC STA WSYNC STA WSYNC STA WSYNC STX VSYNC
; ------
LDA #$35 STA TIM64T
; ------
STA WSYNC LDX #7 LPP: DEX BPL LPP STA RESM1 STA RESM0
; ------
; Finisici il tempo di Vblank
LF20C: LDA INTIM BNE LF20C STA WSYNC STA VBLANK STA HMCLR
; ------
; Kernel LDA #$FF STA ENAM1 STA ENAM0 INC COUNT
; try to uncomment these lines.. ; LDA COUNT ; STA NUSIZ0 ; STA NUSIZ1
LDX #191 LK: TXA ADC COUNT ASL ASL STA HMM1 EOR #$FF STA HMM0 STA COLUP1 STA COLUP0 STA WSYNC
STA HMOVE DEX BNE LK
; ------
STX ENAM1 STX ENAM0
STA WSYNC LDA #$02 STA WSYNC STA VBLANK
; ------
LDA #$2A STA TIM64T
; ------
OVRS: LDA INTIM BNE OVRS JMP MAIN
ORG $FFFC
.byte $00,$F0,$00,$F0
======THURSDAY, 25 DECEMBER ======Piero Cavina: Hypnotic Christmas Demo Program.
SUBJECT: [stella] Combat questions aka Close to a new Mac Dev System! POSTER: Ruffin Bailey <rufbo@xxxxxxxxxxx> DATE/TIME: Wed, 31 Dec 97 15:27:39 -0500 POST: Okay, well, in lieu of XP2 and b/c DASM isn't compiled for the Mac, I've been having quite a time. But I think I have something now that will assemble 6502 programs. As a test program, I've been using Combat off of Nick Bensema's site. I've been getting pretty familiar with Combat, but wondered if you guys could help me with a few questions.
My assembler is having a tough time with these two lines of Combat:
SPRLO byte #
And I can't figure out exactly what they are doing. If I could, I think I could change them into something that my assembler understands. TankShape et al are the markers that deliniate the beginning of the respective player design data. That much I've got. SPEL0 is only seen one other time in this line:
InitField LDX GAMSHP LDA SPRLO,X ;Appropriate something for velocity. STA SHAPES ;Velocity could double as sprite LDA SPRHI,X ;shape. STA SHAPES+1 LDA GAMVAR
This is shortly before address 1544. As far as I can tell, the SPRLO and 'HI are the least and most significant bytes, respectively, for the player shape data. But what's with the greater than and less than symbols and all the pound [#] signs above? Can I replace them with constant addresses?
Hopefully if I can get this stuff figured out and tons of other errors don't pop up in the assembly, I will have bin's from source on the Mac. I have had to change the command syntax in a few lines to compensate for differences between this and DASM, but it really doesn't appear that you'll need more than a few minutes with a text editor to clean source intented for DASM up for the Mac. But, as with everything I've even done on a computer, I won't hold my breath. As soon as I get Combat to work, I'll write a quick post to this list about how to develope games on a Mac and then start making a web page.
Thanks for any help, and thanks to those who have helped me to this point!
Ruffin Bailey rufbo@xxxxxxxxxxx
-- Stella list is Administered by krishna@xxxxxxxxxxxx
======WEDNESDAY, 31 DECEMBER ======Ruffin Bailey: Read Whole Thread About Pointers About Combat.
SUBJECT: [stella] speaking of Combat.. POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 01 Jan 1998 21:39:08 +0100 POST: ...it seems to me that Combat never uses the "classic" DEY/BPL/STA RESxx loop to position players and missiles. It does everything with HMOVE/RESMPx... cool! ;)
P.
-- Stella list is Administered by krishna@xxxxxxxxxxxx
======JANUARY 1998 ======THURSDAY, 1 JANUARY ======Piero Cavina: How Combat Positions Players and Missiles.
SUBJECT: [stella] Programming "Mindsets"?!? POSTER: Ruffin Bailey <rufbo@xxxxxxxxxxx> DATE/TIME: Fri, 2 Jan 98 14:27:09 -0500 POST: >Have you noticed that when you're cycling through the biplane games, >only one player's planes are reset every time you press SELECT?
I can remember that just from "memory burn-in"! Guess there should have been a brain-saver as well as a screen saver routine built into the games... between that and Adventure, I could probably sue! (if there was anything resembling Atari left to sue. ;)
I have to admit after reading that article that I don't know the name of but everyone has read by now that details the 2600's genesis (oh, bad pun!), I have newfound respect for both Combat and Space Invaders. The first because that was what the Atari was explicitly designed to do, and the second as it, by doing something that the 2600 was not explicitly designed for, saved the console and perhaps started console gaming as we know it today.
It certainly aids me in mentally dissembling many games today to get ideas for programming. As I've discussed with Matt, there are two "schools of thought" that I put each part of a game into... games that are dictated by the hardware, and games that are truly creative. Football would be one of the first, assuming each team is a player and the ball's a ball. There's two digit scores, and the timer is used for the clock. Pac-Man is another; basically Football imo where one player isn't repeated with a playfield-player collison check thrown in. What a hack!
Things like Chopper Command where another player is coaxed out of the pf, as I understand it, and Space Invaders with rows and rows of non-flickering objects (though a non-flickering Commie Mutants might be a better example) are truly creative.
So in planning for my Jumpman clone, I am letting the hardware, for the most part, dictate the first few things that I'll do. The start is simply player running around colliding with another stationary player, repeated several times down the screen, on a basically perpendicular playfield, ie all horizontal platforms and ladders. Then I'm trying to throw in fancy, truly creative aspects (for me anyway!) like diagonal platforms, roving missiles, and other less Combat-ive characteristics. Anyway, I was just wondering what kinds of _mindsets_, not merely approaches, you more experienced programmers take when beginning a project?
Thanks,
Ruffin "Horribly Verbal" Bailey rufbo@xxxxxxxxxxx
-- Stella list is Administered by krishna@xxxxxxxxxxxx
======FRIDAY, 2 JANUARY ======Ruffin Bailey: Read Whole Thread Discussing Interesting Innovations of Various Games.
SUBJECT: [stella] off the shelf? POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Sat, 03 Jan 1998 20:24:27 +0100 POST: I've always heard that the 2600 was made with off the shelf parts, and this would explain how some companies could produce adapters for other systems, or clones.
But this seems strange to me... was the 2600 TIA really a chip that you could buy from Radio Shack?! And why should one have bought it, if it was used only by Atari inside the 2600?
Ciao, P.
-- Stella list is Administered by krishna@xxxxxxxxxxxx
======SATURDAY, 3 JANUARY ======Piero Cavina: Interesting Thread on the TIA.
SUBJECT: [stella] Sometimes they come back.. :) POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Sun, 04 Jan 1998 18:30:54 +0100 POST: Last night I've heard Erick's "INV" calling me... and now, here it is again, this time almost finished! Now there's full collision detection, a working saucer, *sounds* and something else... (including some bugs).
Please let me know what you think of it, and with another hacking session we'll have another Atari 2600 game.
Ciao, P.
PS: there's no free RAM anymore, so don't ask for more advanced features: score display, invaders matrix and shields eat a lot of RAM. PPS: luckyly, the program was well written and commented. But is still Erick Mooney amongst us?
======SUNDAY, 4 JANUARY ======Piero Cavina Hacks Together Erik Mooney's "INV" (Invaders Clone) Game.
SUBJECT: Re: [stella] Space Invaders POSTER: Erik Mooney <emooney@xxxxxxxxxxxxxxxx> DATE/TIME: Thu, 8 Jan 1998 08:35:25 -0500 (EST) POST: > In the original Atari "Space Invaders" game: sometimes the invaders would > explode when you hit them and sometimes they would just dissapear. > > I never found a pattern to it. Does anyone know why this happens?
Depends on whether the game needed the sprite to do something else, of course :) Couldn't tell you exactly why and when, though.
> Note: I usually played by holding the "game start" switch down as I turn > the game on, so I get two shots at a time rather than one. Maybe that > has something to do with it?
That shouldn't have anything to do with the explosions. The only way the one could affect the other would be if the code had difficulty handling two explosions at once, which I don't think it does.
> By the way: Why does that "game start" trick work? Anyone ever look at > the Space Invaders code to see why?
I'm fairly sure it's because the game number never gets initialized. On powerup, the code sees the game start switch depressed, so it immediately starts a game with whatever number happened to be in the "game variation" variable, probably zero. For some reason, game zero allows shots for two players, but only displays and responds to one joystick. (the invader bombs and player missiles are drawn on alternating frames, all using the ball - frame A repositions the ball halfway down to draw two invader missiles, then frame B uses the ball twice to draw two player missiles. Notice the bombs and missiles are not the same color as either player or the invaders?) -- Stella list is Administered by krishna@xxxxxxxxxxxx
======THURSDAY, 8 JANUARY ======Erik Mooney: Interesting Answers to Questions About Arcade Space Invaders.
SUBJECT: [stella] Piracy POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Fri, 9 Jan 1998 01:48:12 -0800 (PST) POST: On Fri, 9 Jan 1998, Chris Cracknell wrote: > then go ahead and distribute it, if you want to make a profit doing it > then go for that too. Even though activision and atari claim they have
It would be highly hypocritical of me to go ahead and release a Starpath CD without asking for permission, and even worse to take profit from it.
Besides, as someone who's gotten written up in Wired magazine and is mentioned here and there on the net, I can not "hide between the cracks" like those guys burning CD-Rs in their free time. I'd rather not even suffer the finger-pointing that could result from such actions, regardless of whether I'd be liable for a lawsuit.
Most of all, though, I don't feel as though I should have to stoop so low as to resort to piracy to make a buck.
As much as I'd like to take credit for the Stella CD, the real people who need credit are the programmers, and this documentary is my way of showing my appreciation for their work, and legally earning me a profit to boot!
As a 27 year old film grad who is kinda cutting his teeth doing low res character animations on the web, I'd like to have more genuine accomplishments to be proud of before I formally enter middle-age. I am an opportunitist and someday I hope to wind up in the higher echelons of computer animation (for TV or videogames), television production, or the emerging web/interactive TV industry.
I need to spend my time wisely. The CD did not play to my creative strengths, but the documentary does.
[conspiracy proposals deleted]
Let me just say this regarding my stance on this sort of thing. If I start seeing bootleg CD-Rs float around, I'll blame you. 'Nuff said?
My goal in life is not to supply everyone who wants to play a Supercharger game with a copy of the CD, nor do I see piracy as a proper means to that noble end. I distributed a few hundred out there which is in perportion to what can be expected from an individual with a busy life.
> In your place I wouldn't let my desire to create be blocked by corporate
Piracy isn't creation, it's exploitation.
> bullshit. Besides, there's a certain romantic charm to being a software > pirate, especially if nobody is being hurt by the piracey.
My own sense of self-worth would be hurt by the piracy. I consider myself a creative person with something meaningful to contribute to society as an artist in one medium or another. I want to be able to take full credit for what I do, and not be ashamed of it or need to distance myself from it.
The CD was my first babystep towards creating something I could be proud of since I graduated from college. I can't feel as proud of it today as I was when it was released because I'm already doing more challenging work as an animator at my dayjob, or as a video editor by night.
My agenda in the 2600 domain isn't to exploit the past, it's to appreciate it, study it, process it, and to build upon it.
I feel much better about whatever indirect role I played in the creation of Oystron than I would feel about having any part in a shady piracy deal for profit.
I am having the signature certificate award matted and framed currently at a cost of $50 (minus the engraving to be added later). I really want to encourage all of you guys to code for Stella more than anything else and if I had more free cash I'd dangle a reasonable cash award as well. It means that much to me to see stellalist be more active and to see new kernel ideas spring forth.
The documentary is part of this too, which is why I'm plugging you guys by putting your games on it. Once you guys see the programmers talk about their experiences you will UNDERSTAND the stuff they went through, but at the same time, you have to look at them and realize that although some of them are out of the business, many of them went on to be CEOs of game companies and are currently highly involved in the modern industry.
They have the perspective to look back at where we came from, and where we are, and render an HONEST assessment of the VCS archetecture, and how games were vs. how games are today.
Listen, although they knew what they were supposed to say, not ONE of the programmers said they PREFER writing for today's systems in today's industry. Some of them expressed mourning for the lost age of "one man, one game", and the tremendous sense of satisfaction that comes from completing a pleasing VCS kernel.
Many of these guys are realists and they know that they have to live in the now, but if they had more time, they'd probably be right in here with us getting back down to basics.
Every VCS coder should realize that by the very nature of their autonomy and the imposed limitations on the VCS, they are creating more honest-to-goodness videogames than today's commercial publishers. As Rob Fulop said, "this system's all about gameplay". It cuts through the BS and forces you to deliver the goods. Perhaps the mainstream gaming public out there sees things in reverse, but that doesn't mean they are right. It's the mainstream public that seems content with arcades filled with nothing but fighters and driving sims and home games based around CD-Rom "spectatorware" vs. solid replay-value gameplay.
Maybe you won't make any money off of your game, but you should certainly take the task of writing games for the VCS seriously, and not be ashamed to devote your free time towards it, because it really is videogaming at its purest level.
I want to instill that sense of adventure in the VCS design, and the pleasure that can come from writing within the VCS environment vs. the PC or PSX domain.
I don't want to just make a cheap buck on pirate-ware...
--end of essay--
-- Stella list is Administered by krishna@xxxxxxxxxxxx
======FRIDAY, 9 JANUARY ======Glenn Saunders: Big Essay on Piracy and the Stella CD.
SUBJECT: [stella] Multiload test of Platform Game (DROID) POSTER: "David C. Schweinsberg" <david@xxxxxxxxxxxxxxxxxxx> DATE/TIME: Fri, 9 Jan 1998 22:50:45 -0000 POST: Hi
Please find attached the latest "Platform Game" (a.k.a. DROID), which includes a test implementation of multiloading. I realise it's been three months since I posted the last version - much has changed (especially internally). I still don't have a Supercharger of my own, so comments please on whether this loads and/or runs on the real thing :-) (I've only run this on PCAE)
Some notes: * To test the multiload, press the *select* switch. There are two parts, the first being the main program, and the second being 5 256-byte blocks which load into bank 1. * Pressing select from the second level will reload the first (part 0). * With PCAE, the load is instantaneous, so if you hold down "select" (F4), then level-one and level-two will switch rapidly in succession. * DROID uses Supercharger RAM access to move the enemy droids around, so I don't know if this will work correctly on the real thing. Once again, someone please tell me :-)
I hope this meets with your approval ;-)
Regards, David.
David Schweinsberg: DROID Version 2 released.
SUBJECT: [stella] Sourcecode transcription POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Sat, 10 Jan 1998 02:04:16 -0800 (PST) POST: I am not against taking liberties with copyright where sourcecode is concerned because it is in our best interest to study these games and because this source was given to me personally by the actual programmers.
I have the official printed sourcecode to Bob Smith's games:
Star Voyager Dragonfire Riddle of the Sphinx Moonsweeper (8K) Star Wars:TAG (8K)
And the crowning technical acheivement on the VCS:
Doug Neubauer's Solars (16K).
Bob's source is on loan. Doug's printout was given to me but it is a very faint dot matrix printout which really needs to be transcribed before it fades away. He's got a copy of the source on IBM floppy but will not share it with me because despite owning the copyright, he's afraid that JTS-Atari would protest.
I'm throwing this out to the list in the hopes of finding someone I CAN TRUST to take these printouts and make an error-free transcription of them, adjusting syntax as you go along so that it can be re-assembled with the current VCS assembler of choice: DASM. I need to get Bob's source back in my hands in one piece within a reasonable timeframe (3 months or so) so I can get it back to him.
The source would then be free to distribute as you see fit (at your own risk of course--I disavow everything despite being an accessory).
There are routines here that deserve to be studied and cloned including:
Dragonfire's 4-char single-line-res kernel SW:TAG sprite sharing routines Solaris sprite sharing and color change routines Solaris 3D scrolling algorithm Solaris galactic map display
If I had the time, I'd type it in, but I'm too busy with the documentary. It's all dot matrix so unfortunately it probably won't OCR.
If you'd like to volunteer, let me know.
This is COMMENTED source code from the original authors. It's much better than a raw disassembly. ======Glenn Saunders --3D Graphics / Videography / Web development-- == == krishna@xxxxxxxxxxx homepage http://www.geocities.com/Hollywoo d/1698 == == Stella@20 video page http://www.primenet.com/~krishna == == TV Commercials page http://www.lawguru.co m/production/production.html== ======
-- Stella list is Administered by krishna@xxxxxxxxxxxx
======SATURDAY, 10 JANUARY ======Glenn Saunders: Request for Source Code Transcription.
SUBJECT: [stella] INV update POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Sun, 11 Jan 1998 12:46:39 +0100 POST: Shortly..
- converted shields to double resolution, now I've all the RAM I need! Thanks Erick!
- invader explosions from Missile1. I quite like them, and you?
Let me know.. and now back to MAME! ;-)
PS..: Erick, how are the Invaders bombs supposed to work? Can they drop more than one bomb at a time?
Ciao, P.
======SUNDAY, 11 JANUARY ======Piero Cavina: INV Version 2.1 Released.
SUBJECT: Re: [stella] Piracy -- copyrights expired? POSTER: Chris Cracknell <crackers@xxxxxxxx> DATE/TIME: Mon, 12 Jan 1998 00:26:08 -0500 (EST) POST: In article <34B97C6E.F331133B@xxxxxxxx>, you wrote: >John Saeger wrote: >> >> Maybe the copyrights on the original 2600 game cartridges have expired by >> now. The original games weren't software, they were game cartridges > >Depends... Have any of the authors been dead 75 years yet? ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~
Current copyright law is life+50, not life +75. This applies to anything created after 1982.
For things created after 1972 and between 1982 copyright is 50 years plus it's renewable for another 25 years.
>From 1950-1972 the copyright is 28 years plus renewable for another 28 years.
Before 1950 copyright was just 28 years.
Before 1982 there were no provisions in the copyright law for the protection of software. Software was considered by many to be a "usable object" (meaning a tool, like a hammer or widget calibrator) and not a creative work so to protect software developers from piracey changes were made to the copyright act in 1982 to include protection for software.
Before the act of 1972, anything that didn't have (c) 19xx on it was not copyrighted. After 1972, creators were given 5 years from the date of creation to affix a copyright notice to the work or it would be considered public domain. In 1985 an amendment was made to the copyright law that no longer required a work to have a copyright notice attatched to it. All you had to do was be able to prove the date of creation. However, in US copyright law, if you wish to be able to sue for copyright infringement your copyright must be registered. (If it's unregistered you can still sue to have unathorized duplication halted, but you won't be able to sue for financual compensation). It's always a good idea to register your copyright if you're very serious about perserving the integrity of your copyright. Without a registered copyright it can be virtually impossible to prove you created the work first (especially if the person who is pirating your work has registered a copyright for it. Then you're pretty much screwed. There have been cases involving musicians where one musician has stolen another's work but since they registered the copyright for it, the true creator was screwed. It's extremely difficult to get the courts to recognize you're the rightful owner of a work when it has been registered by someone else).
Copyright law is not retroactive. That means something created in 1935 wouldn't be renewable when the copyright laws changed in 1950. It also means that a record created in 1965 but released without a copyright notice would still be public domain even though the law changed in 1985 to no longer require a copyright notice to appear on a work.
The statute of limitation on copyright violation is 3 years. If a work is pirated and not dicovered for 3 years or the copyright owner takes no legal actions to stop it within that time , then there is nothing the copyright owner can do about it
And that is a brief synopsis of some of the interesting parts of copyright law.
CRACKERS (There are a few variations between Canada and USA copyright law from hell!!!) --
Accordionist - Wethifl Musician - Atari 2600 Collector | /\/\ *NEW CrAB URL* http://www.hwcn.org/~ad329/crab.html ***| \^^/ Bira Bira Devotee - FES Member - Samurai Pizza Cats Fan| =\/=
-- Stella list is Administered by krishna@xxxxxxxxxxxx
======MONDAY, 12 JANUARY ======Crackers (Ahhh! Chris Cracknell!): Explaining (now old) Law About Copyright and Piracy.
SUBJECT: [stella] Latest version of my game POSTER: Robert "A." Colbert <colbertb@xxxxxxxxxxxx> DATE/TIME: Wed, 14 Jan 1998 08:51:13 -0600 POST: Hi again, Time for the latest version of my game. Basically, just the foxhole routines have been added. Only the foxholes on the right side get filled on this version. I also HEAVILY commented the kernel, so you can all see how crazy I am. The foxhole routines really caused me some problems. I tried using a modified 6-character routine, but had problems with it.
If 4 paratroopers land, you won't be able to play past the "wave" you are on.
Next I have to fix the way the helicopter flies, then design some real "waves", including adding some different objects, etc. I'm going to save animation for later, to see how much space I have left. The way it is right now it looks as though I have 1k left for game logic.
Later, Bob
Wanna write a game for the Atari 2600? Check out http://www.novia.net/~rcolbert
======WEDNESDAY, 14 JANUARY ======Bob Colbert: Latest Version of Multi-Sprite Game.
SUBJECT: [stella] my lost game POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Tue, 27 Jan 1998 12:18:47 +0100 (MET) POST: Ok, as I thought I've no time to do something new, so here's something old for you..
This is the latest version (unreleased, if I remember correctly) of my very first project, "Mondo Pong", an evil variation on the Pong theme. I've played it today after many months, and I've found it pretty silly and annoying.. but I like it! :-)
It seems to run fine on PCAE, don't know on a real 2600. Use your paddle controllers, or remember to load a DOS mouse driver before starting PCAE.
There are 8 variations, based on the combinations of "1 player/two players", "score limit 15/45", "normal/hard". Please note that nothing changes from normal to hard, and that I don't remember whether 2 players mode works or not.
But, as I was saying, I quite like the 1 player vs. 2600 cpu mode... :-)
Let me know what you think, or this program might be condemned to oblivion again..
Nick: you might put it on your page..
P.
======TUESDAY, 27 JANUARY ======Piero Cavina: New Version of Mondo Pong.
SUBJECT: Re: [stella] Sprite Delema POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Wed, 18 Mar 1998 20:35:55 +0100 POST: At 00:36 18.03.98 -0500, you wrote:
>I want to have both Sprites moving right to left on the top of the screen, >both sprites stationary in the middle of the screen, then both sprites >moving left to right on the bottom of the screen. > >But I can't come up with an eligant way to do this. Can someone give me a >simple talk through on where my thinking needs to be at, thanks.
You would need to sacrifice some scanlines in your display kernal to reposition the player graphics.
There are generic sprite positioning routines at the end of the SoundX source code on the Stella CD and in the example file on the ST devolopers kit disks.
A good way to do the positioning would be to store the horizontal position of your objects in the high and low nibble of a byte for each. The high nibble would hold the value for the HMOVE and the low nibble would hold the value for the @1:DEY/BPL @1 delay loop.
The positioning routine would look like this: STA WSYNC LDA ypos0 STA HMP0 AND #$0F TAY @1:DEY BPL @1 STA RESP0 STA WSYNC STA HMOVE
If the second player has a fixed spacing to the first, you can position it in the same scanline. Otherwise you would need to add a second delay loop before the HMOVE.
Moving the players would be done by adding or subtracting #$10 from the ypos value and checking if the high nibble has rolled so that the low nibble has to be fixed accordingly.
Ciao, Eckhard Stolberg
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html Don't post pirate BINs to Stellalist. Be a programmer, not a pirate. Write the best game, win framed autographs of famous Atari alumni!!
======MARCH 1998 ======WEDNESDAY, 18 MARCH ======Eckhard Stolberg: Explains a Horizontal Movement Routine.
SUBJECT: [stella] Variable cycle delays POSTER: Jim Nitchals <jimn8@xxxxxxxxxx> DATE/TIME: Wed, 18 Mar 1998 12:22:13 -0800 (PST) POST: Hi,
Here's a way to implement single cycle resolution without the use of the carry flag (which adds overhead in the setup and at the end):
; A is assumed to hold the delay value plus the offset address of JumpTable. ; Or, you can align JumpTable to a page boundary. sta indjmp jmp (indjmp) ; point indjmp+1 to JumpTable somewhere in your init code
JumpTable: dc.b $C9 dc.b $C9 ; repeat as many $C9's as you need for the maximum number of cycles you ; you need to delay by. dc.b $C9 ; opcode: CMP immediate (4 cycles: uses the $C5, executes ; the NOP below.) dc.b $C5 ; opcode: CMP zero page (3 cycles, uses up the NOP as a ; destination address of $EA) nop ; opcode: NOP (2 cycles by itself)
You may find the reduced overhead of this technique useful.
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html Don't post pirate BINs to Stellalist. Be a programmer, not a pirate. Write the best game, win framed autographs of famous Atari alumni!!
Jim Nitchals: A Way to Implement Single Cycle Resolution W/O Carry Flag.
SUBJECT: [stella] movable 48 pixels sprite POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Sun, 29 Mar 1998 22:22:52 +0200 POST: After all this discussion about the movable 6-digit routine, I have experimented a bit with everything, that has been posted so far, and managed to put together a working demo.
The source code is not commented and in A65 format. In order to assemble it with DASM you only need to replace every 'DB' with '.byte'.
I used the standard vdel method in ROM which has 6 cycles to spare. If it were put in RAM like Robin's version, it would have 14 cycles left.
Any comments or questions?
Ciao, Eckhard Stolberg
======SUNDAY, 29 MARCH ======Eckhard Stolberg: Movable 48 Pixel Sprite Demo.
SUBJECT: Re: [stella] Re: the big sprite POSTER: Chris Wilkson <cwilkson@xxxxxxxxxxxxx> DATE/TIME: Wed, 1 Apr 1998 09:18:56 -0800 (PST) POST: > This opens up some sort of possibility here... If one were to use two > megasprites of this size and draw them on alternate frames, and had tons of > ROM space, Mortal Kombat could be done on the 2600. Any takers? :) I'm > tempted to do it just to prove it can be done - let's see you Intelly, CV, > or even NES fans do that! :)
Ooh! Ooh! This simply must be done! I've been waiting for years for this! I'll give you all the ROM space you want!!!!
"MK 2600: The Humbling of Show-Kan"
I know the spelling's wrong. Maybe not even the character's name... I'm not a MK fan. Just a bitter old man who can't master the combos like the younguns can ;)
-Chris
(Eye candy is bad enough, but poorly animated eye candy is just sad...)
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html Don't post pirate BINs to Stellalist. Be a programmer, not a pirate. Write the best game, win framed autographs of famous Atari alumni!!
======APRIL 1998 ======WEDNESDAY, 1 APRIL ======Big Thread Discussing the Creation of 2600 Mortal Kombat.
SUBJECT: [stella] Contest Award! POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Wed, 1 Apr 1998 21:59:53 -0800 (PST) POST: ************************************* 1st ANNUAL STELLA PROGRAMMING CONTEST *************************************
************** AWARD CEREMONY **************
The winner of the 1st annual Stella programming contest is:
********************** Piero Cavina's Oystron **********************
Oystron represents the quintessential 4K VCS game. It is notable in many ways. It strikes a perfect balance between aesthetics, depth, and gameplay, which was only possible through Piero's persistence, creativity, and open-mindedness to the suggestions of others. Perhaps most notable of all is the way Oystron is a totally original game concept. While borrowing certain ideas from other classic games, it still feels totally unique. Overall it has the same style of frantic gameplay associated with the best classic action games of the past such as Kaboom, River Raid, Robotron, and Defender. Here is not a modern 90s "spectator" game where you can zone out or just mindlessly button-mash. This game demands your constant attention, and requires you to scan the entire screen for potential threats to both you and your pearls. The teamwork that was shown in playtesting and code-whittling was vital in polishing the game to the same demanding levels acheived by Imagic or Activision way back when.
Piero will receive the grand prize of a framed and personalized plaque with the signatures of, Nolan Bushnell, Al Alcorn, Steve Mayer, Joe Decuir, Ron Milner, Larry Kaplan, and Larry Wagner, the founding fathers of Atari, and the fathers of the VCS hardware and software.
The runner up is:
********************************* Greg Troutman's This Planet Sucks *********************************
Rescue/TPS is signifiant in that it is a liberal port of a Taito game (Lunar Rescue) that kindof fell through the cracks with the success of its sister game, Space Invaders. Porting lesser known but just as enjoyable classic game concepts to the VCS is a great idea. Technically speaking, the game is also significant in the use of its single-line-res kernel. What I like most about the game, however, is its sense of character, in particular, the spasmodic animation applied to downed humans. Greg will be entitled to a free copy of the Cyberpunks' upcoming CD. The contents of this CD will be described in a pending announcement by Russ Perry.
Honorable Mention:
***************** Erik Mooney's INV *****************
INV was another noble experiment, to attack porting Space Invaders and using playfield to match the number of enemies in the arcade. Technically speaking, VCS "psuedobitmap" kernels are very difficult to pull off, and Erik even managed to add character to the blocky invaders through color changes and different shapes. The game has been worked on by several hands and I'd very much like to see this game evolve further, beyond the strict Space Invaders port. The idea of a two player competitive mode with the 2nd player as the saucer and with limited control of the invaders really intrigues me :)
Congratulations to the winners and I hope I will be able to find a decent prize and hold another contest next year!
======Glenn Saunders --3D Graphics / Videography / Web development-- == == krishna@xxxxxxxxxxxxxxx http://www.geocities.com/Hollywoo d/1698 == == Stella@20 video page http://www.primenet.com/~krishna ======
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html Don't post pirate BINs to Stellalist. Be a programmer, not a pirate. Write the best game, win framed autographs of famous Atari alumni!!
First Annual Stella Programming Contest Winner is Piero Cavina.
SUBJECT: Re: [stella] does the processor stop during VSYNC? POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Mon, 06 Apr 1998 17:28:27 +0200 POST: At 22:21 05.04.98 -0500, you wrote:
>When you do a VSYNC, does the processor wait until it's really time for >the next frame to begin before processing resumes (like a WSYNC), or >does it just send the sync signal to the TV and keep on running >regardless of how many scan lines have passed since the last time? I'm >hoping it's the former, of course, but I'm guessing it's probably >really the latter. The emulator I'm using (Stella 0.7) seems to think >any number of scan lines in a frame is fine, but I don't know how much >faith I should put in its emulation. Unlike the Wsync register, Vsync is not a strobe register. Instead it lets you turn the vertical sync signal on and off. So what you have to do to get a stable picture is: make sure the correct number of scanlines have passed, turn on Vsync, wait for 3 scanlines via Wsync and turn off Vsync.
Ciao, Eckhard Stolberg
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html Don't post pirate BINs to Stellalist. Be a programmer, not a pirate. Write the best game, win framed autographs of famous Atari alumni!!
======MONDAY, 6 APRIL ======Eckhard Stolberg: The Processor Does Not Turn Off During VSYNC.
SUBJECT: [stella] The Big Sprite POSTER: Glenn Saunders <krishna@xxxxxxxxxxxx> DATE/TIME: Wed, 8 Apr 1998 09:52:07 -0700 (PDT) POST: I don't think this kind of thing has ever been done before. Quite impressive. At first I thought this MK stuff was just a joke, and certainly the game would normally be considered impossible in any form on the 2600, but now I can see that it might actually be possible. It's just a shame that the BG on the scanlines with the big sprites has to be completely black. MK was known for its detailed backgrounds. As for the flicker, 30hz flicker is fine. It's 15 and 7hz flicker that starts to really look bad.
If you could free up the ball or the missiles you might be able to at least sprinkle some pixels in there implying blood sprays ;)
Another approach to this game would be to use Suicide Mission stipple bitmap graphics. You won't get as solid an image, but you'd be able to do a limited background at the same time. Of course, if this mode is limited to the SC, there may not be enough memory to hold the gfx necessary vs. a hugely banked ROM...
======Glenn Saunders --3D Graphics / Videography / Web development-- == == krishna@xxxxxxxxxxxxxxx http://www.geocities.com/Hollywoo d/1698 == == Stella@20 video page http://www.primenet.com/~krishna ======
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html Don't post pirate BINs to Stellalist. Be a programmer, not a pirate. Write the best game, win framed autographs of famous Atari alumni!!
======WEDNESDAY, 8 APRIL ======More Discussion on 2600 Mortal Kombat.
SUBJECT: [stella] Length of HMOVE blanks POSTER: <kurt.woloch@xxxxxxxxx> DATE/TIME: Thu, 9 Apr 1998 10:09:33 +0200 POST: On Wed Apr 8 19:54:43 1998, Bradford W. Mott (bwmott@xxxxxxx), obviously the author of the STELLA emulator, wrote:
> BTW, how wide are the HMOVE blanks (8 pixels)?
I think they are 8 pixels, yes. What I don't know is what happens if you apply the horizontal motion at any other time than immediately after a VSYNC. Does the display turn black then, too, maybe for a longer time interval? Has anyone out there tried that out already?
BTW, I've got PCAE 2.0 by now, thanks to you giving me some more URL's to download it. I had a little problem with the long filenames used in the package for the documentation files, 'cause I'm not using Win 95. Attention, Win 3 or DOS users! You could get that problem too! Better use WINZIP for unpacking rather than PKUNZIP! Still, it runs only on 486's and up. Since I've got a 386 at home, I would appreciate a Stella version without the bug (as long as it still runs on a 386, regardless of how fast - it's only for testing if my program does what I want.)
While you were talking about the implementation of MK, I was thinking about some other (older) games who to my knowledge haven't been ported to the VCS by now and could be easier to do:
-PARSEC (a game by Texas Instruments for the TI-99 computer) -PEN-KUN WARS aka Penguin Wars (I've got a Gameboy cart of that) -Antarctic Adventure (currently existing for MSX and Coleco) -Elevator Action (well, maybe with some slight changes) -Traverse USA (another arcade game) -Manhattan (maybe some of you know this arcade game: You have to jump up between two skyscrapers. On the way down you land on several platforms...) -Shao-Lin's road -Marble Madness (this would have to suffer...) -Paperboy (could be quite doable, with some simplifying in the graphics...) -Donkey Kong 3 (would be logical after Donkey Kong and Donkey Kong Jr. have been adapted; I think it would even be easier to do on the VCS than the former two, since all the playfield is symmetric.)
Also, you could try another 3D racing game. I know that there are Pole Position and Enduro out, also TURBO by Coleco (haven't come across a BIN of that yet, only heard that it has been done...). Still, I think that there could be some more approaches on that genre. Pole Position and Turbo, as well as Night Driver, don't display the road in another color than the meadow, which I think isn't impossible to do.
Given the time I need, maybe I'll try one of these myself, but I've got some imaginations on these games, how they could be implemented, what to do on which scanlines, etc. If anybody has interest, I can give you more details.
Bye for now, Kurt Woloch
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html Don't post pirate BINs to Stellalist. Be a programmer, not a pirate. Write the best game, win framed autographs of famous Atari alumni!!
======THURSDAY, 9 APRIL ======Kurt Woloch: HMOVE Blanks are 8 Pixels.
SUBJECT: [stella] Latest version of my new game POSTER: Retroware <rcolbert@xxxxxxxxx> DATE/TIME: Thu, 09 Apr 1998 21:40:27 -0500 POST: Hi, Here is the latest version of my new game, let me know what you think about it! It doesn't have any level design in it yet, I'm still working on the kernel a bit here and there and will be adding more enemies. Then I will probably add the score, etc... Just wanted to update you all, I've been absent for a while since I've changed jobs, but I'm getting back into the swing of things here.
I'd love to hear some opinions regarding this game, ideas for improvements, gameplay, etc.
Thanks, Bob
Bob Colbert: Latest Version of the Multi-Sprite Game.
SUBJECT: [stella] Fixed non HMOVE sprite experiment POSTER: CRACKERS <crackers@xxxxxxxx> DATE/TIME: Wed, 15 Apr 1998 17:22:05 -0400 (EDT) POST: Okee Dokee ((TM) Retroware), I've fixed the problem with a BNE instead of a BPL. I've also cleaned up the VBLANK routine so hopefully it will now run on Eckard's beastie too. Let me know if anyone else has any problems with this.
I'll add some more independent vertical sprite copies and then clean and comment the hell out of the source code and post it to the list so that newbies will be able to get a grip on independent multiple sprites.
Man am I glad I'm done school for now!
CRACKERS (Whew from hell!!!!!!!!!)
======WEDNESDAY, 15 APRIL ======Crackers: Non-HMOVE Sprite Experiment. See earlier post "Aaargh" for Early Source. Thread for Bugfix.
SUBJECT: [stella] Hiragana Font For The 2600 POSTER: Chris Cracknell <crackers@xxxxxxxx> DATE/TIME: Thu, 16 Apr 1998 20:25:28 -0400 (EDT) POST: Well I needed some sprites to do some experiments on the 2600, so I decided to use some japanese characters... then I decided, "what the heck, let's make an entire hiragana font."
If you want to add an exotic touch to your Atari 2600 programmes I've made a font that includes all the hiragana characters (these are characters that are used to spell native japanese words, as opposed to katagana characters that are used to spell words borrowed from other languages).
Now I've set up the punctuation and other things to be used in the traditional japanese writing style, right to left, top to bottom... e l l w w T n i o o h h g k o u a i l e k l t s i d s i i i h n t s .
This is okay because for the 2600 it would be easier to display japanese writing this way. Using the "six digit score routine" would really work great for printing japanese text. The only thing is the marks that give you the alternate pronounciation of a character had to be a seperate sprite placed beside the root character (since the sprites are only 8 bits wide I couldn't incorporate the marks into a single character with the root).
For ease of use I restricted myself to 8x8bit blocks for the fonts. It was extremely challenging to make hiragana characters that are readable in such small packages, but I think I've pulled it off (although some characters might need to be written in context to be fully recognizable. nu and me were particularily hard to pull off, so was no picnic either).
I'll be making a set of katagana fonts (which will probably be more useful, and much easier to make) later. But here's the font set now if anyone out there wants to use them, please help yourself.
------
;Japanese Hiragana Font For The Atari 2600 ;Copyright 1998 Chris "Crackers" Cracknell ;Usage Rights released into the Public Domain
;all these characters are stored UPSIDE-DOWN! It's easier to read them ;into the program that way. a .byte %00111100 ;A - pronounced "ah" as in .byte %01001010 ;fAther .byte %01001010 .byte %00110010 .byte %00011100 .byte %00010000 .byte %00111000 .byte %00010000 i .byte %00100000 ;I - pronounced "e" as in .byte %00110000 ;skI .byte %01000000 .byte %01000000 .byte %01000010 .byte %01000010 .byte %00100100 .byte %00100100 u .byte %00011100 ;U - pronounced similar to "oo" as in .byte %00000010 ;cOOl .byte %00000010 .byte %01000010 .byte %00111100 .byte %00000000 .byte %00001000 .byte %00010000 e .byte %00100110 ;E - pronounced "a" as in .byte %00010100 ;pAy .byte %00001000 .byte %00001000 .byte %00111000 .byte %00000000 .byte %00001000 .byte %00010000 o .byte %00110100 ;O - pronounced "o" as in .byte %01010010 ;gO .byte %00110010 .byte %00011100 .byte %00010001 .byte %00010010 .byte %00111000 .byte %00010000 ka .byte %01000100 ;position dotdot second sprite to the .byte %00101010 ;right to make ga .byte %00100010 .byte %00100010 .byte %00010010 .byte %01111100 .byte %00010001 .byte %00010010 ki .byte %00111100 ;dotdot makes gi .byte %01000000 ;smallya below makes kya/gya .byte %01001000 ;smallyu makes kuy/gyu .byte %00010000 ;smallyo makes kyo/gyo .byte %01111100 .byte %00010000 .byte %00111000 .byte %00010000 ku .byte %00000100 ;dotdot makes gu .byte %00001000 .byte %00010000 .byte %00100000 .byte %00100000 .byte %00010000 .byte %00001000 .byte %00000100 ke .byte %00101000 ;dotdot makes ke .byte %00100100 .byte %01000100 .byte %01000100 .byte %01000100 .byte %01001110 .byte %00100100 .byte %00100100 ko .byte %00111100 ;dotdot makes go .byte %01000010 .byte %00000000 .byte %00000100 .byte %00011110 .byte %00100000 .byte %00000000 .byte %00000000 sa .byte %00111100 ;dotdot makes za .byte %01000000 .byte %01001000 .byte %00010000 .byte %00010000 .byte %00111000 .byte %00010000 .byte %00010000 shi .byte %00011000 ;dotdot makes ji .byte %00100100 ;smallya makes sha/jya .byte %00100010 ;smallyu makes shu/jyu .byte %00100000 ;smallyp makes sho/jyo .byte %00100000 .byte %00100000 .byte %00100000 .byte %00100000 su .byte %00010000 ;dotdot makes zu .byte %00001000 .byte %00011000 .byte %00101000 .byte %00011000 .byte %00001000 .byte %00111110 .byte %00001000 se .byte %00011100 ;dotdot makes ze .byte %00100010 .byte %00100000 .byte %00100000 .byte %01100100 .byte %00110100 .byte %00101110 .byte %00100100 so .byte %00001100 ;dotdot makes zo .byte %00010000 .byte %00001000 .byte %00111100 .byte %00100000 .byte %00010000 .byte %00001000 .byte %00110000 ta .byte %01000000 ;dotdot makes da .byte %01001110 .byte %01000000 .byte %01001100 .byte %00100010 .byte %00100000 .byte %01110000 .byte %00100000 chi .byte %00001100 ;dotdot makes di .byte %00000010 ;smallya makes cha .byte %00000010 ;smallyu makes chu .byte %00010010 ;smallyo makes cho .byte %00011100 .byte %00010000 .byte %00111000 .byte %00010000 tsu .byte %00011100 .byte %00100010 .byte %00000010 .byte %01100010 .byte %01010010 .byte %00001100 .byte %00000000 .byte %00000000 te .byte %00000100 ;dotdot makes de .byte %00001000 .byte %00001000 .byte %00001000 .byte %00001000 .byte %00000100 .byte %01100010 .byte %00011110 to .byte %00111000 ;dotdot makes do .byte %01000100 .byte %01000000 .byte %01000000 .byte %00111000 .byte %00010000 .byte %00010000 .byte %00000000 na .byte %00001010 .byte %00010100 .byte %00001100 .byte %01000100 .byte %00100100 .byte %00100000 .byte %01110010 .byte %00100100 ni .byte %00100000 .byte %00101110 .byte %01000000 .byte %01000000 .byte %01000000 .byte %01000000 .byte %00101110 .byte %00100000 nu .byte %00100101 .byte %01011010 .byte %10010110 .byte %10001010 .byte %01011010 .byte %00111100 .byte %00100100 .byte %01000010 ne .byte %00100010 .byte %11100101 .byte %10100010 .byte %01100010 .byte %00110010 .byte %00101100 .byte %00100000 .byte %00100000 no .byte %00110100 .byte %01010010 .byte %01010010 .byte %01010010 .byte %01010010 .byte %00110010 .byte %00001100 .byte %00000000 ha .byte %01000101 ;dotdot makes ba .byte %01101010 ;pdot makes pa .byte %10000110 .byte %10000010 .byte %10000010 .byte %10000010 .byte %01000111 .byte %01000010 hi .byte %00011100 ;dotdot makes bi .byte %00100010 ;pdot makes pi .byte %00100010 ;smallya makes hya/bya/pya .byte %00100010 ;smallyu makes hyu/byu/pyu .byte %00010011 ;smallyo makes hyo/byo/pyo .byte %01010010 .byte %00100000 .byte %00100000 fu .byte %01001010 ;dotdot makes bu .byte %10001001 ;pdot makes pu .byte %01010010 .byte %00010000 .byte %00010000 .byte %00001000 .byte %00001000 .byte %00010000 he .byte %00000000 ;dotdot makes be .byte %00000000 ;pdot makes pe .byte %00000001 .byte %00000010 .byte %01000100 .byte %00101000 .byte %00110000 .byte %00000000 ho .byte %01000101 ;dotdot makes bo .byte %01101010 ;pdot makes po .byte %10000110 .byte %10000010 .byte %10000010 .byte %10000111 .byte %01000010 .byte %01000111 ma .byte %01101100 .byte %01010000 .byte %01110000 .byte %00010000 .byte %00111000 .byte %00010000 .byte %00111000 .byte %00010000 mi .byte %01100000 ;smallya makes mya .byte %10100010 ;smallyu makes myu .byte %10100010 ;smallyo makes myo .byte %01100011 .byte %00111110 .byte %10100010 .byte %01100010 .byte %00100000 mu .byte %00001100 .byte %00010010 .byte %00110010 .byte %01010000 .byte %00110001 .byte %00010010 .byte %00111000 .byte %00010000 me .byte %00101010 .byte %01011001 .byte %01011001 .byte %01110101 .byte %00011110 .byte %00100100 .byte %00100100 .byte %00000000 mo .byte %00001100 .byte %00010010 .byte %00010010 .byte %00010000 .byte %00111000 .byte %00010000 .byte %00111000 .byte %00010000 ra .byte %00011100 .byte %00000010 .byte %00000010 .byte %01100010 .byte %01011100 .byte %01000000 .byte %00001000 .byte %00010000 ri .byte %00000100 ;smallya makes rya .byte %00000100 ;smallyu makes ryu .byte %00000010 ;smallyo makes ryo .byte %00000010 .byte %01000010 .byte %01100010 .byte %01010010 .byte %01001100 ru .byte %00001100 .byte %00001010 .byte %00000110 .byte %00100010 .byte %00011100 .byte %00001000 .byte %00000100 .byte %00111110 re .byte %00100100 .byte %11100100 .byte %10100010 .byte %01100010 .byte %00110010 .byte %00101110 .byte %00100000 .byte %00100000 ro .byte %00011100 .byte %00000010 .byte %00000010 .byte %00100010 .byte %00011100 .byte %00001000 .byte %00000100 .byte %00111110 ya .byte %00100000 .byte %00100000 .byte %00100110 .byte %10100001 .byte %01100001 .byte %00111110 .byte %00101010 .byte %00100000 yu .byte %00001000 .byte %01001010 .byte %01101001 .byte %01101001 .byte %01011001 .byte %01011110 .byte %01001000 .byte %00001000 yo .byte %01101100 .byte %01010000 .byte %01110000 .byte %00010000 .byte %00010000 .byte %00011100 .byte %00010000 .byte %00010000 wa .byte %00100100 .byte %11100010 .byte %10100001 .byte %01100001 .byte %00110010 .byte %00101100 .byte %00100000 .byte %00100000 wo .byte %00001100 ;object marker wo .byte %00010000 ;pronounced "o" .byte %00010100 .byte %00001110 .byte %00110100 .byte %00101000 .byte %01110000 .byte %00100000 period .byte %00000000 ;japanese style period .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000010 .byte %00000101 .byte %00000010 .byte %00000000 pdot .byte %00000000 ;place this dot beside ha-ho .byte %00000000 ;characters to make them .byte %00000000 ;pa-po .byte %00000000 .byte %01000000 .byte %10100000 .byte %01000000 .byte %00000000 dotdot .byte %00000000 ;two little dashes are placed .byte %00000000 ;beside a character to give .byte %00000000 ;it a different pronounciation .byte %00000000 ;ka-ko/ga-go .byte %00100000 ;sa-so/za-zo .byte %01001000 ;ta-to/da-do .byte %10010000 ;ha-ho/ba-bo .byte %00100000 bquote .byte %00000000 ;japanese begin quotation mark .byte %00000000 .byte %00000000 .byte %00000000 .byte %01000000 .byte %01000000 .byte %01000000 .byte %01110000 equote .byte %00001110 ;japanese end quotation mark .byte %00000010 .byte %00000010 .byte %00000010 .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000000 dblqotb .byte %00000000 ;japanese begin double quote .byte %00000000 .byte %00000000 .byte %11100000 .byte %10100000 .byte %10100000 .byte %10010000 .byte %11110000 dblqote .byte %00001111 ;japanese end double quote .byte %00001001 .byte %00001101 .byte %00000101 .byte %00000111 .byte %00000000 .byte %00000000 .byte %00000000 coma .byte %00000000 ;japanese coma .byte %00000000 .byte %00000000 .byte %00000000 .byte %00000010 .byte %00000110 .byte %00000100 .byte %00000000 smallya .byte %00000000 ;small ya, added below i-dan to make .byte %00000000 ;kya, gya, sha, jya, cha, hya, etc. .byte %00000000 .byte %00000100 .byte %00000101 .byte %00001111 .byte %00000100 .byte %00000000 smallyu .byte %00000000 ;small yu, added below i-dan to make .byte %00000000 ;kyu, gyu, shu, jyu, chu, hyu, etc. .byte %00000000 .byte %00000010 .byte %00001011 .byte %00001011 .byte %00000110 .byte %00000000 smallyo .byte %00000000 ;small yo, added below i-dan to make .byte %00000000 ;kyo, gyo, sho, jyo, cho, hyo, etc. .byte %00000000 .byte %00001100 .byte %00001100 .byte %00000110 .byte %00000100 .byte %00000000 smlltsu .byte %00000000 ;small tsu, placed before a character .byte %00000000 ;to double it's starting constanant. .byte %00000000 ;ka + small tsu + ta = katta .byte %00000010 .byte %00000001 .byte %00001001 .byte %00000110 .byte %00000000
------
If anyone has wants to use japanese in a 2600 game and has questions feel free to ask.
CRACKERS (Now that was fun from hell!!!)
-- Accordionist - Wethifl Musician - Atari 2600 Collector | /\/\ *NEW CrAB URL* http://www.hwcn.org/~ad329/crab.html ***| \^^/ Bira Bira Devotee - FES Member - Samurai Pizza Cats Fan| =\/=
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html
======THURSDAY, 16 APRIL ======Crackers: Hiragana Font for 2600.
SUBJECT: [stella] Strange software, and weirder hardware (long) POSTER: Chris Wilkson <cwilkson@xxxxxxxxxxxxx> DATE/TIME: Thu, 16 Apr 1998 21:04:39 -0700 (PDT) POST: Ok, I said I'd tell you guys a story about misunderstood instructions, code that works on real hardware, but only sometimes, and a fledgling programmer who spent nearly a year beating his head against the wall trying to figure out what was wrong. So here it is. But be warned, it's kinda long...
A couple of weeks after the "How to Draw a Playfield" demo was posted here, I took it home and started playing with it. I added single scanline color cycling in the background with the option to freeze the background and color cycle the bat, via the BW/COLOR switch. So I get the thing working on the 2600, but the switch doesn't work in PCAE. Weird. Oh well, it worked on my *real* VCS, and that's what counted. I intended to use it to test the hardware mods I'm doing.
So I struggle with data bus contention in the new hardware (or so I thought) for a few weeks with no luck whatsoever. At this point I have 2 oscilloscopes 3 power supplies, a function generator, and a logic analyzer hooked up to the thing...it looks like it's on life support in Dr Frankenstein's lab.
So I decide that I'll monitor a known working cart...my modified bat demo. But it doesn't work any more. "Whaddya know? That's odd..." I say to myself. Then proceed to spend a few more weeks trying different consoles with the same non-performance resulting. "Damn..." I try burning the eprom again. Repeatedly. No luck. I build a new cart from scatch. No luck. I try a Frogger cart. Hmmmm...seemed to work, but I couldn't see what was happening. The cart was so big I had to disconnect all my equipment! I didn't feel like hooking up all the test leads again, so I gave up for a while. During this time, I designed a daughter board that lets me just plug the logic analyzer cable directly into the board. Got it back a couple of weeks ago. It rocks!
While I'm testing the new board, I try the bat demo cart. Works like a charm. "Huh???" So I plug in the logic analyzer to see what's going on, and it quits working! Eeeek! Something definitely screwy going on here. So I spend a couple of days setting up the analyzer to decode the address bus for all the TIA and RIOT registers. Now it tells me that "VSYNC" was just accessed, instead of $0001. :) So I'm looking at the code as it gets executed and notice that INPT0 is being accessed right after the read to SWCHB. So I go look at the code and find the problem. I'm trying to use immediate adressing with the BIT instruction. That's a no no! The hell of it is that I made a typo way back when. I typed "BIT $8" instead of "BIT #$8". So my assembler didn't flag it as an error...it just said "ok boss" and assembled it. That still doesn't answer the question of why it quit working when I plugged the analyzer in. Or why it worked in the first place. After all, it was successfully reading the BW/Color switch at address $8. On every console I have...about 15 of them. Weird. Turns out that the signal was being coupled to the INPT0 capacitor. Hooking up the logic analyzer increased the capacitance enough to interfere with this.
Pretty crazy huh? Don't ever let someone tell you that "it's ok because it works on a real Atari".... :)
-Chris
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html
Chris Wilkson: Misunderstood Instructions: Code that Works on Real Hardware, But Only Sometimes.
SUBJECT: [stella] Games that do bad things to HMOVE... POSTER: bwmott@xxxxxxxxxxxx DATE/TIME: Thu, 23 Apr 1998 00:50:35 -0400 (EDT) POST: I've been working on improving the TIA emulation for the next release of Stella. One game that's given my TIA emulation trouble in the past was He-man's title screen. Usually the text that's displayed is distorted a lot. I started looking at a trace of the code that generates the title screen and this is what I found out:
The upper part of the title screen (M Network Presents) is generated by P0 and P1 with NUSIZx set to two close and VDELPx turned on.
P0 and P1 are positioned using the following code:
PC=f622 IR=85 <$nn 2 STA> A= 7 X= 0 Y=ff PS=20 SP=fd Cyc=8284 0 PC=f624 IR=ea
STA RESP0 @ cycle 41 clock location 41 * 3 = 123 + 5 = 128 (60) STA RESP0 @ cycle 44 clock location 44 * 3 = 132 + 5 = 137 (69)
Several lines of code down they finally do: STA HMOVE (HMP0 = $80 HMP1 = $90) Motion registers were set before position code above
So after the HMOVE I guessed the positions to be:
128 + 8 = 136 137 + 7 = 144 and the final pixel locations to be:
P0 = 136 - 68 = 68 P1 = 144 - 68 = 76
However, using these locations there doesn't seem to be anyway for the text to work out since during the drawing of the text P0 and P1 are being hit at the wrong cycle times (i.e. while they're being displayed). I thought about this and tried a few different approaches to solve the problem but nothing worked :-( Then I realized that after the position code above they hit HMOVE in a very strange way. The code is:
PC=f62d IR=85 <$nn 2 STA> A= 7 X= 0 Y= 0 PS=22 SP=fd Cyc=8360 PC=f62f IR=a2 <#$nn f630 LDX> A= 7 X= 9 Y= 0 PS=20 SP=fd Cyc=8362 PC=f631 IR=ea
So they waste 71 cycles and hit HMOVE ending on cycle 74. Thus they are hitting HMOVE two cycles before HBLANK begins.
Now, the best I can figure is that by hitting HMOVE at this time it reduces the amount of motion applied to the objects by 6 clocks. So that instead of moving P0 by 8 pixels and P1 by 7 pixels it moves them by 2 and 1 pixels. So we have that because HMOVE occurs at cycle 74 we loose 6 color clocks and the pixel locations are:
128 + 2 = 130 130 - 68 = 62 137 + 1 = 138 138 - 68 = 70
Using these pixel locations the drawing works out and the text is displayed as it should be.
What do you all think? Is this what happens when you hit HMOVE near the end of a scanline?
Does this mean that if you hit HMOVE during let's say the middle of a scanline it would have no effect?
Finally, do you have any idea why they decided to do it this way? I'm guessing that it somehow avoids the HMOVE BLANK lines and they wanted this because they have a border around the title screen.
Oh well, it's bed time :-) Brad
------Bradford W. Mott (bwmott@xxxxxxx) Computer Science Department http://www4.ncsu.edu/~bwmott/www North Carolina State University ------
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html
======THURSDAY, 23 APRIL ======Bradford Mott: He-Man's Title Screen and Early Stella Emulation.
SUBJECT: [stella] playfield on-the-fly updates POSTER: "Andrew Davie" <adavie@xxxxxxxxxxxxxxxxx> DATE/TIME: Tue, 5 May 1998 12:07:35 +1000 POST: Before I reinvent the wheel, can anybody comment on the feasibility of producing a non-repeated playfield by writing PF0, PF1 and PF2 chasing the scanning beam before data required for the repeated section? Of course, there would be two lots of writes required per scan line, but I'm interested to know if its been done. What I'm asking, I guess, is when it comes to drawing the right half of the PF, does the hardware re-read the PF registers, or is it buffered internally somehow? Cheers A
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html ======MAY 1998 ======TUESDAY, 5 MAY ======Thread Started By Andrew Davie on Non-Repeated Playfield By Chasing the Beam.
SUBJECT: [stella] just wondering POSTER: "Andrew Davie" <adavie@xxxxxxxxxxxxxxxxx> DATE/TIME: Tue, 5 May 1998 19:23:24 +1000 POST: Being extremely new to the 2600 world, and knowing very little about the hardware, I was mulling over how I'd have been using self-modifying code all over the place were this a C64. Then I got to wondering... if the cartridge were, for example, CMOS-backed battery RAM... then...? I'm asking if the ROM addresses could also be writeable, given a correct cartridge? I know I should figure this out myself, but asking is just so much easier. My current plans for speed, by the way, involve placing self-modifying code in zero page to help me whizz the kernel along. Yeah, I know space is tight. Just wondering if anyone has done this kind of thing. Last time I asked that, the answer was "oh... about 1000 people". Cheers A
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html
Thread By Andrew Davie on Self-Modifying Code.
SUBJECT: RE: [stella] Formats (64K Flat Model??) POSTER: "Amos Bannister"<Amos.Bannister@xxxxxxxxxxxxxxxx> DATE/TIME: Wed, 6 May 1998 10:01:11 +1100 POST: > Atari 2600 64K Flat Model -- What's wrong with this picture??? > ------
> Lately, as I've been contemplating the future of the z26 emulator, > I came to the conclusion that it would be nice if it could run minimalist > Commodore 64 binaries, so that we could certify the 6502 CPU emulation > by running the Wolfgang Lorentz 6502 CPU diagnostics. I thought to do > this we might need to support the full 64K address space. Then I started > thinking, wouldn't it be nice if you could write 2600 programs with the full > 64K address space without having to worry about bank-switching? It > would be easy to do in an emulator, but I thought it would be to little > purpose since it could never be implemented in a cartridge. But then it
> occurred to me that maybe I was wrong. Maybe it is possible... So I'm > putting this out to the group to see if anybody can see why it won't work. > And who knows? Maybe someone would want to try to build it.
I was toying with the idea of actually building a "souped up" A2600 with a 6502 and say 4 or 8 K RAM. I haven;t gone very far with this idea, but it shouldn't be too hard to do... -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html
======WEDNESDAY, 6 MAY ======Amos Bannister: Z26 Running C64 Binaries.
SUBJECT: [stella] some more optimization tips POSTER: "Andrew Davie" <adavie@xxxxxxxxxxxxxxxxx> DATE/TIME: Sat, 9 May 1998 09:37:27 +1000 POST: Delay loops seem fairly common in the kernal - or at least timed out sections of code. The optimisation need here is in code size, not speed!
For 2 cycle delays, costing 1 byte.. use a NOP For 3 cycle delays, costing 2 bytes, use LDA $80 or similar Rather than strings of NOPs, you can use the following... pha pla
Pairs of pha/pla cost only two bytes, yet use up 7 cycles each pair. For longer delays. put a label on one of your RTS instructions return RTS now, whenever you want a 12 cycle delay you can go...
JSR return that will only cost you 3 bytes.
Using combinations of the above lets you maximise cycle time, and minimise byte usage.
Enjoy! A
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html
======SATURDAY, 9 MAY ======Andrew Davie: Optimisation Tips for Delay Loops.
SUBJECT: [stella] Demo #1 of my 4 colour playfield game "PUSH" POSTER: "Andrew Davie" <adavie@xxxxxxxxxxxxxxxxx> DATE/TIME: Sun, 10 May 1998 23:22:16 +1000 POST: OK, as part of my first game, I decided I needed a 4 colour playfield. This is pretty much functional at the moment, but I'm working blind - relying on a PC emulator to give me an idea of what things look like. The attached demonstrates a 2 player 4 colour playfield pair (that's 7 effective colours total). Thing is, it flickers like buggery. I figure this is because the frame rate of the emulator isn't synched with the frame rate of my PC. In any case, I'm including a binary in the hope that I can get some feedback on actual hardware. Firstly, everyone note the 4 colours!! Wahooo I'll include the source code for those interested. Please note, this is under development and don't criticise things too harshly! Especially don't worry about optimisations at this point. Functionality is my concern. I'd like to know what the flicker is like on an actual 2600. I'm concerned at my draw code - am I generating an acceptable frame? Does the TV synch OK?
I'd really like some feedback. If you think its interesting, say so. If you think it sucks, tell me why. Positive response will encourage me to continue sharing source - otherwise I'll go native.
Enjoy! A
In case my attachments don't make it, you can always find the latest version of this particular game at http://www.comcen.com.au/~adavie/p ush/
======SUNDAY, 10 MAY ======Andrew Davie: 4 Colour Playfield Demo "PUSH" Version 1.
SUBJECT: [stella] optimization POSTER: "Andrew Davie" <adavie@xxxxxxxxxxxxxxxxx> DATE/TIME: Wed, 13 May 1998 21:21:14 +1000 POST: Here's a quickie... I always like a quickie....
When you need to multiply... think carefully about the binary organisation of either of the numbers, and how you can use powers of two to make your job qucker by incorporating shifts
A shift to the left is the same as multiplying by two lda n asl ; a now holds 2n
So, multiplying by powers of two is as simple as shifting multiple times.... this is pretty straightforward so far... lda n asl asl ; a holds 4n
OK, easy stuff. But what if we want to multiply by 3. ... well, that's the same as multiplying by two and adding the original lda n asl adc n ; assuming n was < 127 originally, a holds 3n
See how I left out the carry before the add, on the assumption that it would be cleared by the shift (asl) instruction before. Mostly, you have a fair idea of values you're working with, so can guarantee the validity of this.
So, x3 turns out to be pretty easy. let's try x10 Welll... breaking it into blocks of multiplies by two (ie: shifts) is as simple as looking at the binary bit pattern... 10decimal is 1010binary. That shows us that we need to shift once, then shift twice, then add the two together. Here we go... lda n asl sta temp ; temp holds 2n asl asl ; a = 8n adc temp ; +2n = 10n
OK, all assuming we won't have overflow - otherwise insert a carry before the add. But see how I've just done a x10 with just 15 cycles of processor time, and 9 bytes! Watch when you need to do multiplies just what values you're dealing with - you could save yourself a lot of cycles :)
Always be prepared, though, to just whack in a huge table in ROM... ldx n lda times10,x
... times10 db 0,10,20,30,40.... etc
That only took 7 cycles, mmmh :)
I hope this stuff isn't too basic for the list, but hope some may be interested. If its too basic, let me know and I'll up a notch :)
Enjoy! A
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html
======WEDNESDAY, 13 MAY ======Andrew Davie: Optimisation Tips for Multiplying.
SUBJECT: [stella] Positioning two objects POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Fri, 15 May 1998 03:11:28 GMT POST: The past couple days, I've been wondering if a routine to position two objects in any positions on a single scanline could be done, allowing more objects with less vertical space between them. Obviously, a delay loop between the objects is impossible (what if the objects are in the same position?) unless they're forced to be apart, maybe on opposite sides of the screen like Street Racer or something. The only way I can think of to do it is use self-modifying code with a large chunk of RAM (SC or megacart) to put it in. The kernel code would be generated by offscreen code, and it'd go something like this:
We make some sort of single-cycle precision delay (Andrew's previous posts on this might be quite helpful) and then the STA RESP0 [1]... the STA RESP0 happens at the earliest possible time so that the object can be HMOVEd into the correct position... example, if the object is to be at pixel 61 onscreen (129 from wsync), we delay 36 cycles, then hit RESP0, which puts it at pixel (36 cycles + 3 for the RESP0) * 3 + the "mystery 5 pixels" = 122, then put -7 into HMP0. [2] Then, we delay as long as necessary to get the second object into position, with the same method. Look at the worst-case scenario - the objects are in the same position. In this case, the code would do the STA RESP1 immediately after the STA RESP0, putting it 3 cycles = 9 pixels after the first player, or at pixel 131. We then put +2 into HMP1, getting it to pixel 129.
Make sense? Might it work? You'd need enough RAM to hold the generated kernel for every time you want to position two objects together, probably about 30 bytes per pair, which kills any chance of zeropage. But SC or megacart RAM could hold the 300-450 bytes for this. And three objects on a line can't be done if they're all in the same position, but if they can be forced far enough apart, it could be done.
[1] The code would have to figure out which object is leftmost and make sure to position that one first. This would be easier if it didn't matter which object was which - suppose a player and its missile were to be used for two Breakout balls or two Missile Command missiles... you could always use player 1 for the left object and missile 1 for the right object.
[2] Of course, that -7 goes into the top four bits of HMP0, and it'd be a good idea to do that during the 36 cycle delay. And a WSYNC is done immediately after the second positioning, and the HMOVE immediately after that.
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html
======FRIDAY, 15 MAY ======Erik Mooney: Thread About Positioning Two Objects on a Single Scanline.
SUBJECT: [stella] optimization : sneaky fractional bit representation POSTER: "Andrew Davie" <adavie@xxxxxxxxxxxxxxxxx> DATE/TIME: Sat, 16 May 1998 20:56:36 +1000 POST: Here's an old favourite of mine.
RAM is pretty tight on the 2600, this one could come in handy for those with really really tight space problems. Its a way of using, say, 2 and a HALF bits to represent a particular datum. That is, you don't have to use a whole number of bits.
Consider this: typically you may wish to store some data, and the values may range from 0 to, say, 11. So, you'd probably want to store that in 4 bits (which can represent 0 to 15), saving yourself those other 4 bits in the byte for other purposes. Neat enough, but you can do better, and actually only use 3 and-a-bit bits. No, really... you can! xxxxBBBB The above shows a typical way of representing a number up to 12 (from 0 to 11), by using the lower 4 bits of a byte - the bits marked "x" can be used for some other purpose - there are 4 bits available, allowing, say, a value of 0 to 15 to be stored.
There's a tricky way to improve this. Think in base 12, not in binary. We only need ONE base 12 digit to represent a number up to 12. Given any byte of data, knowing that the low bits hold a base 12 digit... all we need is the remainder when the whole byte is divided by 12 (assume the entire number is base12, for now). Its pretty simple - switch to base 10 for a second. If you want the low digit of any base 10 number, you take the remainder when divided by 10. That is, n MOD base.
So, we have now extracted the number from 0 to 11 and have a byte left which doesn't have those bits (and fractional bits) used to store that number (remember, we divided by 12). This number that's left could ALSO have been encoded to hold other fractional-bit ranges, also in ANY other base. The method is exactly the same to extract these bits, using the appropriate divisor.
Think about it. A byte can hold 256 values. By encoding a base 12 number in it, we still have (256/12 = 21) other values that we can uniquely represent. This way we could have encoded in the single byte a value from 0 to 11 and another from 0 to 20.
To do that with "whole" bits, we'd need 4 bits for the 0 to 11 and 5 for the 0 to 20... a total of 9 bits (and in the process "wasting" values from 12 to 15 and from 21 to 31 respectively). So, in this example, we saved a single bit. Thus, my claim that this method effectively encodes values using fractional bits.
As I said, this is one of my favourites from long ago.
Enjoy! A
-- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html
======SATURDAY, 16 MAY ======Andrew Davie: Optimisation Tips on Sneaky Fractional Bit Representation.
SUBJECT: [stella] Demo... POSTER: Chrissalo <Chrissalo@xxxxxxx> DATE/TIME: Fri, 22 May 1998 16:29:29 EDT POST: Hi!
A first demo of a ???game???!
Naah, not yet.
I have not a kernel yet, I'm just fooling around with stuff!
Chris section 1/1 file escape.zip [ Wincode 2.7.3 ] begin 644 escape.zip M4$L#!!0````(`+.RMB3T*G#T2`(````0```*````15-#05!%+D))3NV406C3 M8!2`_P9MDHXV.7@0,M=8MB&EC")3RJB[>/'0FQ#!VQ0\M.O_0BQ= MP8."GDK10@8#+QXB3'J0B3E%\+!C3V/T])?"1ITS_DE7:=-6(UXRR)>?G_=> M7M[['^_]>;Q7MUYKZ`4RS&/Y,I&O$?DVD>\0^1N1GW=R`M$0%#:+C'8/2AH/ MF*J0KR.-@?Z#[%U+;;YDZ)N4; -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html ======FRIDAY, 22 MAY ======Chrissalo: A First Demo of a Game. SUBJECT: [stella] a quickie POSTER: "Andrew Davie" <adavie@xxxxxxxxxxxxxxxxx> DATE/TIME: Fri, 29 May 1998 23:54:42 +1000 POST: Further optimization tricks - this time, a pretty simple one. Often, if you modularise things into subroutines (generally a good idea, right!!) you have code that might look like this... ; blah blah blah jsr subroutine rts You can replace the above with a simple... jmp subroutine Let the subroutine itself do the returning for us. You save one byte (whoooooo!) but also you gain 8 cycles - 6 as you're not doing the redundant rts, and 2 because you're jumping instead of jsring. The general principle: wherever you see a jsr followed immediately by a rts, you can replace the pair with a jmp, AND AN EXPLANATORY COMMENT OF WHAT THE HELL YOU'VE DONE!!!! Enjoy. A -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html ======FRIDAY, 29 MAY ======Andrew Davie: Optimisation Tips on Subroutine Jumps. SUBJECT: [stella] Collisions POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Fri, 29 May 1998 15:48:37 GMT POST: Anyone have an easy way to process collisions between two objects, each of which could have any multiple-copy NUSIZ value and any X-coordinate? Like, visualize a three-on-three in Combat, but I want to be able to calculate collisions between each bullet and each plane separately - like the rightmost bullet might hit the leftmost target plane, meaning the NUSIZ for the bullets changes from three-close to two-close, and the NUSIZ for the planes changes from three-close to two-close also, but we move the object's X-coordinate sixteen pixels to the right (because the middle object became the leftmost object.) We can assume the bullets (missiles) are one pixel wide each, and the players eight pixels wide (no double or quad width NUSIZes, and we can calculate collisions - we don't care about pixel-perfect collision detection via the collision registers.) I think I'm just going to slap a huge table in ROM for each 8-pixel step between the objects' X-coordinates, and each NUSIZ value for the source object, containing the X-coordinate change and the new NUSIZ value for each player (this can be done in one byte per player - put the NUSIZ in the lower nibble and the X-change in the upper nibble). That'd be 6 possible NUSIZes for each object, and (320 / 8 = 40) possible X-differences (cause the difference can be from -160 to 160 pixels), times 2 bytes per entry in the table, for a table size of 2880 bytes. If I limit the table so I don't check it if the X-difference is more than 64 pixels either way, that reduces the table to 6 * 6 * 18 * 2 bytes = 1296 bytes. Anyone have a better way to do this? Either by reducing the table size, or having a way to calculate the collisions? (speed is essential, code size is not) -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html Erik Mooney: Request for Help on Processing Special Cases of Collisions. SUBJECT: Re: [stella] a quickie POSTER: Nick S Bensema <nickb@xxxxxxxxxxxx> DATE/TIME: Mon, 1 Jun 1998 14:59:49 -0700 (MST) POST: > Here's another, very simple too... never JMP unless you can't really avoid > it. If you know that some status bit is always 0 or 1 at that point, use a > branch instruction instead, to save a byte and some cycles. And what if > the brach is out of range? Easy: spend a couple of hours re-arranging your > time-sensitive code to make that BNE possible. It happened to me, and might > happen to you too... :) I'd extend that rule to JSR's, if it gets tight enough. > BitmapShape: > .byte $AA > .byte $23 > ZgyzLookupTable: > .byte $00 > .byte $00 > .byte $01 ; <- end of BitmapShape > .byte $01 > .byte $02 Formatting idea... this might clear things up. > BitmapShape: ;BitmapShape: > .byte $AA > .byte $23 > ZgyzLookupTable: ; .byte $00 ;data duplicated in > .byte $00 ; .byte $00 ;ZpyzLookupTable. > .byte $00 ; .byte $01 > .byte $01 > .byte $01 > .byte $02 > Lots of graphics data can be "compacted" in this way. Also, I ended > changing the design of some graphics so that I could compact them better, > and save some more bytes... wicked! I did this to "Dark Mage" but Greg never implemented it. I shaved TONS of space off the fonts by using the Atari 800 font, which has a lot of room for this kind of sharing. Never got to test it because my version of DASM won't compile his code. I think I got the whole alphabet down to like 126 bytes, using six-byte-high characters. Original prototypes used a seven-byte-high font, and I could have compacted that too, by borrowing from the Commodore 64 font. -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html ======JUNE 1998 ======MONDAY, 1 JUNE ======Nick Bensema: Optimisation Tips for Compacting Graphics Data. SUBJECT: Re: [stella] optimization : sneaky fractional bit representation POSTER: "Andrew Davie" <adavie@xxxxxxxxxxxxxxxxx> DATE/TIME: Thu, 4 Jun 1998 00:50:01 +1000 POST: A while ago I wrote on encoding using sub-bit resolution. It just occurred to me WHY I needed to do this on the NES - it was involved with creating a password for a large game, so that the player could come back and rejoin where he/she left off. There were quite a large number of parameters that needed to be saved/restored, but it all had to fit into 6 LETTERS and a few punctuation marks (eg: EP-NZE). That gave very few bits (30, to be exact), and sub-bit encoding was therefore a great idea. By the way, I remembered coz I need to do it for my 2600 project :) Cheers A -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html ======THURSDAY, 4 JUNE ======Andrew Davie: Why You Would Encode Using Sub-Bit Resolution. SUBJECT: [stella] Jim Nitchals POSTER: Ruffin Bailey <rufbo@xxxxxxxxxxx> DATE/TIME: Tue, 9 Jun 98 23:11:14 -0500 POST: Just wanted to post what I found at http://dadgum.com/glist/updates.html on Jim in case anyone was interested. Thanks to Bill Heineman for pointing this page out to me. I was both impressed and a more than a bit honored that the list includes such "big names" among its ranks. >In terribly sad and unexpected news, 6502 guru James Nitchals died this >past Friday. In the glory days of the Apple II Jim > co-founded Cavalier Computer with Barry Printz and Richard Moore; wrote >Bug Attack, Asteroid Field, Star Thief, and > Ring Raiders; and co-authored Teleport and Microwave. This last title was >the first Apple II game to feature in-game music, > something considered impossible at the time. Later he worked for >Electronic Arts and had a substantial hand in games his name > isn't usually associated with, including Hard Hat Mack and Music >Construction Set. I've talked to a number of people who > worked with and learned from Jim over the years, and they consistently >regarded him as brilliant. > > In recent years, Jim was the technical lead for the Cyperpunks' >Supercharger CD, a deluxe compilation of games and > development tools for the Starpath Supercharger (a hardware add-on for >the Atari 2600). He spent considerable time, right up > through this past April, helping teach 6502 and 2600 programming to a new >generation of programmers. People would bring > him code snippets, asking if any improvements were possible, and Jim >would whittle and optimize them in astounding ways; he > was credited for doing just this for Oystron, a new hobbyist 2600 game >released earlier this year. > > In the last few months Jim unexpectedly gained wide exposure as the >"leader" of the anti-spam movement. A recent interview > with him on the subject is available. > > In the words of Doug Ansell, who learned the ins and outs of Apple II >programming from Jim when they worked together at > Cavalier, "The industry has truly lost a legend. Time and time again he >made the impossible possible." Jim Nitchals' web page > is still online, and is well worth a heartfelt visit. His site's URL is as follows: http://pw2.netcom.com/~nitchal s/about.html Ruffin Bailey | Program for the Atari 2600 on your Mac! rufbo at cetlink.net | http://members.aol.com/~mactari -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html ======TUESDAY, 9 JUNE ======Jim Nitchals Obituary. SUBJECT: [stella] New Sinking Ship version POSTER: <kurt.woloch@xxxxxxxxx> DATE/TIME: Wed, 17 Jun 1998 09:50:19 +0200 POST: Hello again, Folks! This is a new version of my "Jim's heart will go on" demo. As I promised, it's got sound now, and also the additional scanline needed to get color on PAL. Also, I've exchanged the shadow color by the $90 you suggested. Other than that, nothing has changed, but I'll work on further changes, as Piero suggested. Ah yes, the tune I play in here was adapted using Eckhard Stolberg's sound frequency and note table. Only to mention that too and give credit to whom it is due. With love (and still many things to improve yet) Kurt Woloch ======WEDNESDAY, 17 JUNE ======Kurt Woloch: New Version of Sinking Ship Demo. SUBJECT: [stella] Cybermorph 2600?!? POSTER: Songbird <forhan@xxxxxxxxxxxxxxxxxx> DATE/TIME: Wed, 17 Jun 1998 08:31:42 -0500 (CDT) POST: Check out this rather funky picture someone forwarded to me... guess the latest vaporware game to emerge for the 2600 is a Cybermorph port. ;-) ______/ / | Carl Forhan <>< | For Atari, Breeders, HeroQuest, and more: | forhan@xxxxxxxxxxxx | http://www.millcomm.com/~forha n/games.html \______\ begin 600 cm2600.gif M1TE&.#EA0`'(`/<``````!@I6AASQB$A(2%K,3&<`#F4(3F<2D)"0DJ -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/li sts/stella/stella.html Songbird: Picture of the Vaporware Game Cybermorph 2600. SUBJECT: [stella] BMI & BPL questions POSTER: Ruffin Bailey <rufbo@xxxxxxxxxxx> DATE/TIME: Mon, 29 Jun 98 17:58:09 -0500 POST: In COMPUTE!'s book _Machine Language For Beginners_, Richard Mansfield warns against ever using BMI and BPL. To justify this ban, Mr. Mansfield writes, "The reasons for this are exotic. We don't need to go into them. Just be warned that BPL and BMI, which sound so logical and useful, are not. They can fail you and neither one lives up to its name." (page 75 in my edition) I wss wondering because I couldn't get this code to work. Originally the asl, bcs was a bmi that I commented out below. Naturally neither of these two options worked, so I'm still confused. > lda CXP0FB ; this byte holds the collision registers for Player > ; Zero and the playfield (D7) and P0 and the ball (D6) > > asl > bcs joycheck ; if D7=1 there is a collision and gravity should be > ; negated. (The guy's standing on the floor) > ;bmi joycheck > > > inc ypos ; gravity moves the player down one scan line. > ; "Note to self": make sure no down inputs are allowed > ; while sprite falls in final. >joycheck [etc etc] This snippet happens between frames during the "game calc" portion of the code. Another question I have is this: For my last post (the joymove.bin), did moving the joystick up move the sprite down and vice versa? I'm using MacStella 0.7, and though I inc the variable ypos to make the sprite go down (as if pulled by gravity), I currently dec the ypos twice when the joystick is moved down (ie, D4 = 1). On MacStella, latching D4 (moving the joystick down) makes the sprite go downwards three scan lines a frame which is what I want, but currently the logic making this happen is somewhat paradoxical. Perhaps the bmi command again? Note: There is a check of scan line versus ypos in the screen drawing kernal that resets the player when they are equal (so dec makes the scan with the sprite closer to the top of the screen and inc a higher number scan line/ lower in the screen). Is this some episode of the X-Files that I missed, or is Mansfield just worried that these two instructions are too complicated for the beginner to use? Or something far more sinister... ;) And what's with the crazy reversed joystick movement? Tune in next time... Thanks, Ruffin Bailey | Write Atari 2600 games on your Mac! rufbo at cetlink.net | http://members.aol.com/~mactari ======MONDAY, 29 JUNE ======Ruffin Bailey: Questions about BMI and BPL. Maybe Read Whole Thread. SUBJECT: [stella] Beat 'em up 05 POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Fri, 31 Jul 1998 15:50:01 +0200 POST: Some time ago we were discussing the possibility of turning the big sprites demo into a Mortal Kombat clone. I have worked a little bit on the demo and got a basic display kernal done. This version shows a possible screen layout and some simple animations. I have to admit, that the demo looks more like International Karate than like Mortal Kombat, though. The biggest problem is, that I need more ROM space now. Does anyone have a working board design with at least 32 kb of bankswitched ROM? Also I might need some help with the animations. It took me several days even to get the two frames in the demo done, and I still don't really like them. If someone thinks he can draw better animations than this and would like to help me with the game, please contact me. As for the controls, I think I will go with the eight joystick directions with and without the fire button. So if anyone wants to suggest a combination of 16 moves, please do so. Any other comment about this demo is of course welcome too. Thanks, Eckhard Stolberg ======JULY 1998 ======FRIDAY, 31 JULY ======Eckhard Stolberg: Mortal Kombat 2600 Version 1 (?). SUBJECT: [stella] Look Mom, no flicker! POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Thu, 13 Aug 1998 21:05:58 +0200 POST: Here it is.. 4 non flickering, single scanline resolution sprites, with no vertical restrictions. The biggest drawback is that the two fake-sprites can't be positioned too near to the borders (there must be about 30 pixels). Also, this technique is very memory-hungry, and for this reason it is not suitable for sprites which have a long vertical range. Moreover, there's almost no time left in the kernel for color changes or to enable-disable the ball. However.. this could be a good starting point for a platform-based game. This kernel could be reused more times to draw a stack of platforms, and between the platforms one could reposition the sprites and change the playfield. Hmmm.. Let me know! ======AUGUST 1998 ======THURSDAY, 13 AUGUST ======Piero Cavina: Four Non-Flickering Single-Scanline Resolution Sprites. SUBJECT: [stella] Barber's pole POSTER: Piero Cavina <p.cavina@xxxxxxxxxxxxx> DATE/TIME: Tue, 25 Aug 1998 15:56:05 +0200 POST: And now for something completely different.. the old "barber's pole" trick.. it's such a "2600-friendly" thing that I couldn't resist :-) Press and hold the fire button to see how it works. Warning: tested only on PCAE. Might not work on a real 2600. ======TUESDAY, 25 AUGUST ======Piero Cavina: Barber's Pole Demo. SUBJECT: [stella] Eighteen Sprites? POSTER: "John Saeger" <john@xxxxxxxxxxx> DATE/TIME: Thu, 27 Aug 1998 00:30:55 -0700 POST: I was playing around with Eckhard Stolberg's trick.asm and I stumbled onto this... John ======THURSDAY, 27 AUGUST ======John Saeger: 18 Sprite Modification of Eckhard Stolberg's Trick.ASM. SUBJECT: [stella] 18 extra lives POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Mon, 31 Aug 1998 20:45:05 +0200 POST: I couldn't resist and have turned the 18 sprites demo into an 18 extra lives demo. On a real VCS this demo displays 18 sprites, which can be turned on and off with the joystick. The sprites are hidden by putting the playfield and the ball over them. The downside of this method is, that the sprites can only be 5 pixels wide. The advantage is, that each sprite could be turned on and off individualy. Also the routine allows the sprites to be animated. Both emulators have their difficulties with this demo. PCAE does the spacing wrong, so that the hiding doesn't work correctly. Stella07 does the spacing right, but displays 20 sprites instead of 18 and swallows the first line of graphics. Also my real VCS seems to do a humming noise, that gets louder the more sprites are displayed. The emulators don't do that. :-) Ciao, Eckhard Stolberg ======MONDAY, 31 AUGUST ======Eckhard Stolberg: Use of the 18 Sprite Mod to Display 18 Extra Lives. SUBJECT: [stella] It's done! It's done! It's finally done! POSTER: CRACKERS <crackers@xxxxxxxx> DATE/TIME: Fri, 11 Sep 1998 07:44:32 -0400 (EDT) POST: Wow I can't believe I had this many days in a row with an hour or so of free time to work on finishing the clock. Wouldn't it be great to be a programmer back in the 2600's golden years? Imagine being paid to do this and having at least 8 hours a day, 5 days a week to work on programs straight. No having to shelve it until you find time then forgetting just what the heck it was you were doing. Imagin the games some of us could put out with that kind of time!!! Anyways, here;s the finished clock. It's pretty accurate although it may drop or gain a little each month. But I don't figure too many people will be leaving their 2600s idle that long anyways. CRACKERS (On to the next project from hell!!) ======SEPTEMBER 1998 ======FRIDAY, 11 SEPTEMBER ======Crackers: Finished Clock Cart? SUBJECT: Re: [stella] This may not be fixable... or is it? POSTER: Glenn Saunders <krishna@xxxxxxxxxxxxxxx> DATE/TIME: Mon, 05 Oct 1998 07:55:05 -0700 POST: At 09:36 PM 9/28/98 -0500, you wrote: >>That ugly black bar is an artifact built into the 2600's hardware. Look at >>Berzerk and Missile Command for realy obvious examples of it. You can't do >>anything except don't use the left 8 pixels of the screen. > > >Do you have any idea how they cleared the problem in games like Combat? Combat only does one HMOVE per sprite at the top of the screen. The original Stella hardware designers did not anticipate the need to reposition sprites more than once per TV frame. These lines only appear when you reposition the same sprite during the visible scanlines, which was a tactic first used before the 2600 was even released (but after the hardware spec was finalized) in Air-Sea Battle. A popular feature, no doubt, because it can give the 2600 the illusion of having many many times the number of sprites that it actually has. Most 2600 fans don't mind the lines. I know I don't. It's part of what gives the TIA display its uniqueness. There are ways to cover it up, but all of them involve either wasting a sprite object (like the ball) and/or constricting your usable horizontal resolution. I don't really see the need for doing that. ======Glenn Saunders --3D Graphics / Videography / Web development-- == == krishna@xxxxxxxxxxxxxxx http://www.geocities.com/Hollywoo d/1698 == == Stella@20 video page http://www.primenet.com/~krishna == == President - Lightwave Toaster Flyer group of LA == == http://home.pacbell.net/al chemy1/html/ltf.html ====== -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======OCTOBER 1998 ======MONDAY, 5 OCTOBER ======Glenn Saunders: The Black Bars on the Side of the Screen. SUBJECT: [stella] Grid demo POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Tue, 27 Oct 1998 15:13:22 +0100 POST: This little demo shows a high resolution grid. You can move the grid left or right with the joystick. The movement will be pixel by pixel. The effect is a variation of the multi sprite trick, therefore you should watch it on a real VCS, since the emulators can't display it correctly. I hope, that someone finds out how the multi sprite thing works, so that Bradford can update his emulator. I don't think the effect is usefull for anything more than displaying a linefilling pattern. I might use it for displaying some big powerbars in the fighting game, if I can find a way to add two markers, though. Ciao, Eckhard Stolberg ======TUESDAY, 27 OCTOBER ======Eckhard Stolberg: Grid Demo. SUBJECT: [stella] Beat em up 08 POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Tue, 10 Nov 1998 14:41:27 +0100 POST: I think it is time to show you the newest version of the beat em up game. This one uses Supercharger bankswitching and displays the powerbars with the multi sprite trick. Therefore you might want to try it out on a real VCS. I hope the powerbars display correctly on all VCSs. (Erik, does it work on your system?) I have also changed the graphics completely. I hope you like this one better than the old version too. You can now step forward and backward, turn around and punch high straight and low in the direction you are facing. I haven't come up with a good way of collision detection yet, so hitting the other player won't have any effect on him. I also added support for y-coordinates, but don't use it in this version. If you have any comments or suggestions, I would like to hear them. Ciao, Eckhard Stolberg P.S. Can anyone here change DASM to output file format 2 without the headers? ======NOVEMBER 1998 ======TUESDAY, 10 NOVEMBER ======Eckhard Stolberg: New Version of Mortal Kombat 2600. SUBJECT: [stella] Stella sequencing POSTER: John Harvey <jkharvey@xxxxxxxxxxxxxxxxx> DATE/TIME: Sun, 03 Jan 1999 23:51:36 -0600 POST: Note: I could be wrong about some of this. If so, please correct me. An interesting thought entered my mind when writing some code yesterday. Basically, I was writing a subroutine within a subroutine (JSR's) and it compiled and actually ran on the PCAE emulator. I was under the impression that in the event of a subroutine, the return address of the subroutine is saved in the program counter (I could be wrong, I read this a while ago), until the event of an RTS. Is this just a fluke? There is no system stack that I know of, unless, $FF thu $80 are automatically called, and the stack pointer incremented, but I do not think this is so. If it is possible to have a nested loop, what is the limit? I see that branching inside of a subroutine is not a problem, but if there were enough nested JSR's and RTS's on the'r own, would the program get confused and ignore the command, or keep going, somehow finding the corresponding JSR? Also, (if anyone knows), does an emulator "fix" programming mistakes? Are there things that I could program on an emulator that would not work on a real VCS? I already know of a few bugs with joystick input that can occur. Any big ones out there? Sorry if I have asked a lot of questions, but it is hard to find the answers by using conventional means. I hope to help other rookies on the list in the future, but as of now, it seems that I am one of the "young 'uns" on the list, as my knowledge is not yet so immense. Thank you to all for putting up with me. -John K. Harvey -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======JANUARY 1999 ======SATURDAY, 2 JANUARY ======SUNDAY, 3 JANUARY ======John Harvey: How JSRs Work Using the Atari 2600 Memory. SUBJECT: [stella] Pressure Guage Game. Is this fun? POSTER: John Harvey <jkharvey@xxxxxxxxxxxxxxxxx> DATE/TIME: Sun, 10 Jan 1999 14:06:09 -0600 POST: *Select crashes the title screen as it is not implemented yet* I got a prototype finished! It's no longer an Equalizer program, but a game. This is a simple demo version. The first guage increases. When it is in the range (the bar on the far left), press the joystick button. The second guage will either increase or decrease depending on if you pressed the button inside or outside of the range. The third moving guage is the timer guage. When it's empty, you lose. In this demo, four speeds are presented. In the future, I plan to have the range decrease, and have the colors change, and also add a level graphic made of player graphics. I also need to put in a top bar for Guage 2 so one can see how much filling is left to go, and re-create a title screen. My questions are: What do you think? Is this any fun? Any comments would be helpful. Thank you. -John K. Harvey ======SUNDAY, 10 JANUARY ======John Harvey: Pressure Guage Game. SUBJECT: Re: [stella] nop and wrap around POSTER: Erik Mooney <emooney@xxxxxxxxxxxxxxxx> DATE/TIME: Tue, 12 Jan 1999 20:27:32 -0500 (EST) POST: > have an LCD screen that allows the user to select a game from it's large > ROM(and simultaniously display instructions while playing), load one from > a pc via serial, load one from actual cart(and send to pc), setup > bankswitching, and any other number of things that I can dream up along > the way. Cool... where do I buy one? :) > My original thoughts to run it would be that my system would be able to > switch on and off the power to the VCS so that once a game was choosen, it > would power cycle the VCS to play the new game. But while working I came > across an idea. What if my system just swaped the rom while that last > game was running? What I was thinking is swapping it to a rom that is all > nop's, and allowing the VCS to run those nops until it got to a certain > address(startup vector?) which would cause some of my hardware to switch > to the new game. Or perhaps to a dummy program which would just display > some text, or maybe a screen saver of some sort until the user selects the > next game. It's kinda like a bankswitch without having a software call to > do it. > > Will this work? Is there a common startup address(as in, is there a > location in memory where the 6507 fetches the very first instruction upon > startup?)? What is it? Will the program counter in the 6507 wrap around > from the max to the minimum address? There is not a common startup address, but there is a startup vector at $FFFC - on powerup, the 6507's PC is set to the word stored at locations $FFFC and $FFFD. > Anybody have any ideas of how else to be able to get from a game running > to another one when you have no control over how either program was > written or where in it's execution it is? Try experimenting with swapping in a ROM full of BRK instructions. I *think* the BRK instruction acts as a soft reset, resetting the PC to the startup vector. As for wrapping around the PC... that's very unlikely to work. Within the 2600's address space, $1000-$1fff is ROM space, then the very next byte at $2000 wraps back around to $0, which is TIA input/output registers - trying to execute code out of those registers is unpredictable, to say the least. :) -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======TUESDAY, 12 JANUARY ======Erik Mooney: These are the 6507 CPU's Startup Vectors. SUBJECT: [stella] Droid source & binary POSTER: "David Schweinsberg" <david@xxxxxxxxxxxxxxxxx> DATE/TIME: Thu, 14 Jan 1999 11:00:59 -0000 POST: Hi Enclosed you will find the source code, plus the subsequent binary, for my Droid project (scrolling platform game). I haven't had a chance to do anything with it for the past year - all I've done before posting it is remove the Supercharger code. By retargeting the 4K format, I'm going to significantly modify it from its current state, but I thought some might be interested in seeing it thus far. All comments are welcome. David P.S. As ever, this remains untested on a real 2600, due to lack of RAM cart. ======THURSDAY, 14 JANUARY ======David Schweinsberg: Binary and Source Code for DROID. SUBJECT: RE: [stella] Final exam for Square One POSTER: "Andrew Davie" <adavie@xxxxxxxxxxxxxxxxx> DATE/TIME: Tue, 19 Jan 1999 00:37:59 +1100 POST: I expected more answers than the one from Dan! Here's my stab at marking... > The machine operates like this, right? The program counter starts off > at the first location in memory after the program is loaded into it. As Dan pointed out - the RESET VECTOR tells the machine where to start running a program. The reset vector is the two bytes at the top of ROM at location $FFFC/$FFFD. It MUST point to the start of the program. The first thing a program must do is initialise a few things to make sure everything is stable. Things like the stack pointer! > It views the first thing there and adjusts the Program Counter > depending on what it finds there--a JMP command makes it go up by > three (the command is one byte in memory location, the location is > two), a BRK makes it go up by one. You rarely NEED to know the size of instructions; the assembler does all this automatically. A JMP to a label (a location) effectively loads the address of that label into the program counter, and execution continues from the address the label specifies. Don't focus on the number of bytes per instruction, or what happens to the program counter before/after bytecode fetching. Concentrate on what the instructions DO. A JMP, for example, changes the value of the program counter - from where the next instruction is fetched. It's a GOTO :) And a JSR is a GOSUB :) Whatever the instruction, after it's done, the program counter will point to the next instruction to be executed. > command and puts it in the Program Counter. If it is a JSR, it takes > the number in the Program Counter, copies it to the Stack Pointer, and > places the bytes after the JSR command into the program counter. Pedantic mode on. Copies it to WHERE THE STACK POINTER POINTS TO. Not to the stack pointer itself :) Pedantic mode off. > the RTS. At RTS, it takes the top number from the Stack Pointer and > copies it to the Program Counter. The unit then moves everything in > the Stack Pointer up one (in the event of nested subroutines) and > continues on. Again, takes the top number from the stack (where the stack pointer points). What do you mean "moves everything in the stack pointer up one"? The stack pointer is a single byte value, having range 0 to FF hex. It is only the value of the pointer which is changed - the contents of the stack remain unchanged when a RTS operation is performed. So, although the return address is retrieved from the stack area (using the stack pointer as an index), the stack contents aren't actually changed - just the pointer to the "top" of the stack. Hope its clearer. A -- adavie@xxxxxxxxxxxxxxxxx <mailto:adavie@xxxxxxxxxxxxxxxxx> visit the Museum of Soviet Calculators at <http://www. comcen.com.au/~adavie/slide/calculator/soviet.html> http://www. comcen.com.au/~adavie/slide/calculator/soviet.html -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======TUESDAY, 19 JANUARY ======Andrew Davie: Details About How the 6507 CPU Program Counter Works. SUBJECT: [stella] Idea for Scrolling Maze Engine. POSTER: Schwerin <schwerin@xxxxxxxx> DATE/TIME: Sun, 7 Feb 1999 01:08:37 -0500 POST: Wow! It's so great to see the 6502(7) discussed! It feels like my small isolated programmer bubble has expanded into a medium size isolated programmer bubble...but enough small talk. Being an eager new convert to the land of 2600 programming and the TIA, I've ingested a few of the major documents and decided to write a small kernal to see if I have any clue how any of this works. Before I go on... DISCLAIMERS: 1) This is not a finished, nor even well developed idea, but more of a "test of concept". Let me know if I am sniffing up the wrong tree in my approach, because I know it needs optimizing. 2) I know the STA WSYNC's are missing 3) I know I write the PF registers at the wrong times. Now that you're expecting the worst :) ... It's assembly code that trys to draw a moving playfield. Here's my idea. The spaceship is always locked to the center of the screen, but it can face any of the four orthagonal directions. (I don't deal with drawing the ship yet) Scrolling can happen in any one of the same four directions, N S E W Assume an assymetrical playfield, which will mean 40 blocks of horizontal resolution (4 color clocks each). The vertical resolution is irrelevant at this point, but assume doubling of scan lines for extra compute time, and assume that at the end of the day the maze looks squarish and not rectangular. Our basic maze unit is an eight by eight outline box, in units of playfield blocks. fig 1. ******** * * * * * * * * * * * * ******** We have maze data in memory that tells us which sides of the box to draw and which not to draw. If you tile "boxes" vertically and horizontally you get a flexible (and common) maze engine of arbitrary dimensions. Each box is free to have some sides drawn and others missing. You can draw about 5 boxes across a line, actually 6 if scrolling makes some partial. Now simplify all of this to the problem of drawing the bottom/top of the boxes. It will look something like this: fig 2. ******** ******** ******** assuming a simple case... Now lets say you have a 6 bit variable "maze" which tells you when to draw and when not to draw....let's call each flag A,B,C,D,E, and F and they are yes/no flags on whether to draw. Let's say that A is our "partial" line to the left, which may or may not even appear on screen, followed by B, and then C, D, E, and F (F must appear partially or in whole) So our flags correlate to the screen like this... fig 3. (shifted 2 blocks right for example) PF0 PF1 PF2 ~PF0 ~PF1 ~PF2 | || || || || || | AABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFF Note that there are 2 As and 6 Fs so each is partial. Store the flags in your "maze" variable like this: bit 5 4 3 2 1 0 F E D C B A The other value we need is a shift value, which ranges from 0 to 7 blocks of right displacement. ("0" means B flag is leftmost) store it like this: bit 4 3 2 1 0 S2 S1 S0 - - Now we have defined the problem (somewhat). Given "maze" ... a set of flags on hline drawing Given "shift" ... a horizontal offset from normal drawing Create, in a timely fashion, 40 bits of picture data, as stored in PF0, PF1, and PF2, the picture field registers and you need to swap the data at the middle of the screen for the right screen side. (set to copy, and not reflect mode). Mission Impossible? I think it's a fun little problem... Here's my attack... Create a lookup table that eliminates bit shifting the picture data. Here's how it works....for any PF register or its right side equivalent, use the "shift" and two of the maze flags as an index. Load the byte from the table and store it to the register...some registers need to load two bytes from the table and ORA them together for reasons that are easier to draw than explain. All this depends on the "coincidence" that the boxes are 8 bits wide...this means that most registers are only affected by two drawing flags, some by three, but we always know exactly which are affected by what. PF0 (first 4 blocks) affected by flags A and B PF1 (next 8) flags A B and C PF2 (next 8) flags B C and D altPF0 C and D altPF1 D and E altPF2 E and F This can be cleaned up if you find a scheme so that no register is affected by more than two flags. (Or also, you could create a lookup table that uses three drawing flags in it's index.) The index is computed like this, combining "shift" with 2 draw flags index bits 4 3 2 1 0 S2 S1 S0 B A <--- the "BA_index" S2 S1 S0 D C <--- the "DC_index" S2 S1 S0 F E <--- the "FE_index" this is the same as BAindex = shift OR (maze & 3) So each table index comes out 0 to 31 There are 9 tables. PF0BA table gives you the PF0 register for the shift and A B flags index. PF1BA gives you the PF1 as influenced by flags B and A PF1DC gives you the PF1 as influenced by the C flag (D line never drawn here) PF2BA gives PF2 (B influenced) PF2DC gives PF2 (D and C influenced) altPF0DC gives right hand PF0 altPF1DC altPF1FE altPF2FE I know it would be easier to understand if you had the tables to look at (twist my arm, they take long enough to draw on paper :) So for each scanline (or two scanlines rather) we need to Access the maze flags Generate the table indexes Load the table data. Overlay some table data with OR statements Store the data to the PF registers at the right times. (do other graphics and misc overhead) If you assume 76 cpu clocks per scanline, we need the 152 you get from line doubling. Here goes..I'll count the cycles for you... (assume no page-crossing indexes) (remember the DISCLAIMERS) top: lda maze (3) [3] get our maze flags from somewhere zero page and #3 (2) [5] mask for the low two bits A and B ora shift (3) [8] mix in with the shift value to create BA_index tay (2) [10] save index in Y register lda PF0BA,Y (4) [14] read table sta PF0 (3) [17] note: i don't time these register writes correctly. we can get around this by buffering the 6 bytes. lda PF1BA,Y (4) [21] different table, same index sta tempPF1 (3) [24] workspace so i can combine table values lda PF2BA,Y (4) [28] read table sta tempPF2 (3) [31] workspace lda maze (3) [34] we need flags C and D now lsr (2) [36] shift right for divide by 2 lsr (2) [38] and #3 (2) [40] mask for C and D ora shift (3) [43] make DC_index tay (2) [45] lda PF1DC,Y (4) [49] read table ora tempPF1 (3) [52] mix with previous data to make picture value sta PF1 (3) [55] lda PF2DC,Y (4) [59] read table ora tempPF2 (3) [62] mix sta PF2 (3) [65] -----compute right side------lda altPF0DC,Y (4) [69] read table sta altPF0 (3) [72] don't copy until correct time, or something like that lda altPF1DC,Y (4) [76] read table ^^^^^^^^^this is aproximately where we reach scanline #2??^^^^^^ sta altPF1 (3) [79] lda maze (3) [82] lsr (2) [84] lsr (2) [86] lsr (2) [88] lsr (2) [90] get E and F flags ora shift (3) [93] tay (2) [95] lda altPF1FE,Y (4) [99] ora altPF1 (3) [102] sta altPF1 (3) [105] buffer for later? lda altPF2FE,Y (4) [109] sta altPF2 (3) [112] lda altPF0 (3) [115] sta PF0 (3) [118] lda altPF1 (3) [121] sta PF1 (3) [124] lda altPF2 (3) [127] sta PF2 (3) [130] ...... etc...... that's under 152 cycles and without much tinkering yet. Congratulations if you got this far, I know I'm getting a bit blurry eyed after pondering this problem for a lot of the day. My current idea is to go for 6 bit table indexes rather than 5 bit, so there are 64 table entries, and 8 tables, to reduce the number of ORA's that happen. Also, you simplify computing the index to eliminate LSR's: given a precomputed-once-per-frame shift and shift_ shift is bit 5 4 3 2 1 0 S2 S1 S0 - - - shift_ is bit 5 4 3 2 1 0 - - - S2 S1 S0 ABC_index is bit 5 4 3 2 1 0 which is shift OR (maze & 7) S2 S1 S0 C B A DEF_index is bit 5 4 3 2 1 0 which is shift_ OR (maze & 56) F E D S2 S1 S0 The tables are: PF0ABC, PF1ABC, PF2ABC, PF2DEF, <--- ORA number1 altPF0ABC, altPF0DEF, <--- ORA number2 altPF1DEF, altPF2DEF the 8 tables come to .5K which may be a limiting factor for 2K or 4K formats if that is a goal. I think that's enough for now. -Andrew Schwerin schwerin@xxxxxxxx Tune in next time for Part II: Drawing the Vertical Walls.... -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======FEBRUARY 1999 ======SUNDAY, 7 FEBRUARY ======Schwerin: Rough Notes on Scrolling Maze Engine. SUBJECT: [stella] Poll: Developer Wishlist POSTER: Schwerin <schwerin@xxxxxxxx> DATE/TIME: Wed, 10 Feb 1999 00:04:42 -0500 POST: Hi. I've been reading the stella back issues, and it seems to me it would be a good idea to have a common developer wishlist. In reading the letters, there is often a common pattern. Someone will present a problem, someone will reply, and maybe a few people will chime in. If there is a lingering problem, someone says "Wouldn't it be great if someone wrote code to do so and so..." and after a month, electronic dust begins to settle on the suggestion. Suggestions also abound in the area of documentation. "Wouldn't it be nice if someone wrote up such and such...". I think my interest in all this is that I like to write tools. I think every programmer has some inclination to do that, especially if they see a need for better development tools. The trap (or bliss depending on your outlook) is to just go on creating tools all the time and never get back to using them. Without commiting myself to anything (hehe), how popular/useful would a java based tool be for you? Here is my outlook on the tools and documentation. A "tool" is an application, whether it runs on the 2600, or some other platform, that helps you develop. Documentation is any textual item that helps you learn, such as a tutorial, a reference, or a code example or disassembly. Awe, what the heck...lets have a wishlist for Games/Demos you wish were developed. My Picks: Tool: All-around graphic design--->hex--->binary editor (more than a text editor, less than a TIA emulator) Doc: Comprehensive 2600 tutorial, friendly pictures and analogies at the front,code segment examples in the middle, complete commented programs toward the end A "tricks" book with a game-by-game analysis of special techniques and the stories behind them that make the impossible possible. Game: i'll pass on this till I know what i want to code myself. ok, everybody go crazy and post your wishlist...I'll cut and paste when the dust settles. -Andrew Schwerin schwerin@xxxxxxxx -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======WEDNESDAY, 10 FEBRUARY ======Schwerin: Thread on Developer Wishlist. SUBJECT: [stella] One Bit Sound? POSTER: Schwerin <schwerin@xxxxxxxx> DATE/TIME: Wed, 10 Feb 1999 00:26:09 -0500 POST: Is there anyway to create hi-lo 1 bit squarewave audio ouput with CPU control over the duration of the hi and lo states? for example, to generate a squarewave: ______A| B|______C|... where A, B, and C are non-equal time intervals. If this were possible, then you could have a very crude digitized audio playback engine. Memory size, cpu usage, and cpu speed are the obvious limitations to this method, but these three factors alone don't rule out the possibility. My idea is that any 8 bit or 16 bit waveform that we commonly use on our computers can be reduced to zero crossings. The original waveform is translated into an interval format, consisting of a list of delay values before forcing a zero-cross. This is also good for generating multi tone music. I guess I'm hoping that I can use the volume registers as a zero cross control, and set the tone registers to something helpful... For example, to get access to a hi and lo signal, could I set the oscilators to run opposite each other, set it to a low frequency, have software "know" which osc is hi, and hope that the sine applitude going to zero doesn't kill the effect? I guess the problem is I don't want the oscillators to oscillate! If this is possible, the volume registers can be fully used to give more resolution to the output waveform. The other option would be to "model by clay" a custom audio ouput through various register stores to the audio registers (a linear piecewise synthesis). This, however, is mind bogglingly complex, and doesn't guarantee any specific level of fidelity to the original waveform. -Andrew Schwerin schwerin@xxxxxxxx -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ Schwerin: Thread on One Bit Sound. SUBJECT: [stella] Building yourself an A2600 POSTER: Tennessee Carmel-Veilleux <veilleux@xxxxxxxxx> DATE/TIME: Mon, 1 Mar 1999 08:52:03 -0500 (EST) POST: Hello, Since many of you think it would be difficult to build an Atari 2600, I have good news for you, IT'S NOT !!! The schematics, online are at: http://www.atarihq.com/danb/vcste ch.htm at the bottom of the page. Parts required: All custom chips (and crystals) can be found at BEST electronics: http://www.best- electronics-ca.com/custom_i.htm All others can be found at Jameco. http://www.jameco.com /\/\/\/\/\/\/\/\/\/ Now for a price sample: If we use a simple 6502, it's: Jameco Item #43191 "6502", 3.25$ (Stock > 1000) or a 6507 BEST electronics Item "STK6507 CPU", 5.00$ (Stock unknown) --- For the RIOT, we need Jameco Item #43297, "6532 128x8+timer+I/O", 3.25$ (Stock >1000) or BEST electronics Item "UM6532", 5.00$ (Stock unknown) BUT We can replace the RIOT by: Jameco Item #43254, "6522 VIA" (RIOT less the RAM) (Stock >1000) Plus Jameco Item #38738, "2016-12, 2k SRAM, 120ns", 1.49$ (Stock >1000) and a clever addressing trick. --- For the RF modulator: Jameco Item #141639, "12 VDC RF modulator", 3.95$ (stock > 1000) ------* All the Jameco components cost less if we buy >10 of them. * If we make our own VCS, it will be able to have: * Internal ROM (Like Combat included) * Composite Video Out * Other neat stuff people might think about BTW, I'll soon be making a batch (5-10) CART readers (2-4-8k, non bank-switched) with software and parallel port connection... E-mail-me if you think it's a good idea (if I don't get enough mail about this, I will only make 1 for me and 1 for a friend, so hurry :) They'll be in plastic casing. Regards, -- Tennessee Carmel-Veilleux (Coordonator of Digital Meltdown) veilleux@xxxxxxxxx (www.ameth.org/~veilleux) ICQ ID : 8604827 Support Linux ! (www.linux.org;www.gnu.org) 1.99$ CD->(www.cheapbytes.com) ||*|| This message was written in Canada / Ce message a ete ecrit au Canada -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======MARCH 1999 ======MONDAY, 1 MARCH ======Tennessee Carmel-Veilleux: Build Your Own 2600. SUBJECT: [stella] Color & drawing limitations questions POSTER: slapdash@xxxxxxxxxxxx (Russ Perry Jr) DATE/TIME: Fri, 19 Mar 1999 00:58:04 -0600 POST: This is a very general set of questions that I'm curious about... What are the exact color limitations of the 2600 as far as the player, missile and ball graphics? If I understand it correctly, each can only have one color per line, but can have any number of colors vertically? And can ALL of them have different colors, or are some dependent on others (like the ball is dependent on the background?)? Also, if you're copying a sprite, will all the copies have the same color per line, or is it possible to change the color before the next copy is drawn? And what is the exact resolution of the screen in low-res and high-res mode? Other questions I'll bet aren't as easy to answer... How many "sprites" can you put on the screen at once? I guess you can do maybe 13 per line, but can you do that every "line" (or sprite height)? Also, you can manipulate the background to look like there are extra sprites, right? What kind of limits are on this? If you want to summarize all this mess into one simple question, here it is: "what would you have to keep in mind if you wanted to make a fake screen shot that might theoretically be possible?". :-) //*======++ || Russ Perry Jr 2175 S Tonne Dr #105 Arlington Hts IL 60005 || || 847-952-9729 slapdash@xxxxxxxxxxxx VIDEOGAME COLLECTOR! || ++======*// -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======FRIDAY, 19 MARCH ======Russ Perry Jr: Thread on Colour and Drawing Limitations. SUBJECT: Re: [stella] music compression POSTER: Chris Wilkson <ecwilkso@xxxxxxx> DATE/TIME: Fri, 2 Apr 1999 18:30:01 -0500 (EST) POST: > Hi all, here's my lastest puzzle: I'm working on a four channel music > engine, and I'm trying to work out some of the internal memory management Andrew, Have you considered creating your own waveforms? This allows you to use any frequency you want. If you only update the sound registers once per line, you get 0 to 15.7kHz, or 8 (resonable) octaves. If you update every other scanline, you get a top end of 7.85kHz...still not bad. Also, let's assume that no voice ever jumps more than an octave. If you use relative motion, with chromatic scales, you need 3.5 bits of storage for each voice, and you give each voice a total range of 4 octaves (conservative 2-scanline approach). Also, since (I assume) you're doing 2 voices per channel, if you're just re-writing the volume data for each channel, you can store the information in terms of channels instead of voices. Doing this gives double the storage resolution, or 1.75 bits per voice, per beat. This all assumes infinite clock cycles with which to work. :) Right now, I'm way too tired to do the math and get the *real* numbers. But it might give you a different way of thinking about the problem. "So why didn't he try to give feedback before my engine was locked in place!???" - Andrew Ok, I have to go watch TV. But I'll think more on this and get back to you. -Chris -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======APRIL 1999 ======FRIDAY, 2 APRIL ======Chris Wilkson: Thread on Using Your Own Waveforms With 2600. SUBJECT: [stella] Solaris Source Code POSTER: Bob Colbert <retroware@xxxxxxxxxxxxx> DATE/TIME: Mon, 19 Apr 1999 10:09:10 -0500 POST: Hi, Just wanted everyone here to know that I have put the source code to Solaris up on my webpage. Thanks to Glenn for sending me a printout of the listing! I used Distella to disassemble each bank of the game, then I went to work applying all of the variable names and comments. The result is a very authentic listing that compiles with dasm v2.12 (not 2.02 - you get a memory error). I actually finished this quite a while ago, but haven't bothered to put it up on my webpage until last Friday. I hope it serves as a valuable tool for learning about the inner-workings of the 2600. Enjoy, Bob P.S. I am still planning on transcribing the other listings Glenn sent me, but time is a valuable resource right now! -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======MONDAY, 19 APRIL ======Bob Colbert: Source Code to Solaris. NO FILE. SUBJECT: [stella] some questions about the a2600 POSTER: gentlben@xxxxxxxxxxxx DATE/TIME: Tue, 25 May 1999 12:59:34 -0700 POST: hey everybody...i have been studying this atari 2600 programming stuff off and on for a few months and i am wondering a few things, being a newbie and all: 1. how are interrupts (BRK, IRQ, NMI) handled by the 2600? 2. what exactly is the point of having missile and ball objects and how are they used in already existing roms? 3. should the 3 VSYNC and 37 VBLANK lines be applied as soon as execution begins, or is it possible to have a blank 1st frame in which initialization and other housekeeping goes on? 4. what exactly are overscan lines and how are they done? 5. is it true that the 6507 can only address 13 bits of information (i read somewhere that it can, but then i read somewhere else that it could only read 12, maybe it was a typo) and can this be used to any effect at all? 6. has anyone ever written a home brewed game that had bank switching (is larger than 4K)? i know some of these arent really good questions or are obvious but like i said i am a newbie so i hope i havent made too much of a nuisance of myself :) dee -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======MAY 1999 ======TUESDAY, 25 MAY ======"Gentlben": Thread on Some Interesting Questions about the 2600. SUBJECT: Re: [stella] horizontal positioning POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Sun, 30 May 1999 14:21:47 +0200 POST: At 15:22 29.05.99 -0700, you wrote: >does this mean that i can position an object and perform a reset for the >player/ball/ >missile and it will show up on the line FOLLOWING the scan line where >the >reset was performed (at the interval where it was reset)? You have to position the object by hitting RESPxx and then you apply the fine movement in the HMxx register by accessing HMOVE at the beginning of the next scanline. When you store the value to the HMxx registers doesn't matter much, because HMOVE will shift all five objects at the same time according to the values in the five HMxx registers. The thing about objects not showing up in scanlines where RESxx for that object is accessed is a bit more complicated, but as long as you are still learning the basics, it is OK to assume, that the object will start displaying in the following scanline. >2. if the HMOVE command has to be performed following a WSYNC, how does >one place objects on the far left side of the screen and move them >relative with the >horizontal movement register if, to store a value in memory, takes 3 >cycles (9 pixels)? i would not need to actually write to the horizontal >movement registers >because i figure i can obtain the position and relative movement needed, >during the >housekeeping part of the program (which would be in non-picture >lines)... A scanline is 228 pixels wide, but only the last 160 pixels are visible. So you have 68 pixels / 3 = 22 processor cycles to prepare the values for positioning or to set up graphics for that scanline etc. BTW objects don't get positioned at the pixel that corresponds with the processor cycle when the access to RESxx happens. The missiles and the ball have a 4 pixel offset to the right, normal players have a 5 pixel offset and double/quadruple players seem to have a 6 pixel offset. >3. this one doesnt really have to do with the horizontal movement...but >if i write to the playfield registers during the actual scan line at >different times for each register and leave playfield reflect off, is it >possible to actually make a playfield thats longer >than 20 bits? Yes, that is possible. Many games that for example use the playfield to display a title screen use this technique. Ciao, Eckhard Stolberg -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======SUNDAY, 30 MAY ======Eckhard Stolberg: Answering Gentlben's Questions About Horizontal Positioning. SUBJECT: [stella] Role-Playing Game Development POSTER: "David Schweinsberg" <david@xxxxxxxxxxxxxxxxx> DATE/TIME: Sat, 19 Jun 1999 21:54:00 +0100 POST: Hello Here is the basic playfield for an RPG I'm working on. The layout is very much like Ultima IV, although the grid is 9x9 rather than 11x11, and the status info on the right will consist only of triple P0 graphics. Colour coding is used to indicate the type of terrain, and P1 graphics show spot detail (castles, towns, bridges, ships, pursuing creatures, etc.). Feedback would be appreciated, and any suggestions. Dungeons will be represented in a similar fashion. You can't move about in this demo, as the world-data is fixed. An encoding scheme is currently under development to allow a large world (hopefully 256x256) to be held within something like a 16K cart. (thanks Chris!), with lots of space left over. I have some ideas but suggestions are encouraged. David Schweinsberg P.S. This has been tested using StellaX and PCAE, but not real hardware. (encl. Our hero stands on the shore of a mighty sea, after emerging from the dark, enchanted forest.) ======JUNE 1999 ======SATURDAY, 19 JUNE ======David Schweinsberg: Basic Playfield for RPG. SUBJECT: Re: [stella] Cart shells POSTER: Chris Wilkson <ecwilkso@xxxxxxx> DATE/TIME: Sun, 27 Jun 1999 23:37:31 -0400 (EDT) POST: On Sun, 27 Jun 1999, Glenn Saunders wrote: > At 05:39 PM 6/27/99 -0700, you wrote: > >please DO answer, for the love of gawd! > > It's the whole Save Mary thing. I'm going to try asking Hasbro to fund > this thing as a CG Expo promotion. > > Tod Frye will be there, so he should be able to sign them too. > > I don't know if we'd have enough time, but I'm willing to give it a shot. Hmmm. If you want to do injection molding (probably the best technique), the molds can cost anywhere from $10k to $25k to make. So I would guess that that's out. Is there anyone on the list with machining skills and access to equipment? I think the if you have acceptable molds, the cases could be made in someone's garage. But I think you'd be better off just trying to find 500 Combats lying around...or go dig up those E.T. carts!!! :) You know...toy companies do a lot of injection molding...both in house and contracted. If you could only find a toy company... :P -Chris -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======SUNDAY, 27 JUNE ======Chris Wilkson: Comment on Injection Molding for New Cartridges. SUBJECT: [stella] My version of a scrolling demo POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Thu, 01 Jul 1999 14:24:28 +0200 POST: John said he doesn't mind some competition and he wondered how much difference a six sprite routine would make to the scrolling display, so I did two little demos by myself. They work like Kurt has sugested it, so I hope he isn't disapointed about my programming skills as well. ;-) Both feature a font which is 7 (double)scanlines high and up to 8 pixels wide (+ 248 blank pixels after a character, if you want to). The character set has ASCII characters from $20 to $7e and the text can be added conveniently in ASCII form to the scource code. SCRLBAR6.BIN uses single scanline resolution and can have 3056 characters. Since it was a bit hard to read on a real VCS, SCRLBAR5.BIN uses double scanline resolution and can hold only 3015 characters. On a Supercharger both programs can only hold 4 characters less than on a real cart or an emulator. These BINs are sligtly optimized versions of two BINs that I posted two days ago, but that Glenn hasn't approved yet. If both post make it through at the same day, I apologogize for the double post. Ciao, Eckhard Stolberg. ======JULY 1999 ======THURSDAY, 1 JULY ======Eckhard Stolberg: Version of a Scrolling Text Demo. SUBJECT: [stella] RPG Development (iii) POSTER: "David Schweinsberg" <david@xxxxxxxxxxxxxxxxx> DATE/TIME: Sat, 3 Jul 1999 22:05:33 +0100 POST: Here is a version you can walk around in. The spot-detail of castles, boats, etc. is not present in this version. The joystick will move the player - it is non-repeating so you have to keep nudging the joystick to continue in a direction. The world is encoded in a very inefficient fashion - it is a 32x32 test world in which I'm going to develop some of the basic gameplay. So don't disassemble the world-decoding code and freak-out :-) David Schweinsberg ======SATURDAY, 3 JULY ======David Schweinsberg: RPG Development New Version. SUBJECT: Re: [stella] need some quick software help... POSTER: emooney@xxxxxxxxxxxxxxxx (Erik Mooney) DATE/TIME: Thu, 08 Jul 1999 04:03:10 GMT POST: >I'm playing with a couple of projects (yes Glenn, I *know* I should be >working on the Superchip board! :) and I need some Quick&Dirty Code(tm) >to send a square wave out the joystick port. Does anyone have a code >snippet that does this? Or that simply sends out *anything*? Maybe >for the keypad controller? > >I know this is pretty easy to do, but I don't have time to re-invent the >wheel. :) Actually, this fits in nicely with the recently discussed >networking project... Okay, took me about 4 minutes :) Here's the code.. I'll email a binary to Chris separately. If someone sees a problem here, lemme know. It should generate a square wave on all four directional lines of both joysticks, at about 1 KHz. (there's 8 WSYNCs for each half-cycle, and the Atari scans at something like 15.8 KHz IIRC.) It's untested, of course, but it seems too simple to fail. (Yes, Nick, those are still your comments way back from How to Draw a Playfield, which I still use as a skeleton for my code) include vcs2600.h org $F000 ;RAM locations Start SEI ; Disable interrupts, if there are any. CLD ; Clear BCD math bit. LDX #$FF TXS ; Set stack to top of RAM. LDA #0 ;Zero everything except VSYNC. B1 STA 0,X DEX BNE B1 DEX STX SWACNT ;set data direction registers to output STX SWBCNT bigloop LDA #$FF STA SWCHA STA SWCHB STA WSYNC STA WSYNC STA WSYNC STA WSYNC STA WSYNC STA WSYNC STA WSYNC STA WSYNC LDA #$00 STA SWCHA STA SWCHB STA WSYNC STA WSYNC STA WSYNC STA WSYNC STA WSYNC STA WSYNC STA WSYNC STA WSYNC jmp bigloop ;Starting positions for PC org $FFFC .word Start .word Start -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======THURSDAY, 8 JULY ======Erik Mooney: Quick and Dirty Code™ to Send Square Wave Out Joystick. SUBJECT: [stella] Built-in screen saver POSTER: "John K. Harvey" <jkharvey@xxxxxxxxxxxxxxxxx> DATE/TIME: Fri, 06 Aug 1999 00:06:23 -0500 POST: Hello all. I was reading the article that was posted in IEEE Spectrum on the net, when suddenly I came across this paragraph: " An example of extensive color manipulation is a subroutine developed by Mr. Decuir to avoid burning game patterns onto the TV screen if the VCS is left unattended. The routine, which cycled through all possible color-luminance combinations, used only a dozen bytes, a great advantage in early game cartridges, which held only 2 kilobytes of ROM. "In 2K, you barely have room to brush your teeth," Mr. Decuir said." Is this just a subroutine that is accessed in the "mainloop" (to use Nick Bensema's playfield code)? Does anyone know what this code looks like, and how it checks if a game is idle or not, and how long the game waits before a screen saver mode hits? Thank you. -John K. Harvey -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======AUGUST 1999 ======FRIDAY, 6 AUGUST ======John K. Harvey: Thread on Colour Cycling Routine. SUBJECT: [stella] Bensema's Playfield instructional POSTER: Pete Holland <petehollandjr@xxxxxxxxx> DATE/TIME: Fri, 6 Aug 1999 15:55:00 -0700 (PDT) POST: I'm going through Nick Bensema's "How To Draw A Playfield" but am not getting very far. On page two, it lists a command that reads as follows: STA 0,X I thought STA stored what followed the command, from memory location or actual number, in the A register. The book on 6502 programming didn't mention anything about a comma like that. What am I missing? Also, just before it mentions that command, it mentions: "Since X is already loaded to 0xFF, our task...." What is 0xFF? That lower case "x" is what's throwing me. Is "0xFF" referring to location FF on the zero page? ______Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ Pete Holland: Thread Clarifying Some Issues With Basic Assembly. SUBJECT: [stella] WSYNC and RESPx questions POSTER: Thomas Jentzsch <tjentzsch@xxxxxxxx> DATE/TIME: Sat, 21 Aug 1999 10:55:42 +0200 (CEST) POST: Hello, i've been following this list for a while and also searched the archives. I'm trying to make my own kernel and still have some questions: There was some discussion about WSYNC, where some people said, that it has to start not later than cycle 72 to catch the end of the line. This means to me, that WSYNC needs >=5 cycles. I used distella to disassemble riveraid.bin, where i found this piece of code: LF258: STA WSYNC ;3 STA HMOVE ;3| STA ENAM0 ;3| STY GRP0 ;3| LDA $94,X ;4| a = 0..10 BEQ LF277 ;2|(15) TAX ;2| CPX #$07 ;2| BCS LF288 ;2|(21) ... LF277: NOP ;2|(18) NOP ;2| LDA #$60 ;2| STA RESP1 ;3|(25) position player 1 STA HMP1 ;3| shift left 6 pixel BNE LF26E ;2|(30) ... LF288: SBC #$04 ;2|(24) a = 3..6 TAX ;2| DEC $FD ;5| LDY $FD ;3| BEQ LF274 ;2|(36) LF291: DEX ;2| BPL LF291 ;2|(55-70) STA RESP1 ;3|(58-73) position player 1 LF296: STA WSYNC ;3|(61-76) <- ??? You can see, that WSYNC sometimes ($94,X == #$0a) starts at cycle 74. This happens when the planes are flying on the very right side. I've checked the possible values of $94,X not only by looking at the code, but also by patching the binary (cpx #$07 -> cpx #$0a, sbc #$04 -> brk). This caused Z26 (v1.32) to stop when the first plane enters from the right. I have no access to hardware, therefore i'm testing everything on different emulators. They all allow WSYNC to start at cylce 74, but i'm not shure if this emulation is correct. My second question is: what is the earliest usefull cycle for RESPx? If you look at riveraid.asm again, you find a special routine for players on the very left side. The RESP1 doesn't end at cycle 23, which would be correct in relation to the other possible values. It ends at cycle 25 and an extra HMOVE for 6 pixel to the left is done to correct this. I've no explanation why this is done that way, maybe on a real VCS lower values have no effect? Z26 reacts on values down to 22, lower values have the same effect as 22. I hope some of you VCS-experts can help me. === Thomas Jentzsch | *** Every bit is sacred ! *** tjentzsch at yahoo dot de | ______Do you yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======SATURDAY, 21 AUGUST ======Thomas Jentzsch: Thread on WSYNC and RESPx Questions. SUBJECT: [stella] An exercise in minimalism... POSTER: Mark De Smet <desmet@xxxxxxxxxxxx> DATE/TIME: Wed, 1 Sep 1999 18:47:08 -0500 (CDT) POST: I've been trying to make a 'game' that takes up the minimum amount of rom space. So far, I've been able to reduce it to 62 bytes(unless my count is off). The only thing it does is display the scrolling rainbow. I was trying to make it as small as possible, yet still display something on the screen so that someone running it knows that it is in fact running. Anyone have ideas for making it smaller? I still havn't used the accumulator in it, but there has to be a way to use that to save another byte or two... I also couldn't come up with a way to use the timer to save more bytes(it isn't used at all right now.), but there has to be a way to use it efficiently... Mark processor 6502 include vcs.h backcolor = $80 org $F000 Start ;Initialise SEI ;1 ; Disable interrupts. This may be removeable. CLD ;1 ; Clear BCD math bit. Removeable? depends if ;inc&dec are affected. ;need to clear out the player and playfield graphics regs as well as ;turn off the missles and ball. I think this loop is smaller than ;doing each of those individually. LDY #$FF ;2 LDX #0 ;2 B1 STX 0,Y ;2 DEY ;1 BNE B1 ;2 top OverScan LDY #34 ;2 STY VBLANK ;2 ;yes, I loose a scan line(it is blanked), but ;by doing this trick, I've removed 3 bytes!!!! DEY ;1 KillLines STY WSYNC ;2 DEY ;1 BNE KillLines ;2 VerticalBlank LDY #38 ;2 ;Y now is %00100110(1 in bit1) STY WSYNC ;2 vsync STY VSYNC ;2 STY WSYNC ;2 STY WSYNC ;2 DEY ;1 ;Y now is %00100101 (37) STY WSYNC ;2 STY VSYNC ;2 ;0 in bit 1, turns off VSYNC INY ;1 ;Y is now 38 vbloop STY WSYNC ;2 DEY ;1 BNE vbloop ;2 ;Y is now 0 STY VBLANK ;2 ; 0 turns off VBLANK LDY #191 ;2 LDX backcolor ;2 INC backcolor ;2 ScanLoop STX WSYNC ;2 INX ;1 STX COLUBK ;2 DEY ;1 BNE ScanLoop ;2 BEQ top ;2 org $FFFC ;4k .word Start ;2 -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======SEPTEMBER 1999 ======WEDNESDAY, 1 SEPTEMBER ======Mark De Smet: 62 Byte Scrolling Rainbow Demo. SUBJECT: [stella] Indirect Why? POSTER: "Ruffin Bailey" <rufbo@xxxxxxxxxxxxx> DATE/TIME: Mon, 6 Sep 1999 12:24:20 -0400 POST: Ok, I've been pouring over my code a bit _too_ long I suppose. I just can't get indirect y to work the way I'd like. I've got some bytes at the end of my demo that I'd like to use as the player graphic. I'm setting those up like this: ORG $FF01 .byte %10101010, %01010101,%10101010, %01010101 Then in earlier in my demo, I'm assigning this position to two bytes in RAM like so: LDA #$00 STA CTRLPF ;======; setting up where the player graphics are located ;====== STA $90 ; zero LDA #$FF STA $91 ; FF + 00 = FF00 (used with an indirect Y below) Now 90 should be the LSB and == #$00 and 91 should be the MSB and == #$FF, correct? Just one byte away from where I want to grab my graphic info. So during the screendraw, I've got this code to do just that: LDY #$01 STA WSYNC LF0AD: INX CPX #$60 BEQ DrawThePF LDA $90,Y ; "FF" + "00" = FF00; FF00 + Y = FF00 + 1 = FF01 STA GRP0 INY STA WSYNC CPY #$10 BNE LF0AD Did I screw up somewhere? Let me just say it's not working... I get one scan line worth of player, and that's it. Thanks for the help, and sorry if this is such a simple matter it's embarassing. I'll slap the full code up at: http://members.aol.com/mactari/why .asm Thanks again, Ruffin Bailey -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======MONDAY, 6 SEPTEMBER ======Ruffin Bailey: Question About Getting Indirect Y Addressing Working. SUBJECT: [stella] A question about ROR and ROL POSTER: Pete Holland <petehollandjr@xxxxxxxxx> DATE/TIME: Tue, 14 Sep 1999 15:28:09 -0700 (PDT) POST: Does ROR, when it rotates the bits, rotate them all, or does it just move them over and, any bits at the end, just dump them? It seems like ASL and LSR do the later, and I can't image redundant commands in computer programming, but I just want to make sure. ______Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======TUESDAY, 14 SEPTEMBER ======Pete Holland: Question About ROR and ROL. SUBJECT: [stella] Submitted for your (dis)approval: griddemo POSTER: Gene Johannsen <gej@xxxxxxxxxxxxxxxxxxxx> DATE/TIME: Fri, 17 Sep 1999 12:35:12 -0700 POST: Hey: I've been working on this off and on (well, more off than on) for a couple of weeks and I thought I'd post what I've managed to do so far and see if anyone can give me their reactions and thoughts. My development environment is dasm on a SGI IRIX 6.5 system using Xstella to test the program. This program has not been tested on a real 2600. This will be a puzzle game with an 8x6 grid of colored tiles. The object will be to jump tiles based on their colors and empty the board. It is based on an old Mac program called Stained Glass. I use a dynamic routine to change the background color as the scan line goes across the screen. This routine is in RAM, so I update the colors directly to make it as fast as possible. One thing I'm having problems with is why the board is so far to the left side of the screen. If I add one more NOP to delay it, I go over the scan line limit and break the display. Can anyone give a suggestion on how to center the display? Thanks for any help. Here's the code: ; ; griddemo.asm ; Displays and 8x6 color grid and randomly moves the colors. ; ; Gene Johannsen ; gej@xxxxxxxxxxx ; processor 6502 include vcs.h ; ; Constants ; red = %00110010 orange = %00010110 yellow = %00011010 green = %11000010 blue = %01110010 purple = %01010100 black = %00000000 squarerows = 30 ; number of scan lines to make a square. SEG.U ram org $80 gbcounter DS 1 ; Which piece in the gameboard gameboard DS 48 ; The gameboard itself rowcounter DS 1 ; Which scanline are we on ; Space reserved for a routine in RAM that will simply update the ; background color several times on a scanline, giving us the ; color grid. It is in RAM so it can be dynamically updated to ; minimize cycle use. ramdrawline DS enddrawline - drawline + 1 tmp ds 1 ; tmp location for swap rndl ds 1 ; for random number generating routine rndh ds 1 ; for random number generating routine SEG code org $F000 Start SEI CLD LDX #$FF TXS LDA #0 B1 STA 0,X DEX BNE B1 ; Copy the drawline code to the area pointed to by ramdrawline. ; Ramdrawline will be dynamically updated to produce the screen. LDX #[enddrawline - drawline] copyloop LDA drawline,X STA ramdrawline,X DEX BPL copyloop JSR initboard LDY #$F0 STY rndl ; Seed random number generator. main ; Begin drawing screen here. LDA #2 STA WSYNC STA VSYNC STA WSYNC STA WSYNC LDA #45 STA TIM64T STA WSYNC STA VSYNC vblankwait LDA INTIM BNE vblankwait STA VBLANK STA gbcounter LDY #1 LDX #[squarerows * 6] scanloop STA WSYNC DEY BNE drawclrs ; If Y = 0 then stop drawing and update the colors in the ; screen draw routine in RAM. This takes 2 scan lines. STX rowcounter LDY gbcounter LDX gameboard,Y LDA colorchart,X STA [ramdrawline+1] INY LDX gameboard,Y LDA colorchart,X STA [ramdrawline+5] INY LDX gameboard,Y LDA colorchart,X STA [ramdrawline+9] INY LDX gameboard,Y LDA colorchart,X STA [ramdrawline+13] INY STA WSYNC LDX gameboard,Y LDA colorchart,X STA [ramdrawline+17] INY LDX gameboard,Y LDA colorchart,X STA [ramdrawline+21] INY LDX gameboard,Y LDA colorchart,X STA [ramdrawline+25] INY LDX gameboard,Y LDA colorchart,X STA [ramdrawline+29] INY STY gbcounter LDY #[squarerows - 1] LDX rowcounter DEX DEX BNE scanloop JMP overscan drawclrs NOP NOP NOP NOP NOP NOP JMP ramdrawline ; Go to the routine in RAM to change the background colors rdlreturn ; ramdrawline jmps here when it is done DEX BNE scanloop overscan LDA #36 STA TIM64T ; Do some random color swaps during the overscan JSR rnd48 TAY JSR rnd48 TAX JSR swap JSR rnd48 TAY JSR rnd48 TAX JSR swap JSR rnd48 TAY JSR rnd48 TAX JSR swap waitoverscan LDA INTIM BNE waitoverscan STA WSYNC jmp main ; ; Initialize game board in RAM ; initboard LDX #47 outergb LDY #6 innergb STY gameboard,X DEX BMI doneinitgb DEY BEQ outergb JMP innergb doneinitgb RTS ; Swap two squares in the gameboard. X and Y hold the squares that will swap. swap LDA gameboard,X STA tmp LDA gameboard,Y STA gameboard,X LDA tmp STA gameboard,Y RTS ; Generate a random number rnd LDA rndl LSR LSR SBC rndl LSR ROR rndh ROR rndl LDA rndl RTS ; Generate a random number less than 48 rnd48 JSR rnd AND #$3F CMP #48 BCS rnd48 RTS ; A should now have a value from 0-47. drawline ; This routine will be copied from ROM into RAM ; so the color values can be changed and updated ; on the screen as fast as possible. colorcode LDA #$20 ; These numbers are meaningless since they will be overwritten in RAM STA COLUBK LDA #$40 STA COLUBK LDA #$20 STA COLUBK LDA #$40 STA COLUBK LDA #$20 STA COLUBK LDA #$40 STA COLUBK LDA #$20 STA COLUBK LDA #$40 STA COLUBK LDA #$00 STA COLUBK JMP rdlreturn enddrawline org $FE00 colorchart BYTE black, yellow, blue, green, red, orange, purple, black org $FFFC .word Start .word Start -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======FRIDAY, 17 SEPTEMBER ======Gene Johannsen: Demo For a Game Based on Grids. SUBJECT: [stella] Voice Synthesis POSTER: Russell Babylon <babylon@xxxxxxxxxxxxx> DATE/TIME: Fri, 17 Sep 1999 21:15:02 -0400 POST: Does anyone have any suggestions of how to record a digitized voice sample for replay on the 2600? With only 16 sample values you are somewhat restricted. Back in the mid 1980's I remember building a device for my Atari 8 bit computer that allowed you to record sampled sound and to play it back. It worked very well and was a big hit on the local bulletin boards. It was called Ramtalker I believe but I have lost the information on it. Since the Atari 8 bit computer uses the same audio volume technique as the 2600 the sampled sound files from Ramtalker should be useable on the 2600. I have been playing with 8 bit WAV files recorded on the PC but I have not had any luck manipulating them to play on the 2600. Any comments or suggestions? Russ Babylon -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ Russell Babylon: 2600 Voice Synthesis. SUBJECT: [stella] Thrust! POSTER: Thomas Jentzsch <tjentzsch@xxxxxxxx> DATE/TIME: Tue, 2 Nov 1999 17:07:56 +0100 (CET) POST: Hello, in the last months, i have followed the list. Soon i got the idea to write my own game. This should be a vcs clone of one of my favourite C-64 games, called thrust! I had to realize a 2d-scrolling PF, reused players and some missiles. It looked nearly impossible to me to put it all together, but i always liked to work with bits and bytes. The binary is what i got at this moment, just the kernel and some basics, most of the gameplay is still missing. What do you think? Does it work on a real vcs? I have no access to real hardware, just testet with z26. I've nearly reached the 4k limit, but the game will need at least 2k more. So i just started to implement the standard atari bankswitching (may be i will change this to the supercharger format). ===== Thomas Jentzsch | *** Every bit is sacred ! *** tjentzsch at yahoo dot de | ______Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de ======NOVEMBER 1999 ======2 NOVEMBER ======Thomas Jentzsch: First Version of Thrust Released! SUBJECT: [stella] Ho ho ho #2 (horizontal scrolling playfield thing) POSTER: Rob <kudla@xxxxxxxxx> DATE/TIME: Wed, 22 Dec 1999 23:59:46 -0500 POST: This is my first attempt at doing a horizontally scrolling playfield. I haven't seen too much of this so I figured I'd give it a try. This one I did more or less from scratch but obviously I used Nick's Playfield source as a reference. I'd love any ideas you have for tightening things up since I'm sure my code is still pretty ghastly and I imagine, completely bloated. It's only a couple hours old. What I'm hoping to do next is vertical scrolling and then, dare I say it, first-person perspective (faked, no vanishing point, just a horizon.) I'm trying to come up with a way to make my scanline loop skip 2 lines between XOR's, then 4 lines, then 8 etc until the bottom of the screen (or region, I also want to try a split screen kind of thing - OK, by now you can probably guess what game I want to do) in as few cycles as possible so I have room to add sprites and stuff. I have some ideas but I just wanted to get this out as proof of concept. I'm sure it can be done, with the tricky part being to make it look good. I also want to make the pattern finer, but this was the best I could do without having to discover writing the PF registers mid-scanline. Anyway, since boing26 was my first real 2600 project following the hacks and I didn't know about the stella-list then, I figured this one might make a good introduction. It's even tangentially related to boing26, you could think of it as an extreme close-up of a really large boing ball ;) Happy holidays to all. Rob ======DECEMBER 1999 ======WEDNESDAY, 22 DECEMBER ======Rob: Ho Ho Ho #2: Horizontal Scrolling Playfield. SUBJECT: Re: [stella] Ho ho ho #2 (horizontal scrolling pla POSTER: kurt.woloch@xxxxxxxxx DATE/TIME: Mon, 10 Jan 2000 16:25:59 +0100 POST: On December 28th, 1999 Glenn Saunders wrote: >Anyone have a list of games which do horizontal scrolling? Vanguard, >Defender, Killer Sattelites, Chopper Command, what else? >How many provide full scrolling both vertically and horizontally in the >same kernal? I'm talking about scrolling with playfield graphics in tow, >not just sprites acting as background ala Stargate. I don't have a full list of games, but I know some games that were not mentioned yet: -The Activision Decathlon, in principle, does horizontal scrolling, but with sprites only. -Moon Patrol has got some scrolling mountains in the background. -Astro Attack also has horizontal scrolling (this is a budget game where you fly along with a spaceship shooting at helicopters etc., then have to pass through a narrow maze). -Road Runner scrolls horizontally, but I don't know how exactly, since I don't have that game. -Pole Position also scrolls the mountains in the background when going through curves. -Super Cobra: This is probably the most interesting of my list, because it has (nearly) full-screen horizontal scrolling (which means mid-screen changes to the playfield registers, as we know by now), which is also important for the game. You fly along mountains, through caves etc. with your helicopter and have to shoot ground obstacles as well as flying ones, as well as fuel tanks for fuel supply. Parker Brothers wrote this game and also adapted it to the Magnavox/Philips Odyssey/G7000, which is a far more ugly platform for horizontal scrolling than the 2600. With love (and many landscapes to scroll) Kurt Woloch -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======JANUARY 2000 ======MONDAY, 10 JANUARY ======Kurt Woloch: Games That Did Horizontal Scrolling. SUBJECT: [stella] Pressure Gauge 2 POSTER: "John K. Harvey" <jkharvey@xxxxxxxxxxxxxxxxx> DATE/TIME: Tue, 18 Jan 2000 11:22:31 -0600 POST: Hello all. About 6 months ago I was deliberating over the miniscule number of multiplayer games available for the 2600. So, I decided to make a sequel to Pressure Gauge... but better. It's a 4-player game (using paddles), which is mostly finished. I figured I'd post it to the list, because I hit a brick wall as far as ideas. But, I'm way ahead of myself. Here's how to play. PG II: Basic instructions: It's pretty easy. Plug in the paddles. Turn on the game. The annoying music does not stop unless you press reset or select (I came up with the stuff while mowing my lawn this summer... couldn't get it out of my head. Don't worry, I'll probably replace it later on). Each player has their own corner of the screen. Of course, they start of with P1 in the upper-left, p2 in the upper right, p3 in the lower left, p4 in the lower right. The object is simple. Press the corresponding paddle button when it's in the "Green Zone". It'll cause the score section in the middle of the screen to increment. 48 correct hits later nets you the title of game winner. However, the winner screen is just blank again. I haven't decided how to finish that yet. That's about it for the old Pressure Gauge stuff. The new additions are quite cool. There is a grey bar also within the corresopnding player's corner of the screen. If you press your button while on it, nothing happens, but when it turns white (randomly, of course), and you press the fire button in the area, you receive a prize. It changes until you press the button, and then you receive that actual item. You'll understand if you try it. Your paddle knob is then activated. Because of code limitations, the moveable range of the paddle is not very large, so it moves fast. Basically, you move a highliter around that allows you to select someone (even yourself!) and "give" that item to them. The items are: 1) Rainbow wafer - it does.... nothing! 2) Red light - stops the individual who is targeted for 3 seconds or so. 3) Green light - speeds up the targeted individual (there are 4 speeds -stopped, slow, medium, and fast. All players start on slow). 4) Pink down-arrow - inverts the player selected 5) Yellow Lightning bolt - stops all but the selected player for 3 seconds. 6) Yuk face - completely drains a player's score to zero. 7) Light blue 4 arrows pointing in corners thing - switches all player positions on-screen (don't worry, your score moves with you) except the player selected. 8) Pink question mark - picks one of the random items above. That should be about it. Basically, my concerns involve what to do when someone wins. In Super Bomberman 2, the winner of a few rounds ends up getting a special item for the next few rounds. Or, I could interlude with a sub-game. Or I could just have the game end after 5 rounds or so, and play a fanfare for the winner. I haven't figured anything out that far yet. As far as other future plans, I plan on updating the colors of some objects, because of bleeding problems. Also, I need to add background music, and a title screen that isn't blank, and plays less annoying music. Any ideas would be appreciated. Also, I don't think there will be any problems (I tested it on an EPROM and a supercharger, with no problems), but if there are, please feel free to report them. Thanks a bunch. Hope ya like it. :) -John K. Harvey Didn't play the original Pressure Gauge yet? Download it hat http://www.cs.wisc.edu/~harvey/ atari2.htm ======TUESDAY, 18 JANUARY ======John K. Harvey: Pressure Gauge 2: Multiplayer. SUBJECT: [stella] Try this demo, please. POSTER: Scott Huggins <sub17_5k@xxxxxxxxx> DATE/TIME: Sun, 19 Mar 2000 14:19:25 -0800 (PST) POST: This is a my first 2600 demo. All it does is draw a playfield (8 scanline resolution) and then a multi-colored sprite. You can then move the sprite around screen. If the sprite collides with the middle part of playfield, the playfield will change colors. Nothing complicated here, but the sprite "acts funny" when you move it to around pixel position 12-20(the left third of the screen.) You'll notice it when you try this .bin in an emulator. It acts like I'm doing too many cycles during the Horizontal Fine Coarse (done during vblank) positioning and "bleeding" over to next scanline...if that makes sense. Anyways, could one of you fellas give this a whirl? Thanks! Scott ______Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com ======MARCH 2000 ======SUNDAY, 19 MARCH ======Scott Huggins: Demo From a New Programmer. SUBJECT: [stella] Color test POSTER: "Philipp Graf" <ut3h@xxxxxxxxxxxxxxxxxxx> DATE/TIME: Mon, 1 May 2000 23:41:49 +0200 POST: Hallo everyone! While searching the web for information about the VCS2600 and its programming I found this mailing list. The archives helped me a lot so to get started here's my first try in putting something together. It is a little color test. Don't ask me what the playfield graphics are supposed to mean. Maybe it could be used as a tool for hypnotisation. It does not contain any sublimal messages, though. Of course I am interested if it works on a real (NTSC-)2600... (this is a 'frequently asked question' on this list as it seems ;) ) Bye, Philipp. PS: I dont want to 'flood' your mailboxes, but if anyone is interested I could also post the source. ======MAY 2000 ======MONDAY, 1 MAY ======Phillipp Graf: Colour Bars Demo. SUBJECT: [stella] Collision detection POSTER: "John K. Harvey" <jkharvey@xxxxxxxxxxxxxxxxx> DATE/TIME: Thu, 04 May 2000 12:36:04 -0500 POST: Ok, so I've been thinking about collision detections (pretty obvious, if you read the subject line). I've never done these things before, and was wondering when to check, set, and clear the latches. The stella guide says I should do it typically in VBLANK. However: Hypothetically, I've been thinking of a situation: P0 and P1 collide on scanline 4. P0 and P1 collide on scanline 104. Should I check for collisions after scanline 4, and then rewrite to CXCLR immediately afterward, and check for another collision after liune 104, or just try to figure the stuff out all in VBLANK? I guess I'm just wondering what works bet for some of you others who have used this stuff. And also, are collisions only detected in the kernal? Thanks! -John K. Harvey "The man who didn't care about his igneous rock took it for granite." -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======THURSDAY, 4 MAY ======John K. Harvey: Thread About Collision Detection. SUBJECT: Re: [stella] scanline counts POSTER: Eckhard Stolberg <Eckhard_Stolberg@xxxxxxxxxxxxxxxxxx xxx> DATE/TIME: Tue, 30 May 2000 18:28:44 +0200 POST: > Basically, I'm wondering how many or how few scanlines I can have per >frame before I will have any given television "roll". I believe I remember >hearing on this list that Activision games may have been a little bit >larger than 262 scanlines. Was this true? I think Activision games use more lines in the visible part of the frame. But they do less scanlines during the VBLANK and overscan part of the frame to make up for that. 192 visible scanlines is a very conservative value. I heard that most NTSC TVs can display over 200 scanslines. > If I did 261 or 263 scanlines per frame, would that be ok? I am mainly >curious because TPS needed to be modified because of a scanline problem (I >assume), which caused flipping on some TVs. Anyone know the limits? Or am >I forced to stay with exactly what I know. The problem with TPS was that it did an odd number of scanlines which would result in no colour being displayed on PAL TVs. Due to the way Atari implemented PAL colour encoding you would get only a greyscale picture if you did for example 261 or 263 scanlines per frame. If you always do an even number of scanlines per frame you would get a coloured display on PAL too, although the colours would be different from those on NTSC VCSs. >Otherwise, which is worse for a TV, more than 262 scanlines, or less? The number of scanlines that your TV can handle before starting to roll is adjustable with the VHOLD knob. Therefore there are no absolute numbers that would work on all TVs. If your TV is perfectly tuned for 60Hz, there shouldn't be a difference in how many lines more or less than 262 it can handle. Since PAL TVs are tuned for 50Hz display and a perfect 262 line 60Hz display is pretty close to it's lower limits, you shouldn't do much less than 262 lines, if you want your game to display properly on PAL systems too. Ciao, Eckhard Stolberg -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======TUESDAY, 30 MAY ======Eckhard Stolberg: Answering Question About Scanline Numbers. SUBJECT: [stella] Thrust v0.9 POSTER: Thomas Jentzsch <tjentzsch@xxxxxxxx> DATE/TIME: Mon, 12 Jun 2000 16:00:18 +0200 (CEST) POST: Hi, here is my latest version of Thrust. There's also a manual included, which is based on the original C64-manual. So everyone should know what to do. The game is now completely playable with z26, and i hope you enjoy playing and testing it. There are a few questions i still have: - I'm using an illegal opcode (lax) for the scrolling effect in the score-display. Only z26 supports these opcodes and i wonder if they work with a real vcs. I haven't found any information in the biglist, so it's up to those who know better... - On my computer (doesn't matter which emu) the sound is terrible, when both circuits are used. Is there a problem with my hardware or the emulation? Or is this a general problem when using both circuits? Now that i've crossed the 8K border, i have plenty of space left. I'm planing to add one or two extra deep and heavy levels. I could also add another obstacle (what?) besides REVERSE GRAVITY and that even more deadly "something". And there should be a rookie and an expert mode, which could have different starting-lifes, gravity, gun-fire etc. Any more ideas? Have fun! Thomas ===== Thomas Jentzsch | *** Every bit is sacred ! *** tjentzsch at yahoo dot de | ______Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Mail auf Ihrem Handy? - http://mobil.yahoo.de ======JUNE 2000 ======MONDAY, 12 JUNE ======Thomas Jentzsch: Thrust v0.9. SUBJECT: Re: [stella] 2600 questions POSTER: Mark De Smet <de- smet@xxxxxxxxxxxxxxx> DATE/TIME: Tue, 20 Jun 2000 22:36:22 -0500 (CDT) POST: > "Since the TIA latches all instructions until altered by another write > operation it could be updated every 2 or 3 lines". Note for the hardware knowledgeable, they are not 'instructions' per-se, but instead simply register writes. The registers can be considered memory, so latched, yes.(NOTE, that because of the way the TIA was implemented to reduce hardware, the memory is write ONLY, or read ONLY depending on the direction of the register.) > I'm assuming this means that whenever you want the same scanline to show up > for multiple scanlines, you simply execute a WSYNC on the successive > lines? But for any kernel that does register hits in mid-scanline, you > must re-execute those hits on every scanline, right? Yes, if you don't do anything, the line will be repeated, hence the vertical bars which you sometimes see when you pull a cartridge with the power still on. The exception to this, as you have noted, is when you do resets(resp0, respm0...) more than once per line, or update graphics mid-line. If you do a reset once, like the TIA was originally designed for(2 sprites, 2 missles, 1 ball, playfield on the entire screen), then you do not have to do the 're-execution' every line. The reset object will repeat if you don't change it. The other note is with horizontal motion, but if you don't strobe hmove, then the above is correct. As you say, the line will not repeat if you are setting the playfield(for example) twice in a line(once at the beginning, and once in the middle) > So if you just wanted to draw a stripe, you could have one line in the > kernel and all others would be WSYNCs? Could the programmer also use this > screentime to perform number crunching and other non-visible stuff? This > is how the paddles are typically read, correct? Big time yes! This is why early games did graphics that have a large vertical resolution. The intent was to allow more programmer time. I suspect it wasn't that the early games needed the program time, but that they didn't have the experience yet to realise what all could be done. Yes, paddle reads must be done during the screen. > "when a 1 is written to D1 of the CTRLPF register, the left half of the > playfield takes on the color of player 0 and the right half takes on the > color of player 1." > > Does this mean it actually does a color shift automatically in > hardware? Also, this feature does not prevent sprites from being used on > those scanlines, does it? It is done in hardware. I don't see why this would prevent sprites, and it should have no effect on those colors. I had always wondered about that 'score' bit. I mean it is theoretically great for doing scores at the top of the screen like in airsea battle. The thing I don't understand is because I think this is why it was designed this way when they designed the TIA, but that would imply that when they designed the TIA, they knew that they could do playfield updates mid line. I had thought that this was a later revalation... > That's one feature I never knew about. I thought Combat was doing the > color shift manually. It could be done either way, but it would be easier using the 'score' bit. > Also, has anyone thought of trying to wire something into the unused bits > (D5 D4 and D2) of PortB/SWCHB? Never heard anything of it. It is 100% doable. the 6532 is a stock part, and those pins are simply not connected. > Also, anyone know the reason why the trigger buttons connect to the TIA > instead of PIA? Not sure, best guess is because the designers wanted the latch feature. The PIA(6532) basically provides no latching(except for that edge trigger I talked about before, which I don't think anyone uses) By putting it through the TIA, they could add that latch which would allow for better grabbing of fast button presses. If your program only reads the inputs once per screen(and you have the latches off), then a person has to have the button pressed fully for 1/60 of a second, which although is a short period of time, is actually long when you talk about bouncing, which you may want to catch. With the latch, you can catch all presses, no matter how fast(I lie, the speed is limited to the transistor speed, but that is pretty darn fast). Mark -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ ======TUESDAY, 20 JUNE ======Mark De Smet: Answering Technical Questions about the 2600 and TIA. SUBJECT: Re: [stella] RAM optimization POSTER: Erik Mooney <emooney@xxxxxxxxxxxxxxxx> DATE/TIME: Tue, 20 Jun 2000 21:37:22 -0400 POST: >Has anyone ever tried using some of the unused data bits in the TIA >registers for general purpose RAM storage? Never tried, but it's most likely impossible, since all of the TIA registers are write-only; the same addresses always access totally different registers for reads and writes. -- Archives (includes files) at http://www.biglist.com/list s/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/ Erik Mooney: Speculating that Unused Data Bits in TIA Cannot Be Used Like RAM. SUBJECT: [stella] RAM usage POSTER: Glenn Saunders <cybpunks@xxxxxxxxxxxxx> DATE/TIME: Tue, 20 Jun 2000 17:18:52 -0700 POST: