Skip navigation
Welcome, Guest! Please Login or Join

Loading...

Ask all programming questions here!

May 16, 2013 at 5:10:51 PM
gliptitude (0)
avatar
(J D) < Crack Trooper >
Posts: 123 - Joined: 02/26/2013
Ohio
Profile

Originally posted by: Shiru

Program before assembling is a text (source code), usually there are many text files with the code, along with files with various binary data, such as graphics sets, music, etc.

Average length is difficult to say, and it depends from programming language, and data storage approach - sometimes part of it is stored as binary, sometimes it is encoded in the source code, various amounts. Anyway, no less than thousand(s), even a simple one-screen logic game could be like 5000 lines of assembly code or 1500-2000 lines of C code.
 

Thanks for this reply Shiru.

Could you possibly explain to me in a conceptual way, how the "many text files with the code" are grouped together? ... Is it eventually all organized in ONE sequential list of commands ("the program")? ... Or is it that there is one core program with occasional instructions to "leave" and go to another, or to "retrieve" information from one of the other "text files"? Or are most of these extra files deposited by the cartridge in memory on the console while the program is running?

Or perhaps it is silly to ask these questions at the outset?

May 16, 2013 at 5:27:42 PM
SUBSCRIBER
GradualGames (39)
avatar
(Derek Andrews) < El Ripper >
Posts: 1050 - Joined: 10/09/2009
Pennsylvania
Profile
Originally posted by: gliptitude


Originally posted by: Shiru

Program before assembling is a text (source code), usually there are many text files with the code, along with files with various binary data, such as graphics sets, music, etc.

Average length is difficult to say, and it depends from programming language, and data storage approach - sometimes part of it is stored as binary, sometimes it is encoded in the source code, various amounts. Anyway, no less than thousand(s), even a simple one-screen logic game could be like 5000 lines of assembly code or 1500-2000 lines of C code.
 

Thanks for this reply Shiru.

Could you possibly explain to me in a conceptual way, how the "many text files with the code" are grouped together? ... Is it eventually all organized in ONE sequential list of commands ("the program")? ... Or is it that there is one core program with occasional instructions to "leave" and go to another, or to "retrieve" information from one of the other "text files"? Or are most of these extra files deposited by the cartridge in memory on the console while the program is running?

Or perhaps it is silly to ask these questions at the outset?

Those are great questions, not silly at all. The answers to them will become more clear over time, but a general answer follows:

It is optional whether a game program is contained all within one text file or multiple text files before assembled into a final binary ROM that the NES or an emulator reads. Neither an emulator nor the NES can know how many text files created it. The only reason multiple text files are ever used is to help the programmer split up their code into logical chunks. You might have a text file that deals with the camera,  a text file that deals with updating all enemies on screen, another to decode the map and perform scrolling, another for generic PPU operations, etc.  It's all about organization.  That leaves a ton of details out, but hopefully helps a little.


It took a bit for another part of your question to sink in. The NES can *potentially* see up to 64kb of ROM or RAM at any given time. However, the way the cartridge pins and memory pins are wired up to the NES, it can usually only see 2kb of RAM (8kb with wram), and up to 32kb of ROM at any given time. That 32KB of ROM is basically where your text files appear, in binary form. It is typically made up of two 16 kb chunks, and depending on the mapper they can be swapped out, like "windows" into the code that originally appeared in your text files.   2kb of ram is on the NES itself, any additional RAM has to be on the cartridge. All of your program code just stays right on the cartridge---and is read directly by the CPU with the help of the mapper on the cartridge, for letting the cpu dig into various 16kb chunks at a time. Again...I probably glossed over a lot of details, but trying to keep my answers as simple as I can.

-------------------------
Creators of: Nomolos: Storming the CATsle, and The Legends of Owlia.


Edited: 05/16/2013 at 05:40 PM by GradualGames

May 16, 2013 at 5:40:31 PM
Mario's Right Nut (350)
avatar
(Cunt Punch) < Bowser >
Posts: 6576 - Joined: 11/21/2008
Texas
Profile
Originally posted by: JKeefe56

