Search the Community

This is just a simple fix for the top two lines having the same color ;*************************************************************** ; ; 88 rows that are 2 scanlines high. ; DF6FRACINC = 255 : DF4FRACINC = 255 DF0FRACINC = 128 : DF1FRACINC = 128 : DF2FRACINC = 128 : DF3FRACINC = 128 asm LDA DF6FRACDATA ; bgcolor priming read (first value will be read twice) LDA DF4FRACDATA ; pfcolor priming read (first value will be read twice) end ;*************************************************************** ; ; Displays the screen. ; drawscreen

Here's some bB examples of stuff that's not easy to figure out, so might save somebody some time. Change color behind score without minikernel CHANGE_COLOR_BEHIND_SCORE.bas Change scorecolor SCORE_COLORCYCLE.bas Change playfieldcolor on any row/rows you want CHANGE_PLAYFIELD_COLOR.bas Change backgroundcolor on any row/rows you want CHANGE_BACKGROUND_COLOR.bas I'll try and come up with some more.

[ON HOLD] So DionoiD has now released his WIP of Tower of Rubble and his take is amazing to say the least! Great visuals, music and game play really makes it a fantastic Atari 2600 conversion. So for now I'm going to leave this to one side - I might pick up the game to maybe do something different down the track. I'm also making the source code available if anyone wants to make use of anything. Tower of Rubble How long can you survive on the lethal TOWER OF RUBBLE as it crumbles and rebuilds itself around you? This is my first Atari 2600 game written batari Basic and DPC+ as a way of learning to code the Atari which I have recently returned to after a very long hiatus. I started coding just before Christmas so about 4 weeks worth of work so far. How to play Control the player with the joystick only (no fire button) moving left and right to run across the tiles and pushing up and down to climb. Learning to jump is key to surviving the tower and is essentially automatic: you jump off the edge and depending on whats in front of you, you will jump across and hang or drop and hang you can climb down backwards into a hanging position then move left/right to jump across (again depending on whats in front of you). there is a short jump (between 1 tile gap) and a long jump (between 2 tile gap). State of the game Currently a basic mechanics of the game is complete and the following is essentially complete: the player can run, jump, climb and hang around the main beam drops tiles randomly another beam destroys tiles and sends them crumbling into the water (moving from the outside-in) some basic sounds (walk, jump, death) pause game with Color/B&W button (press fire to continue) game currently ends and pauses for a period of time before returning to title screen (you can restart directly after a short pause here by pressing fire) I've had to work around a few things to keep the frames from jumping (hopefully!) There is still a number of things to finalise: test on real hardware (Harmony cart on it's way) balancing - game runs quite quickly ATM add some variation to the tiles (currently causing a few frame issues so not sure I will be able to do it) sound and music - always an issue for me but we'll see how I go! horizontal beam - will need to look at drawing this with the background (I believe?) - have about 900 bytes available in the bank I'm using for the beams. other beams - there are a couple of other beams which I need to investigate which drop and clear tiles slightly differently game over notification - still deciding on whether to add this as it will explain your death (would love to overlay but doesn't appear possible) any remaining bugs would love a 2 player version - I've partially coded it so this may be possible - not sure how may frames might be left though Feedback Any feedback would be very much appreciated. Real Hardware 17/01 - Currently it appears the game doesn't work on real hardware when launching off the title-screen (frame overrun) - will investigate. 18/01 - A build has been tested by @cimmerian which has fixed the launching issue but I still have a minor overrun with the crumbling beam to sort through 21/01 - This build should now run on hardware without any frame overruns [TBC] Downloads 20190121 - all frame overruns should now be removed (Stella is showing no overruns) as I've fully split the game initialisation (start) and beam completion (ie. main beam - adding tile, crumbling beam - removing columns) over multiple frames. This should set me up for adding the next horizontal beam (fingers crossed). towerofrubble.20190121.bin Older builds 20190117 - this release includes some sounds (Walk, Jump and Death), a number of optimisations to provide better/faster access to the ram bank, reduced cross-bank access (found 1 or 2 not required) and cleaned up a lot of no longer used code. The game runs a lot smoother and seems to have removed most/all frame overuns (finger crossed). towerofrubble.20190117.bin 20190115 - Initial WIP release towerofrubble.20190115.bin

Here's a first draft of LumaBoost in bB, it can be used for other things to as it allows you to change graphics and colors very easily. I will continue to update it and make it more usefull. Hopefully someone figures this out so we don't have to do all the overlap checking again. I made the LumaBoost very exagerated so it's noticable. NEW VERSION LumaBoost example 2019-02-05.bas OLD VERSION: using the same high pointer didn't work for all players LumaBoost example 2019-01-10.bas LumaBoost example 2019-01-10.bas.bin

Unfinished (way unfinished)... Posting my first attempt at this song, don't know if it will be fixed or final before Christmas. This uses the Pitfall II type of 3-channel music, with notes in tune. DPC+ needs Stella 3.1 or newer for emulation, Oops, Harmony or Harmony Encore 2600 cart for real hardware will not work as I did not merge it with the header.. Thanks to Supercat via SpiceWare for this assembly routine. It has a nice vibrato effect, a little bit better than Stay Frosty 2 as this is just doing the tune and a simple sprite display and not an entire game engine logic. DPC+ music has to be done in assembly as no kernel has been made for batari Basic. I got the color changed, and tried to have the display flip (so it is more tree-like), but no luck with my newbie asm skills! Joystick speeds it up, but default 0 is already quite fast. SilverBells2600.bin Merry Christmas to all here that celebrate it, and Happy Holidays to everyone else!

in the standard kernel rand produces a jsr to randomize and produces a new number with the DPC+ kernel it just loads rand unless you've specified inline rand so how often does DPC+ update rand? or does DPC+ not touch rand at all?

I got this to work, and wanted to share as I could find no information searching. RT has added a clearer example to his batari Basic site: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_dpc_shooting_nusiz Also there is a powerful "trick" that lets you cover all (or as many) virtual sprites as you want with the same code block. First you check for missile0 Player1 collision. Skip the routine if no collision. Second, find which virtual sprite was hit, set trick value, go to find out which copy, and rearrange. For triple copy, medium, there are 7 routines. For double copy, medium, there are 2 routines. Keeping track of the remaining routines are the variables enemyP2 thru enemyP8. To explain double copy: Player2 starts out with 2 copies, enemyP2 is 2. If you hit the left one, the on-goto will take the far right branch. (the first branch if enemyP2 is 0, the 2nd branch if enemyP2 is 1, the third branch I'd enemyP2 is 2) As the left sprite was hit, change to one copy NUSIZ2=0, move the single sprite over to where the copy was, set enemyP2 to 1. When next Player2 is hit, move it off screen, set enemyP2 to 0. Triple copy has more rearranging. Shooting the left enemy of 3 copies first, change to double copies, medium, move right to where copy 2 was, set enemyP3 to 3 which will next take "which 2 on the right" has been hit. Shooting the center enemy of 3 copies, change to double copies wide. enemyP3=5, that branch being "which 2 of wide" has been hit. Shooting the right enemy of 3 copies, change to double copies, medium. enemyP3=6. "which 2 on the left" So what is left over after a hit on one of 3 copies determines which branch will be taken for the 2 remaining copies to become 1 copy. Now to explain the "trick". Why is everything in the routine enemyP2 and player2 and NUSIZ2? The value in the brackets points to them sequentially. player2[0] is player2 player2[1] is player3 player2[2] is player4 etc. It works for NUSIZ2[0] thru NUSIZ2[6] (and NUSIZ2[7] if you need to set NUSIZ9) and because I set enemyP2 through enemyP8 as variables: a, b, c, d, e, f, g it works there also. Sometimes I have seen some collisions detected, the missile resets, the explosion sound is played, but the player doesn't get removed. I think my +values are correct, but possibly they are not. Maybe every once in a while it just fails a check? dim enemyP2=a dim enemyP3=b dim enemyP4=c dim enemyP5=d dim enemyP6=e dim enemyP7=f dim enemyP8=g ; Note: Above must be sequential for "trick" dim trick=t NUSIZ2=$02: NUSIZ4=$02: NUSIZ6=$02: NUSIZ8=$02: enemyP8=2: enemyP6=2: enemyP4=2: enemyP2=2 NUSIZ3=$06: NUSIZ5=$06: NUSIZ7=$06 enemyP7=7: enemyP5=7: enemyP3=7 DF6FRACINC=255: DF4FRACINC=255: DF0FRACINC=255: DF1FRACINC=255: DF2FRACINC=255: DF3FRACINC=255 ; Backgrnd colors.; PF colors.; Column 0. ; Column 1. ; Column 2. ; Column 3. drawscreen ;******************************************************************************************************************************************** ; ; missile0 collision check. ; ;``````````````````````````````````````````````````````````````` ; Checks for missile0 collision with other 8 sprites, reflected. ; As above, outside game loop, NUSIZx x=2 thru 8 ; Sprites 2, 4, 6, 8 are double, medium. ; Sprites 3, 5, 7 are triple, medium. ; if !collision(missile0,player1) then goto __Skip_m0_Collision if (missile0y+4)>=player2y && missile0y<=(player2y+4) && missile0x >=player2x && missile0x <= (player2x+64) then trick=0: goto whichCopy2 if (missile0y+4)>=player3y && missile0y<=(player3y+4) && missile0x >=player3x && missile0x <= (player3x+72) then trick=1: goto whichCopy1 if (missile0y+4)>=player4y && missile0y<=(player4y+4) && missile0x >=player4x && missile0x <= (player4x+64) then trick=2: goto whichCopy2 if (missile0y+4)>=player5y && missile0y<=(player5y+4) && missile0x >=player5x && missile0x <= (player5x+72) then trick=3: goto whichCopy1 if (missile0y+4)>=player6y && missile0y<=(player6y+4) && missile0x >=player6x && missile0x <= (player6x+64) then trick=4: goto whichCopy2 if (missile0y+4)>=player7y && missile0y<=(player7y+4) && missile0x >=player7x && missile0x <= (player7x+72) then trick=5: goto whichCopy1 if (missile0y+4)>=player8y && missile0y<=(player8y+4) && missile0x >=player8x && missile0x <= (player8x+64) then trick=6: goto whichCopy2 goto __Skip_m0_Collision whichCopy1 temp2=enemyP2[trick] on temp2 goto __Skip_m0_Collision which7w1 which7w1 which7w2l which7w1 which7w2w which7w2l which7w3 which7w3 if missile0x <= player2x[trick]+8 then NUSIZ2[trick]=$02: player2x[trick]=player2x[trick]+32: enemyP2[trick]=3: goto resetMissile0 if missile0x >= player2x[trick]+32 && missile0x <= player2x[trick]+40 then NUSIZ2[trick]=$04: enemyP2[trick]=5: goto resetMissile0 if missile0x >= player2x[trick]+64 && missile0x <= player2x[trick]+72 then NUSIZ2[trick]=$02: enemyP2[trick]=3: goto resetMissile0 which7w1 if missile0x <= player2x[trick]+8 then player2y[trick]=200: enemyP2[trick]=0: goto resetMissile0 which7w2w if missile0x <= player2x[trick]+8 then player2x[trick]=player2x[trick]+64: goto whichCopyEnd if missile0x >= player2x[trick]+64 && missile0x <= player2x[trick]+72 then whichCopyEnd which7w2l if missile0x <= player2x[trick]+8 then player2x[trick]=player2x[trick]+32: goto whichCopyEnd if missile0x >= player2x[trick]+32 && missile0x <= player2x[trick]+40 then whichCopyEnd whichCopyEnd NUSIZ2[trick]=$00: enemyP2[trick]=1: goto resetMissile0 whichCopy2 temp1=enemyP2[trick] on temp1 goto resetMissile0 which7w1 which7w2l dim enemyP2=a dim enemyP3=b dim enemyP4=c dim enemyP5=d dim enemyP6=e dim enemyP7=f dim enemyP8=g ; Note: Above must be sequential for "trick" dim trick=t NUSIZ2=$02: NUSIZ4=$02: NUSIZ6=$02: NUSIZ8=$02: enemyP8=2: enemyP6=2: enemyP4=2: enemyP2=2 NUSIZ3=$06: NUSIZ5=$06: NUSIZ7=$06 enemyP7=7: enemyP5=7: enemyP3=7 DF6FRACINC=255: DF4FRACINC=255: DF0FRACINC=255: DF1FRACINC=255: DF2FRACINC=255: DF3FRACINC=255 ; Backgrnd colors.; PF colors.; Column 0. ; Column 1. ; Column 2. ; Column 3. drawscreen ;******************************************************************************************************************************************** ; ; missile0 collision check. ; ;``````````````````````````````````````````````````````````````` ; Checks for missile0 collision with other 8 sprites, reflected. ; As above, outside game loop, NUSIZx x=2 thru 8 ; Sprites 2, 4, 6, 8 are double, medium. ; Sprites 3, 5, 7 are triple, medium. ; if !collision(missile0,player1) then goto __Skip_m0_Collision if (missile0y+4)>=player2y && missile0y<=(player2y+4) && missile0x >=player2x && missile0x <= (player2x+64) then trick=0: goto whichCopy2 if (missile0y+4)>=player3y && missile0y<=(player3y+4) && missile0x >=player3x && missile0x <= (player3x+72) then trick=1: goto whichCopy1 if (missile0y+4)>=player4y && missile0y<=(player4y+4) && missile0x >=player4x && missile0x <= (player4x+64) then trick=2: goto whichCopy2 if (missile0y+4)>=player5y && missile0y<=(player5y+4) && missile0x >=player5x && missile0x <= (player5x+72) then trick=3: goto whichCopy1 if (missile0y+4)>=player6y && missile0y<=(player6y+4) && missile0x >=player6x && missile0x <= (player6x+64) then trick=4: goto whichCopy2 if (missile0y+4)>=player7y && missile0y<=(player7y+4) && missile0x >=player7x && missile0x <= (player7x+72) then trick=5: goto whichCopy1 if (missile0y+4)>=player8y && missile0y<=(player8y+4) && missile0x >=player8x && missile0x <= (player8x+64) then trick=6: goto whichCopy2 goto __Skip_m0_Collision whichCopy1 temp2=enemyP2[trick] on temp2 goto __Skip_m0_Collision which7w1 which7w1 which7w2r which7w1 which7w2w which7w2l which7w3 which7w3 if missile0x <= player2x[trick]+8 then NUSIZ2[trick]=$02: player2x[trick]=player2x[trick]+32: enemyP2[trick]=3 if missile0x >= player2x[trick]+32 && missile0x <= player2x[trick]+40 then NUSIZ2[trick]=$04: enemyP2[trick]=5 if missile0x >= player2x[trick]+64 && missile0x <= player2x[trick]+72 then NUSIZ2[trick]=$02: enemyP2[trick]=6 goto resetMissile0 which7w2r if missile0x <= player2x[trick]+8 then NUSIZ2[trick]=$00: player2x[trick]=player2x[trick]+32: enemyP2[trick]=1 if missile0x >= player2x[trick]+32 && missile0x <= player2x[trick]+40 then NUSIZ2[trick]=$00: enemyP2[trick]=2 goto resetMissile0 which7w1 if missile0x <= player2x[trick]+8 then player2y[trick]=200: enemyP2[trick]=0 goto resetMissile0 which7w2w if missile0x <= player2x[trick]+8 then NUSIZ2[trick]=$00: player2x[trick]=player2x[trick]+64: enemyP2[trick]=1 if missile0x >= player2x[trick]+64 && missile0x <= player2x[trick]+72 then NUSIZ2[trick]=$00: enemyP2[trick]=4 goto resetMissile0 which7w2l if missile0x <= player2x[trick]+8 then NUSIZ2[trick]=$00: player2x[trick]=player2x[trick]+32: enemyP2[trick]=2 if missile0x >= player2x[trick]+32 && missile0x <= player2x[trick]+40 then NUSIZ2[trick]=$00: enemyP2[trick]=4 goto resetMissile0 whichCopy2 temp1=enemyP2[trick] on temp1 goto resetMissile0 which2w1 which2w2 which2w2 if missile0x <= player2x[trick]+8 then player2x[trick]=player2x[trick]+32: enemyP2[trick]=1: NUSIZ2[trick]=$00: goto resetMissile0 if missile0x >= player2x[trick]+32 && missile0x <= player2x[trick]+40 then enemyP2[trick]=1: NUSIZ2[trick]=$00 goto resetMissile0 which2w1 if missile0x < player2x[trick]+8 then player2y[trick]=200: enemyP2[trick]=0 goto resetMissile0

Ideas I just had to get out. Quick mock-up. Would be a great AtariVox+ game, because the Arcade version talks a LOT. Thanks again to RT and his website for the start of virtual player collision detection!!!! I could not find any info on what is commonly done like in 2600 Space Invaders - where it detects a collision with a copied sprite, and then how you have to shuffle things around depending on the order you shoot the triple or double copies. Shows I got it to work. Also the 1 pixel fuel decay using PF blocks and the ball. I found that a cool trick. Also thought about just a playfield block going from 4 high to 3, 2, 1, 0 and then decay the next one, and so on.

A lot of us 7800 fans hold the POKEY up in high regard because it's the sound chip we feel should've been standard with the 7800 in the first place or Atari [inc/Corp] should've included it in more titles. There's mods to add it to our 7800s, the Concerto, or a big reason to support the XM. However, the number of available POKEYs for use are dwindling and we have to compete with Atari arcade collectors and A8/5200 owners for those supplies. And the HOKEY solution hasn't been perfected yet. So why not use the DPC/DPC+ instead? It has an authentic Atari - via Activision - pedigree and receives support from the 2600 homebrew scene. Looking back, I'm rather dumbfounded why as to Activision didn't use their own chip in their post-Pitfall II 2600 - and 7800 - releases other than them pinching pennies. Same goes for Atari Corp. Thoughts?

If you like 2600 demos and don't visit the batari Basic programming section, you may have missed this. I decided to see how the TIA would fare for the arcade game Mappy's ragtime music, expecting it to be missing important notes and range. I was surprised at how well it turned out! Let me know what you think. http://atariage.com/forums/topic/233403-mappy-tia-music-demo-enjoy/?p=3150703 This is the Atari TIA built-in sound, no DPC+ tricks, however this is a DPC+ bank switching rom. It could be a 2K or 4K rom, minus the detailed Meowky, but my environment was set to build DPC+ and I wanted to attach the sound to some kind of video display and I already had this 30 frame flicker for 5 colors made in DPC+. Newer Stella and Harmony Cart.

Building on the "Flicker 5 colors from 3" topic: http://atariage.com/forums/topic/229091-flicker-5-colors-from-3/?p=3059920 I decided to do the gameplay music in TIA (stereo) to see how bad it sounds. (That, and I'm obsessed with all things Mappy. ) Turns out I think is very good, especially for the out-of-tune TIA sound. Only a few slightly-off notes and a few dropped notes in the entire piece. (By slightly-off I mean obvious sour notes, because almost all 2600 notes are out-of-tune to start.) The music is about 1 minute 20 seconds. Originally it took all of 4K, but through optimization I got the data down to 1,496 bytes! This whole demo could be done in 4K, but I compiled it with DPC+ bank-switching, just because that it what I usually work in, and if I ever make this into a flickery-mess of a game, I'll probably use DPC+. The 2nd channel can be used for game sound because even off the tune still holds up. I decided to try fading the notes with reducing the volume, and by "happy accident" got the ragtime tremolo (shaking volume)!! You can look at the source code, but I optimize it this way: Take out all the volume data and duration data. Those values can be fixed (or with volume, changed in program loops). That cuts the data in half. Since the Control is mostly 12 (pure lower), I have both channels set to 12. When it needs changing to a 4 (or the few 1's), I do an if/then check. Since the Frequency can also be a value of 4, I replaced all the Channel 4's in the data with 42. That saves 200+ bytes. When it needs to be 0 (silent) I check for that also, just set the Control to 0 (silences everything better than setting volume to 0) and skip setting a frequency. Then there are all those f'n zeros!!! More than 900 of them! More than half of the remaining data was 0's. It is like you are always telling the sound channels to shut up over and over. The final thing I thought up is a kind of pause check. If both channels are silent, twice, I replaced the 0,0,0,0 with 67 and set the Control to 0, the volume up (to reduce popping noise), and double the duration, and skip everything else. (I guess you could reduce the data even more with finding the segments that repeat and have that data only once. It sounds like the first part repeats three times in the piece.) Mappy_TIA_MusicTitleDemo_Stereo2015.bas.bin Mappy_TIA_MusicTitleDemo_Stereo2015.bas

I will add to this post, so check back if you are following. How to get 5 colors from 3 colors: This is done in the batari Basic DCP+ kernel, but it would work in the original batari Basic kernel if you can have an asymetrical playfield and both missiles and quad size players. The M and A are red playfield. The 2nd P and Y are blue playfield. It flicks between the red PF drawscreen and the blue PF drawscreen. The A, P and second P are dim yellow 2 players (quad size) and both missiles (set to 4 wide). Player0 is the A and the first 2 bits of the P. Missile0 is the long third bit of the P. Missile1 is the short center of the P before the hole. Player1 is the end 2 bits of the first P and the 2nd P. To blend the players with the playfield, it is set to show the playfield in front of the players. There is a program called: flickerpicker.bin The colors don't always mix like paint colors. Here the red and yellow make a nice orange, but the blue and yellow do not make green, but more of a sky blue or light gray. It looks a bit worse than the above photo of the TV screen. Also the first P is more yellow, the A is more orange. The M and the Y flicker the most. It will also look a bit different system to system, and depending on how the Atari's color is adjusted and the TV's colors are adjusted. The cat is a demo of both players making a multicolor sprite. This is rarely used due to flicker or due to using both players, but D.K. VCS uses this technique quite effectively. The source and binary will be attached, along with flickerpickerntsc.bin In assembly language you would just code an asymmetric playfield with mid-line color changes. That would give you five actual colors across without any flicker. flickerpicker.ntsc.bin MappyRYB220140824b.bas MappyRYB220140824b.bas.bin

Csonicgo asked if a 2600 Tempest could be done with the tools we have now. If we have enough ram and a 96+ x 192 bitmap, it could be quite nice. I have this quick mock-up for the "severe compromises" version. It is showing a blue Playfield segmented shape with different color green spikes, and a yellow player shooter. All the virtual sprites are left for the enemies. Tempestfault.bas.bin