Jump to content
geek504

My First C64/X16 Programs!

Recommended Posts

2 minutes ago, geek504 said:

Gotcha! But I think we don't have enough VRAM for two 320x200x256 buffers... that's why SlithyMatt did 2 pages with 16 colors each.

I'm going to start some assembly coding and would like to ask: What workflow are you guys following? Which assembler? What steps to get the binary file inside the emulator? etc. I think my way is just too slow...

And if you need more VRAM for other things like sprites, you can decrease the color depth and take up less space with the buffers.

I use the cc65 toolchain (C Compiler, Assembler, Linker, etc.) with Atom as my IDE for syncing with GitHub and getting syntax highlighting, etc.

  • Like 1

Share this post


Link to post
Share on other sites
27 minutes ago, geek504 said:

Gotcha! But I think we don't have enough VRAM for two 320x200x256 buffers... that's why SlithyMatt did 2 pages with 16 colors each.

Edit: DOH! 4bpp = 16 colors... I should go get my coffee...

I'm going to start some assembly coding and would like to ask: What workflow are you guys following? Which assembler? What steps to get the binary file inside the emulator? etc. I think my way is just too slow...

🙂 Yes 2x8bpp does not work. But 2x4bpp works. I would say in any animated form 8bpp is not usable if you use graphics mode and not tile mode. It is simply to much data to draw CPU constrained and also double buffering is not possible.

I do not like the cc65 approach ... I will never do and actually do not want to compile and then link my assembler .. I want to have it in my own hand how everything works. 

I am using C64studio that has ACME assembler included. It creates .prg files, that can be loaded directly into the emulator from the normal operating system. It also enters the typical SYS2062 to run your program at 080E .. ...

Edited by SerErris

Share this post


Link to post
Share on other sites

@SerErris I was impressed with C64studio as well. For my own Prog8 I'm also trying to make the whole process as smooth as possible so you just point it to a source file and it will compile it to assembly, run the assembler for you with the correct options, turning it into a .prg file and then launching that in the appropriate emulator executable.  It loads and autostarts the program.   From source code edit to running in the emulator in about 1 or 2 seconds on my machine. Works for C64 and CommanderX16.

The above is hotkeyed in my IDE too.  I'm using IntelliJ IDEA.  It's a really nice workflow for me because I'm still developing the compiler itself as well, in the same IDE

  • Like 1

Share this post


Link to post
Share on other sites
On 9/10/2020 at 9:08 PM, geek504 said:

That’s why I am wanting the X16 to be at least 20MHz! We could do so much with that 🤪

SuperCPUv2
Processor:  WDC 65C816S
Architecture:  8/16-bit
Clock Speed:  20 MHz
Opcodes:  Documented 6510 opcodes only

But you can't make a clock to clock comparison, since the SuperCPU was still bottlenecked to a certain degree by the 1MHz system bus. A hypothetical CX16 DMA card can talk to the Vera registers at 8MHz, while the SuperCPU  can only store to the RAM that the VIC can see at 1MHz. While designing the FPGA for the DMA, pick one with built in 16x16->32 multiply and include a scaled */ register setup for 16x16->32/16->16 operations. That avoids needing all of that tabled operation ROM.

Then alternate between turn off layer 0 and build in layer 0 and turn off layer 1, build in layer 1 Switch layers in VRefresh it should certainly be flicker free. Whatever resolution / color depth cannot support two bitmapped

And you get another level of effort reduction if you animate enemies and their cover onto sprites, since you can animate rising to fire or turning to call for help the same way with palette color games allowing the same animation to have enemies with different features and the higher priority sprite automatically masking whatever is being covered by the door frame, overturned table, etc, so that doesn't have to be blitted.

