Before you try to program for the NES, you should learn about basic computer-related things, like the command line prompt because it looks like you don't know about it yet.

Also, you should research what a compiler is and what it does.

And I don't understand why you insist on getting a video tutorial. If you want to become a programmer, you should be able to gather information in text form. Not everything will be presented to you in the form of a video.

But in the moment, this point is moot anyway. You won't get very far with NES programming if you seriously have to ask for a video tutorial on setting up a simple compiler from a zip file. That's like trying to write a novel without even being able to read.Even if you follow the instructions that the other users listed for you, you will most likely be stuck by the next step. And the next step afterwards. And so on.

Before bothering with NES programming at all, it's mandatory that you have basic computer knowledge. For a start, research what the windows command line prompt is and what a compiler is used for.

Also, for starting programming, you should use something different than the NES. The NES is very specific.Since you don't even seem to know how to program at all (otherwise you wouldn't ask where to enter the source code), I'd suggest to start with a C, C++ or C# tutorial for Windows (at least the first few chapters) where you write simple text-based applications, so that you first learn about the concept of programming before you get to the highly hardware-specific NES.

Please don't let this discourage you. But I think if somebody wants to start with something, he should start at the beginning. Programming the NES is advanced stuff. Don't do this unless you know what a Win32 console application is and you can create one yourself from a source code file.

Friend, you kind of jumped to conclusions about me, I know what is the command prompt as well as have notions of informatica and also already programmed some things just never programmed anything for old consoles and I would just like to know how to make a rom, a video class would be enough for the rest I am able to learn from research ...

It sounds like you are more than capable of following the instructions of the linked tutorials or FrankenGraphic's post.I doubt that anyone here is going to bother recording a video tutorial about typing text in a text editor and running it through a compiler or assembler.If you are using windows I'd recommend Notepad++ as your text editor, that's what I've been using anyway.

If there's something in particular you don't understand you can post and ask about it on this forum.

I know what is the command prompt as well as have notions of informatica and also already programmed some things

If you know the command prompt, then that's even better. I assumed you didn't because you had problems running the cc65 compiler. Which is literally just a zip file that contains a bunch of command line tools like "cc65.exe" or "cl65.exe". If you know about the command line, starting these programs should be pretty simple. cc65 even has a step by step documentation included.

vedita wrote:

just never programmed anything for old consoles and I would just like to know how to make a rom, a video class would be enough for the rest I am able to learn from research ...

Before you try to program for the NES, you should learn about basic computer-related things, like the command line prompt because it looks like you don't know about it yet.

Also, you should research what a compiler is and what it does.

And I don't understand why you insist on getting a video tutorial. If you want to become a programmer, you should be able to gather information in text form. Not everything will be presented to you in the form of a video.

But in the moment, this point is moot anyway. You won't get very far with NES programming if you seriously have to ask for a video tutorial on setting up a simple compiler from a zip file. That's like trying to write a novel without even being able to read.Even if you follow the instructions that the other users listed for you, you will most likely be stuck by the next step. And the next step afterwards. And so on.

Before bothering with NES programming at all, it's mandatory that you have basic computer knowledge. For a start, research what the windows command line prompt is and what a compiler is used for.

Also, for starting programming, you should use something different than the NES. The NES is very specific.Since you don't even seem to know how to program at all (otherwise you wouldn't ask where to enter the source code), I'd suggest to start with a C, C++ or C# tutorial for Windows (at least the first few chapters) where you write simple text-based applications, so that you first learn about the concept of programming before you get to the highly hardware-specific NES.

Please don't let this discourage you. But I think if somebody wants to start with something, he should start at the beginning. Programming the NES is advanced stuff. Don't do this unless you know what a Win32 console application is and you can create one yourself from a source code file.

+1If you can't even learn on your own without a video, you can forget about NES programming immediately. However doing a Win32 application is not a necessary step for coding on the NES, but it'll help in developing your own tools when a specific tool is lacking in what already exist. For example I had to use my own tool to compress my levels in my game.

Quote:

Just out of curiosity: What do you dislike so much about C?

Can't speak for him, but there's plenty of things I dislike about C. Making an explicit list wouldn't be terribly useful, as you can probably get a lot of C langauge critisism by searching the internet. However my major gripes are :