I hate to ask something like this, because I feel like it's asking too much. But I'm working on a puzzle game. I can make a level of it, but then I get stuck. Is there anyone willing to write out a code to show me, that would do something like this, just so I can see how it is done?

Just load a background screen and then when a certain button is pressed it loads the next background?

I've gotten stuck here a few times. Or if there's a NN that covers this that I missed, could you point me in that direction?

Basically, you have to create a subroutine that is activated when something happens.  i.e. your score reaches a level, you die, you win, etc. 

Just have it set a flag that allows your subroutine to run.  This routine will switch the game state, load the status screen, clear the variables in the level RAM, and then sit there and wait for you to push Start or something.

Then you push start and it loads the next level, changes the game state, and dumps the player into the next level. 

It is challenging, but you just have to think:  Okay, what did I do to get the first screen to load?  Sprites, background, initilize all the RAM required to run the room, etc.  Do this every friggin' time you load a room or different level, set, death, and stuff. 

It would probably be easier with an example, but I really don't have time to whip up another tutorial right now.  Hope that helps though. 


-------------------------

This is my shiny thing, and if you try to take it off me, I may have to eat you.

Check out my dev blog.


May 16, 2013 at 5:43:13 PM
gliptitude (0)
avatar
(J D) < Crack Trooper >
Posts: 123 - Joined: 02/26/2013
Ohio
Profile
Originally posted by: SegF4ult

Any program, no matter whether it's for a NES, PC, GameBoy or , starts out as flat text. This text is then interpreted by specialized software to build binary files.
An average length for a full game, that's a tricky one. It depends on the algorithms you want to use and how efficiently you can implement them.

All games have at least some structural similarities. It is common to structure a game as follows:
  • Initialize key variables
  • Start a main game loop (loops are important, otherwise execution would halt)
  • Poll controller(s) for input
  • Change variables based on controller input (think sprite placement or something entirely different)
  • Make extra checks, i.e. collision detection, valid input, etc.
There are more things you could add. What is important is that the NES/PC/Whatever gets the time to render the screen at some point. Video timing is critical.

As for optimization and tweaks to work properly on a real NES? It depends on the emulator you're using. No emulator works the same, so what is valid in one emulator could go wrong in the other. What works on an emulator could also fail to work on real hardware.
There are certainly emulators out there that do a really good job of mimicking the real hardware. Chances are, if it runs in that emulator, it'll work on the hardware.

 

This game structure is semi comprehensible to me. ...

