What we need are people who are willing to get together and discuss designs for new tutorials without hastily throwing them together. Not some kind of random posting to a Wiki, actual English communication where all aspects of the tutorial design are discussed and approaches proposed. After a while a general approach to tutorials would emerge, with outlines for each tutorial. A more coherent strategy for documentation would also come of this.

Part of the problem is people coming in without any prior programming experience. Those of us who came to nesdev FROM somewhere else didn't have much difficulty catching on because we pretty much already had the idea. What makes learning the NES as your first system especially hard is trying to swallow both its cryptic method of graphics programming, on top of learning how to use X assembler, on top of learning a new assembly language, on top of learning basic programming fundamentals.

There is no way in hell anyone with no prior programming experience will be able to comprehensively write a program to play a major scale on the NES by the 3rd lesson. If they make it that far, they'll pretty much have skimmed over (but not really absorbed) the material, and copy/pasted the code into their assembler. That's not really that much help. Not that I'm knocking your idea tepples, I'm just making a point. I didn't want to name names, but I see Ninetendo struggling to swallow everything NES-related in one go when he has no prior experience, and it's apparent that he's having a difficult time. I don't think that's because of lack of tutorials... I think it's because he's trying to learn too much at once.

To really get a ball rolling on this, the first thing to do is figure out where on the experience totem pole we want to focus on. There's no way we can make a tutorial that will work for everyone, we have to figure out who we're targetting first. If we assume the person reading the tutorial understand X criteria, we can more effectively create a tutorial they'll have an easier time following. And maybe even later, we can write tutorials covering X for those who don't already understand it. For example, we might assume the reader already understands 6502, and then we can just focus on how to operate the NES. Then later (or even before), we could make a tutorial which covers just 6502 and nothing really NES related. (Note I'm not really suggesting we break it up like this -- this is just a loose idea)

An all-in-one shot is very difficult to do. Trying to teach 6502 alongside the back-asswards restrictions the NES imposes is rough. And if we also have to explain what a variable is, how labels work, how program execution flows (what code will execute when), and all that fundamental stuff -- there's just no way it can really be done effectively.

I definately feel... before anything NES-specific is exposed to the reader, we assume they have a basic (but comprehensive) understanding of 6502. I'm not saying they have to be 6502 gurus or anything -- but if we tell them stuff like "write blah to $4014" or something, they should know what we mean and how to do it. If we're talking about NES stuff, we shouldn't have to explain what 6502 instructions do... or even how addressing modes work. We might go over how certain addressing modes can be effectively applied -- but we shouldn't have to explain them in detail -- they should already have the jist of it.

and before they try to pick up 6502, we should assume they have basic programming fundamentals down. What a variable is and how to use them. How loops work and how to use them. Subroutines... program flow... etc.

That's my idea anyway.

So the question is... who exactly are we targetting? Do you think we should cater to people without any prior experience?

I was planning on targeting users with some experience programming in C. Asking people to learn 6502 assembly on some other platform first isn't all that easy because "some other platform" isn't well standardized. A lot of people don't own an old 8-bit computer such as a C=64 or an Apple II (and thus have no way of dumping the computer's BIOS for use in an emulator).

Part of the problem is people coming in without any prior programming experience. Those of us who came to nesdev FROM somewhere else didn't have much difficulty catching on because we pretty much already had the idea. What makes learning the NES as your first system especially hard is trying to swallow both its cryptic method of graphics programming, on top of learning how to use X assembler, on top of learning a new assembly language, on top of learning basic programming fundamentals.

Very well said. Meandering through some old posts I saw somebody complain that their assembler "threw up a black screen and disappeared", implying they had no knowledge of DOS. I thought about this a lot last night since I'm interested in a tutorial, and came up with the same problem that Disch mentioned. Forget Assembly, as days go by more and more people don't even know what the command prompt is. Where do the tutorials end?

In previous experience trying to learn new computer related things, I ran into this very problem: "Before you can do this, you have to learn this!" Then I'd get referred to some other person's tutorial (and a missing link to it), which was vaguely related to present subject. The same can be said for here...people have mentioned that the C64 guide is probably the best tutorial for 6502 out there, but yet...what do you use it with if you don't have a C64? Of course the answer is then to get a 6502 simulator/emulator/whatever, but...how do you use that? (I'm not saying I don't know how to use these things, but I'm referring to other readers).

