Jump to content

Search the Community

Showing results for tags 'DPC+'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Classic Consoles
  • Classic Computing
  • Modern Consoles
  • Gaming General
  • Marketplace
  • Community
  • Community
  • Game Programming
  • Site
  • PC Gaming
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's CDFJ+
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Robin Gravel's new blog's Games released
  • Robin Gravel's new blog's The Flintstones Comic Strip
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion
  • The Homebrew Discussion's Topics
  • Hair Club for Men's Bald? BEGONE!


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 39 results

  1. March 19, 2019 news. Release Candidate 1 DK_Arcade_2600_RC1.bin I've decided to share "DK Arcade 2600" and post the Release Candidate. This has sound, item, color differences, along with a fixed Kernel that should eliminate any "flashing ghost playfield pixels" that appear when nearly cycle maximum and that some machines were displaying. The "latest batari Basic" version from RevEng's thread has this fixed kernel. Reply in this thread any comments and suggestions - they are all considered, no matter good or bad, or not possible to include! Thank you. It is also decided by me, the author, that any "Release" will be through this "batari Basic Forum Thread". If you expressed desire for a real cartridge in this thread, no need to post again. You will be contacted when I have finished cartridges available later in 2019 or next year 2020. Payment will only be taken when finish cartridges are available - made with AtariAge hardware. This was my first designed game, both because I liked the game, I liked the challenge, and I wanted to show that very good games can be made with the "batari Basic" DPC+ kernel. - iesposta ----------------------------------------------------------------------------------------------------------- October 12, 2014 Two Demo binaries! You can now play as "The Lady" (created for the 2 women on AtariAge!). By popular demand, "The Carpenter" moves quicker up and down ladders. Fireballs descend ladders quicker. Alarm sound when timer falls below 1000. Numerous sound updates and bug fixes. Japanese order only (Levels 1, 2, 3 & 4) that end after Level 4. The title is a selection screen: Up, down, left or right selections. (Note: American selection defaults to Japanese order for these demos.) Remember to turn Phosphor Effect (Ctrl-p) on in Stella! DemoE = easy. As will be the first time though the levels. DemoH = hard. As will be the increased difficulty the next time through the levels. DK20141011BcDemoE.bin DK20141011BcDemoH.bin October 11, 2014 Second Demo Binary(s) soon! We have listened to comments and suggestions. I think everything done since the last demo has been an improvement in every area. Gameplay, graphics, sound and music, and options. List of "bugs" that probably are permanent "features": - Some odd TIA chips cause a few playfield pixels to blink. Does not affect gameplay. - Cement Factory level with hammer will show ghost garbage pixels when fireballs climb down due to Intelligent Flicker and virtual sprite vertical alignment. Does not affect gameplay. - Jumping to the left-most part of the center elevator (descending) player becomes unresponsive to joystick. Affects gameplay. -Jumping a fireball over a rivet can trap the fireball over the gap. One I had trapped later climbed thin air to the level above and started acting normally - except it was a few pixels below the girder. September 27, 2014 No binary, but we are still working on this! Latest binary directly below, in March 1. rem Note: 9-02-14 Made ditty1 note duration shorter, Opening longer, How High tune ends with harmony. rem Note: 9-09-14. Started adding Pauline Edition. rem Note: 9-20-14. Moved pies down in three! different locations. rem Note: 9-21-14. Fixed 'static' in ditty sounds. Added Pauline climb head wiggle. Fixed broke items grab sounds on elevators. rem Note: 9-22-14 Fixed "Death scene gone bad Elevator Level". Fixed winning Elevator w/Mario and having Pauline appear below. rem Note: 9-22-14 New PreTitle Screen layout. Removed a redundant ballheight=0. rem Note: 9-23-14 Needed to add Pauline Colors in skipmario2. PreTitle Screen has left / right joystick player selection. rem Note: 9-27-14 Difficulty increases by Byte Knight! New Pretitle Screen removed. Added Harmony to Opening Tune. rem Switched L/R selection and icon. Screen order progression fixed. Sped up prize sound. Fireballs descend faster. rem set optimization noinlinedata works. March 1, 2014 DK23Arcade2600.bin Bug fixes for the demo: Ramp Level Mario shouldn't get stuck in girders any more. Overlapping barrels shouldn't sneak through the hammer any more. Increased barrel spawn timer to make the level a little easier. Moved hammer up and right on top level so you can't grab it from the level below and you can jump straight up and get it. Fixed Mario jumping bug that would kill Mario after 5 jumps in a row. Cement Pie Level Kong has less separation anxiety! Fixed ghosting of the tops of fireballs. Elevator Level Mario won't "fall" through girders on Elevator Level. February 19, 2014 There's a new DK in town called DK Arcade 2600, joining AtariAge member Joe Musashi's phenomenal D.K. VCS! This playable demo features all 4 levels in full-screen goodness, so check it out! Brought to AtariAge by members "Byte Knight" and myself, "iesposta." Binary: DK_Arcade_2600.bin The playable demo features all four levels but will end after the rivet level (Level 4). Let us know your thoughts and post your high scores! The release version will feature: Japanese and US level order. Difficulty level increases. The ability to play Mario or Pauline. Thanks to RevEng and Bogax for technical help, and Atari Brian for beta-testing. February 12, 2014 Update. - Dynamic titlescreen has 1 to 4 Stupid Monkeys on How High Can You Try? depending on level. - Bonus/Countdown timer has color. Score is 6 digits and white. - Spinning death sound created. - Japanese and American order selection (difficulty switch). - Flicker reduced on top of level 1 by adding 2 playfield screen lines and removing 1 line from The Lady, putting her 7 lines above the barrels. Notice I said reduced. It still flickers a lot but that is where everything happens at once. - Going "over cycles" fixed by adjusting Overscan time, adding scanlines. Currently stable at 270 lines. - Custom Score Font. (I know it looks like other games, but I did create each number to match the arcade game.) February 5, 2014 Let it spin, let it spin, let it spin. No game, just spinning... DK21y140201bSpin.bas 2.bin January 19, 2014 This binary plays levels 1, 2, 4 and then properly goes back to level 1. DK21y140119f.bas.bin January 15, 2014. !! Level 2 pie/cement factory done!! Binary 1-15-2014: DK21yMKH14cr.bas.bin >>Positive or Negative Feedback appreciated, especially on real hardware during gameplay (rolling or jittering). Note: It does jitter before Level 4.JumpmanBLU20130826.bas.bin JumpmanBLU20130826.bas JumpmanBLU20130915a.bas.bin JumpmanBLU20130915a.bas JumpmanBLU20130919a.bas.bin DK26b.bas.bin DK2600-2013-12-23.bas.bin DK2600-2013-12-25.bas.bin
  2. 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.
  3. 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
  4. I am a bit of a chiptune nut, and I've been wondering about the possibilities of a small DPC+ music module player. From what I've read, the DPC+ is a 3-channel square wave sound generator, plus the two TIA sounds. I have no idea how fast the DPC+ can be called to change sound pitches, but given the examples I have heard, it can be quite a fun music machine. So at the end of the day, 5 channels to mess with sounds pretty enticing to me. Speccing a small module format wouldn't be difficult (Heck, the C64 had one) and most modules out there with no sample data (like for SID) are around 2-4K in size. I would be more than willing to assist with making specs for a module format. Does anyone out there think this is possible? Or would it be more trouble than it's worth?
  5. Here is a mock up example using batari Basic 1.1d. Titlescreen was made with Titlescreen Editor DPC+ The inline assembly was from the example "Move Sprite on a Slope" It uses single line playfield resolution. Unzip the file to your projects directory. Ask if you have any questions. Food Fight.zip
  6. Please check out the binary in the first post of Byte Knight and my work on a 1980 arcade port to the Atari 2600. With respect to AtariAge, no keywords in comments & suggestions please. Many people aren't aware batari Basic can now make games of this detail. You may have missed this if you avoid batari Basic games http://atariage.com/forums/topic/216037-dk-arcade-2600-progress-files-source-code-help-appreciated/
  7. iesposta

    Mappy. Title

    From the album: Status Art

    Flicker 3 colors to get 5.
  8. iesposta

    IMG 3748

    From the album: DK 2600 Jumpman

    Level 1
  9. iesposta

    IMG 3745

    From the album: DK 2600 Jumpman

    Title screen.
  10. iesposta

    Pauline Edition 02

    From the album: DK 2600 Jumpman

    DK Arcade 2600 Pauline Edition mode.

    © 2014

  11. From the album: QbBertari

    September 9 work in progress.
  12. 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.
  13. 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!
  14. •This thread is to discuss Playfield data in batari Basic DPC+ to benefit very detailed and lots of playfields in a single game. (The assembly programmers have tools, but I wanted to develop ones for batari Basic.) •This thread is to discuss playfield compression. Is it really worth it? Does it save space? •Creation of guides or scripts or apps to compress playfield data. •Creation of code to decompress data. Beyond the normal defining of playfield, I needed to store playfield screens in the rom banks, apart from the area DPC+ puts playfields. I have 2 highest resolution playfields in the DPC+ data area by defining the normal "playfield:" command. I also have 3 other highest resolution playfields as data in the usable DPC+ banks, bank2, bank3, bank4, bank5, or bank6. • Procedurally drawing a playfield. Bogax coded a routine to turn pixels on and off using data. <routine will go here> • Regular Playfield. Storing 8 pixels in a single byte is already quite a good storage technique. There are 8 bits in a byte and each bank only has around 4,000 bytes, so to get the most in a program, every byte counts! For one line of playfield, batari Basic has 32 pixels and this works out to 4 bytes: 00000000, 00111101, 00001111, 00000000 Here is the top 1/4 of my DKbB playfield: %00000111,%11111111,%11111111,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00001001,%00000000,%00000100,%10000000 %00000000,%00000000,%00000000,%00000000 %00000010,%00000000,%00000010,%00000000 %00001111,%11111111,%11111111,%10000000 %00001010,%10101010,%10101010,%10000000 %00001010,%10101010,%10101010,%10000000 %00001010,%10101010,%10101010,%10000000 %00001111,%11111111,%11111111,%10000000 %00000000,%00000000,%00000000,%00000000 %00000000,%00000000,%00000000,%00000000 %00001001,%00000000,%00000100,%10000000 %00000000,%00000000,%00000000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%00000000,%00000000,%00000000 %00001001,%00000000,%00000100,%10000000 %00000000,%00000000,%00000000,%00000000 That 1/4 takes 176 bytes. All 4 playfield data chunks takes 704 bytes to make one highest resolution playfield. That's almost three quarters of 1K of the 4K bytes. There sure are a LOT of 0's, each "0" holding one bit in the ROM. I have searched for compression in the "Basic" language here and on the web, and I have not found much. Here's what I have found / developed so far. Can compression gain space? • RLE Compression. RLE or Run Length Encoding is a simple compression that takes data and says 5 zeros, 19 ones, 16 zeros, 1 one, 11 zeros, etc. The above 1/4 playfield would RLE compress to this: ; 105 bytes compressed play field %00000101, %10001001, %00010000, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00001011, %10000001, %00001011, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00001011, %10000001, %00001011, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00001011, %10000001, %00001011, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00001011, %10000001, %00001011, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00000010, %10000001, %00001101, %10000001, %00000010, %10000001 %00101101, %10000001, %00001111, %10000001, %00001101, %10010101 %00001011, %11111111, %10101010, %10101010, %10101000, %00000000 %10101010, %10101010, %10101000, %00000000, %10101010, %10101010 %10101000, %00000000, %10000000, %10010101, %01001011, %10000001 %00000010, %10000001, %00001101, %10000001, %00000010, %10000001 %01101011, %10000001, %00000010, %10000001, %00001101, $10000001 %00000010, %10000001, %00100111 That is 105 bytes, a savings of 71 bytes, but routines are still needed to expand the data. (Note: the bottom of the above data is incorrect, as I have begun to add "flag" bytes.) I used a python script, and hand typed the above table with the 1st bit in each section showing if the number is ones or zeros. The decimal for the data that starts with "%0" is how many zeros. The first line says 5 zeros. The data that starts with "%1" is data for on bits. The byte converted to decimal, minus 128, would be the number of 1's. The fourth byte, "%10000001" says 1 ones. <- I noticed this is wasteful. A whole byte to say one 1? Looking at the above data, I began to see more patterns. Notice it alternates zeros data, ones data, etc. Also notice it alternates a lot with: data, one 1, data, one 1, data, one 1, etc. More waste: %10101010 just doesn't gain anything from this compression, it actually goes from one byte to 16 bytes! This is the point where I came up with Conditions. • Compressed Playfield with Conditions. It makes sense to set a byte to tell the playfield plotting routine to just use every bit as playfield data - it is not compressed. I came up with three Conditions: Condition0 128 means normal RLE operation. 128 = %10000000 Condition1 192 means every other operation is 1 on pixel. 192 = %11000000 Condition2 256 means plot every byte. 256 = %11111111 The playfield data with Conditions would be this: %10000000 ; Condition0 %00000101, %10001001 %11000000 ; Condition1 %00010000, %00001011 %00110011, %00001011, %00110011 %00001011, %00001011, %00001011 %00110011, %00001011, %00110011 %00001011, %00001011, %00001011 %00110011, %00001011, %00110011 %00001011, %00001011, %00001011 %00110011, %00001011, %00110011 %00001011, %00001011, %00001011 %00110011, %00001011, %00110011 %00000010, %00001101, %00000010 %00101101, %00001111 %10000000 ; Condition0 %00001101, %10010101, %00001011 %11111111 ; Condition2 %10101010, %10101010, %10101000, %00000000 %10101010, %10101010, %10101000, %00000000, %10101010, %10101010 %10101000, %00000000 %10000000 ; Condition0 %10010101 %11000000 ; Condition1 %01001011, %00000010, %00001101, %00000010 %01101011, %00000010, %00001101 %00000010, %00100111 Now the data takes 67 bytes from the original 176. A savings of 109 bytes. This is as far as I got today. The above still has patterns, like the 10 "%00001011"'s in the center column. I can't think of a Condition for that. Times 4 playfield parts that would save around 435 bytes. Is that enough to make compression/decoding worth it?
  15. I'm attempting to mix bB code and Assembly to do some more advanced things, such as having a single bank of colors/sprites that are assigned to players based on a variable. Note that this is using the DPC+ bB kernel. The issue here is in regards to pointers and how flexible they are in Assembly, because I don't know. For instance, I have a set of colors for a sprite: asm milCol .byte $D6 .byte $D6 .byte $D6 .byte $D6 .byte $D6 .byte $D6 .byte $D6 end I want to call this bank of color values and assign them to every player in a loop, in case I want to assign a specific color to individual players later. I noticed when looking at the game's assembly that colors are assigned like so: .L0241 ; player2color: lda #<(playerpointers+20) sta DF0LOW lda #(>(playerpointers+20)) & $0F sta DF0HI LDX #<playercolorL0241_2 STX DF0WRITE LDA #((>playercolorL0241_2) & $0f) | (((>playercolorL0241_2) / 2) & $70) STA DF0WRITE . ; .L0242 ; player3color: lda #<(playerpointers+22) sta DF0LOW lda #(>(playerpointers+22)) & $0F sta DF0HI LDX #<playercolorL0242_3 STX DF0WRITE LDA #((>playercolorL0242_3) & $0f) | (((>playercolorL0242_3) / 2) & $70) STA DF0WRITE . ; There's a pattern--players 1-9 are assigned their low and high points using the (playerpointers+x) phrase where x = 20 + (sprite# * 2) I'm attempting the following: for temp1 = 0 to 3 temp2 = 20 + temp1 + temp1 asm .enemycolor lda #<(playerpointers+temp2) sta DF0LOW lda #(>(playerpointers+temp2)) & $0F sta DF0HI LDX #<milCol STX DF0WRITE LDA #((>milCol) & $0f) | (((>milCol) / 2) & $70) STA DF0WRITE end next This should calculate where the high and low points for the player pointer will be and add it to playerpointers in order to point to the right location. It compiles, but doesn't work. Is there some special way I need to address the temp2 variable in order to allow it to be added to playerpointers? This also applies to sprites. I would like the sprite for any player to be chosen based on a certain variable (in my case it's enemy0, enemy1, enemy2, etc.) so, if enemy0 is 1, it will grab a certain sprite for that player and set it to a certain color, without the redundancy of repeating sprite and color tables for each possible combination for each player. There are two ways to do it. Either I could have a series of statements like the above .enemycolor for each possible color/sprite and then adjust the player's pointer based on a variable to point to the sprite/colors that are applicable, or (preferably) I need some way to change which data set is being loaded on the fly, such as the following mock-up: for temp1 = 0 to 3 temp2 = 20 + temp1 + temp1 data playerColors milCol, milCol, milCol, drkCol end temp3 = enemy0[temp1] temp4 = playerColors[temp3] asm .enemycolor lda #<(playerpointers+temp2) sta DF0LOW lda #(>(playerpointers+temp2)) & $0F sta DF0HI LDX #<temp4 STX DF0WRITE LDA #((>temp4) & $0f) | (((>temp4) / 2) & $70) STA DF0WRITE end next ... asm milCol .byte $D6 .byte $D6 .byte $D6 .byte $D6 .byte $D6 .byte $D6 .byte $D6 drkCol .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 .byte $00 end So, two questions: 1. Is there any way to dynamically adjust the value being used for the player's pointer? 2. Is there any way to dynamically adjust which data set is being pointed to?
  16. iesposta


    From the album: DK 2600 Jumpman

  17. [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
  18. 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
  19. 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?
  20. 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.
  21. 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
  22. iesposta

    IMG 3765

    From the album: DK 2600 Jumpman

    Level 4.
  23. iesposta

    IMG 3751

    From the album: DK 2600 Jumpman

    Level 2.
  24. iesposta

    IMG 3664

    From the album: 2600

  25. iesposta

    Pauline Edition 01

    From the album: DK 2600 Jumpman

    DK Arcade 2600 Pauline Edition mode.

    © 2014

  • Create New...