With the question of emulation/console disparity I am coming from an experience with Vectrex, in which (someone else's homebrew game) looks PERFECT in an emulator, but VERY DISTORTED on the actual Vectrex. ... It appears to me that this is far less of an issue on NES (and other consoles), and that the NES is working with a much more straightforward paradigm of graphics display and organization. "Tiles" and "scrolling" are kind of a built functionality of this machine. Correct???? I know that Vectrex is a very strange point of reference, but in comparison there seems to be much more of a language and a modular structure to "drawing" the graphics on NES.

You say that "video timing is critical" though, and that time must be allowed for rendering, (if I understand correctly this "time" is tiny fractions of a second, in between other equally brief commands which are constantly being executed and re-executed in a cycle).  ... Is it common that major compromises need to be made to the (NES) game program in order to get it to LOOK the way you want it to?

May 16, 2013 at 5:52:54 PM
gliptitude (0)
avatar
(J D) < Crack Trooper >
Posts: 123 - Joined: 02/26/2013
Ohio
Profile
Originally posted by: GradualGames

It is optional whether a game program is contained all within one text file or multiple text files before assembled into a final binary ROM that the NES or an emulator reads. Neither an emulator nor the NES can know how many text files created it. The only reason multiple text files are ever used is to help the programmer split up their code into logical chunks. You might have a text file that deals with the camera,  a text file that deals with updating all enemies on screen, another to decode the map and perform scrolling, another for generic PPU operations, etc.  It's all about organization.  That leaves a ton of details out, but hopefully helps a little.
 

Awesome succinct answer. Thank you.


May 16, 2013 at 6:09:36 PM
KHAN Games (88)
avatar
(Kevin Hanley) < Master Higgins >
Posts: 7785 - Joined: 06/21/2007
Florida
Profile
Originally posted by: JKeefe56

I hate to ask something like this, because I feel like it's asking too much. But I'm working on a puzzle game. I can make a level of it, but then I get stuck. Is there anyone willing to write out a code to show me, that would do something like this, just so I can see how it is done?

Just load a background screen and then when a certain button is pressed it loads the next background?

I've gotten stuck here a few times. Or if there's a NN that covers this that I missed, could you point me in that direction?

LoadNametable:
  LDA $2002                         ;normal loading routine
  LDA #$20
  STA $2006
  LDA #$00
  STA $2006
SetNametable:
  LDA BG_ptr                        ;BG_ptr is a variable in your zero page which tells the game
  ASL A                                  ;which level you're on.  Everytime you beat a level, increment this.
  TAY
  LDA bkgd_pointer_table, y                 ;pointer table which takes the BG_ptr variable and
  STA AddrLow                                        ;tells it which level data to load.
  LDA bkgd_pointer_table+1, y
  STA AddrHigh

  LDX #$04
  LDY #$00
LoadBackgroundsLoop:
  LDA [AddrLow], y               ;load nametable
  STA $2007                      ;draw tile
  INY                            ;X is 0, so move on to get new counter number
  BNE LoadBackgroundsLoop
;;Outer Loop
  INC AddrHigh
  DEX
  BNE LoadBackgroundsLoop
  RTS

bkgd_pointer_table:  ;;table of addresses for backgrounds.  if BG_ptr is #$00, it will
                                      ;;load the first one.  #$01, the second.  etc
  .dw gamebkgd0   ;;level 0 background
  .dw gamebkgd1   ;;level 1 background
  .dw gamebkgd2   ;;level 2 background
  .dw gamebkgd3   ;;level 3 background
  .dw gamebkgd4   ;;level 4 background
  .dw gamebkgd5   ;;level 5 background
  .dw gamebkgd6   ;;level 6 background
  .dw gamebkgd7   ;;level 7 background
  .dw gamebkgd8   ;;level 8 background
  .dw gamebkgd9   ;;level 9 background
  .dw gamebkgd10  ;;level 10 background
  .dw gamebkgd11  ;;level 11 background
  .dw gamebkgd12  ;;level 12 background
  .dw gamebkgd13  ;;level 13 background
  .dw gamebkgd14  ;;level 14 background
  .dw gamebkgd15  ;;level 15 background

gamebkgd0:  ;a full table of tile numbers that fill up the screen.  you'll need one of these for
                         ;every ".dw" in the pointer table.
    .db $05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05,$05, etc, etc


Edited: 05/16/2013 at 06:11 PM by KHAN Games

May 17, 2013 at 1:15:37 AM
JKeefe56 (55)
avatar
(Jim K) < Meka Chicken >
Posts: 882 - Joined: 12/05/2011
New York
Profile
Khan and MRN, thank you very much for this.

KHAN - The script will be very helpful, I'm sure. I can't wait to implement it. What does dw stand for? I've only ever seen .db before.

MRN - Thank you as well. I think that was what was screwing me up...I kept trying to just re-load images, as opposed to initialize the ram, and doing everything over from the start.

-------------------------
This space intentionally left mostly blank.

May 17, 2013 at 4:11:22 AM
Roth (66)
avatar
(Rob Bryant) < Lolo Lord >
Posts: 1741 - Joined: 09/14/2006
Illinois
Profile
Originally posted by: JKeefe56

What does dw stand for? I've only ever seen .db before.
 

As .db is a byte-sized chunk, .dw is a word sized chunk. 

.db $12 ; 8-bit number

.dw $1234 ; 16-bit number

MOST of the time, as in Kevin's example, it is an address in ROM. Some assemblers have different ways you can have a word-sized numeral for better readability, such as .addr (address):

.addr gamebkgd0   ;;level 0 background
.addr gamebkgd1   ;;level 1 background
.addr gamebkgd2   ;;level 2 background
; etc etc etc

That just depends on the assembler that you end up choosing though.

-------------------------
http://slydogstudios.org...

May 17, 2013 at 4:19:05 AM
acomicbookguyc (343)
avatar
(Cristian Romero ) < Bowser >
Posts: 5853 - Joined: 09/30/2010
California
Profile
What are some classes one could take at say a Community College to get a better idea about programming.

-------------------------
Help me complete my N64 set!
206/296 Carts - 217/296 Manuals - 223/296 Boxes
http://nintendoage.com/index.cfm?...
 

May 17, 2013 at 2:47:30 PM
KHAN Games (88)
avatar
(Kevin Hanley) < Master Higgins >
Posts: 7785 - Joined: 06/21/2007
Florida
Profile
Originally posted by: acomicbookguyc

What are some classes one could take at say a Community College to get a better idea about programming.

I'm sure that varies school to school.  You'd just have to check their curriculum.  I doubt there would be anything directly assembly language related though.


May 17, 2013 at 2:52:39 PM
m308gunner (62)
avatar
(Jason ) < King Solomon >
Posts: 3542 - Joined: 05/07/2012
Connecticut
Profile
Originally posted by: Roth

Originally posted by: JKeefe56

What does dw stand for? I've only ever seen .db before.
 

As .db is a byte-sized chunk, .dw is a word sized chunk. 

.db $12 ; 8-bit number

.dw $1234 ; 16-bit number

MOST of the time, as in Kevin's example, it is an address in ROM. Some assemblers have different ways you can have a word-sized numeral for better readability, such as .addr (address):

.addr gamebkgd0   ;;level 0 background
.addr gamebkgd1   ;;level 1 background
.addr gamebkgd2   ;;level 2 background
; etc etc etc

That just depends on the assembler that you end up choosing though.
  So .dw means Data Word, and .db means Data Byte?



-------------------------
 

May 17, 2013 at 2:58:35 PM
Roth (66)
avatar
(Rob Bryant) < Lolo Lord >
Posts: 1741 - Joined: 09/14/2006
Illinois
Profile
Originally posted by: m308gunner

  So .dw means Data Word, and .db means Data Byte?
 

Sounds about right!

-------------------------
http://slydogstudios.org...

May 17, 2013 at 4:22:37 PM
Mario's Right Nut (350)
avatar
(Cunt Punch) < Bowser >
Posts: 6576 - Joined: 11/21/2008
Texas
Profile
Originally posted by: JKeefe56

Khan and MRN, thank you very much for this.

KHAN - The script will be very helpful, I'm sure. I can't wait to implement it. What does dw stand for? I've only ever seen .db before.

MRN - Thank you as well. I think that was what was screwing me up...I kept trying to just re-load images, as opposed to initialize the ram, and doing everything over from the start.


Don't clear out all the RAM, just the stuff applicable to the rooms.

You can also use:
  .byte
  .word


-------------------------

This is my shiny thing, and if you try to take it off me, I may have to eat you.

Check out my dev blog.


May 18, 2013 at 11:40:17 AM
XYZ (76)
avatar
< King Solomon >
Posts: 3881 - Joined: 03/15/2012
Tennessee
Profile
I am taking a slightly different approach to learning 6502 than jumping right into the Nerdy Nights. I have read the first 4 tutorials but before I move on, I am trying to learn 6502 from scratch. Every book I have skimmed always begins with hex-dec-bin and doing math with these. The next thing covered is explanations of the 7 flags and operand formats, such as indexed direct and immediate. My question is for some of the veterans to tell us what stuff is key and most important to know in 6502. Just so we have an idea what things we need to have a good understanding of. I feel like ASCII code is not useful for NES game making, so I have not spent as much time on it as I have with HEX math. I am hoping for a response that might give us a very skeletal overview of what stuff is integral. Clearly, the 6502 books don't cover sprites, sound, controller input, or anything to make games - it's just about learning the actual language and its concepts.

Also, I am having a hard time with LDA/STA and remembering which does which. Sure, it might be easy for some, but I keep confusing the two. How do you guys go about this? Load the Accumulator and Store the Accumulator. Sound the same but do two completely different things. I hate having to look in my notes every single time. I need "hints" and "tricks" to memorizing key stuff.

Do you guys take notes? Do you write things down in a notebook or do everything using the computer?

Mostly general questions about approaches you take. Not necessarily specifics to a program I am working on. But that's because I haven't started my program yet. Your answers will help me move forward though!!


Edited: 05/18/2013 at 11:42 AM by XYZ

May 18, 2013 at 12:02:05 PM
KHAN Games (88)
avatar
(Kevin Hanley) < Master Higgins >
Posts: 7785 - Joined: 06/21/2007
Florida
Profile
I mostly remember "Load" and "Store" as in you have to "Load" something to change it, and when you're done, you "Store" it when you're done. Like when you go grocery shopping. You store everything away in the cabinets and walk away. I don't really know how else to explain it. Just give it some time.

I think a lot of people that are learning to program are getting hung up on math. I have no idea what %01010101 is in decimal. I have no idea what $E4 is in decimal. When I need to know these things, I open up the Windows calculator, turn it to Hex or Bin, type in the value, then change it to Dec and it converts it for me.

The main thing you're going to have to understand is the various values of addresses on the Nintendo, because you're going to be manipulating them over and over and over.

The nametable you're going to be using 95% of the time is $2000. The sprites you're using will be starting at $0200 (or $0300 depending on where you put them.) The palette is at $3F00. All of these addresses are just things you're going to have to ingrain in your memory, because that's the stuff you're going to be changing.

Other than that, the main thing you're going to have to learn is how certain things are changed and when you can change them. Moving a sprite across the screen can be done at anytime. Changing a tile of the background can only be done in a very short time called Vblank, which sounds complicated, but there's a specific location in your assembly document where all this stuff goes. Eventually if you try to do too much there, it will run out of time and things start blowing up, so you have to be very careful.

I generally don't take notes, but I do have to open up some of the Nerdy Nights tutorials every now and then to remind myself on how to do certain things.

I build my entire games with only these commands haha.

LDA
STA
CMP
BEQ
BNE
BCC
BCS
LDX
CPX
TAX
TXA
LDY
TAY
TYA
CPY
ADC
SBC
JSR
JMP

Well, I guess that's more commands than I thought.  Still seems simple!


Edited: 05/18/2013 at 12:34 PM by KHAN Games

May 18, 2013 at 1:06:51 PM
thefox (0)
avatar
(Kalle Immonen) < Meka Chicken >
Posts: 533 - Joined: 07/08/2008
Finland
Profile
Originally posted by: XYZ

Also, I am having a hard time with LDA/STA and remembering which does which. Sure, it might be easy for some, but I keep confusing the two. How do you guys go about this? Load the Accumulator and Store the Accumulator.
If you really need to, write it down on a sticky note (either a virtual one or a real one): "LDA: Load from memory to A, STA: Store from A to memory". You will without a doubt learn it by heart after using it for a a couple of weeks.

As for hexadecimal and other numbering systems, I agree with KHAN. The most important thing is to understand that all of the numbering systems are just different representations for the same number. It's also useful to understand some relations between them, for example the fact that a hexadecimal digit (0 through F) corresponds to 4 binary digits (bits) (e.g. $F = %1111). But don't get hung up with conversions.

-------------------------
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

May 18, 2013 at 2:49:55 PM
DoNotWant (1)

(Ham Sammich) < Eggplant Wizard >
Posts: 440 - Joined: 12/08/2011
Sweden
Profile
Originally posted by: KHAN Games

Moving a sprite across the screen can be done at anytime.


Really? I thought you updated the sprite RAM and then used DMA in the VBLANK.
Can you use writes to $2003/4 outside NMI?

-------------------------
 

May 18, 2013 at 3:32:55 PM
KHAN Games (88)
avatar
(Kevin Hanley) < Master Higgins >
Posts: 7785 - Joined: 06/21/2007
Florida
Profile
All you'd be doing is changing the value of $0300/$0303 (or whatever sprite you're moving), so yes, that can be done anytime.

