Jump to content

codernator

Members
  • Posts

    8
  • Joined

  • Last visited

About codernator

  • Birthday 11/08/1975

Profile Information

  • Custom Status
    I Implement I Work
  • Gender
    Male
  • Location
    Jacksonville, FL
  • Interests
    gaming, programming, beaches, canoeing
  • Currently Playing
    Saints Row 3, Daggerfall, Pitfall, Heroes of Might and Magic IV
  • Playing Next
    Saints Row 4

codernator's Achievements

Combat Commando

Combat Commando (1/9)

0

Reputation

  1. Thanks to this post, I now have an animated tank that you can move back and forth on a multi-colored background.
  2. Wow, I feel like such a code monkey. I read the addressing modes over and over, but still didn't pick up what was being laid down. Anyway, it works now. I was using DASM 1.09. I've upgraded to DASM 2.20.11. Either way, no error was reported concerning the invalid addressing mode at any verbosity. :/
  3. I am attempting to use indirect addressing to render a sprite, by referencing a table of addresses to various sprite frames. I did read http://atariage.com/forums/topic/198867-address-table-question-urgent/page__hl__+indirect%20+address?do=findComment&comment=2536600, but I seem unable to correctly apply this to my code. What is rendered is not the sprite I intended, but whatever happens to be in whatever address I happen to be incorrectly referencing. Please help me uncover the error. Here is a snippet: FRAME_POINTER will point to the current frame by address. (In this snippet there is only one frame). SEG.U VARS ORG $80 FRAME_POINTER ds 2 SEG CODE LDA TankImageTable STA FRAME_POINTER LDA TankImageTable + 1 STA FRAME_POINTER + 1 Gfx Kernel reducted to only the relevant part. LDY #2 LDX #7 TankArea LDA (FRAME_POINTER),X STA GRP0 STY WSYNC DEX BPL TankArea Sprite Definition: TankImageFrame0 .byte #%01111110 .byte #%11010101 .byte #%10101011 .byte #%11111110 .byte #%10111000 .byte #%10011000 .byte #%00011000 .byte #%00011000 TankImageTable .word TankImageFrame0
  4. I'm playing with movable objects. I generally have the gyst, but in this example there is a mild visual anomaly - the movement of the vertical line is slightly out of synch. I feel like there is something fundamental I am missing here. Any thoughts? student2.asm
  5. I have dealt with the carry bit issue, which ate up alot of CPU. I imagine with some clever math I could tighten things up more, but I am not going to obsess more over this project. The display is alot more solid, although one little anomaly remains. It appears I'm getting an extra scan line at intervals that is rendered with the last background color. Any ideas? student.asm
  6. Hah. It all seems so obvious. Had I been doing this an a high-level language, I would have written something like "color = (color + increment) % MAX_COLOR". It didn't occur to me to do that here. I'll fix that tonight and see how things stand.
  7. Greetings Atari Fans and Developers! My first post was in the n00bs section, but Godzilla suggested I post here and reference that one, so here I am. I feel like my question is beyond the newbie topic, even though I am new to 2600 programming. I do look forward to getting some feedback. Here is my original post: http://atariage.com/forums/topic/212657-jumping-in-head-first/ Thanks, Grif
  8. Greetings Starfighter, You have been recruited by the Star League to defend the frontier against Xur and the Ko-Dan armada. --- Sorry, wrong topic. I loved that movie, though. Greetings Atari Fans and Developers! I am a computer programmer, no stranger to assembly language, yet I am new to the 6502 (or 6507, as it were) chip and - more to the point - cpu cycle counting. As such, my first Atari program is an exercise in timing. I have attached my first program for your critiquing pleasure. Basically, the program displays colored lines in the background, each based on the current descending line count. However, that being only marginally interesting, it also changes the color as frequently as possible on the current scan line. Finally, just for fun, it tracks a cycle counter that is added to the current line number. The final effect is 11 scrolling color bands. I have executed this program both in Z26 and Stella, and observed a couple of bugs that I am having trouble tracking down: * At regular intervals there is a short period of increased velocity, as if the program is "catching up". * There is a minor visual anomaly that results in the horizontal seems between scan lines being slightly crooked at times. This is probably related to the previous issue, and could very well be simply due to a limitation of the EMUs. * The first color band is shorter than all the others, while the last is longer. I feel like this is just the nature of the alignment of the cycles, but I am curious if it can be fixed. I haven't the means to dump this to a cart, but I do wonder if those behaviors would be the same on the actual device. If any devs out there have some insight or general advice, I'd be glad to have it! Thanks, Grif PS: This was part of the alphabet would look like if Q and R were eliminated. PPS: I love the Topics Tags. We need more adoption of tags on the internet. student.asm
×
×
  • Create New...