nesdev.org

Ok, optimizations aside, what are features you would like to see in an assembler?

One of the things I am really set on having is block comments (/* */).

Are there any features you wish a current 6502 assembler had? Anything you really don't like?

GCC has a feature analogous to lint (-Wall); adding such a checker to ca65 should ideally qualify. If organized education fails to recognize that a solution that builds on an existing free software product is just as valid as a solution from scratch, that'd explain a lot of the NIH syndrome I've seen. (For more about NIH, see my previous post discussing definitions of plagiarism.) Are these IB criteria a trade secret?

As for your second question, almost every assembler feature that I've needed I've been able to implement as a preprocessor. See for example my source code shuffler written in Python (implementation and discussion), intended to help discover buffer overflows and to help trace leaked binaries.

I'd like to see a 6502/65816 assembler that supports the very 6502-like SPC700 instruction set with the same feature set that ca65 provides to 6502, 65C02, and 65816.

As it were, IB CS forces students to use Java. Now I'm not 100% certain, but I've got $20 saying the ca65 is not written in Java.

For the curious, the criteria are as follows:

1) Arrays
2) User-Defined Objects
3) Objects As Data Records
4) Simple Selection (if-else)
5) Complex Selection (nested if, if with multiple conditions, or switch)
6) Loops
7) Nested Loops
8.) User-Defined Methods
9) User-Defined Methods w/ Parameters
10) User-Defined Methods w/ Return Values
11) Sorting
12) Searching
13) Binary File I/O
14) Use Of External Libraries
15) Use Of Sentinels/Flags

Personally I think the whole IB CS thing is a load of shieße. Had I known what I was getting into with this class, I would have not taken it. To give you an indication of the level of mastery my teacher has, he once told the class you could concatenate two chars into a String in 'System.out.println()' by separating them with a comma.

I told him to compile this:

If the Java language is the requirement, then a preprocessor might be the perfect project.

Well the one problem with only making a preprocessor is that my teacher wants us to read and/or write a binary file. I can't imagine ever having to do anything involving binary files for a preprocessor.

Anyway regarding a compiler, aside from macros and block commenting, are there any other desirable features out there?

Haha, make it compile, but also output 8-Bit BIN files of the code with another command line switch? It's not that hard at all with C. Even noobs like me figured it out quite easily, even if not that good.


Well this is sounding very interesting now and has great ideas. I hope you get a good grade and your tool gets used alot! Sounds like it'll be good.

67726e wrote:Well the one problem with only making a preprocessor is that my teacher wants us to read and/or write a binary file.

Then add a new directive .incdpcm that takes a .wav file (binary), encodes it to DPCM, and spits out a huge block of .byt statements. I did something similar for the GBAdev community when the GNU assembler didn't have .incbin.

I talked to my teacher about my choice for the final project and he isn't 100% sure even a compiler would fulfill all the requirements. He is emailing some IB brass to find out what they have to say about it.

That sounds like a really retarded teacher. Just tell him you'll be working with assembly, if that will be fine, and tell us how he answers to that. lol.

Maybe you should try to write the next BASIC compiler for the NES. Make it ridiculously easy to write a "hello world" program on the NES. But provide the ability to stick in pure asm when needed, etc. It would make for an awesome tool for total beginners to programming who want to eventually learn enough to make a game.

67726e wrote:One of the things I am really set on having is block comments (/* */).

Agreed, I hate having to go line-by-line to comment something out.

cartlemmy wrote:

67726e wrote:One of the things I am really set on having is block comments (/* */).

Agreed, I hate having to go line-by-line to comment something out.

I do too. When I need to comment out more than a dozen or so related lines, I'll use ".if 0", ".endif" to temporarily disable them.

I've decided that if the compiler it enough on its on, I'm going to through the compiler in with a small 'IDE' that basically just manages the current project you are on and offers syntax highlighting.

Either way I will be writing some kind of compiler for fun at the very least. And FYI, I just wrapped up the code that strips out line comments from the source file so at the very least a preprocessor utility is with that feature will happen.

3gengames wrote:That sounds like a really retarded teacher. Just tell him you'll be working with assembly, if that will be fine, and tell us how he answers to that. lol.

Its not so much the teacher so much as it is the IB program and their rules on what you have to do to prove you have 'mastery' over the language. I originally was gonna write this in C++ and just use JNI to put it in a Java shell but anything that isn't written in Java is not taken into consideration for the 'mastery' portion.

Gradualore wrote:Maybe you should try to write the next BASIC compiler for the NES. Make it ridiculously easy to write a "hello world" program on the NES.

Yeah, something along the lines of batari Basic. A lot of people who had no clue about programming are making Atari 2600 games with it (and some are actually good!), and that's a system that's not particularly easy to code for, specially when you are completely oblivious to programming. It abstracts all the hardcore stuff such as screen-drawing kernels (by providing a set of general-purpose built-in kernels) and leaves just the game logic itself and the art for the programmer.

The equivalent of that on the NES would be to radically facilitate video and audio generation. For example, the programmer would interact with the name tables through an array, without ever having to worry about VBlank and NMIs. Behind the scenes, your framework would delay all such updates so that they were performed at the correct times, but the user doesn't have to care about that.