May 18, 2013 at 3:39:46 PM
DoNotWant (1)

(Ham Sammich) < Eggplant Wizard >
Posts: 440 - Joined: 12/08/2011
Sweden
Profile
Sorry, I was just nitpicking.
I meant, the sprites aren't actually changed when you change the sprite RAM.
But it is easy as changing it anytime you want, since you can just DMA one RAM page to the sprite OAM.

Or am I wrong here?

-------------------------
 

May 18, 2013 at 5:05:16 PM
KHAN Games (88)
avatar
(Kevin Hanley) < Master Higgins >
Posts: 7785 - Joined: 06/21/2007
Florida
Profile
Originally posted by: DoNotWant

Sorry, I was just nitpicking.
I meant, the sprites aren't actually changed when you change the sprite RAM.
But it is easy as changing it anytime you want, since you can just DMA one RAM page to the sprite OAM.

Or am I wrong here?

Oh, I see what you're saying.  Yes, if you're being nitpicky about it you are correct.  I'm just trying to explain things to people who have no idea what you're talking about (most people reading this thread).


May 18, 2013 at 5:07:46 PM
thefox (0)
avatar
(Kalle Immonen) < Meka Chicken >
Posts: 533 - Joined: 07/08/2008
Finland
Profile
Originally posted by: DoNotWant

