My First C64/X16 Programs!

[SlithyMatt]

54 minutes ago, geek504 said:

Yeah, I am having problems getting SharpNinja extension to work smoothly if at all... it's really old. I am now trying to setup Atom like Matt says below:



So I revert to Matt and ask... what's your setup like? Config files, workspace, hotkeys, build process, etc.

It's pretty dead simple, and pretty much how I have shown it in my videos.

For all my projects, I use Atom as my "IDE", because everything I do is hosted on GitHub and it provides really nice integration for that. I use the following "community" packages that are specifically for my development:

* file-types - This is how I set up specific rules for determining what syntax highlighting to use for different filename patterns by adding statements to the config.cson file.

* language-65asm - This provides syntax highlighting for multiple 6502 family assemblers, including ca65, which I use as the target file types in the config

* language-xci - My very own package for XCI source highlighting! It opened my eyes to just how easy it is to publish a community package, which is both exciting and terrifying

So, to set up the config, I added this to config.cson (accessible by going to Edit->Config...):

  "file-types":

    "*.asm": "source.assembly.6502.cc65-toolchain"

    "*.inc": "source.assembly.6502.cc65-toolchain"

 

So, as you can see, I use *.asm because *.s just seems weird and wrong to me. To each their own!

I am running Linux, so the build environment is within the Bash shell and my projects use Bash build scripts, GNU makefiles, or both. I simply call all of these from a terminal window, usually with multiple tabs so that I can switch between different working directories and have separate histories where I do the same few commands over and over again. Generally, I'll have one in the directory where I build from, and another in the directory where the build is  placed and I can then run it in the emulator.

I know some folks really want to have the workflow extremely streamlined so that the build is happening within the IDE, but I just prefer a dedicated terminal tab. You could totally create a button or hotkey within Atom that will call your build script or makefile and then launch the emulator with what was built, but that's not something I really feel the need to have. I'm a Linux/Unix person, and I like to use my terminals.

[geek504]

On 9/21/2020 at 1:55 AM, SlithyMatt said:

It's pretty dead simple, and pretty much how I have shown it in my videos.

Err... what videos?

My config.cson didn't need the use of * file-types as per the instruction of the * language-65asm package:

Quote

"*":

  core:

    telemetryConsent: "no"

    uriHandlerRegistration: "always"

  "exception-reporting":

    customFileTypes:

      "source.assembly.6502.cc65": [

        "asm"

        "inc"

      ]

Also you mentioned:

Quote

I am running Linux, so the build environment is within the Bash shell and my projects use Bash build scripts, GNU makefiles, or both. I simply call all of these from a terminal window, usually with multiple tabs so that I can switch between different working directories and have separate histories where I do the same few commands over and over again.

In that case, Atom might as well be Emacs with syntax highligting...  

[SlithyMatt]

46 minutes ago, geek504 said:

Err... what videos?

https://www.youtube.com/user/slithymatt

I missed that instruction for language-65asm. If that works, then you don't need the file-types package in this case.

You could certainly make emacs have a lot of Atom features, if you're an emacs sort of person. Atom is much more of a modern text editor and has a really nice interface with git and GitHub, which is all I need.

[SerErris]

I worked a little in Atom now and added to the language-65asm as I did not like some things:

1. the cc65 variant does highlight #$FE0A in on thing (so the # is the same color as the following constant). I like to have it separated as # is an operator and $FE0A is a constant. Also as # is such an important thing not to overlook ... Better it sticks out.

2. I like that the cc65 labels/constants/symbols are highlighted everywhere I find them, to clearly identify them in the source code. In the cc65 grammar labels or symbols do not exist at all ... 

3. I like to highlight illegal statements ... e.g a label that is a register (A: or X: would not work as the assembler will interpret that as X register).



The output looks like that so far (colors need work ??



There is one thing in my grammar file, that I do not understand. 

I cannot get the highlighting of the X in line 39 off. 



This is the regex that is activating it.

# Registers

      {

        match:  '(?!^\\s*[AXY])\\b[AXY]\\b'

        name:   'keyword.parameter.register.ca65'

      }

It is supposed to highlight a single letter AXY but NOT if it is at the beginning of the line with only whitespaces in between. It is actually working for directly at the beginning of the line. But not if there is one space in it. I am puzzled ... and do not understand how to instrcut the regex to math it but not if there is nothing else before than whitespaces.



Maybe anyone of you have ideas... 



However I attached my ca65.cson file - which you can simply copy into the language-65asm grammars folder and you can work with it. The colors of cause are coming from your scheme and require adoption as well. I will create a color scheme later on, purely for the cc65 usecase.



Other todos: I have no idea how to get the folding right. It currently folds only on indention and not on .scope/.endscope or anything alike. Anyone ever got that to work?


ca65.cson

[Ender]

1 hour ago, SerErris said:

There is one thing in my grammar file, that I do not understand. 

I cannot get the highlighting of the X in line 39 off. 



This is the regex that is activating it.



# Registers

      {

        match:  '(?!^\\s*[AXY])\\b[AXY]\\b'

        name:   'keyword.parameter.register.ca65'

      }



It is supposed to highlight a single letter AXY but NOT if it is at the beginning of the line with only whitespaces in between. It is actually working for directly at the beginning of the line. But not if there is one space in it. I am puzzled ... and do not understand how to instrcut the regex to math it but not if there is nothing else before than whitespaces.

I think the problem is, regardless of the negative look-ahead at the beginning, the second part still matches the criteria. Maybe something like this? I don't have Atom in front of me right now to test it though:

Quote

{

  match: '^\\s*\\S+.*\\b([AXY])\\b'

  captures:

    1:

      name: 'keyword.parameter.register.ca65'

}

 

[SerErris]

Hmm the regex is supposed to match the second part \b[AXY]\b but not if the first part is matched before (which is ^\s*[AXY] or beginning of line with any number of whitespaces followed by one character AXY ... that should actually work. 

 

what is this captures Statement doing? I could not find the right documentation to explain how the grammar file is setup.

[Ender]

5 minutes ago, SerErris said:

Hmm the regex is supposed to match the second part \b[AXY]\b but not if the first part is matched before (which is ^\s*[AXY] or beginning of line with any number of whitespaces followed by one character AXY ... that should actually work. 

 



what is this captures Statement doing? I could not find the right documentation to explain how the grammar file is setup.

In the regex I wrote, the part you want to match is just the [AXY], so I put it inside of a capture group. That statement should choose only group 1 for the match.  I found a reference to it here https://gist.github.com/Aerijo/b8c82d647db783187804e86fa0a604a1

[SerErris]

Awesome ... not sure why that is not part of the official flight manual

[pastblast]

On 9/1/2020 at 9:48 AM, SlithyMatt said:

This was a surprising discovery for me, since the only 8-bit assembly I did before learning 65C02 for the X16 was Motorola/Freescale 68HC11, which did have 8x8 multiplication, thanks to the ability to combine the 2 8-bit accumulators (A and B) into a single 16-bit accumulator (D). I had assumed all these years that that was standard for a lot of 8-bit CPUs, but was actually a very specialized feature to support the 68HC11's signal processing capabilities, being a primarily embedded microcontroller variant of the 6800, which did not have built-in multiplication despite having the same register structure.

Yeah, I was surprised by the comment, too, because I "grew up" on the Motorola 6809E in the Color Computer, which not only has a hardware multiply instruction, but also 4 index registers (X, Y, U, and S). The auto-incrementing made memory-to-memory copies a breeze.