I was working on some other compiler and want to get a fresh breeth, so, I worked on that project.

It support basic syntax and some preprocessor directives. It can generate binary file (ROM) but not ELF or MBF format. You can use it for NES or Atari game development. I will be happy to get feedback and improve it make it usable by who interest on that.

https://github.com/erhanbaris/timu6502asm

Hello, and welcome! Well done, it's always good to see a software project which is useful to 6502 users.

I think perhaps it would be best to call this an assembler - even better if you could edit the subject of this thread. Otherwise we might have a pointless reply (or two) about the use of "compiler" versus "assembler" - which to me is obviously just a difference of dialect.

Done

Great!

What we should really be doing is discussing the facilities your assembler offers - of course, I haven't had a good look.

Also notable, on this forum you'll find a number of unique self-built 6502 computer designs, as well as interest in the historical offerings from Commodore, Apple, Acorn, and others. We're quite well distributed over the various possible interests - including but not limited to the consoles.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Oh, one thing I notice in your README, Erhan, is that you do offer local labels - a nice feature - but you call them 'branches'. I think everyone would say that a label is the place you get to, whereas a branch is the means of getting there.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I made a small mess in the README file. I'll make the necessary correction. Since English is not my first language, I occasionally make mistakes. I appreciate all of your feedback. I'll take care of those problems as soon as I can, and feel free to request any more features that you would really like to see or use. Since I wrote it in less than ten days, not many features are available at this time. If someone is interested in my project, I intend to dedicate more effort to improving it.
I will check all those links and try to change based on those informations.

Very impressive! Not to worry too much about your English - easily corrected!

I see you have a few minimal test files - it might be good also to have an example file which shows every feature. In particular, all of your directives.

One directive which might be useful is an alignment directive - for example to place something at the next page boundary.

That's what every assembler I've used does, and it's almost always what you want.

But not always always. Occasionally there's a need for assembling code to one location with the intent that it be copied to another before it is run (such as CHRGET in Microsoft's BASIC). Do any assemblers provide a way to do that? It's not something that would be used often, but it would be a useful feature to have.

Most assemblers can do that. I most cases the .org statement defines the stert adress of the code, but not the location of the code in the source file. Thus, by careful .ORGing und referencing the code in question can be easily copied to its destined location in memory.

Dietrich

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

vasm supports the rorg directive to do that:

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I haven't studied the behaviour of org in this assembler. But one common little difficulty - not really a difficulty, but often seen as one - is that, for example, code which lives in a ROM which will ultimately be accessed at say $8000 will have addresses in the ROM which start at $0000. There's a difference between the offset in ROM, and the address the 6502 sees.

I think this difficulty is resolved by the way in which the assembler can produce a binary, or the way in which that binary is used to produce a ROM image.

(In the case of emulators, of course the ROM image will be a binary file loaded by a program. In the case of physical systems, the ROM image will be fed to a programmer, or built into a bitstream, or loaded by a monitor.)