I'm working on some minimal ca65 examples for new NES programmers and would like comments. Below is what I came up with as the absolute minimum example that does something and doesn't need
any other files, not even a .cfg (it uses ld65's build-in NES configuration). This eliminates the main reason I previously preferred nesasm, that of not needing any extra configuration files. The built-in configuration isn't great (vectors start at $FFF4 and some other minor things), but it's fully usable for examples.
ca65 mini.a
ld65 -t nes -o rom.nes mini.o
Code:
.segment "CHARS"
;.incbin "chr.bin" ; if you have one
.segment "HEADER"
.byte "NES",26,2,1 ; 32K PRG, 8K CHR
.segment "VECTORS"
.word 0, 0, 0, nmi, reset, irq
.segment "STARTUP" ; avoids warning
.segment "CODE"
nmi:
irq:
reset:
lda #$01 ; play short tone
sta $4015
lda #$9F
sta $4000
lda #$22
sta $4003
forever:
jmp forever
This is nice. I always felt a bit stupid for not being able to assemble anything with the big boy's tools... I'll remember to check out this thread for reference. But I'll stick to ASM6 for now... can't beat it's perfect balance between simplicity and features.
Here's what I've got of a basic "Hello, world!" example, mainly trying to decide what code to put in. Comments would be changed a bit:
hello_world.asm
This example is fairly short yet allows text display, which is important for an early example. I tried to avoid using subroutines, since I want as few distractions as possible. Provide your own ascii.chr font if you're trying to assemble it.
(again, this thread isn't for helping people with these examples, it's for refining them
before they are offered as tutorials)
Mini would be slightly improved if it didn't imply that nmi and irq should be pointed at reset. This might reduce confusion once subsequent examples introduce NMI.
Code:
nmi:
irq:
rti
reset:
lda #$01 ; play short tone
Now from hello_world.asm in the pastebin:
Code:
sei
ldx #$FF
txs
lda #0
sta PPUCTRL
sta PPUMASK
jsr wait_vbl
jsr wait_vbl
Would it be more confusing to clear CPU RAM $0000-$00FF and $0300-$07FF between the two calls to jsr wait_vbl?
Code:
jsr wait_vbl
lda #$0A
sta PPUMASK
At what point do we want to introduce the distinction between spinning on PPUSTATUS, which misses frames if the read from PPUSTATUS happens precisely at the beginning of vblank, and a wait based on NMI, which works more reliably and should be used once the PPU has warmed up?
Code:
lda #0
sta PPUSCROLL
sta PPUSCROLL
; Loop forever
forever:
jmp forever
I noticed that this code does not write to PPUCTRL after filling VRAM. Writing to PPUCTRL sets the VRAM address corresponding to which of the four nametables is used for the pixel at the top-left corner of the screen. If this isn't done, the values of these bits can be hard for a beginner to predict if the program has just loaded an attribute table. I follow the guideline of always writing to PPUCTRL when writing to PPUSCROLL before a frame starts.
Thanks for the ideas, tepples; it inspired me to get more done. Now I've got four examples that progress:
Code:
1-beep.a Minimal setup of header and reset handler that just beeps.
2-hello.a Sets up palette, nametable, and prints message.
3-scroll.a Scrolls smoothly using NMI as timebase, introduces routines.
4-controller.a Scrolls using controller, clears RAM, has common routines etc. in common.a.
Here's the source for examination:
blargg_nes_tutorial.zip
No. We need a few experienced NES programmers to design and implement a set of tutorials. This is just some crap I whipped out with little planning.
ok well, can i comment from a newbs point of view?
Laserbeak43 wrote:
ok well, can i comment from a newbs point of view?
Go ahead.
How much 6502 knowledge should we assume? None?
How much programming knowledge at all should we assume?
tepples, here are some that use a shell to cover really basic 6502 stuff. With this we can go very slowly and make it easy for the learner to try different things without having to know anything about NES programming:
blargg_nes_tutorial.zip
bunnyboy suggested to provide a batch file to assemble these, in an attempt to avoid the learner ever having to use the command-line. I think if a few of us got together, we could make a good set of tutorials to get someone up to the level of basic PPU graphics, scrolling, and sprites.
I think it would be good to make a set of tutorials covering all the basics. It would be good to explain things in a way that requires no prior programming knowledge. Also, perhaps there could be pictures involved in the tutorial. I don't know, maybe it could a PDF file or something. It could be HTML too (it would actually be better that way).
Hmmm, with HTML we could include one of those JavaScript-based 6502 simulators. That'd be even better than the examples I just posted. Immediate feedback, and the example code could be executed right there in the HTML page, below the description! I like this. I'll have to take a look at the simulators.
Well, I was just suggesting HTML so one could incorporate a little bit of imagery into it, but that sounds cool too. I just think with images, it would be SO much easier to understand everything.
tepples wrote:
Laserbeak43 wrote:
ok well, can i comment from a newbs point of view?
Go ahead.
How much 6502 knowledge should we assume? None?
How much programming knowledge at all should we assume?
i've messed around with C++ and C++ books for over 7 years on and off. but i'm still a major noob. never really practiced much in that time. took on a few projects and took it very seriously, but at the time it might have been too much for me to do on my own.
for example, i've run the STK(synthesis tool-kit) etc. done all the tutorials and the same for PortAudio. modified the tutorial files and have done very minor things with the source as a base for my own original code. but wasn't skillful enough to debug things etc.
NES programming? very new in comparison to what i do with C++. no doubt about that. but i do have the programming concepts down a bit. sometimes i may just miss something simple and trivial, like the purpose of a counter in a simple loop like i did in the noob section the other day(blargg knows what i'm talking about).
from the point of view of someone with my level of skill would it be useful for me to ask questions/make suggestions?
Yes, it would actually be quite useful. Often, people who write tutorials forget that they were once new to what they are writing about. So they are really writing the tutorial understanding it themselves, not realizing that people who are newer have no clue what they're talking about. You seem to have a bit of programming experience, but not too much to see things through the eyes of a newbie. Regardless, I believe a tutorial should be written to assume no programming experience from the reader.
Celius wrote:
Regardless, I believe a tutorial should be written to assume no programming experience from the reader.
Even to the point of having to answer questions such as "what is a variable" and "what is a loop" by itself?
Another point of scope: Should a tutorial assume knowledge of the command prompt, or should it be aimed at people who, up until starting the tutorial, only know how to
point and drool?
Yeah, I think it should even go that far. But those things are easy to understand once they're mentioned. It only takes a few sentences to explain what exactly a variable does, or what a loop is. The tutorials should be easy to read, nice to look at, entertaining, informative, and newbie friendly.
Haha, it's funny that you mention the command prompt. Back when I started, I didn't know crap about anything. So I didn't know how to really use command line programs. That actually took me a while to figure out. I think just to avoid confusion, the tutorials should guide people through all of the steps. At least it should start out that way, and as the tutorials progress, it should be assumed that the reader learned some of the basic procedures that were previously explained.
tepples wrote:
Celius wrote:
Regardless, I believe a tutorial should be written to assume no programming experience from the reader.
Even to the point of having to answer questions such as "what is a variable" and "what is a loop" by itself?
Another point of scope: Should a tutorial assume knowledge of the command prompt, or should it be aimed at people who, up until starting the tutorial, only know how to
point and drool?
maybe someone could write tutorials for the sticky that blargg can point to in the introduction of his his tutorials.
if i can remember how the hell i did it, i can write a tutorial for adding nesasm to the PATH variable in windows and how to assemble a ROM with it, with pictures etc.
Quote:
maybe someone could write tutorials for the sticky that blargg can point to in the introduction of his his tutorials.
Any forum is the bottom of the barrel when it comes to value for effort put in. I haven't been to other forums, but I
know inside that the way things are done here is pretty pathetic compared to what can be done. Anyone with imagination can picture much less wasteful and organized approaches than what goes on here. I'm not blaming anyone (I sure haven't changed things), just am not blind to the sad reality. The only mention I'll make of any forum is for discussion. I'd never link to a sticky from a tutorial.
Celius wrote:
Yeah, I think it should even go that far.
Can we rely on Wikipedia's description of the
binary numeral system,
Boolean logic, and other fundamental topics? Or should we assume that people who download this tutorial will read it on a machine with no Internet access?
As for forums vs. other media, I'll probably take the project to the wiki very soon.
tepples wrote:
Celius wrote:
Yeah, I think it should even go that far.
Can we rely on Wikipedia's description of the
binary numeral system,
Boolean logic, and other fundamental topics? Or should we assume that people who download this tutorial will read it on a machine with no Internet access?
As for forums vs. other media, I'll probably take the project to the wiki very soon.
i just came from the emergency room. my lady was sick we were there for at least 4 or 5 hours.
i was modifying the sound ROM code from the noobie section. for one reason or another, i wanted to create a variable(which i worked around anyway, i just put the code inside of a label) and i couldn't find crap on my laptop. and i have tons of NES docs. in this time i browsed through many docs, searched them, and even did a windows document search with no luck at all.
even if this tutorial is to be used offline, maybe an offline archive of the wiki would be good too(after broken links are fixed XD ).
my 2 cents as always.
LUV YA!!
I just started a
list of basic computer science concepts that answer the question "What is a computer?" (other than "that magic box that shows you the intarweb") and "What is a program?".
It's good to have people read these, even though much of the material may be known already, people may read them and learn little things along the way. I could probably read through those and learn a few things.
tepples wrote:
I just started a
list of basic computer science concepts that answer the question "What is a computer?" (other than "that magic box that shows you the intarweb") and "What is a program?".
personaly i don't think you have to go as far as defining a computer or even giving tutorials on hex and binary.
even though i too struggle with them, i think it's something people should pick up some docs learn about it, and if need be, get help from the community.
now when it comes to setting up an assembler and environment variables for a nes related assmebler, or suggesting things to practice and giving examples, then it starts to make sense. i really don't think NESWiki should be wasting space teaching people what a computer is. but just my opinion.
-edit-
well at least it links to another page....didn't notice that.
Laserbeak43 wrote:
personaly i don't think you have to go as far as defining a computer or even giving tutorials on hex and binary.
I didn't know what a bit or byte really WAS when I came here. I'd heard of them many times, but I didn't really know what defined them. And many people don't know the exact definition of a computer. Many people just think of a PC when they hear the term, but they don't really think about the fact that the NES is a computer. People that come here really may be people like I was who know absolutely nothing. Perhaps a huge long explanation of simple things isn't necessary, but I do feel quick explanations/reminders are necessary. For example, in a tutorial where someone is learning how to make simple games, and the tutorial is now guiding them through the assembling process, it's good to put in something like:
"Now keep in mind that the assembler is translating our code into 1s and 0s for the NES to read."
Just to keep the person learning completely aware of what's going on, even if they might know that already. I don't know, that's just what I think.
fair enough
I started learning this like a week ago, and I have some knowledge of programming in other languages (all of which are object oriented), and don't find the overall structure of NES programs confusing - quite the opposite. NES programs seem really straightforward and there is actually a lot less to understand somehow. The biggest bumps so far have been the use of hexadecimals (which is really cool, once you understand it) and trying to figure out the 3-letter commands, what they do and what the various addresses are. The problem isn't that the programs are complicated but that the code doesn't give the slightest hint about what it does since you use extreme abbreviations and numbers rather than letters in most cases. Today I read up on the PPU in the wiki and a lot of things that were total fog before became pretty clear.
I think one of the dangers here is giving the newb too much information at once. Reading about the PPU addresses and what they do isn't a good start. The tutorials should both cover as much of the absolutely necessary info as possible while leaving out as much unnecessary info as possible, since it will only confuse the reader. For the very first tutorials, every single line probably needs an explanation for everyone to understand. You need to explain the notation for those who are not used to it. For example:
Quote:
.segment "HEADER"
.byte "NES",26,2,1
These lines have no comments, no explanation about what they do, what the dots before "segment" and "byte" mean or what the numbers are, or what they are for. Agreed, telling would perhaps be too much info, which I just said was a bad thing, but for those who want to know right away, where should they look? This particular piece of code was explained a bit more in the first tutorial, but not in a way that a newbie would understand. There are several sections in the first tutorial listed as "not used here" but no explanation as to why they're even in the code if they're not used.
This is why I think a wiki page for each tutorial would be nice - the reader could get more and more detailed explanations for each of the lines in the code, and click any word they don't understand ("dude... what's a "CHR Rom"?").
It's kinda funny how technology this old needs to be reverse-researched like this. I mean, there are probably 50 or so people worldwide who know how to do this really well, but they're not around to be asked about it... I'm very grateful that the people who have managed to find out all this info on their own are willing to share it like this.
Well, so, does anyone think these examples should go into the wiki where they can be explained row by row?
Yes. We just have to agree on a set of code examples that will be explained.
I'm thinking this code wont be used in that way. unless someone gets blarggs permission and does it themselves.
I'd do it, but you'd be teaching me about what i'm documenting as i'm doing it. so i dunno how well that would work out.
Are we talking about Blargg's examples being posted? If so, well, we need to make sure he is okay with this first. And also, we should probably post examples that don't include assembler-based macros. Since the language being learned is the 6502, we should just put plain 6502 pieces up.
I think we should put a Hello World demo up, just to show how to initialize the NES and whatnot. But we should also have demos showing how to work with the scroll registers, how to do PPU updates, sprites, sound, etc.
Naturally, no one's code gets up there without the author's permission. I don't even know this stuff well enough to know what's assembler macros and what isn't. Personally, I think it would be nice if such things could be explained as well - suggestions on how to do the same thing in other assemblers etc. For someone learning 6502 learning to use the assembler could be as serious an obstacle as learning the language itself.
so are we suggesting a new tutorial?
Well, I'm not so sure about that. It would be nice if all macros were either completely explained, or completely removed.
And don't forget, I have made this:
http://www.freewebs.com/the_bott/test.rar
So people don't have to learn about the assembler right away. It's just a simple NROM set up for WLA-DX. I don't know really anything about CA65 (Or CC65, I don't know what the difference is if there is any), but it's only because I started learning about WLA-DX and thought it was fine.
Personally, I don't really want to use macros. I just code in plain 6502 code. And since in the end that's what it's turned into, I think it's kind of annoying to try and go through code that has a bunch of macros so I have to go dinking around looking for the definition of the macros.
No, what is needed is more than "Hey let's put up a tutorial... here's a tutorial". Lots of questions must be answered.
- What level of knowledge will these assume?
- Will the very first code examples be standalone, or use some kind of shell that hides the details? (this mostly depends on how basic the examples start)
- What assembler will be used?
- There will be marked up examples on the Wiki. Will these be directly assemblable?
- What order will things be introduced in? Each code example should build on the concepts introduced in the last, and not explain them again. So the order is critical to decide on before writing code, since changes in order require lots of rewriting.
I envision a series of descriptive texts and code to go along with it, starting with basic 6502 instructions and using a shell to print values to a text console. Once 6502 operation is established, then a complete standalone NES ROM is introduced. After that, graphics are covered. Each unit would have text that introduces new concepts, with little bits of code interspersed, along with a runnable code example that puts it all together. ca65 would be used as the assembler. Each unit could be on a separate Wiki page, with the runnable code as a linked file at the end.
If I'm going to contribute, it will only be with a small number of people (2 or 3 others perhaps), and there will have been planning beforehand, not just charging ahead. I'm interested in something really high quality, or nothing at all. Maybe tepples and I can work on a few trial units, one from the 6502 operation section, and one or two standalone ones. Perhaps making some as a template would allow others to duplicate the format and keep consistency.
It seems that most people tend to use ca65, so I also agree that should be the assembler.
And yes, I agree that it should be really high quality. Otherwise, there's basically no point in making it. My answers to your questions:
-These should probably assume little programming knowledge. The list of things tepples linked to give a good boost into the basics of programming.
-I don't know exactly what you mean by this...
-ca65, since that is very common around here
-These should be directly assemblable, but perhaps there should be files to download, like graphics files and whatnot.
-The most simple things to start understanding are graphics. After that sound should follow.
I also think there should be fully compiled test roms at the end of the "lessons" as well as maybe some pictures.
6502 has to be learned before graphics or sound, since both require lots of setup. Trying to teach 6502 and graphics at the same time is too much; errors in a student's understanding will be hard for him to pinpoint the cause of, since it could be 6502 or NES graphics related. That's why I think there should be several units before NES that focus on 6502 only, and use a shell that has routines like "print the value of A" and "print a message". This allows the tutorial to start with basics like LDA, without the student needing to understand anything else about NES or 6502 operation.
Well, I was kind of assuming that 6502 would come before either of those. Sorry for not being clear on that.
But yeah, I think we should have some test programs that deal with plain 6502. For example, a loop storing values into RAM. Even though RAM is kind of another field, I think it's safe to combine both of them into the same lesson.
But yeah, there should definitely be 6502-focused lessons. They will definitely need to come first since everything relating to the NES is in some way involved with 6502.
blargg wrote:
- What level of knowledge will these assume?
I'd say very beginning. most tutorials are full of lots of holes, and i haven't ben able to peice them together with other tutorials
Quote:
- Will the very first code examples be standalone, or use some kind of shell that hides the details? (this mostly depends on how basic the examples start)
I think learning things like setting/creating up a .chr and stuff like that is very important.(i've been searching forever, the tutorial i did find basicaly skipped right through the whole process).
Quote:
- What assembler will be used?
if you're going for detailed quality, and you've already started out with Ca65, I'd say continue.
Quote:
- There will be marked up examples on the Wiki. Will these be directly assemblable?
Maybe you could make the first unit's chapters about setting up the environment. and then say on the wiki that "Unit 1 must be completed and environment in tact in order to use this code".
Quote:
- What order will things be introduced in? Each code example should build on the concepts introduced in the last, and not explain them again. So the order is critical to decide on before writing code, since changes in order require lots of rewriting.
i guess like other programming languages, you learn about initialization first. but i see where this could be an issue. maybe in the beginning, or even for early debugging use 6502 simulator as well. before any code can be seen in an emulator(i could be wrong about this too, now that you mention it, i'm sure you could see even the simplest stuff that does output audio or video in the debugger).
my 2 cents
P.S.
yeah im a noob if anyone knows that it's you guys. but i'd be happy to help in any way that i could, trust me.
I'm posting in this thread because I want to learn this stuff. I don't really care myself about what assembler is used - if you use a particular one (CA65? CC65?) and it works well, there's really no reason to bring up any others. Sticking to only one assembler will probably help reduce confusion. I agree most tutorials, including schoolbooks etc. skip a lot of very important steps a lot of the time. It might be an idea to assume some knowledge about some things but then an explanation for those who don't understand must be readily at hand, and there are few more suitable ways to organize information like this than in a wiki. Rather than printing everything there is to know about everything, those who don't understand can click a link and find a deeper explanation, while those who do understand can read on.
A better solution is, of course, to explain each step from the beginning and as the examples become more and more advanced, those who don't understand can be reminded about in which example a certain step was brought up the first time, for reference. You should always be able to find what you're looking for though, if you just keeping going backwards in "the book". I feel most tutorials on NES programming have assumed way too much. When I begun doing this stuff I didn't even know about hexadecimals. Sure, it's a not a big deal to learn, but it must be learnt before you can continue, otherwise you'll have no idea what the letters are doing in the numbers, and every hexidecimal number will just look like a random mess.
Since I don't see how I could be of any other help, I'd be glad to point out where the tutorials could use some more detail, which is sometimes difficult to tell for someone who already knows how something works.
Laserbeak43 wrote:
Maybe you could make the first unit's chapters about setting up the environment. and then say on the wiki that "Unit 1 must be completed and environment in tact in order to use this code".
I've started on this:
Installing CC65Quote:
i guess like other programming languages, you learn about initialization first. but i see where this could be an issue. maybe in the beginning, or even for early debugging use 6502 simulator as well. before any code can be seen in an emulator(i could be wrong about this too, now that you mention it, i'm sure you could see even the simplest stuff that does output audio or video in the debugger).
On the NES, audio requires a lot less initialization than video. I'd recommend making the first NES tutorial ding, then have the next few work up to the "da-ding" sound commonly associated with Mario getting a coin.
Laserbeak43 wrote:
i guess like other programming languages, you learn about initialization first. but i see where this could be an issue. maybe in the beginning, or even for early debugging use 6502 simulator as well. before any code can be seen in an emulator(i could be wrong about this too, now that you mention it, i'm sure you could see even the simplest stuff that does output audio or video in the debugger).
my 2 cents
P.S.
yeah im a noob if anyone knows that it's you guys. but i'd be happy to help in any way that i could, trust me.
"i'm sure you could see even the simplest stuff that
does output audio or video in the debugger"
should have been
"i'm sure you could see even the simplest stuff that
does not output audio or video in the debugger"
sorry. but you made it seem like a simple task anyway. so i guess it doesnt matter
tepples wrote:
I've started on this:
Installing CC65
it looks great. i dunno how safe this could be to post, but could there be an addition to this tutorial to add CC65 to the environment variables?
-edit-
i guess it'd be ok if you first get everyone to make a backup copy of the environment variables...
I don't see any mention of cc65-nes-2.11.0-1.zip in there. What is it, what does it do, and why is it of no use to us?
Laserbeak43 wrote:
but could there be an addition to this tutorial to add CC65 to the environment variables?
I had a section about putting cc65's bin folder into PATH, but I removed it once I checked 'set' and found that install.vbs of step 5 had done that for me.
Dafydd: That zipfile contains the C library, configured for the NES, along with some (hard-to-load) joystick code. There is also a linker script for NROM-256 with a 12-byte vector segment, as opposed to the 6-byte segment one would expect. And the naming conventions don't exactly align with the conventions used on the rest of the wiki. As far as I can tell, it's intended for quick throwaway recompiles of C code on the NES, not for serious NES development in pure assembly language.
tepples wrote:
As far as I can tell, it's intended for quick throwaway recompiles of C code on the NES, not for serious NES development in pure assembly language.
so how much could you expect to get done with CC65?
Quote:
so how much could you expect to get done with CC65?
There's nothing stopping us from making a better C runtime for NES development. But what does it matter, since we're aiming for asm development (and CC65's code efficiency isn't very good either)?
blargg wrote:
Quote:
so how much could you expect to get done with CC65?
There's nothing stopping us from making a better C runtime for NES development. But what does it matter, since we're aiming for asm development (and CC65's code efficiency isn't very good either)?
ok. can see your point. sorry to turn things around, but weren't these originaly Ca65 tutorials?
Quote:
weren't these originaly Ca65 tutorials?
I think that's the point, to tutor someone on 6502 assembly and NES assembly programming. I think the only reason CC65 is involved is that the assembler, CA65, isn't distributed separately. Speaking of distribution,
tepples, can you rebuild the Windows executable with
my patch to ca65, which gives warnings when # is probably missing?
Can't wait to see the results when you're done with the first (ok, maybe the second, then) tutorial.
Anyway, I had an idea for a tutorial (not too early) - a simple counter, like a score meter. Pressing a button (say A) gives 1 point, pressing another button (say B) gives 5 points. Making the value of a variable show up on the screen as a number is, I would guess, more difficult to do than to display a predefined text, so it might be something to teach after getting the hang of displaying text (like in example 2 in this thread), scrolling and so on, but before things like interactions between backgrounds and sprites.
Also, about this shell you mentioned - who's making it and using what? It should be pretty easy to write a console 6502 emulator in pretty much any high-level programming language... I'm thinking something like the Python IDLE or MATLAB, but in a DOS window.
very good idea
i'm looking for it
thank u
Dafydd wrote:
Also, about this shell you mentioned - who's making it and using what? It should be pretty easy to write a console 6502 emulator in pretty much any high-level programming language... I'm thinking something like the Python IDLE or MATLAB, but in a DOS window.
I learned 6502 on this thing.
http://home.pacbell.net/michal_k/6502.html
If I had to learn it again, the first thing I'd want to understand up front is memory-mapped I/O (although maybe it's not a problem for total beginners who aren't used to high-level abstractions) and how the whole thing loops around the vblank/sprite 0. I also like the idea of introducing just enough technical material to get something done, and not shove every addressing mode and memory location down one's throat (nesasm on nespowerpak.com does this pretty well). That way readers can use it as a springboard to understanding stuff like Patrick Diskin's NES doc.
strat wrote:
Looks like it's capable of doing a lot more than the NES can - as far as I know you can't write stuff like "lda = timer+3" in NES assembler. I could be wrong.
strat wrote:
If I had to learn it again, the first thing I'd want to understand up front is memory-mapped I/O (although maybe it's not a problem for total beginners who aren't used to high-level abstractions)
I learned Java and then C#, so reading about how the 6502 handles memory was both illuminating and confusing, though interesting more than anything else.
strat wrote:
I also like the idea of introducing just enough technical material to get something done, and not shove every addressing mode and memory location down one's throat
Amen. That's the problem I've had with pretty much every tutorial I've read. Either that or it tells you to do stuff without explaining why.
It's pretty likely that 'timer' in lda Timer+3,x is a macro, meaning it would be declared like
timer = $06
and that instruction would actually assemble to lda $09,x.
Actually, when I started using that thing, I got macros and variables mixed up and went crazy using INC on some macro. Ah, noobs.
Well, ok. I'm not really interested in using macros if I'm learning this, even though assigning names to certain numbers, variables and adresses would help reduce confusion (like in blargg's examples).
Yeah, macros are kind of confusing at first, but when you write lengthy programs you'll love them real quick.
I'm sure you will. I just want to learn how to do this the hard way before I start taking shortcuts. I still make webpages using notepad for the same reason.
So... any breakthroughs yet?
Bumping just to show you I'm interested.
Can we just ask memblers to sticky this till its done and delete all of these bumps?
I was searching for the wiki and I ended up in that thread. I will give my opinion on the current subject.
I think there's at the least, a minimum that the user of the tutorial should know:
- basic CS skill (what is a variable, a loop etc)
- basic 6502 asm programming
Your goal is to write a tutorial about how to program on the nes, not about learning how to program in general.
This should be clear for the potential readers from the beginning. For the readers that may not have the knowledge, referring then to an external reference about the subject that they may lack knowledge of would be a plus.
Once you know about basic CS and 6502 you are automatically aware that developing your software will requires some tools. A basic introduction of the available tools without going into details would be a must. Advanced users could use that information from the get go and beginners would be now aware of them. At a later stage, how to use those tools would be explained in the appropriate module (or the module do a reference to the appropriate how-to).
Now that we know which tools I have access to we need to know what steps are required to create my first application. There is good chances the nes needs some basic initialization to work. This is the first thing to explain.
From that point, you go incremental in concept. As long one concept can be built on top of the other, the better. The tutorial example grow with every step.
Which step would be perfect, that I cannot tell since I'm looking exactly for that exact information. I want to learn how to program on the new but I don't know where to start from.
Finally, what is the most important in the writing process of your tutorial is to do a review with your target audience. The problem with writing a tutorial is that you already know the subject: it's hard to confirm if what you wrote is clear enough. Your target audience will bring all kind of questions that you may have not though about and it will improve the tutorial content.
Banshaku wrote:
I think there's at the least, a minimum that the user of the tutorial should know:
- basic CS skill (what is a variable, a loop etc)
- basic 6502 asm programming
I would imagine that a lot of the audience knows programming but not assembly language for the 6502 family. So on what 6502-based platform should the user be familiar with 6502 programming? Should we refer people to an Apple II tutorial, a Commodore 64 tutorial, or something else?
If the tutorial is about programming the NES by definition, referring to other 6502 systems might be distracting. The asm syntax, addressing modes, and i/o ports are really three different things to grasp. Beginners should be aware up front that they'll have to study all three to make software (plus the quirks of PPU frame timing and bank switching when you want to make a side-scroller).
It's probably best to learn 6502 instructions and addressing without a system-specific context, and juxtaposing it with a HLL might help experienced programmers learn asm:
char array = {5,6,7,8};
char sum = array[2] + 0x14;
printf("%d\n",sum) // would print 27
in 6502:
array:
.db 5,6,7,8
ldx #$02 ; load X register with 2
lda array, X ; absolute indexed addressing
; loads accumulator with the
; contents of the address of array+X
clc ; clear carry flag before adding
adc #$14 ; adds 20 to contents of accumulator
jsr PrintAccumulatorContents ; must be implemented elsewhere
tepples wrote:
I would imagine that a lot of the audience knows programming but not assembly language for the 6502 family. So on what 6502-based platform should the user be familiar with 6502 programming? Should we refer people to an Apple II tutorial, a Commodore 64 tutorial, or something else?
This is a good question. Like mentioned by Strat, if we refer them to a tutorial it should be platform independent. Basic 6502 skill should be about pure 6502 asm only.
For example, you can learn the C language without having to know about Win32, unix, ms-dos etc. Once you know C, you can learn about the specific platform that you are interested. That is usually what they do in CS classes.
Since I'm in this situation, I would love to find a nice generic 6502 tutorial. Then, what I would do is practice with a 6502 simulator. I know there is one web based (
http://www.6502asm.com/) and another one for windows made by Michal Kowalski (
http://home.pacbell.net/michal_k/6502.html).
What would be interesting as an appendix to these tutorials is a section about common problem solving on the nes. That is always a time saver.
Banshaku wrote:
For example, you can learn the C language without having to know about Win32, unix, ms-dos etc. Once you know C, you can learn about the specific platform that you are interested. That is usually what they do in CS classes.
C programs written in CS classes rely on <stdio.h>, an I/O library whose implementations across multiple platforms share a standard API. Assembly language doesn't have this luxury unless a program written in assembly language uses the local implementation of C standard I/O.
C was just used as an example since it exist on so many platform. You still learn how to use C in CS classes without learning how the platform works.
In the case of the 6502, you're on your own unless a specific platform gave you some kind of library in their SDK.
Since I'm looking (not seriously yet) to find one, this is what I think I would be looking for as a tutorial:
It explains me about:
- The available registers (accumulators, indexes, segments if any)
- The addressing mode
- The list of all possibles commands
If some basic information about variables, loop etc is explained too, even better. Then I could test it in a simulator.
Any of those tutorial exist or I'm just too optimistic?
I'd say this is a great place to get started on the 6502:
http://www.obelisk.demon.co.uk/6502/index.html
They introduce the architecture of the processor, explain the addressing modes, provide a really good reference for each instruction, and even have a "algorithms" section, where some basic principles are explained.
Read that while trying out stuff on the
6502 Simulator and you'll be good to go.
This link is familiar. I may have saw it when searching for 6502 information in the past.
Thanks, I will give it a try.
About the simulator, it is a nice one, I tried a few time. Since he offer the code, it would be great if we could make a nes simulator, but that would requires too much job. That could be a great tool for developing nes games thought.
Yes, the idea of a NES simulator was discussed before. It would be a nice tool indeed. It would probably be easier to turn a NES emulator into such a tool though... The authors of the good (accurate) emulators could consider including an assembler somehow... There is a simple assembler in FCEUXD, but that's not exactly what we need. Something simple, like asm6, that can quickly assemble from a single input without much setup, so that the same type-and-go system featured in the 6502 simulator is retained. If options to save the ROM and the source file(s) was included, it'd make a nice all-in-one development tool.
Any plans to continue this set of examples? As a beginner, they're massively helpful, especially as a companion to the 'Nerdy Nights' programming intro over at NintendoAge.
Yes, I guess it would be a good idea to add extra ones, more like the first set of example that Blarg did. Hiding too much about what the nes can do (second set) had the opposite effect on me: I was not able to understand what was going on.
I started out of those and I was able to learn how to load some chr-data, show it on the screen, scroll it, show a sprite, change the palette, use the joystick etc. I learned how to use the minimum for ca65 and create some makefile to simplify the process. I still have a lot to learn but I'm very grateful that I found those examples, it helped me a lot. By the way, thanks Blarg for your example, I never said it to you directly. It got me started and I'm happy about that.
Now I put my nes project on hold because I need some tools to create the data. I'm planning to build a small map editor for my needs. I want to make it as simple as possible, just to be able to show more things on the screen. I just don't want to code my map by hand, I'm a visual guy and I want to see the result on the screen right away. And it's easier to manage later. If I do make it (I'm doing enough programming at work so I don't know if I can invest a lot of time on it in my spare time), I may give it back to the community, if anybody is interested.
Is it possible to get normal listing file just like in asm6? I guess it could be done only by linker, but obviously it doesn't have such comand line parameter.
well,when i go to the link,it just tell me access denie
I know this thread is pretty old, but does anybody know where the original zip file with ca65 examples can be found? The link no longer works. Any other links to ca65 nes examples? I just want some basic examples of how to set up the files, do the header, etc.
BTW, this thread started about ca65 examples and then turned into a discussion about making a new nes tutorial. I assume that never happened. I've done technical documentation and know how much work it is. But if anybody is still interested in what would be useful for beginners tutorials, here's my perspective, having been trying to learn as fast as I can for only a few weeks:
1) Don't try to introduce basic programming concepts, just link to them, including Easy 6502
https://skilldrick.github.io/easy6502/ . It's way to ambitious to try to cover everything.
2) Leverage what is already online, including the Nerdy Nights tutorials. They are the best beginner guide online. No need to re-explain the things it covers well, including several basic NES concepts. See shortcomings? Then write a "companion page that adds better info"
3) Fill in what the othersources leave out: a) how to use ca65 b) how to organize code properly c) how to set up a project to build and link, etc. d) a good overview of the memory map and concepts behind it, including mappers with simple working examples
4) Examples, example, examples! Well commented examples that isolate one thing they are exemplifying are the best. The controller example should do almost nothing else, the sprite one should just be simple sprite setup and display, the one on code organization should just be a shell with comments and "your code goes here".
I assume that at this point it is unlikely that anybody will do any of the above, but I can definitely tell you it would have a lot of value, and it would be a lot easier and quicker than some of the grand tutorial plans I've seen on this and other threads.
Here's my minimal ca65 example:
http://forums.nesdev.com/viewtopic.php?t=11151 (Minimal NES example using ca65)
I have several other ca65 projects scattered around
my website, but this is the only one I wrote to be an easy to follow example.
Tepples is apparently writing a tutorial that will use ca65.
See this thread...
viewtopic.php?f=2&t=13113This appears to be its location, but as you see, it's just an outline yet. Maybe check back on it in 6 months or so.
http://wiki.nesdev.com/w/index.php/User ... s/tutorial
Thanks rainwarrior! That's a huge help. And actually having debug symbols sure is nice too.