I took a look at the C64 6502 tutorial, and it really is great. However as stated. this method sends the potential tutorial reader on a wild goose chase to search for a different software package (which they may or may not find), attempt to learn the software before even touching the tutorial, and then try to understand why certain parts of the tutorial may not apply to the simulator they are running stuff on.

My vote for prerequisite would be to attempt to write the book for somebody who has no prior programming experience. I doubt that we could write something so gracefully, but with that goal in mind, the tutorial would DEFINITELY be readable by somebody with some programming experience. Write it as simple and as slow as possible! Who cares if the reader has already programmed and knows what a variable is? They will breathe a sigh of relief and be more confident as they progress through introductory chapters, ready to take on the harder stuff.

Have a complete compendium from binary/hex to 6502 to NES, all in one. No separate tutorials spanning different text files that will get separated via the net, but one file.

Furthermore, have the book have side sections supporting NesDev's recommended software suites, OR just go all out and design the entire document around the tools that should be used. It would be tough to decide which tools/assemblers/simulators/emulators to use in the book, but would alleviate any extra confusion that the tutorial would otherwise create. For example, right now I'm using NesAsm, but I've heard very good reasons not to use it. That's one more notch into my confusion bank, tripping me up on the way to programming the NES. If I could read an ultimate tutorial that sais "USE THIS EXACT SOFTWARE PACKAGE" and possibly even include it in a zip file with it (with the author's consent), then I would be stoked.

My vote (based off of reading opinions here and my own experience) would be to write the 6502 section using the "6502 Macroassembler & Simulator" by Michal Kowalski. Any opposed?

Even more to mention...what type of file format to use? A simple text file would be great, but what about pictures and diagrams? Perhaps PDF or (gulp) MSWord format?

I still suck at the NES, and I moderately suck at the 6502, but I would be really excited to start a 6502 section of the tutorial. Having the C64 guide as a side reference, it would be a great opportunity to filter out the good and bad, improve my own skills, and write an up to date document. At the very least it would allow me to contribute a little to a subject I know nothing about. What do you think?

Of course on the contrary, I definitely don't want to start on a defunct incomplete NES tutorial that is nothing more than a 6502 reference. Who else is excited about this?

Bah screw it, I am starting tonight on the 6502 stuff. The worst that can happen is that it gets rejected by tommorrow and I lose a couple of hours of writing. I need the practice anyway.

What we need are people who are willing to get together and discuss designs for new tutorials without hastily throwing them together. Not some kind of random posting to a Wiki, actual English communication where all aspects of the tutorial design are discussed and approaches proposed. After a while a general approach to tutorials would emerge, with outlines for each tutorial. A more coherent strategy for documentation would also come of this.

Okay so after getting overtly excited about starting right away, I reread this and slowed myself down. Tonight I will start on basic concepts and design for a 6502 tutorial, and propose them later rather than writing immediately.

I'd like to see what you can do as for a 6502 tutorial from the ground up. Most of the 6502 tutorials that I've read assume knowledge of the BASIC interpreter that was shipped with the same machine, as they're geared toward developing subroutines for BASIC programs, not pure asm programs.

Personally, I just knew a bit of basic with my C64 and Visual Basic before I learned 6502. I had no other programming knownledge, and I had no trouble learning how 6502 works and how to write routines for it at all. I didn't got any problems for the NES graphics thanks to Nesticle, that show pattern tables, palette, name tables, etc...
However, I got a lot of problems with how to structure my code to get easy handling to separate NMI code and non-NMI code (game loop). At the begining I was always trying to do everything in the NMI routine and nothing out of the NMI routine, as many demoes did show. However, that was a bad idea, and that lack of help to structure my code did slow me a lot while learning how to programm the NES.
Another thing that slowed me a lot is that I didn't understand the fact that the VBlank is short, and that then the frame continues while my code is running. Before, in my mind, I just had infinite time to code what I want between frames and to update as much PPU stuff as I want. Well, maybe not infinite, but I was just really thinking that the CPU was much faster than the PPU. It was just logical to me.

Now, I'm experienced and it is hard to impossible for me to revert in the skin of a newbie and to think about what would be good method to teach me things. I also tend to learn things easily when they interest me, even if they are complicated. For that reason, I also suck to explain things to people that have trouble to undertand things, even when they want to learn, because I think they play stupid. In other words, I'd be a very bad teacher.

_________________Life is complex: it has both real and imaginary components.

Who is online

Users browsing this forum: No registered users and 7 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum