8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

User avatar
tokumaru
Posts: 11445
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Tue Aug 16, 2011 12:36 pm

tepples wrote:
I don't know why so many games does terrible things at enemies respawning (Ninja Gaiden, Mega Man, ....)
RAM limits, I guess.
It might be more difficult without the extra RAM, but definitely not impossible.

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered » Tue Aug 16, 2011 7:29 pm

tokumaru wrote:Well, if you can understand the basic concept and are feeling confident about implementing this, then go for it! =)
Thank you so much! The positivity is very good! It helped me to decide to try my best... then I read through the rest of you and Shiru talking and it made me realise that this will be an incredible journey. :)
tokumaru wrote:
Bregalad wrote:Trust me, even if you're not scrolling, use 16-bits by all means !
I second this. Even in single-screen games you may need to scroll in and out of the screen, and smooth acceleration and deceleration.
Ok, thanks Bregalad and tokumaru. I remember hearing that from yall during my first nes game attempt... I think I was username "aaable" on yall's old forum. I dont remember much from then. :oops:

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered » Thu Aug 18, 2011 11:30 pm

In my lst file I just found out that $D0D1 skips down through a lot of famitone code. There are instructions on the right but the address never changes from $D0D1 for quite a while. Why..what..how? :?

edit: Maybe it's because that part of the code isn't used or is disabled; i remember telling famitone to not include DPCM code. Maybe that is correct! :)

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered » Mon Aug 22, 2011 1:46 pm

Code: Select all

enum $000	;asm6's way of declaring vars in ram

  ;a is for A register
  ;x is for X register
  ;y is for Y register


currControllerButtons .dsb 1,0
lastControllerButtons .dsb 1
newControllerButtons .dsb 1
read .db #31
oX .db #$8b  ;($0004 is X)
oY .db #$8b  ;($0005 is Y)
ok, I would like the X and Y coordinates to be equal to #$8B. It never makes it to #$8B.... the sprite just stays at #$00... unless, I press up down left or right then it incrementsORdecrements oXORoY by 1; the sprite then responds accordingly! :D ...Do I have to set oX and oY manually? :? Why? :?

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Mon Aug 22, 2011 2:01 pm

You can't make RAM anything on start up, you have to store it with your program there if you want it to start at a value.

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered » Mon Aug 22, 2011 2:24 pm

Why? In asm6 there's .dsb
asm6's README.TXT wrote:DSB, DSW (also DS.B/DS.W)

Define storage (bytes or words). The size argument may be followed
by a fill value (default filler is 0).

DSB 4 ;equivalent to DB 0,0,0,0
DSB 8,1 ;equivalent to DB 1,1,1,1,1,1,1,1
DSW 4,$ABCD ;equivalent to DW $ABCD,$ABCD,$ABCD,$ABCD
Why did they make this... changed my code to oX .dsb 1,$8b and it still started the sprite at 0, 0. :( :?
Last edited by unregistered on Mon Aug 22, 2011 2:30 pm, edited 1 time in total.

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Mon Aug 22, 2011 2:28 pm

Your program you put in the ROM isn't RAM.When the system boots up, it has garbage in it. Usually it's cleared on boot up, you have to store the variables you need in it at the spot you want them. Before your program starts, do a LDA #$NUMBER STA Label to put it there, there's no way around it, you have to.

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered » Mon Aug 22, 2011 3:13 pm

Thank you 3gengames for your help. :) ...Why would loopy add a pointless way of declaring a storage fill value in his assembler? :? dsb :? :?:

User avatar
tokumaru
Posts: 11445
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Mon Aug 22, 2011 3:21 pm

unregistered wrote:Why would loopy add a pointless way of declaring a storage fill value in his assembler? :? dsb :? :?:
Because .dsb can also be used in ROM, where you can actually fill values.

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered » Mon Aug 22, 2011 3:43 pm

tokumaru wrote:
unregistered wrote:Why would loopy add a pointless way of declaring a storage fill value in his assembler? :? dsb :? :?:
Because .dsb can also be used in ROM, where you can actually fill values.
Ah, that's great tokumaru, thank you. :D So, when using a mapper you could specify RAM; right?

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Mon Aug 22, 2011 3:47 pm

No, nothing in the world can put what you compile in RAM at startup except a Boot ROM which is wasteful and not going to happen because it's not even in the ROM for it to know what to put there.

tepples
Posts: 21720
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Aug 22, 2011 3:49 pm

If you want something to be in RAM when your program starts, copy it from ROM to RAM in the init code. This is exactly how the cc65 runtime library handles .segment "DATA".

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered » Mon Aug 22, 2011 4:15 pm

tepples wrote:If you want something to be in RAM when your program starts, copy it from ROM to RAM in the init code.
:shock: How would I do that? :)

3gengames
Formerly 65024U
Posts: 2269
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Mon Aug 22, 2011 4:24 pm

No offense....but you know how computers work right? You should maybe read up more on programming and more 6502. This something really, really..REALLY basic.

It'd go something like this for a small chunk of data to copy to RAM:

Code: Select all

;Somewhere in RAM:
MoveToRAM: .rs $100

;Somewhere in ROM, put:
SomeLabel: incbin "Data256bytes.bin"

LDX #$00
Loop:
LDA SomeLabel,X
STA MoveToRAM,X
DEX
BNE Loop
;Done.
It's the most straightforward a program can be.

unregistered
Posts: 1038
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered » Mon Aug 22, 2011 4:46 pm

3gengames wrote:No offense....but you know how computers work right? You should maybe read up more on programming and more 6502. This something really, really..REALLY basic.
:oops:
3gengames wrote: It'd go something like this for a small chunk of data to copy to RAM:

Code: Select all

;Somewhere in RAM:
MoveToRAM: .rs $100

;Somewhere in ROM, put:
SomeLabel: incbin "Data256bytes.bin"

LDX #$00
Loop:
LDA SomeLabel,X
STA MoveToRAM,X
DEX
BNE Loop
;Done.
It's the most straightforward a program can be.
:oops: 3gengames, thank you for that explaination! :) How can I choose RAM instead of ROM?

Post Reply