Jump to content
IGNORED

Crimson Editor 6502 syntax spec - first cut


Slor

Recommended Posts

I did a bit of searching to see if there were any syntax files available for 6502 assembly editing with Crimson Editor. While I found a couple posts of people requesting such files as well as at least one post by someone who has at least done part of it already, I could not find anything readily available to grab and use for my coding. So, I took it upon myself to start working on one, and the endeavor is also turning out to be a good way to brush up on my assembly while finding differences among various assemblers.

 

To make a long post short, I have posted the syntax files I created for anyone interested. I welcome any feedback from those of you who use Crimson Editor, and I'm specifically interested in reports of any errors and omissions in the spec. I'll warn you that I started with the 8-bit compilers that I'm most familiar with and am branching out from there in an effort to make the syntax coverage as complete as possible. After a few rounds of revisions, I plan to submit this to the Crimson Editor forums for public comsumption. You can grab it here:

 

http://www.slor.net/a8/6502spec.zip

 

 

thanks

James

Link to comment
Share on other sites

I did a bit of searching to see if there were any syntax files available for 6502 assembly editing with Crimson Editor. While I found a couple posts of people requesting such files as well as at least one post by someone who has at least done part of it already, I could not find anything readily available to grab and use for my coding. So, I took it upon myself to start working on one, and the endeavor is also turning out to be a good way to brush up on my assembly while finding differences among various assemblers.

 

To make a long post short, I have posted the syntax files I created for anyone interested. I welcome any feedback from those of you who use Crimson Editor, and I'm specifically interested in reports of any errors and omissions in the spec. I'll warn you that I started with the 8-bit compilers that I'm most familiar with and am branching out from there in an effort to make the syntax coverage as complete as possible. After a few rounds of revisions, I plan to submit this to the Crimson Editor forums for public comsumption. You can grab it here:

 

http://www.slor.net/a8/6502spec.zip

 

 

thanks

James

Thanks! I'd meant to do that, but I never got a round tuit. I want to make one for bB's commands, too.

 

Michael

Link to comment
Share on other sites

Thanks! I'd meant to do that, but I never got a round tuit. I want to make one for bB's commands, too.

 

Michael

Well, duh! I have two installations of Crimson Editor-- one under "Program Files," and another one under "Atari2600" (which is the one I'm actually using these days). I just checked the one that I'd originally installed under "Program Files," and I have batari Basic language files that I'd created back on December 25, 2005! I need to update them, since they're for bB 0.35, and there are several new commands or keywords that I need to add, but I did include the 6502 assembly opcodes, plus the standard names of the Atari 2600's memory addresses (or TIA/RIOT register names), since inline assembly can be included in bB programs. Here's what I have for now, and I'll post updated versions if I ever get a round tuit so I can update the files for version 1.0.

 

Also, I looked at your 6502 assembly language files, and I like what I see-- although I would like to suggest that you add (or consider adding) the compiler directives without the dots in front of them-- e.g., BYTE (or byte) in addition to .byte, etc.-- since DASM will allow either format. Perhaps you can guess that I like to use BYTE, WORD, HEX, etc., without dots in front of them! :)

 

Michael

batari_basic.zip

Link to comment
Share on other sites

Also, I looked at your 6502 assembly language files, and I like what I see-- although I would like to suggest that you add (or consider adding) the compiler directives without the dots in front of them-- e.g., BYTE (or byte) in addition to .byte, etc.-- since DASM will allow either format. Perhaps you can guess that I like to use BYTE, WORD, HEX, etc., without dots in front of them! :)

 

Michael

 

Thanks - that's the kind of input I need. I'll take a look at DASM and pull out the corresponding directives.

 

James

Link to comment
Share on other sites

  • 2 weeks later...

I added DASM stuff and replaced the download file.

Thank you again! And I was obviously hallucinating when I looked at my batari Basic syntax files, because there were no 6502 opcodes in it after all-- but I do have the TIA/RIOT registers in it.

 

Michael

 

Anyone else tried this out? I have revised and re-posted this a few times, so feel free to grab the latest. I will post it to the Crimson Editor forums soon.

 

James

Link to comment
Share on other sites

I added DASM stuff and replaced the download file.

Thank you again! And I was obviously hallucinating when I looked at my batari Basic syntax files, because there were no 6502 opcodes in it after all-- but I do have the TIA/RIOT registers in it.

 

Michael

 

Anyone else tried this out? I have revised and re-posted this a few times, so feel free to grab the latest. I will post it to the Crimson Editor forums soon.

 

James

I didn't realize you had posted newer versions, I'll download the latest and try it. :) Thanks!

 

Michael

Link to comment
Share on other sites

  • 1 month later...

I tried out the syntax files with the cc65.org compiler and there are some keywords I would like to add:

 

ina

 

jne

 

bra

 

jeq

 

dea

 

stz

 

jcs

 

These are commands I found to have wrong colors when examining the output of the C-compiler. There may be more.

 

Here are some interesting examples of the cc65.org compiler output:

;
; memcpy(palette, paraback_beverly_hills, sizeof(palette));
;
L056A:	ldy	 #$1F
L0570:	lda	 _paraback_beverly_hills,y
sta	 _palette,y
dey
bpl	 L0570

 