Sorry, I was just nitpicking.
I meant, the sprites aren't actually changed when you change the sprite RAM.
But it is easy as changing it anytime you want, since you can just DMA one RAM page to the sprite OAM.

Or am I wrong here?
That's correct. (Calling it "sprite RAM" is misleading though, better call it something like "shadow OAM" or "shadow sprite RAM" instead because "sprite RAM" is usually used to refer to the 256 byte sprite RAM that's inside the PPU).

-------------------------
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

May 18, 2013 at 5:24:55 PM
DoNotWant (1)

(Ham Sammich) < Eggplant Wizard >
Posts: 440 - Joined: 12/08/2011
Sweden
Profile
Sorry.

I have a question. Is it common to interpret a value as a 2's complement signed number,
and use the negative values for left movement and positive values for right movement?
Could you then get away with just adding a value to the sprite's X value every time you move?
You know, instead of having to branch and subtract if you want to move left?
If this is a good idea, some example code would be appreciated.

An example or explanation of sub-pixel movement would also be nice.

I hope I'm making sense, thanks!

-------------------------
 

May 18, 2013 at 5:26:54 PM
DoNotWant (1)

(Ham Sammich) < Eggplant Wizard >
Posts: 440 - Joined: 12/08/2011
Sweden
Profile
Originally posted by: thefox

