Hi,
Does anobody here know a syntax highlighting editor for the 6502 assembler? I'm trying to use gedit with the following language-specs file:

http://www.ele.uva.es/~jesus/6502/asm6502.lang

I modiffied this file from another example, but the results aren't satisfactory yet. The main problem is the rule set for hex. and binary numbers. It would be also interesting to have a different style for labels, directives and immediate operands. But, I must admit I don´t know much about regex...

I'm using PSPad, http://www.pspad.com/en/. You have to make your own INI file for the text to be highlighted but you can have a copy of mine of course. Another nice feature of PSPad: with Ctrl/F9 you can start up a compiler during editing.

_________________

Thanks, but I forgot to mention I wanted an editor for Linux. PSPad looks nice, but I don't think it is a good idea to switch to a Windows OS just for the sake of the editor. Meanwhile, I found a better language-specs example (for NASM) and after some mods I came with an usable syntax highlighting for gedit. The language-spec file for the 6502 assembler can be downloaded fom here:

http://www.ele.uva.es/~jesus/6502/asm6502.lang

This file has to be copied to the following directory:

/usr/share/gtksourceview-2.0/language-specs

Then select: "View -> Syntax Highlight -> Other -> ASM6502" on the gedit menus (english names for menus can be different. I got them in spanish). Here is how it looks:

_________________
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?

Hi Jesari
thanks for sharing your work. I use emacs and it usually syntax colours things (until I turn it off for better readability.) I'm not using more than 1% of what emacs offers, but my fingers know the basic commands so I continue to use it.

I think Garth's point in this case is that operations on 16bit data values can usefully be wrapped in macros, to be more readable and reliably correct. It would be interesting to see how a highlighter deals with macro definitions and usage.

Cheers
Ed

... And that was only a tiny piece of code. Wait until you see the remaining 2800 lines...
Macros can help. You're right. But they have a different syntax on each assembler. Even the labels can have different syntaxes (colon suffix or not). So, at the end, I'm just writing plain assembler for ca65. ca65 is part of the C compiler cc65 and it could possibly use the cpp macros: #define DEC16(ptr) (lda.....)
Indentation is always possible. No excuses this time...

_________________
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 was beginning to wonder there, Garth.

I would like to offer this tip to aid code legibility though: try to prevent yourself from stating the obvious in your comments. For example,



is pretty obviously incrementing a pointer. We know it's a pointer because of the operand labels, and we know it's incrementing because of the INC instructions.

A better technique for comments is to explain why you're doing what you're doing, not what. To help illustrate what I mean, consider this hypothetical piece:



or:



Depending on the experience level of the reader, though, he might find even these comments to be unhelpful, since these are such common 6502 idioms. But I hope they illustrate the qualitative difference in commenting style.

Just a friendly suggestion.

Perhaps the topic would be better named "Syntax Highlighting for a 65xx-Aware Editor"

I do some work in the Kowalski simulator, which has a source code syntax highlighting capability, better described as field highlighting. I've found it to be only marginally useful, in that I already know 65xx assembly language and don't need an editor to tell me when I've made a boo-boo—the assembler will take care of that.

As for "colorizing" in editors such as EMACS or vi, I'd rather it be off by default. I'm blue-green color blind, and any attempt to spruce up text with color is usually annoying. I particularly find Linux's use of color in directory listings to be a pain, and immediately kill that feature.

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

One of the reasons why assembly language listings use columns dates back to the IBM punch-card days, where most languages (both high AND low level) placed various program terms on certain columns. They did this precisely because they had no means of indicating the type of construct at hand. For example, labels start in column 1, opcodes start at column 9, etc. In this way, it's perfectly legal to have a label LDA, and an opcode LDA, and they'd be fully disambiguated.



Today's low-level languages benefits from modern language research, including the field of LL and LR parsing techniques. It's now possible to write assembly language using more conventional program structure, though few people ever do so.



Syntax highlighting makes a lot more sense in this free-form, quasi-conversational approach. The cost is you lose potentially useful labels, and certain things become harder to see.

And then there is ColorForth[1], which kind of combines the two approaches. The editor doesn't highlight the source text, YOU highlight the source text based on how you want Forth to interpret your source code. Green code is compiled, yellow is executed immediately (e.g., compile-time), etc. This is singularly liberating! Unfortunately, it has its own trade-offs.

_______________
1. Chuck Moore doesn't care about any potential vision problems you might have; he wrote ColorForth for him. However, he does encourage folks who are color-blind to try that style of programming with, perhaps, different type-faces instead. The idea of tagging words at edit-time is universal; the choice of using colors to indicate this tagging is only an implementation-specific detail.

Color is fine and all that, but obviously is not going to help when displayed on a monochrome terminal, which device until relatively recently, dominated computer displays. I guess I'm just an old stick in the mud (or dinosaur in the swamp). I like my programming environment to keep color changes to a minimum. I also run my browser in monochrome, mostly because of sites like this with their pastel colors (hard for me to distinguish).

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

Hence the footnote. If all you have is monochrome displays, then you can substitute colors with typefaces. It does require a bitmapped terminal though.

I know this post is pretty ancient but I've been building a full 65C02 IDE for macOS and recently tackled this very problem. Numbers were the most annoying so I thought I'd share my solution (though my stylistic choices might bother some or all of you) but you can tailor it a bit to your liking. I've included a screenshot that illustrates most of the relevant numerical situations that have arisen for me with comments describing them.

Here are the regexes I use for the various types of numbers in Swift.



Hope this help someone tidy up their IDE of choice.

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

Seems like you and I are both grumpy today BDD. Allow me to translate: BDD has vision problems, and prefers that people post high contrast monochrome images.

Edit: I do apologise for this outburst. There is indeed a potential accessibility problem with low contrast images, and a polite request to post a higher contrast version would not be out of place.