I am not good with english, so excuse me. (
Sometimes, I could be a little clowny in the comment.)
I just figured out on converting .C files into .ASM files using ASM6 I just got now by dragging the .C file onto the program, ASM6. I feel like I'm getting closer on making .NES files, but I'm not sure anymore.
What do I do with the .ASM files now? I'm a little lost now.
I'm not sure dragging .ASM files onto ASM6 would work also.
Ignore this: I just now got time to do NES stuffs, and I need to put list in here to remind me what I need for NES making and to catch up and remember what I need to do and stuff.
-Graphics and sprite making: YY-CHR (Latest versions.)
-Background, scene, and stage making: PRG-ROM Pattern Editor (Can get it in same site as YY-CHR.)
-Music: FAMITRACKER!
***Code:
Place to write: ConTEXT
ASM: ???
___
___
Huh? You don't turn .c to .asm, you compile .C into a .NES file. Same with assembly. You should look up batch (or bash for Linux) and how command line programs work, and then look at the readme of the programs you use on how to use them.
The only file I got is "exe" and "php" so, there's no readme file.
And I don't understand some of them; I'm not good with english, so the manual on the Command Prompt barely help on me.
does it obey if I put down C:\Users\JOHN\>any letter it ask like c or chr
or something like C:\Users\JOHN\>any symbols like "-" before the letter
I recommend you get familiar with the Windows Command Prompt (
cmd.exe). Here are some resources:
http://www.bleepingcomputer.com/tutoria ... roduction/http://pcsupport.about.com/od/termsc/p/ ... prompt.htmThe syntax you want is
asm6 file.asm file.nes.
You'll need to make sure your .asm file has the necessary bits/pieces to make the
16-byte .NES header and so on.
P.S. -- You do not drag-drop files onto
asm6.exe, and you
especially do not drag-drop .c files onto it (asm6 is an assembler, not a compiler -- it understands 6502 assembly, not C!).
Look it up in your native language then. Or google translate the page.
Yeah, the .exe somewhere has a readme that will describe the command line arguments you pass to it in what order and such...I don't know how else to help, you have to go find it. We can explain here, but it would take so long it's just a burden really...we do it so often.
caramelpuffpuff wrote:
I just figured out on converting .C files into .ASM files using ASM6 I just got now by dragging the .C file onto the program, ASM6.
That's not how it works. ASM6 is not capable of handling C source code. If it is generating an ASM file for whatever reason, it's probably a garbage file and not an actual convertion of the C program to ASM.
It's very unclear what you are trying to accomplish.
A lot of people get started in NES programming by following this tutorial. Maybe it will help you:
http://www.nintendoage.com/pub/faq/NA/nerdy_nights_out.html
rainwarrior wrote:
It's very unclear what you are trying to accomplish.
A lot of people get started in NES programming by following this tutorial. Maybe it will help you:
http://www.nintendoage.com/pub/faq/NA/nerdy_nights_out.htmlI'm trying to figure out on how to convert C. file to NES. file (and maybe convert ASM. to NES. that is working instead of gray-background), whichever one is better/easier.
You cannot easily use the C programming language on the NES. It's too small/limited of a platform for most things. Stick with assembly. I
said the same thing in another thread recently as well, where the person trying to use the C code is already running into issues. :P
Furthermore (as I said above), asm6 is an assembler, not a compiler; it does not understand C code, it only understands 6502 assembly.
koitsu wrote:
You cannot easily use the C programming language on the NES. It's too small/limited of a platform for most things. Stick with assembly. I
said the same thing in another thread recently as well, where the person trying to use the C code is already running into issues.
Furthermore (as I said above), asm6 is an assembler, not a compiler; it does not understand C code, it only understands 6502 assembly.
(Awwwwwwwwwwwwwwww.) I see. So, 6502 assembly code is perfect for it, not "C".
What's the difference between compiler and assembler? Is compiler ""C" assembler" while assembler is "6502 assembler"?
koitsu wrote:
Oh. ASM. is 6502 code.
There is a C compiler for 6502/NES and many of us here use it:
http://www.cc65.org/The words you are using still makes it hard to understand what your goal is. Please explain more about what you are trying to do. Be specific about it, not general/vague. What kind of C program do you have? Who wrote it? Where did it come from?
Compiling a C program is not a simple matter of "converting C to binary". To make your NES ROM from it you will need a specific compiler, and a specific build process. This information should be included with the C source files you have, hopefully. If you are starting from scratch, why don't you try
Shiru's Tutorial?
caramelpuffpuff wrote:
What's the difference between compiler and assembler?
Compilers make executable binaries out of code written in high-level languages (C, BASIC, Pascal, etc.), while assemblers make executable binaries out of code written in assembly language. Assembly language programs consist of direct CPU instructions, so assemblers basically convert written instructions into the binary equivalent of that text. Compilers are more complex, since high-level languages are more abstract and need a lot of processing in order to be converted to CPU instructions.
Back when the NES was still supported by Nintendo, there were no good 6502 C compilers, so all games were coded in ASM. Nowadays there are a couple of decent C compilers, but I believe it's still somewhat hard to get good code out of them. I have the impression that a person has to have a good understanding of the NES platform before being able to program it in C, wich makes it kinda hard for newbies to start out that way.
You should probably try the Nerdy Nights tutorials first, to get an idea of how things work. If you are already comfortable with C, you can then try coding something in C after you get the hang of the basics. If you don't already know C, you should probably stick to assembly all the way.
rainwarrior wrote:
There is a C compiler for 6502/NES and many of us here use it:
http://www.cc65.org/The words you are using still makes it hard to understand what your goal is. Please explain more about what you are trying to do. Be specific about it, not general/vague. What kind of C program do you have? Who wrote it? Where did it come from?
Compiling a C program is not a simple matter of "converting C to binary". To make your NES ROM from it you will need a specific compiler, and a specific build process. This information should be included with the C source files you have, hopefully. If you are starting from scratch, why don't you try
Shiru's Tutorial?
http://www.youtube.com/watch?v=pgRKkL_etOQ When I saw this, I got ConTEXT, so
the C program I have is ConTEXT (My apologize, I'm still learning english.)
The source for this is http://www.contexteditor.org/ I'm guessing "ConTEXT project" wrote it, seems like an independant developer. I install 6502 Assembly to ConTEXT, but now, I'm not sure which is easier; C or 6502. Long story short;
I am trying to figure out on how to change C./ASM. into an NES. without any "Gray background" or "Error, can't open on Fecux" stuff, which, for now, is my goal. I got ASM6, CC65, and ConTEXT.
Context is just a text editor, it does NOTHING to help you to get a .NES file more than Notepad would. Like said, you have to write program in C or assembly, and run it through the right programs (CC65/ASM6) for it to look at the program and process it to a .NES ROM with the program you wrote in the file. Even if this happens, you have to write the code 100% right to get any results even with the right compiler/assembler. You should read on different assemblers/compilers to understand how they work, as it seems you don't even understand what tool you need, let alone how to use it!
AFAIK, ConTEXT is a context sensitive text editor, that helps you with writing your codes. Having just an editor won't make you eligible in writing stuff for a specific system immediately and you still need to learn how to code for it (which I suppose those youtube videos are for). Getting the (C-) source codes to that particular text editor wouldn't help either, unless you need to compile the editor yourself, or do you want to compile ConTEXT into a NES rom? But why?
If you just want to make games just follow those tutorials people suggested. People normally enter codes with text editors and any text editors will do, then parse the source text files with compilers or assemblers to get executables or roms. ConTEXT is just one of these text editors, and it has syntax highlighting that helps you with coding. That's it.
edit: Ninja'd by 3gengames.
3gengames wrote:
Context is just a text editor, it does NOTHING to help you to get a .NES file more than Notepad would. Like said, you have to write program in C or assembly, and run it through the right programs (CC65/ASM6) for it to look at the program and process it to a .NES ROM with the program you wrote in the file. Even if this happens, you have to write the code 100% right to get any results even with the right compiler/assembler. You should read on different assemblers/compilers to understand how they work, as it seems you don't even understand what tool you need, let alone how to use it!
Awwww. Well, I want to test it by using the sample of .ASM game-files with ASM6...to see if I got the right file for me...Not sure if I'm explaining it right.
Keep in mind that even if a file has the .ASM extension that doesn't mean that you can use any assembler with it. For example, source code written for NESASM will have some commands that ASM6 doesn't understand, and vice-versa. You need to know what assembler the programmer was targeting when he wrote the program, and use that assembler.
tokumaru wrote:
Keep in mind that even if a file has the .ASM extension that doesn't mean that you can use any assembler with it. For example, source code written for NESASM will have some commands that ASM6 doesn't understand, and vice-versa. You need to know what assembler the programmer was targeting when he wrote the program, and use that assembler.
Oh muffins. -___-;
I guess I'll try to make a demo and explain what I did. In the 6502 assembly, does all the letters like "STA" and "LDA" must me capitalized?
(I understand it...but now I have to figure out making a picture of myself, and do something that convert that code into the NES. so I could give the record and hypothesis on it and how I do it and what happens now.)
caramelpuffpuff wrote:
I guess I'll try to make a demo and explain what I did.
Yes, the best thing is to start with something simple, like setting some colors and writing something on the screen.
Quote:
In the 6502 assembly, does all the letters like "STA" and "LDA" must me capitalized?
That's one of the things that can change from assembler to assembler, but most current assemblers should accept lower-case as well as upper-case instructions.
tokumaru wrote:
caramelpuffpuff wrote:
I guess I'll try to make a demo and explain what I did.
Yes, the best thing is to start with something simple, like setting some colors and writing something on the screen.
Quote:
In the 6502 assembly, does all the letters like "STA" and "LDA" must me capitalized?
That's one of the things that can change from assembler to assembler, but most current assemblers should accept lower-case as well as upper-case instructions.
Poyo. I'm trying to find a "most recent version" replacement for YY-CHR that doesn't have "cyan" color and that is "black-transparent color" as a default, because mine doesn't have an editor that allows you to make background world or something... FOUND IT!!!
http://www.geocities.jp/yy_6502/yychr/y ... 407_en.zip???..What program convert assembler to .NES?
You don't convert anything. You assemble it. There are lots of assemblers, google "NES assembler" and you'll find some. The popular ones are ASM6, NESASM3, and CA65. They all work in different ways, they all will have information on the features they have in documentation on the site. That's basically ALL there is to it, it's YOUR job to figure everything else out, basically. Most of those will be command line tools, which we showed ya how, but if not then go to Nintendoage and download a nerdy nights file and look at the .bat to see how command line tools are run from a batch file.
And google for YY-Chr 0.98 Beta 2. I believe it's the last one until they went to a MS-generic library and made it into complete trash excuse for a graphics editor.
caramelpuffpuff wrote:
???..What program convert assembler to .NES?
An assembler. The language is "assembly language"; the program that turns it into object code is an "assembler". The popular assemblers here are "asm6" and "ca65". A lot of people find asm6 easier to set up for the first time, but ca65 might be better for large projects once your skills pass a certain point.
Apart from YY-CHR, the other way to draw graphics is to make a BMP or PNG file in GIMP and then use a program to convert that to the CHR format that the NES expects.
tepples wrote:
caramelpuffpuff wrote:
???..What program convert assembler to .NES?
An assembler. The language is "assembly language"; the program that turns it into object code is an "assembler". The popular assemblers here are "asm6" and "ca65". A lot of people find asm6 easier to set up for the first time, but ca65 might be better for large projects once your skills pass a certain point.
Apart from YY-CHR, the other way to draw graphics is to make a BMP or PNG file in GIMP and then use a program to convert that to the CHR format that the NES expects.
Oh. Than ASM6 would be suitable for me now.
Well, I sometimes do that, but I find it more fun doing it on YY-CHR instead of GIMP; even if I use the NES palette for GIMP, it still doesn't feel like I'm making sprite.
"And google for YY-Chr 0.98 Beta 2. I believe it's the last one until they went to a MS-generic library and made it into complete trash excuse for a graphics editor."
Thank you for this one.
(
.....Sooooo lonely. -u-)
A bit off-topic, but I thought I'd ask: caramlepuffpuff, your native tongue isn't English (and that's fine!) -- so what is your first language? This forum is quite diverse language-wise, so possibly there's someone who can speak to you in your native tongue thus help diminish any confusion. :-) Let us know!
koitsu wrote:
A bit off-topic, but I thought I'd ask: caramlepuffpuff, your native tongue isn't English (and that's fine!) -- so what
is your first language? This forum is quite diverse language-wise, so possibly there's someone who can speak to you in your native tongue thus help diminish any confusion.
Let us know!
PM on that.....
caramelpuffpuff wrote:
PM on that.....
If you answer by PM the people that do speak your language won't know!
Wild paranoid guess: "If people know what my parent language is, they'll know where I grew up, and I don't want to give out any more PII than I absolutely have to, especially in a country that tries to suppress homebrew."
caramelpuffpuff, am I allowed to disclose publicly what your native tongue is? I understand your concerns that you mentioned in your PM, but we have had no language (or ethnic/racial) issues on this forum. It's very diverse.
koitsu wrote:
caramelpuffpuff, am I allowed to disclose publicly what your native tongue is? I understand your concerns that you mentioned in your PM, but we have had no language (or ethnic/racial) issues on this forum. It's very diverse.
Sure....
His native tongue is Spanish (as in Mexican Spanish), so if anyone speaks Spanish and can translate more complex things that he might not understand, that'd be awesome. Thanks folks. :-)
Well, that's an easy one! Tons of people here speak Spanish. Still, even if it was something more exotic there would be absolutely no reason to be ashamed. Even though I can't write/speak proper Spanish, I understand it quite well, and will try to help whenever I can.
¡Puedo hablar un poco español tamíen!
Pero yo sólo tomé dos clases de español, entonces lo es muchas mas mal a mis español.
¿Pienso que Tokumaro puede ayudarle, Entonces es bueno?
¡Divertirse!
Nevermind.
I'll just figure it out...
Look, it's clear you are pretty lost. It seems you didn't get how NES programming works yet, and it's unlikely you'll figure it out by yourself.
The thing is, an .ASM file isn't "converted" to an .NES in the same way that a .BMP file can be converted to .PNG. BMP and PNG are well documented data formats that follow certain standards. But .ASM and .NES are programs (meaning they can contain pretty much anything!), and depending on the assembler used, the .ASM file will have to follow different standards.
The best thing you can do right now is follow a tutorial, so that you can get the basic idea of how things work. Try the Nerdy Nights tutorial that has already been suggested, and use the same tools that the author used. Once you understand how the program you write can become a ROM file, you might try different things. There's no point in trying to do something by yourself if you don't even know where to begin.
.ASM is a text representation to describe what the CPU has to do for the programmer. The programmer understands it and can change as necessary. .NES is that text translated into what CPU can understand, the CPU does not understand that text, it is completely alien to it. It is like English vs Spanish, one really does not understand the other, until its translated. Assembler is the program that does the translation.
TmEE wrote:
Assembler is the program that does the translation.
...however, there are different "dialects" of assembly, so not all assemblers will understand all .ASM files.
Right, I completely missed that part ^^
Different CPUs "speak" in different languages/dialects and don't usually understand each other.
TmEE wrote:
Different CPUs "speak" in different languages/dialects and don't usually understand each other.
Heh, I'd say that different CPUs often use completely different assembly languages... What I meant by "dialects" is that an .ASM file written for ASM6 won't assemble in NESASM without at least some modifications, even though both work with 6502 code.
tokumaru wrote:
TmEE wrote:
.ASM is a text representation to describe what the CPU has to do for the programmer. The programmer understands it and can change as necessary. .NES is that text translated into what CPU can understand, the CPU does not understand that text, it is completely alien to it. It is like English vs Spanish, one really does not understand the other, until its translated. Assembler is the program that does the translation.
...however, there are different "dialects" of assembly, so not all assemblers will understand all .ASM files.
Ooooh, I get most of it.
_______
...Testing. Okay good.
Now, I want to test it by drawing a picture of myself. (
I am so cute. Am I? >w<)
Most assemblers have an
INCBIN command you can use to
INClude
BINary files. At the correct location in your ASM file (usually the very end) you can write this:
Code:
.incbin "graphics.chr"
This won't magically make tiles appear on the screen when you run the ROM though, you have to write a program that will put these tiles in the background.
tokumaru wrote:
Most assemblers have an
INCBIN command you can use to
INClude
BINary files. At the correct location in your ASM file (usually the very end) you can write this:
Code:
.incbin "graphics.chr"
This won't magically make tiles appear on the screen when you run the ROM though, you have to write a program that will put these tiles in the background.
DISASM6 is a
disassembler, it's meant to convert binary programs into ASM code, the exact opposite of what you want.
Also, you are blindly writing stuff in the command prompt! The ".incbin" line is supposed to be written inside an ASM file, which then needs to be compiled. But like I said before, just including it won't do anything unless you write the code to use those tiles.
I'll be honest with you: You are really, really, REALLY lost, you have absolutely no idea what you're doing. Nothing you're trying makes ANY sense. Programming isn't something you guess. You can't just download a bunch of programs and type random stuff hoping it will work. You have to study!
We have suggested several times that you follow
this tutorial. Please stop guessing and read this. Believe me, NES programming isn't like Photoshop, which you can poke around and learn by yourself, you won't learn NES programming like this.
I still don't get it.
I read those BunnyBoy stuff, and I can't seem to get it working. I read the "Commands Prompt" tutorial, and I don't understand.
You'll need to run "c:\users\whoever\documents\nes maker files\asm6.exe" "c:\users\whoever\documents\nes maker files\input.asm" "c:\users\whoever\documents\nes maker files\output.nes"
Which is to say you'll need to make a file "input.asm" using something like notepad or any other plain text editor.
In that file you put the commands, like ".incbin"
lidnariq wrote:
You'll need to run "c:\users\whoever\documents\nes maker files\asm6.exe" "c:\users\whoever\documents\nes maker files\input.asm" "c:\users\whoever\documents\nes maker files\output.nes"
Which is to say you'll need to make a file "input.asm" using something like notepad or any other plain text editor.
In that file you put the commands, like ".incbin"
By making file, "input.asm" does it also work on ConTEXT? And then what?
By command, like
"c:\users\whoever\documents\nes maker files\asm6.exe"".incbin"? Do I have to put " " everytime I want to command the ASM?
The output.nes means any NES that is blank?
(Gosh, I'm terrible at vocabulary...)
The .incbin command goes inside a source code file.
Have you ever written a program in any other programming language?
tepples wrote:
The .incbin command goes inside a source code file.
Have you ever written a program in any other programming language?
I don't think so... I read a lot of tutorials about ASM and CMD, and I still can't understand some of those...
OK, here are the steps for creating a valid NES ROM with ASM6:
1. Go to
this post and copy the NROM template;
2. Open Notepad and paste the code you copied;
3. In the last line, change "tiles.chr" to the name of your CHR file;
4. Save the file as "game.asm" to the same folder where ASM6 and the CHR file are;
5. Open another Notepad window ans write the following in it:
Code:
asm6 game.asm game.nes
pause
6. Save this as "compile.bat", in the same folder as the other files;
7. double click "compile.bat";
OBS: When saving files from Notepad, make sure to select (*.*) in the type field, otherwise it may end up putting ".txt" after the file names, and then it won't work.
This should open a command prompt window, but you don't have to type anything in it, because it will automatically execyte the command that are written inside the .bat file. The "pause" command is there to prevent the window from closing before you can see any messages the assembler outputs.
Anyway, after this you will get a valid NES file, but it won't do anything because there's no code to do anything, since the template was blank. You will need to write 6502 code to initialize the system and display something (tip: this code will go right after the "Reset" label, which is where the program begins - don't bother with NMI and IRQ for now). At least you have a place to start now.
tokumaru wrote:
OK, here are the steps for creating a valid NES ROM with ASM6:
1. Go to
this post and copy the NROM template;
2. Open Notepad and paste the code you copied;
3. In the last line, change "tiles.chr" to the name of your CHR file;
4. Save the file as "game.asm" to the same folder where ASM6 and the CHR file are;
5. Open another Notepad window ans write the following in it:
Code:
asm6 game.asm game.nes
pause
6. Save this as "compile.bat", in the same folder as the other files;
7. double click "compile.bat";
OBS: When saving files from Notepad, make sure to select (*.*) in the type field, otherwise it may end up putting ".txt" after the file names, and then it won't work.
This should open a command prompt window, but you don't have to type anything in it, because it will automatically execyte the command that are written inside the .bat file. The "pause" command is there to prevent the window from closing before you can see any messages the assembler outputs.
Anyway, after this you will get a valid NES file, but it won't do anything because there's no code to do anything, since the template was blank. You will need to write 6502 code to initialize the system and display something (tip: this code will go right after the "Reset" label, which is where the program begins - don't bother with NMI and IRQ for now). At least you have a place to start now.
Attachment:
aww.PNG [ 48.06 KiB | Viewed 2304 times ]
Do I have to replace "game.asm" with the file?
caramelpuffpuff wrote:
Do I have to replace "game.asm" with the file?
Precisely. You should either rename "gametest.asm" to "game.asm", or edit compile.bat to use "gametest" instead of "game"
lidnariq wrote:
caramelpuffpuff wrote:
Do I have to replace "game.asm" with the file?
Precisely. You should either rename "gametest.asm" to "game.asm", or edit compile.bat to use "gametest" instead of "game"
Attachment:
File comment: ...Muffins?!
WHAT THE....PNG [ 13.9 KiB | Viewed 2297 times ]
O3O...!?
..."Anyway, after this you will get a valid NES file, but it won't do anything because there's no code to do anything, since the template was blank. You will need to write 6502 code to initialize the system and display something (tip: this code will go right after the "Reset" label, which is where the program begins - don't bother with NMI and IRQ for now). At least you have a place to start now."
...
Uhh...So this is where I start now...
Yep, that's what it shows when you don't do anything to the system. You have to wait for the PPU to be ready, set it up, display graphics, and then make a game.
But at least you have some structure to work on now (a valid NES ROM with a 16 byte header, 16KB PRG-ROM and 8KB CHR-ROM = 24592 bytes), which you couldn't figure out before. Your tiles are there, ready to be used by the program. You should now look into how to
initialize the system (tip: don't just copy and paste it - it might not even work because of assembler differences! - try to understand what's going on), setting palettes and showing some tiles.
tokumaru wrote:
But at least you have some structure to work on now (a valid NES ROM with a 16 byte header, 16KB PRG-ROM and 8KB CHR-ROM = 24592 bytes), which you couldn't figure out before. Your tiles are there, ready to be used by the program. You should now look into how to
initialize the system (tip: don't just copy and paste it - it might not even work because of assembler differences! - try to understand what's going on), setting palettes and showing some tiles.
......
Uhhh....can you write the steps like you did on the ASM?
caramelpuffpuff wrote:
......
Uhhh....can you write the steps like you did on the ASM?
Not without doing all the work for you... you won't learn anything this way.
tokumaru wrote:
caramelpuffpuff wrote:
......
Uhhh....can you write the steps like you did on the ASM?
Not without doing all the work for you... you won't learn anything this way.
true...what is @vblankwait1 and 2? Do I put this in a notepad and convert it into ASM.? or bat.?
In asm6 and ca65, a label whose name starts with with @ is a "cheap local label" that can't be seen across regular labels. This allows reuse of label names such as "loop" in different parts of a single program.
In the asm6 manual, loopy wrote:
Labels are case sensitive. The special '$' label holds the current program address. Labels beginning with '@' are local labels. They have limited scope, visible only between non-local labels. Names of local labels may be reused.
Likewise, the
ca65 manual has a section on cheap local labels.
Code:
label1:
; stuff
@loop:
; stuff
dey
bne loop ; goes to the @loop below label1; can't see @loop below label2
label2:
; ...
@loop:
; stuff
dey
bne loop ; goes to the @loop below label2; can't see @loop below label1
Yes, you do put the init code in Notepad.
caramelpuffpuff wrote:
tokumaru wrote:
caramelpuffpuff wrote:
......
Uhhh....can you write the steps like you did on the ASM?
Not without doing all the work for you... you won't learn anything this way.
true...what is @vblankwait1 and 2? Do I put this in a notepad and convert it into ASM.? or bat.?
First, learn what the hell 6502 assembly is. Once yo understand 6502 programming ideas,read the wiki. It will have ALL questions answered there.
But it's to wait for the PPU to warm up. You can not write to it before the 2 vblanks, so we wait for those and do other initialization.
tepples wrote:
In asm6 and ca65, a label whose name starts with with @ is a "cheap local label" that can't be seen across regular labels. This allows reuse of label names such as "loop" in different parts of a single program.
In the asm6 manual, loopy wrote:
Labels are case sensitive. The special '$' label holds the current program address. Labels beginning with '@' are local labels. They have limited scope, visible only between non-local labels. Names of local labels may be reused.
Likewise, the
ca65 manual has a section on cheap local labels.
Code:
label1:
; stuff
@loop:
; stuff
dey
bne loop ; goes to the @loop below label1; can't see @loop below label2
label2:
; ...
@loop:
; stuff
dey
bne loop ; goes to the @loop below label2; can't see @loop below label1
Yes, you do put the init code in Notepad.
Oooh.
Okay...I got the init code in ConTEXT (initializer.asm), I copy the game.nes to another folder in case if I "put the wrong ingrediants" in it...
At this point, you shouldn't have multiple .asm files, that would just complicate things. Once you know what you are doing, it is a good idea to separate code in different files, but not now.
Everything goes into game.asm. You have to put the init code right after the "Reset" label, like I told you before. Are you even paying attention or did you completely ignore that? If you want to be a programmer, you have to pay attention to detail, if you keep letting things slip like this you won't go very far.
tokumaru wrote:
At this point, you shouldn't have multiple .asm files, that would just complicate things. Once you know what you are doing, it is a good idea to separate code in different files, but not now.
Everything goes into game.asm. You have to put the init code right after the "Reset" label, like I told you before. Are you even paying attention or did you completely ignore that? If you want to be a programmer, you have to pay attention to detail, if you keep letting things slip like this you won't go very far.
I am trying hard to pay attention, but I think way too different, and every time I "understand", I perform things that isn't the correct way. I'm not like one of those "common sence" person; that's why I'm terrible at explaining things...
You told me to initialize the system, and setting palettes and showing some tiles. I didn't understand if the code should be in the same asm. or in the completely new file, so I thought if I should've make a new ASM. files for the initializer, until now you told me that everything goes in the ASM. files that contains valid NES files...
Sounds like you need to step back, and read on what you don't understand. Trying to perform actions with something you don't understand...how will you ever perform them correctly? You won't.
incbin just includes binary data into the location. Include includes a new source (.asm program) file to also add to it. And that's basically it. just gotta add the code to do everything. The initialization of the system is on the Wiki, or some of it should be.
You should probably ready the Nerdy Nights to learn the harware of the NES:
http://www.nintendoage.com/pub/faq/NA/n ... s_out.html
caramelpuffpuff wrote:
I didn't understand if the code should be in the same asm.
In
this post I said that the initialization code should be right after the "Reset" label, and this label is in the template you copied, so I assumed you'd realize it should be in the same file.
tokumaru wrote:
caramelpuffpuff wrote:
I didn't understand if the code should be in the same asm.
In
this post I said that the initialization code should be right after the "Reset" label, and this label is in the template you copied, so I assumed you'd realize it should be in the same file.
Attachment:
umm.PNG [ 33.38 KiB | Viewed 2511 times ]
I'm still reading it twice on http://www.nintendoage.com/forum/messag ... eadid=4440 , and I still forget it somewhat easily. I'm trying hard...I even have to look the dictionary to some words...
Looks like progress to me. You understand why we're doing all that? Also, you may or may not want to clear all your RAM first, just to make sure.
3gengames wrote:
Looks like progress to me. You understand why we're doing all that? Also, you may or may not want to clear all your RAM first, just to make sure.
Well...this is what the words it looks like:
(The bold is the one that is changed)
;----------------------------------------------------------------
; constants
;----------------------------------------------------------------
PRG_COUNT = 1 ;1 = 16KB, 2 = 32KB
MIRRORING = %0001 ;%0000 = horizontal, %0001 = vertical, %1000 = four-screen
;----------------------------------------------------------------
; variables
;----------------------------------------------------------------
.enum $0000
;NOTE: declare variables using the DSB and DSW directives, like this:
;MyVariable0 .dsb 1
;MyVariable1 .dsb 3
.ende
;NOTE: you can also split the variable declarations into individual pages, like this:
;.enum $0100
;.ende
;.enum $0200
;.ende
;----------------------------------------------------------------
; iNES header
;----------------------------------------------------------------
.db "NES", $1a ;identification of the iNES header
.db PRG_COUNT ;number of 16KB PRG-ROM pages
.db $01 ;number of 8KB CHR-ROM pages
.db $00|MIRRORING ;mapper 0 and mirroring
.dsb 9, $00 ;clear the remaining bytes
;----------------------------------------------------------------
; program bank(s)
;----------------------------------------------------------------
.base $10000-(PRG_COUNT*$4000)
Reset:
sei ; ignore IRQs
cld ; disable decimal mode
ldx #$40
stx $4017 ; disable APU frame IRQ
ldx #$ff
txs ; Set up stack
inx ; now X = 0
stx $2000 ; disable NMI
stx $2001 ; disable rendering
stx $4010 ; disable DMC IRQs
; Optional (omitted):
; Set up mapper and jmp to further init code here.
; Clear the vblank flag, so we know that we are waiting for the
; start of a vertical blank and not powering on with the
; vblank flag spuriously set
bit $2002
; First of two waits for vertical blank to make sure that the
; PPU has stabilized
@vblankwait1:
bit $2002
bpl @vblankwait1
; We now have about 30,000 cycles to burn before the PPU stabilizes.
; One thing we can do with this time is put RAM in a known state.
; Here we fill it with $00, which matches what (say) a C compiler
; expects for BSS. Conveniently, X is still 0.
txa
@clrmem:
sta $000,x
sta $100,x
sta $300,x
sta $400,x
sta $500,x
sta $600,x
sta $700,x ; Remove this if you're storing reset-persistent data
; We skipped $200,x on purpose. Usually, RAM page 2 is used for the
; display list to be copied to OAM. OAM needs to be initialized to
; $EF-$FF, not 0, or you'll get a bunch of garbage sprites at (0, 0).
inx
bne @clrmem
; Other things you can do between vblank waits are set up audio
; or set up other mapper registers.
@vblankwait2:
bit $2002
bpl @vblankwait2 ;NOTE: initialization code goes here
NMI:
;NOTE: NMI code goes here
IRQ:
;NOTE: IRQ code goes here
;----------------------------------------------------------------
; interrupt vectors
;----------------------------------------------------------------
.org $fffa
.dw NMI
.dw Reset
.dw IRQ
;----------------------------------------------------------------
; CHR-ROM bank
;----------------------------------------------------------------
.incbin "NewFileaa.chr"
___
And to be honest...I somewhat don't understand what to do next...
aaaaand....maybe a little; to encourage me to do things independant?
You can do a LDA #$FF STA $200,X to write FF to the $200 page, just putting that in there.
3gengames wrote:
You can do a LDA #$FF STA $200,X to write FF to the $200 page, just putting that in there.
o-o........Uhhh...
LDA: the color palette.
STA: the location pixel....
"X to write FF to the $200 page"
is the "$200" the beginning of the location-screen? The "top-left" location of the screen?
caramelpuffpuff wrote:
is the "$200" the beginning of the location-screen? The "top-left" location of the screen?
No, $200 is the place where most people write their sprite attributes before uploading the to them PPU.
The CPU doesn't have direct access to the video memory, so you can't just STA to the location where you want a tile to be. The CPU communicates with the PPU through two memory mapped registers. One of them is used to tell the PPU which video memory address you'll be accessing, and the other is used to send/receive data. So, to put tile number 7 at the top left corner of the screen, you'd do this:
Code:
;tell the CPU we'll write something to address $2000 in VRAM
lda #$20
sta $2006
lda #$00
sta $2006
;write the tile index there
lda #$07
sta $2007
This alone won't give you any picture yet, because you still have to do the following:
- set the palette (use $2006/$2007 to write color values to VRAM address $3F00 and up);
- reset the scroll (the scroll defines what part of the name table is visible, so you need to set it to (0,0) to actually see the top left corner);
- configure the PPU and enable rendering (read about registers $2000 and $2001);
Only after doing this you'll be able to see something on the screen.
tokumaru wrote:
caramelpuffpuff wrote:
is the "$200" the beginning of the location-screen? The "top-left" location of the screen?
No, $200 is the place where most people write their sprite attributes before uploading the to them PPU.
The CPU doesn't have direct access to the video memory, so you can't just STA to the location where you want a tile to be. The CPU communicates with the PPU through two memory mapped registers. One of them is used to tell the PPU which video memory address you'll be accessing, and the other is used to send/receive data. So, to put tile number 7 at the top left corner of the screen, you'd do this:
Code:
;tell the CPU we'll write something to address $2000 in VRAM
lda #$20
sta $2006
lda #$00
sta $2006
;write the tile index there
lda #$07
sta $2007
This alone won't give you any picture yet, because you still have to do the following:
- set the palette (use $2006/$2007 to write color values to VRAM address $3F00 and up);
- reset the scroll (the scroll defines what part of the name table is visible, so you need to set it to (0,0) to actually see the top left corner);
- configure the PPU and enable rendering (read about registers $2000 and $2001);
Only after doing this you'll be able to see something on the screen.
I'm somewhat anxious to reply due to reaction thoughts... Where do I set the palette, reset the scroll, and configure the PPU and enable rendering? I'm lost here...
You set the palette by setting the PPU data location to $3F00 and writing the 32 bytes of the palette. You set the scroll with registers $2005, and $2000. You enable rendering with $2001. It's all on the wiki:
http://wiki.nesdev.com/w/index.php/PPU_registers
The next question is "when". The correct time to set the scroll and enable rendering is after you've finished uploading all nametable and palette data to the PPU.
I'm still reading the BunnyBoy...and I keep failing to understand. -.-
I know it's harder than I thought...but at least I'm still trying...
What's hard to you? Binary and hex are a bit tricky, do you understand those concepts?
3gengames wrote:
What's hard to you? Binary and hex are a bit tricky, do you understand those concepts?
"You can do a LDA #$FF STA $200,X to write FF to the $200 page,"
"- set the palette (use $2006/$2007 to write color values to VRAM address $3F00 and up);
- reset the scroll (the scroll defines what part of the name table is visible, so you need to set it to (0,0) to actually see the top left corner);
- configure the PPU and enable rendering (read about registers $2000 and $2001);"
About this. I feel like I want to know where do I put these. I can't find a word for it but...where do I set the palette? in the "inturrupt vectors" section? "CHR-ROM bank" section? (I kinda feel that one is obvious.)
To be honest, no. I'm still trying to understand the concepts. I understand (barely) on number sytem of decimal, binary, and a little bit on hexdecimal, barely understand on the system overview, which I'm starting to forget about it, and 6502 ASM is the one I'm stuck on when writing codes...I sometimes skip that one, but I often go back to there...
Just try to understand each part. The interrupts are only done once a frame, to know where you're at. You can put them anywhere though, but the PPU stuff needs to be done in VBlank. But do you understand what it's doing, where $200 is? What #$FF is?
3gengames wrote:
Just try to understand each part. The interrupts are only done once a frame, to know where you're at. You can put them anywhere though, but the PPU stuff needs to be done in VBlank. But do you understand what it's doing, where $200 is? What #$FF is?
A little bit, but I don't know how it's organized.
$200 is the beginning of location of where you can see the sprite?
#$FF is the maximum value, or what you call it, and (#)$FFFF is the maximum memory it can hold?
Yep, $200 is sprite OAM RAM. Then yes, #$FF is the number you put there. That's basically all there is to programming, moving numbers, flags, comparing them, etc.
But there's special CPU registers in the $2000 area that are used to do stuff with graphics. The $200 page has to be pointed by $2003 (Write #$00, for start of RAM) and then the special $4014 register for the DMA. DMA just moves the data to the PPU quickly.
The PPU also has it's own memory, from $0000 to $3FFF. $0000 to $1FFF are graphics, $2000 to $2FFF are screens, and then $3F00 to $3FFF are graphics. What you have to do is tell the PPU you want to write to the palette, at $3F00 (LDA $2002, LDA #$3F STA $2006 LDA #$00 STA $2006) and then write the data to it ($2007. The location then moves up by 1 or 32 each time, selected by $2000 register.)
Help glue some things together? Just read the Wiki over and over to learn how the registers interact.
You need to have a solid understanding of binary and hexadecimal.
I would suggest you should be pretty comfortable with chapter 1) and 2) from
here.. The rest of that document is pretty good too, but you could skip anything specific to 16-bit (65816) or 65c02, 65802.
Alternate link:
http://www.westerndesigncenter.com/wdc/ ... manual.pdf
Movax12 wrote:
You need to have a solid understanding of binary and hexadecimal.
I would suggest you should be pretty comfortable with chapter 1) and 2) from
here.. The rest of that document is pretty good too, but you could skip anything specific to 16-bit (65816) or 65c02, 65802.
Seems interesting.
Barely got time to read the entire chapter 1 and 2; school. But OH MY GOSH! IS THAT WHAT IS CALLED!? "MNEMONIC"!? THE STA, DEC, DEX, AND MAYBE ALL OF IT!! I HOPE I GOT TIME TO READ IT!!!
Movax12 wrote:
I would suggest you should be pretty comfortable with chapter 1) and 2) from
here.. The rest of that document is pretty good too, but you could skip anything specific to 16-bit (65816) or 65c02, 65802.
That's actually a very good document, from what I read of it. This would have helped greatly when I was first starting, had I known about it. I didn't understand the relationship between hex and decimal, or really anything at all for that matter in terms of programming.
That's a good place to start reading; it doesn't assume you know very much about programming.
Is something wrong with the page? It's not letting me read it.
EDIT: Nevermind! It's fixed. >u<
caramelpuffpuff wrote:
rainwarrior wrote:
There is a C compiler for 6502/NES and many of us here use it:
http://www.cc65.org/The words you are using still makes it hard to understand what your goal is. Please explain more about what you are trying to do. Be specific about it, not general/vague. What kind of C program do you have? Who wrote it? Where did it come from?
Compiling a C program is not a simple matter of "converting C to binary". To make your NES ROM from it you will need a specific compiler, and a specific build process. This information should be included with the C source files you have, hopefully. If you are starting from scratch, why don't you try
Shiru's Tutorial?
http://www.youtube.com/watch?v=pgRKkL_etOQ When I saw this, I got ConTEXT, so
the C program I have is ConTEXT (My apologize, I'm still learning english.)
The source for this is http://www.contexteditor.org/ I'm guessing "ConTEXT project" wrote it, seems like an independant developer. I install 6502 Assembly to ConTEXT, but now, I'm not sure which is easier; C or 6502. Long story short;
I am trying to figure out on how to change C./ASM. into an NES. without any "Gray background" or "Error, can't open on Fecux" stuff, which, for now, is my goal. I got ASM6, CC65, and ConTEXT.
Dude haha ConTEXT is not a compiler it's a text editor.
Honestly you strike me as a little too young for this. Forgive me if I'm wrong but you seem to have too little knowledge and experience for it. You need to learn what assembly is, and what compilation is, and what C is, and what the 6502 processor is. There is also a ton to learn about the NES hardware. It took me 2 weeks to get rolling and I'm a professional programmer.
Did you just bump this just to tell him something people already told him? (That context is not a compiler/assembler)
Jeroen wrote:
Did you just bump this just to tell him something people already told him? (That context is not a compiler/assembler)
Oops, erm.... yeah I guess it was a pointless post. I stumbled on the thread from a search.
Thanks for the "tip"...
Does the documentation (prog. the 65816) also teach you to make SNES games? (Having a lot of busy times, making it difficult to read the pages.)
No tech docs on computer systems such as game consoles, or their components such as CPUs, teaches how to make games. These docs only explain what the hardware could do, everything else is up to programmers.
In fact, I don't think there ever was any text on how to make SNES games specifically. Not the official ones for sure, because official docs are intended for experienced developers.
caramelpuffpuff wrote:
Does the documentation (prog. the 65816) also teach you to make SNES games?
It doesn't, because this document is not focused on game programming techniques and does not cover anything about the rest of the hardware in the SNES (video, sound, input, etc). The document is focused on the architecture of these CPUs, which you have to know in order to make games on the NES and SNES, but there are many other things you have to learn in addition to getting acquainted with the CPUs.
Learning assembly for making games on old consoles is like going to college in a country whose language you don't speak: you have to learn the language first in order to take the classes, so that you can communicate with the teacher and your classmates. Learning the language is only the first step, you still have to study all the different subjects in order to get your diploma. When programming games, assembly is just a language. You have to learn about game programming techniques (things like physics, object management, etc.) and your target hardware (memory, video, audio, input) in order to know WHAT to say to the CPU.
Wait, what happened to the links?!