Originally posted by: DoNotWant

Sorry, I was just nitpicking.
I meant, the sprites aren't actually changed when you change the sprite RAM.
But it is easy as changing it anytime you want, since you can just DMA one RAM page to the sprite OAM.

Or am I wrong here?
That's correct. (Calling it "sprite RAM" is misleading though, better call it something like "shadow OAM" or "shadow sprite RAM" instead because "sprite RAM" is usually used to refer to the 256 byte sprite RAM that's inside the PPU).
Ok, I will remember that, kiitos!



-------------------------
 

May 18, 2013 at 6:09:43 PM
thefox (0)
avatar
(Kalle Immonen) < Meka Chicken >
Posts: 533 - Joined: 07/08/2008
Finland
Profile
Originally posted by: DoNotWant

I have a question. Is it common to interpret a value as a 2's complement signed number,
and use the negative values for left movement and positive values for right movement?
Yes.

Originally posted by: DoNotWant

Could you then get away with just adding a value to the sprite's X value every time you move?
You know, instead of having to branch and subtract if you want to move left?
An example or explanation of sub-pixel movement would also be nice.
Yes. Basically your signed number would be the X velocity here.

To get sub-pixel movement you would make the velocity a fixed point number, for example 8.8 fixed point (8 bits for the whole part, 8 bits for the fractional part, 16 bits total). The position also needs a fractional part, so you would make that a fixed point number as well.

