Aha! Now I understand! Thanks for the help ^^

The PPUDATA read buffer (post-fetch) section of that page is interesting. I have used this a lot with collision detection and know you have to read twice, but I didn't know why! Learning. Who'd a thunk it.

I have another question about my program... In my program, the "randomness" factor is determined by incrementing a certain value. When the button is pressed, this value is stored in the box to determine the letter. However, it's not really that random as you might have guessed, so I'd like to know if there's a way to make better "random" values, which can be used for things a bit more advanced than generating a random letter like taking a random card from a deck of cards

You can find some random number generators from here: http://codebase64.org/doku.php?id...

Thanks! This one seems fairly simple, here's what I understand about it. Keep in mind that I'm a beginner at 6502 ASM, as I just finished the Nerdy Nights.
getrandom:

lda random+1 ;Loads random into the accumulator (Don't have a clue about the +1 though)
sta temp1 ;Stores random+1 to temp1
lda random ;Loads Random without the +1
asl a ;Shifts the value (random divided by two) in the accu to the left, sticks byte 0 in the carry flag
rol temp1 ;ROLs (Rotate left, multiplies by two) temp1, which is random+1
asl a ;Do what you already did to the value in the accu a second time
rol temp1 ;Same for temp1
clc ;Clear the Carry flag
adc random ;Then add random to the accumulator
pha ;vectrex280996.exe encountered an unknown opcode and stopped running. What I understand is that this makes a copy of the accu to the stack according to http://www.obelisk.demon.co.uk/65...
lda temp1 ;Loads temp1 to the accu
adc random+1 ;Adds random+1 to accu
sta random+1 ;Then stores this to random+1
pla ;What does this opcode do? According to http://www.obelisk.demon.co.uk/65..., it takes the value you put in the stack before and sticks it in the accumulator
adc #$11 ;Add #$11 (Decimal 17) to what is in the accu (don't really know what's in the accumulator due to pla)
sta random ;Store it in random
lda random+1 ;Loads random+1 in the accu
adc #$36 ;Add hex value 36 (Decimal 54 to the accumulator
sta random+1 ;Then stores it to random+1

rts

temp1:
.byte $5a
random:
.byte %10011101,%01011011


A few questions now.
1.What is the +1 for?
2.What do PLA and PHA really do?
3.What is .byte for?
4.How can I use this subroutine when I want a random value in my game?

Im kind of interested in starting to get a cheap eprom programmer ( http://www.ebay.com/itm/TOP853-US... ) and i wonder if its suited for snes eproms and what eproms should i get?
I got some german and japanese games i want to translate like terranigma. Is there anything special i should learn before geting one?
Every answer is a big help!

thumbs up for the site thefox mentioned, I got a psrng from there as well, haha.

1. The +1 accesses one byte past what the address "random" points to. "random" is an address, which is basically an index into a huge list of "bytes". Bytes can be thought of as a number from 0 to 255. You can look up 65536 bytes all in a row, numbered from 0 to 65535, using the 6502's 16 bit addressing system. Some of these bytes are mapped to RAM, others to permanent ROM, and still others to registers that control what the NES's graphics, sound and input hardware do.

2. pha and pla push to and pull from the stack, respectively. Basically it literally takes whatever is in the accumulator and literally puts it on a stack. The only rule is, the last thing you put in (pha) is the first thing you will pull out (pla). It's most common use is when calling subroutines, with jsr. The cpu automatically uses the stack, with that, though, you don't need pha and pla for calling a routine (you do need rts though).  It's very useful for preserving local state when you need to jump to a routine that may clobber a part of RAM you were using before you called said routine. Typically one wants to avoid that but used judiciously it can be very convenient.

3. .byte tells the assembler to just spit out a byte into the ROM. This is a bit hard to explain. When you first start out you will see .res 1  in some places and .byte $00 in others and wonder what the real difference is. Basically, .res will not actually output a byte. It just means

random: .res 1

Will point to a location in memory. You won't typically see .res anywhere but ZP or RAM on the NES, because its for reading/writing variables.

.byte $00 will actually put the value "0" permanently into your rom. So if you're storing data such as a metasprite, a coordinate, some other value for whatever you're doing in your engine, and you want it to be PERMANENT, you use .byte. (or .word, or a host of other directives that some assemblers offer)

Using a prng is fairly easy. Just call it to let it permute the current value of random (and random+1...looks like this one works with a 16 bit value), and then transform that value into something usable like a coordinate, a speed, or whatever else you may need it for. It's often possible to get better results from prngs by throwing more chaos into it drawn from parts of your engine, such as the player's coordinates (a human can add a lot of randomness to a game).

Hope that helps a little!

Note! That prng you found is probably intended for a machine that loads a program into RAM, as it DOES use .byte to spit out a value into what appears to be treated as RAM, in that routine. On the NES, you may want to adapt this by doing:

random: .res 2

and then have an init routine that fills "random" with an initial seed value.

I skimmed over a lot there---there's a lot of details other tutorials and folks here can help fill in. Hopefully something in there helped a bit, though.

The random routine you posted is the same one I use in all my games, Vectrex.

Thanks for the explanation! However, I still don't understand a few things...
1.Whenever I input .res 2 in NESASM3, it says "Unknown instruction!". Any idea on how I could adapt this piece of code to the NES?
2.What I understand about using the prng is that you call it with a JSR to get the current value of random and random+1, then you can do something like
LDA random
STA playerspeed
to make the player's speed "random". random+1 should be used in a 16 bit value (I think).

Someone may need to step in and help. ".res" is what I'm familiar with in CA65...I actually forget right now what its counterpart in nesasm is. It might be .rs. Also, make sure based on whatever tutorials you are using that you're using these directives in the right places. .rs / .res needs to be used somewhere in ram (usually zp, stack, or bss). .byte, somewhere in your rom.

for #2 yes, you just need to play with it and figure out how to transform the random value to something that makes sense for what you are doing. Usually this sort of thing takes a lot of tweaking to get desirable results that "feel truly random." even though ultimately they really aren't

Oh yeah! I use .rs when I declare variables at the beginning of my code so this may be it.

Sent you a pm.

I'm not sure what answer I'm expecting, but I'll ask anyway

At what point do you guys just give up on doing things the "right way" and just settle for something that works? I find myself spending too long finding clever tricks which is really holding me back, and I'm finding it hard to force myself out of it. A sort of premature optimisation I guess. I see the same thing where people spend all their time bickering over the best way to do something, to the point where they never finish their projects.

Anyway, I really just wanted thank you all for the advice and tutorials here, they've been a great help.

Rob.

That is an important question. All too many people get a bit too consumed with the "right way." We see the opposite extreme, however, where there's no concern at all for the "right way." It's a balancing act. It all depends on what is most deeply important to you. If it is more deeply important to you to build an entire game from end to end, then sometimes you may have to pick something that works rather than do it the right way. It's amazing how deep the "right way" can really go. When it comes to bugs and glitches, I believe it is important to always get at the root cause, or you can really step on yourself and make it very difficult to maintain your code. But in terms of choosing the right way of doing some aspect of a game engine---it is a balancing act.

IMHO, if something is worth doing, it is worth doing badly (G.K. Chesterton). This quote has helped me focus on building complete games from end to end. Nice thing is---this quote merely helps remove inhibition, it doesn't mean I will commit to doing things poorly for all time. The code in Nomolos is pretty messy and ugly compared to what I'm doing in Owlia, yet I'm still aware of many flaws I could improve on for when I make a third game. I'd rather have it this way than spin my wheels for years and never finish something!

We're not bickering, we're discussing.

Great question. I agree with Derek. What matters most is that the game runs smoothly with minimal bugs. A playable game with messy code is arguably better than a half-finished demo with elegant code.

However, I would like to stress code modularity. There's a difference between inefficient (un-optimized) algorithms and unstructured code. It's worth taking the time to think ahead and abstract your code down to the simplest possible modules. In other words, writing an entire game in one huge function would be a nightmare to debug or modify, even with elegant code. So code structure is more important than elegance when it comes to editing your game by scaling and maintaining your code.

TL;DR: write functions that are well-defined and optimize them later, as needed.

This is coming from someone who still hasn't touched 6502, so take it with a grain of salt

In my opinion, as long as it works, it's the right way.

Thanks for the advice guys, I just need to suck it up and get it done. Like Derek said, this is probably going to be an incremental thing, so get my first game done and learn and optimise from there. I like that plan

And MRN: I was more thinking of the NesDev forums when I said that than here, your programming resources thread is fucking awesome

yes, modularity of code is just as important in 6502 as any other language. I've found it's possible to write very clean/readable code in pure 6502 with very little language level abstraction, or even macros. Often, an optimization can be found at a higher, architectural level that is influenced by the mechanics of your game that will give you more bang for your buck than squeezing every last cycle out of the CPU.

KHAN: That's a good way of looking at it, from the perspective of your players. For yourself though, being the programmer, you have the most to gain from thinking about the "right way," as it can increase efficiency of development and reduce the number of bugs you may have to work through.  Note, in saying this I do not claim to be perfect at getting things right, code wise. I have a backlog of bugs and am aware of many flaws in my own code as well. It is something we all ought to think about.

That's a great attitude. Start with something of reasonable scope, too. Most successful homebrewers I've met start small, finish their projects and then increase complexity from there. 

Once your game is done nobody cares about what the code looks like! Working vs a good design vs the best way makes no difference. However a good-best way usually ends up being faster dev for that project and code reuse for the next project. If my game is something I just need finished fast my code is very sloppy and inefficient compared to my full games.

The code from my first game scares me. When I open it up I just get stressed out. I re-coded Frogger and it took like 1/3 of the code space. It's hilarious.

Hahaha, you don't want to see my current code then!  I'm probably over stretching myself with what I'm attempting, but I'll keep at it and learn for future projects like you say.  I'm having fun working on this, so if it never gets finished it'll have at least provided some entertainment for myself.  Hopefully it'll get done and provide entertainment to others when they play it

Yea, I'm on my forth iteration of the nightman code. The first two attempts I honestly have no clue how the room selection worked. I had a professor in college that used to put ? marks everywhere and write "compensating errors". I just stopped messing with it when it worked. Then, like Bunny said, there's no way to use it when you make another game. The third iteration was pretty good, but it included separate engines for the levels and background, bad guys and playable characters. Basically, doubling the code required. This fourth iteration I have a better idea of what I'm doing and it's pretty fucking sleek. Adding new shit is as simple as copy/paste & update pointer tables. It all just depends on what you're going for.