Indeed, don't get trapped in bitmap-only assumptions. Plenty of dungeon crawlers will rely on the 1024 16x16 tiles available. 15 tiles spans a 320x240 top to bottom, one will be the wall to ceiling corner, the ones below it the wall at that distance, the ones above it the ceiling progressively closer as you go up the screen. In a normal level the ceiling might only have the occasional water stain, so most ceiling tiles in a row duplicated. Similar for a walls and doorways. Then you have a handful of distinctive features for the ceiling or the walls, and those need to have the current version, the next and the previous ... as they come closer maybe multiple tilemaps ... but as you advance or retreat, you only have to update one tile set or tile at a time after a POV move has moved, and you are always updating not-in-display tilemaps, so that is not limited to VBlank.

That DOES NOT move you closer to executing a DOOM wad ... your POV needs to be a stable height above the immediate floor level for those to work ... and it constrains detail that isn't being added by terrain sprites ... but it seems like there's a lot of vertically scaled dungeon crawler game design to be explored in that space. Working on tiles in one layer while displaying the other will give much higher framerates than the equivalent bitmap approach.

Edited by BruceMcF
Stupid tablet autocorrect thinks a "DOOM wad" should be "DOOM was"
  • Thanks 1

Share this post


Link to post
Share on other sites
17 hours ago, SlithyMatt said:

I use the cc65 toolchain (C Compiler, Assembler, Linker, etc.) with Atom as my IDE for syncing with GitHub and getting syntax highlighting, etc.

 

16 hours ago, SerErris said:

I am using C64studio that has ACME assembler included.

I checked C64studio but in the end I chose cc65 toolchain with Visual Studio Code as my IDE...

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, geek504 said:

...in the end I chose cc65 toolchain with Visual Studio Code as my IDE...

I'm on cc65, and VS Code is what I use at work -- I should use it @ home as well, instead of vi.

 

Share this post


Link to post
Share on other sites

Remember, VS Code is basically just Atom with a Microsoft logo slapped on it. Atom has a huge community of folks writing add-on packages. You can convert those to work on VS Code, but you might as well plug right in to the wider open source community.

Just my 2¢

Share this post


Link to post
Share on other sites

Does Atom/VS Code allow debugging with breakpoints and stuff? Or is that also not working currently?

Btw: You can completely integrate the emulator into C64 studio to get your workflow to the point of beeing able to automatically compile and run it.

Edited by SerErris
Wrong thread

Share this post


Link to post
Share on other sites
On 9/11/2020 at 1:07 PM, geek504 said:

I checked C64studio but in the end I chose cc65 toolchain with Visual Studio Code as my IDE...

I am looking into that option now but have issues to get it to work.

I have cc65 running, I have Visual Studio Code and I use "cc65 for 6502/65816 machines" by SharpNinja as an expansion. However I cannot get VS Code to build anything. It never understands that it shall use cc65. Instead it asks me to tell VS Code what compiler to use.

Is there anything I need to configure in the workspace for it to work?

Share this post


Link to post
Share on other sites
On 9/19/2020 at 11:20 AM, SerErris said:

I am looking into that option now but have issues to get it to work.

I have cc65 running, I have Visual Studio Code and I use "cc65 for 6502/65816 machines" by SharpNinja as an expansion. However I cannot get VS Code to build anything. It never understands that it shall use cc65. Instead it asks me to tell VS Code what compiler to use.

Is there anything I need to configure in the workspace for it to work?

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:

On 9/10/2020 at 2:48 PM, SlithyMatt said:

I use the cc65 toolchain (C Compiler, Assembler, Linker, etc.) with Atom as my IDE for syncing with GitHub and getting syntax highlighting, etc.

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

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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...  

emacs-cc65.thumb.PNG.553e97e6425f371142ca50c960385b56.PNG

Edited by geek504

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 🙂😞

image.thumb.png.fab9e23699606ab35989218af069b019.png

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

Share this post


Link to post
Share on other sites
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'
}

 

Edited by Ender

Share this post


Link to post
Share on other sites

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.

Edited by SerErris

Share this post


Link to post
Share on other sites
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

  • Thanks 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
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.

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.


×
×
  • Create New...

Important Information

Please review our Terms of Use