I was expecting that the compiler would make a call to a routine memcpy. Instead it inlines the memcpy code.

 

; ---------------------------------------------------------------
; void __near__ erase_eeprom ()
; ---------------------------------------------------------------

.segment	"INTRO_CODE"

.proc	_erase_eeprom: near

.segment	"INTRO_BSS"

L0746:
.res	1,$00

.segment	"INTRO_CODE"

;
; {
;
jsr	 enter
;
; for (i = 0; i < 64; i++)
;
lda	 #$00
L09FF:	sta	 L0746
cmp	 #$40
jcs	 leave
;
; write_eeprom(i, 0xffff);
;
lda	 L0746
jsr	 pusha
lda	 #$FF
jsr	 pushaFF
jsr	 _write_eeprom
;
; for (i = 0; i < 64; i++)
;
lda	 L0746
ina
bra	 L09FF

.endproc

 

I wonder if the Crimson Editor could be connected to the Handy for debugging the code. Single stepping and setting breakpoints would be very useful as the compiler produces very understandable output. So it does not really matter that you cannot debug C directly. But I would love to use the intermediate commented file instead of crude disassembled code.

 

--

Karri

Link to comment
Share on other sites

I tried out the syntax files with the cc65.org compiler and there are some keywords I would like to add:

 

ina

 

jne

 

bra

 

jeq

 

dea

 

stz

 

jcs

 

Hi Karri - I believe the above keywords are currently handled (or not handled) as appropriate:

 

- ina, bra, dea, and stz are opcodes specific to the 65C02 processor, so they are highlighted in a different color than the base 6502 opcodes. The 6502 base opcodes are in one color, the illegal 6052 opcodes in a second, and 65C02 and 65816 additional opcodes in a third.

- jne, jeq, and jcs are actually macros defined by the ca65 longbranch package. They are not highlighted since they are not truly opcodes and are not reserved words unless specifically defined by that macro package.

 

That make sense?

James

Link to comment
Share on other sites

I tried out the syntax files with the cc65.org compiler and there are some keywords I would like to add:

 

ina

 

jne

 

bra

 

jeq

 

dea

 

stz

 

jcs

 

Hi Karri - I believe the above keywords are currently handled (or not handled) as appropriate:

 

- ina, bra, dea, and stz are opcodes specific to the 65C02 processor, so they are highlighted in a different color than the base 6502 opcodes. The 6502 base opcodes are in one color, the illegal 6052 opcodes in a second, and 65C02 and 65816 additional opcodes in a third.

- jne, jeq, and jcs are actually macros defined by the ca65 longbranch package. They are not highlighted since they are not truly opcodes and are not reserved words unless specifically defined by that macro package.

 

That make sense?

James

 

Makes lots of sense. I am lousy at assembler so I did not know this.

 

--

Thanks,

 

Karri

 

PS. I also checked Notepad++ and fell in love with that one as it has folds. The Scintilla (previous version of Notepad++) had a feature to launch compilation of a file (Ctrl + F7), complete project build (F7) and execute in debugger directly from the editor (F5). I have used it a lot in Atari Lynx developement. It is almost like an IDE. The only problem is that the debugger opens a new window for single stepping through the code and does not work with the original source.

Link to comment
Share on other sites

For TextPad there was a C64 assembler syntax colouring definition file.

http://www.textpad.com/add-ons/files/syntax/c64asm.zip

 

This can easily be used as a base for an Atari releated equivalent (e.g. CA65, DASM etc)

 

(I had done this before but is on my machine at my old work only, not at home.

I might be able to get someone to lift it for me though)

Edited by Wrathchild
Link to comment
Share on other sites

It didn't take too much to knock the basis of some support together for TextPad

(mostly for CA65 so may need tweaking for other assemblers)

 

Copy the syntax file to TextPad's "System" folder and then associate this with files such as '.s' and '.inc'. For example I created a new document class for these extensions and then associated the "Atari-asm (6502 CA65).syn" file with this. You can then adjust the colours to your liking.

Atari_asm__6502_CA65_.zip

post-1822-1176308913_thumb.jpg

post-1822-1176308945_thumb.jpg

Edited by Wrathchild
Link to comment
Share on other sites

I was expecting that the compiler would make a call to a routine memcpy. Instead it inlines the memcpy code.

 

You are compiling with -Osir? The -Oi inlines some "well-known" library functions (don't ask me which ones though!)

 

I am compiling all my code with these setting:

 

CFLAGS=-I . -t $(SYS) --add-source -O -Or -Cl -Os

 

Hmm. The first -O is probably not necessary. The compiler is really incredible. I like it a _lot_.

 

--

Karri

Link to comment
Share on other sites

I am compiling all my code with these setting:

 

CFLAGS=-I . -t $(SYS) --add-source -O -Or -Cl -Os

 

I usually compile with -Osir, which I think is all the optimizations. Maybe -Oi inlines "more" code?

 

The compiler is really incredible. I like it a _lot_.

 

Yes, I think Ullrich and crew have done an excellent job on it. I use it pretty much exclusively for my small projects.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...