The necessary of ; to terminate statements

The abundance of symbols like { } [ ] which are easy to reach on an american keyboard but hard and annoying to reach on a german-style keyboard like we have here

The necessity to either declare function in headers before you use them or have them in a specific, un-intuitive "declare-before-use" order

Case sensitive labels/variables

The type system is retarded, the size of an int is unknown cannonically so you have to use weird crap using SIZEOF. Yes in "modern" C we can use types like uint16_t and know their size but they don't come naturally.

The way pointers/arrays are declared and used is FUCKING RETARDED

C-strings impose a format of zero-terminated strings when you would want to use otherwise (for example, $ff terminated or having the length as a header)

Inability to call arguments by value (bad)

The confusion between = and == symbols is constantly annoying

Memory management is a headache

The "*" symbol can mean 3 different thing, the "const" keyword is annoying and the "static" keyword can have 3 completely different meanings, all of them very poorly described by the word "static".

None of this prevents me to use C and write C programs, but that doesn't change I do not like the language very much.Actually while writing a program in both assembly or C is not particularly hard per se, I find understanding C code I wrote 5 years ago again typically much harder than assembly code I wrote 5 years ago, ironically. But this depends on a case-per-case basis.

The abundance of symbols like { } [ ] which are easy to reach on an american keyboard but hard and annoying to reach on a german-style keyboard like we have here

I couldn't agree more. Since these are symbols that are normally never used in Swedish writings, they are placed so they require the AltGr key to be held instead of shift. But in programming they are used all the time, which gets really tiresome. Same goes for other symbols that requires AltGr including @, $, £, \, ~ and |, but they are not used as often as {[]} so they are usually fine. The exception is $ which is used all the time in 6502 assembly as hexadecimal notation. I'm just glad that semicolon (also never used in Swedish writings) is easy to type, it only requires holding shift. But GNU ARM assembler apparently uses @ for comments, what a nightmare!!

I couldn't agree more. Since these are symbols that are normally never used in Swedish writings, they are placed so they require the AltGr key to be held instead of shift. But in programming they are used all the time, which gets really tiresome. Same goes for other symbols that requires AltGr including @, $, £, \, ~ and |, but they are not used as often as {[]} so they are usually fine. The exception is $ which is used all the time in 6502 assembly as hexadecimal notation. I'm just glad that semicolon (also never used in Swedish writings) is easy to type, it only requires holding shift. But GNU ARM assembler apparently uses @ for comments, what a nightmare!!

Well here the '$' is accessible directly without needing neither shift nor AltGr keys. I guess we're lucky. '@' is relatively easy to access because we can use AltGr with our right hand wile typing '2' with our left hand. However the []{} needs to type both AltGr and the corresponding key with the right hand, which is very tiresome.

Actually I'm seriously considering switching to Pascal or Python language as a "default" programming language JUST to get rids of the brackets.

Actually I'm seriously considering switching to Pascal or Python language as a "default" programming language JUST to get rids of the brackets.

C does have two alternatives built in. The first is trigraph and digraph alternatives to those as part of the language standard, e.g. ??< (trigraph) and <% (digraph) both have the same meaning as {, but also #define would let you pick a symbol of your choice to replace it. Most compilers these days (including CC65) seem very tolerant of unicode as well.

It caused me to remember my experience collaborating with teammates on The Curse of Possum Hollow. The most confusing thing about setting up any toolchain on Windows is PATH configuration, as the steps seem to change with every Windows version. It needed Skype screen sharing when I walked people through it the last couple times. So setting up PATH might be the one step that needs a video.

Yeah that one is indeed confusing and Microsoft loves changing these things.

Personally I often just throw the assembler and linker (or other command-line program) in the same directory as the bat file so I don't have to setup PATH on every single computer with every single command-line program I happen to be using at the moment. They are often so small that it doesn't make much of a difference.

I just put a copy of cc65 in a cc65 folder at the same level as each project, and then my command lines are just relative like cc65/bin/cc65 etc.

There are only a few cases where I'm happy at all with using a global PATH. Especially not with programming, where projects can have varying age, dependent on different versions of tools and libraries, etc. I want that all relative whenever it's practical to do so.

Who is online

Users browsing this forum: No registered users and 5 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