Then just add the velocity to the object position on every frame, and modify the velocity depending on which direction you want the object to move. If you add a constant value to velocity on every frame, you get acceleration/deceleration.

-------------------------
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi

May 18, 2013 at 9:12:57 PM
SUBSCRIBER
GradualGames (39)
avatar
(Derek Andrews) < El Ripper >
Posts: 1050 - Joined: 10/09/2009
Pennsylvania
Profile
Originally posted by: XYZ

I am taking a slightly different approach to learning 6502 than jumping right into the Nerdy Nights. I have read the first 4 tutorials but before I move on, I am trying to learn 6502 from scratch. Every book I have skimmed always begins with hex-dec-bin and doing math with these. The next thing covered is explanations of the 7 flags and operand formats, such as indexed direct and immediate. My question is for some of the veterans to tell us what stuff is key and most important to know in 6502. Just so we have an idea what things we need to have a good understanding of. I feel like ASCII code is not useful for NES game making, so I have not spent as much time on it as I have with HEX math. I am hoping for a response that might give us a very skeletal overview of what stuff is integral. Clearly, the 6502 books don't cover sprites, sound, controller input, or anything to make games - it's just about learning the actual language and its concepts.

Also, I am having a hard time with LDA/STA and remembering which does which. Sure, it might be easy for some, but I keep confusing the two. How do you guys go about this? Load the Accumulator and Store the Accumulator. Sound the same but do two completely different things. I hate having to look in my notes every single time. I need "hints" and "tricks" to memorizing key stuff.

Do you guys take notes? Do you write things down in a notebook or do everything using the computer?

Mostly general questions about approaches you take. Not necessarily specifics to a program I am working on. But that's because I haven't started my program yet. Your answers will help me move forward though!!

The more code you write, it'll become more clear. Maybe try to come up with metaphors for yourself. I probably take it for granted, but I think of the accumulator as like, your workspace. LDA puts a number on your workspace. STA, "stores" something that had been on your workspace (but leaves a copy there) when you're done with what you had been working on. Not sure if that helps.

When I first did NES code, I had had some x86 background but had to look things up quite a bit to get a hang of 6502. New assembly languages will have a different feel but will use the same concepts, if that makes sense. Once you know binary, hex, bitwise operations, branches, addressing modes, 2's complement....etc. you can pick up any assembly language. Basically just keep at it.

It's hard to gain so much fluency in assembly language that you don't have to sketch something out "in pseudo code" first. I'm starting to get almost that comfortable with 6502, after one game and now working on another, but usually I have my devlog up while working, and I think "out loud" into my text document for quite a while before coding something. I usually break it down into lots of tiny chunks and work on them one at a time. I definitely wouldn't fit the stereotypical thought of "guy staying up late hammering out code at a million miles an hour" heck, sometimes I sit and think and write in my devlog and just sit there..for a long time, before actually coding anything. Even now, it is a slow process. I have no idea if this is normal or not, or if there are some folks out there who can do it way more efficiently, but....I'm able to do it and I'm happy I'm doing it.  I guess that's why I feel so compelled to get others into it or help out somehow. I know I'm not a genius, I just realllly want to do this stuff, even if I'm slow as moles' asses in january at it.

-------------------------
Creators of: Nomolos: Storming the CATsle, and The Legends of Owlia.


Edited: 05/18/2013 at 09:13 PM by GradualGames