Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Elijah

#1
General Discussion / Re: Geometry Dash
20 Feb 2024, 11:59 AM
Geometry Dash gained its initial popularity during my middle school years. Witnessing it being ported like this would definitely be intriguing!
#2
right, sorry
I was messing around with the session 21 sprites code from Andrew Davie
MiddleLines     

               stx COLUP0
               sty COLUP0
               inx
               iny
               SLEEP 20



               sta RESP0



               SLEEP 10

               sta RESP1



               sty GRP0
               iny             ; modify sprite 0 shape

               stx GRP1



               sta WSYNC

               inx



               cpx #184

               bne MiddleLines
this code that does work.

But, when I dex or dey
MiddleLines     

               stx COLUP0
               sty COLUP0
               dex
               iny
               SLEEP 20



               sta RESP0



               SLEEP 10

               sta RESP1



               sty GRP0
               iny             ; modify sprite 0 shape

               stx GRP1



               sta WSYNC

               inx



               cpx #184

               bne MiddleLines
The other sprite just becomes a square! I have no idea why this happens, but it only seems to happen with DEX and DEY
#3
Programming / DEX and DEY player sprites
08 Feb 2024, 02:28 AM
Hello everyone,

I've been experimenting with sprites lately and noticed a limitation: I'm unable to DEX and DEY player sprites, at least not in the manner I've been attempting. While it's not a major issue, I'm curious about the technical reasons behind this. I've, of course, been able to with the playfield and player color. Despite searching online, I haven't found a clear answer, so I'm reaching out to all of you for insights. Any help would be appreciated.

Best regards,
Elijah
#4
Quote from: JetSetIlly on 31 Jan 2024, 07:54 PMHi Elijah,

First of all, well done on getting this far. Looking at your code the first problem I see is that you've placed the "mainplayer" data in the middle of the executable code. This means that the 2600 will try execute the data!

So, in this case, after executing the "ldx #os_h" instruction the program counter will be pointing to the memory location holding the %00000111 byte. I'm not sure what instruction this is without looking it up, but I know it can't be anything good.

A few cycles later the program counter will point to the %00000000 instruction, which I know is a BRK instruction. This causes your program to start all over again from the very beginning.

So, first thing you should do is move the mainplayer data block so that it is "outside" the executable data. A good place will be after the "ORG $F000" directive and before the "reset:" label

Looking at the player code I'm sure there are other problems but move the data block as instructed first and see how you get on from there.




Hello there,
  First thank you for the kind words!  Moving this section of code has made a difference. While the playfield no longer flashes, it's now appearing for about two frames before disappearing entirely, which I consider to be progress. Still no character, but progress is progress! I'll continue to delve into this until I either crack the solution or someone else discovers and shares it on this thread. The journey to resolve this issue continues! Thank you for your help!

Quote from: alex_79 on 31 Jan 2024, 09:16 PMYou also need to intialize the decimal flag and stack pointer because the internal state of the CPU is undetermined when you power on the console.
e.g. add this at the beginning of your "reset" code:
  cld        ;clear the decimal flag
  ldx #$ff
  txs        ;set the stack pointer to "$ff"
If you don't, the result of arithmetic operations (ADC, SBC) might not be the expected one, and using subroutines might overwrite your variables or TIA registers.



Thank you!

As of now, I haven't made any changes to other parts of the code except for the recommended adjustments mentioned in this thread. This means that anyone who wishes to contribute can easily do so, and should I make substantial progress independently, I'll be sure to share it here in this thread for everyone's benefit. Thanks again everyone!
#5
Hello everyone,

I'm reaching out for some assistance regarding a programming challenge I've encountered while working on my project.

For the past couple of days, I've been tackling the task of integrating a sprite (currently without movement) into a playfield that I've developed. However, I've hit a roadblock where the playfield fails to render correctly, and worse, the character sprite isn't appearing at all. Instead, there's just a rapid flashing of the playfield. This playfield was perfectly fine before trying to draw the player sprite.

After some investigation, I suspect that I may have exceeded the machine cycle limit, causing the first issue. However, the reason behind the sprite not drawing remains unclear to me. As someone relatively new to this field, I'm hopeful that the solution might be simpler than it appears.

I would greatly appreciate any insights, suggestions, or guidance that you could offer to help resolve this issue. Thank you all in advance for your time and assistance.

Attached below this post, you'll find the relevant sections of the code for your reference.

Best regards,
Elijah
           processor 6502

           include "vcs.h"

           include "macro.h"



           SEG
PFCOL      equ #$A2
Pfheight   equ #192
os_h       equ #34
Playerheight equ #10
BACKGROUND equ #$00
COL0       equ #$1E
            seg.u vars ; uninitialized segment
            org $80
p0_y   ds 1
tp0_y  ds 1
scanline ds 1
           seg main
           ORG $F000




reset: ldx #0 ; Clear RAM and all TIA registers
lda #0
 
clear:        sta 0,x ; $0 to $7F (0-127) reserved OS page zero, $80 to $FF (128-255) user zero page ram.
inx
bne clear

lda #%00000001 ; Set D0 to reflect the playfield
sta CTRLPF ; Apply to the CTRLPF register

lda #PFCOL
sta COLUPF ; Set the PF color

               
                lda #COL0
                sta COLUP0

                sta     WSYNC

                SLEEP   19

                sta     RESP0


StartOfFrame:
                lda   #%00000010
                sta  VSYNC

                sta WSYNC
                sta WSYNC
                sta WSYNC

                ; turn off vsync
                lda #0
                sta VSYNC

                ldx #0
lvblank:    sta WSYNC
                inx
                cpx #37
                bne lvblank

                ldx #0
Drawfield:      lda       #%00000000 ;2
                sta PF0 ;3
                sta PF1 ;3
                sta PF2 ;3

                stx COLUBK  ;note, havent loaded background yet, 3
                sta WSYNC  ;3

                inx ;2
                    cpx #162 ;2?
                    bne Drawfield ;2
                ldx #0 ;2
               
Drawfield2:               lda #%11111100 ;2
                sta PF0 ;3
                sta PF1 ;3
                sta PF2 ;3

                lda #BACKGROUND ;load background color,3
                sta COLUBK ;3
                inx ;2
                    cpx #30 ;2
                    bne Drawfield2 ;2
                ldx #0 ;2

player1       
                lda #Playerheight
                sec
                sbc tp0_y ; Replace "isb tp0_y" with "sbc tp0_y"
                bcs draw_player
                lda #0
draw_player
                tay
                lda mainplayer,y

                sta WSYNC
                sta GRP0
                dec scanline
                bne player1

                sta WSYNC

                lda #%00000010
                sta VBLANK
                ldx #os_h
mainplayer
;just a square
.byte %00000111 ;
.byte %00000111 ;
.byte %00000111 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;
.byte %00000000 ;

overscan:    sta WSYNC
                  inx
                  cpx #30
                  bne overscan

                  jmp StartOfFrame

                  org $FFFA
 

irqvectors:
.word reset          ; NMI
.word reset          ; RESET
.word reset          ; IRQ
               
#6
Awesome, thanks guys!
#7
Hello everyone,

I'm currently grappling with a dilemma that seems to be somewhere in the realms of hardware, programming, or emulators concerning the Atari 2600. While playing a game of Pitfall (which for the record, I'm very bad at), I inadvertently left my emulator running in the background after I died, only to observe a fascinating phenomenon: the color pallet started changing after a while. Now, I'm not quite sure whether this is a hardware glitch, a programming quirk, or simply an emulator idiosyncrasy.

Given my relatively novice status in programming for the Atari, I'm eager to learn the reasons behind these color transformations. Any insights or knowledge on what might be causing this would be immensely appreciated! Attached below are screenshots capturing the intriguing color shifts. Thank you and I will be testing other games for this interesting glitch.

Yours,
Elijah