CC65 development in Visual Studio Code

[Nop90]

28 minutes ago, sage said:

yes. often enough. my favoured way to move to a new hardware.

So you are better than me as a Linux admin ?. Last time I tried do do it, the OS on the target machine was a mess and in the end I reinstalled it, compiled the developement toolchains from scratch and took only the data from the backup.

[+karri]

So back to the topic. Is anyone using Visual Studio Code for developing cc65 stuff?

 

I kind of like the idea as we could make the development more user friendly with Docker plus a real IDE.

 

I know that hard core Emacs users will reply. Why? But what about the rest?

 

[scottinNH]

On 1/17/2021 at 5:11 PM, LordKraken said:

I do indeed, I'm pretty satisfied with my custom sublime text "pipeline" but I don't mind getting it to work on VS Code. Just wondering if it's going to be more than me and Fadest though

I mainly use VS Code for Python so far but I do appreciate the VS Code specifics (and the containerization) for CC65, which I am just getting started with.

 

 

[scottinNH]

I suppose everyone's seen this by now?

 

Much of the optimizations didn't sink in given my skill set, but he did a great job of making the information/techniques accessible.

[+karri]

2 hours ago, scottinNH said:

I suppose everyone's seen this by now?

 

Much of the optimizations didn't sink in given my skill set, but he did a great job of making the information/techniques accessible.

Yep. Programming anything at all on c++14 could be described as a nightmare. A tiny mistake produce an error log that is thick as an old time phone directory.

You also need to have a very clear understanding of how the compiler works in order to produce small code.

 

But I do give thumbs up for the compiler optimizer. It does an amazing work on the code.

 

If you think about how the Lynx operates you really need to address interrupts, segmentation and cart access. There are languages that understand parallell events much better than C++. Go, rust, python comes to my mind.

 

But if you really understand coding at this level. Any language will do. For speed use ASM. For readability I would use C.

 

PS. On the cc65 compiler you can also ask it to include the source and compile a *.s file. By looking at the produced assembly it is easy to see if the code is optimal or not.

[laoo]

Guys working on LLVM-MOS are doing pretty good progress. It's very promissing.

 

11 hours ago, karri said:

PS. On the cc65 compiler you can also ask it to include the source and compile a *.s file. By looking at the produced assembly it is easy to see if the code is optimal or not.

Sheer power of my mind allows me to answer this question without looking into the produced assembly ?

[scottinNH]

Request for assistance ?

 

The main issue: The XEX that cc65 builds, will not load., error: "binload: can't open "\text.xex"

After this, the emu loads Self Test (or if I choose 800 ROM, Memo Pad)

 

Basically I am following the initial post in this thread. For example code to see it work, I drew on a few example posts for Hello World. 

 

As far as I can tell, the XEX created is always bootable, no?? (It was bootable when I made a XEX on my mac system)

 

Possibly TMI but expect I should show what I've done:

 

 

PS C:\Users\scott\work> C:\Users\scott\Downloads\atari800-4.2.0-win32-sdl\atari800-4.2.0-win32-sdl\atari800.exe -run \text.xex                                                                                                                  Using Atari800 config file: .atari800.cfg
Created by Atari 800 Emulator, Version 4.2.0

Video Mode: 336x240x32 windowed without vsync
binload: can't open "\text.xex"
Writing config file: .atari800.cfg

PS C:\Users\scott\work> dir                                                                                             

    Directory: C:\Users\scott\work


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----         10/3/2021  10:28 AM                .devcontainer
d-----         10/3/2021  12:48 PM                .vscode
d-----         10/3/2021   2:08 PM                cc65
-a----         10/3/2021  11:44 PM           3389 .atari800.cfg
-a----         10/3/2021   9:39 PM            123 main.c
-a----         10/3/2021  10:18 PM            219 Makefile
-a----         10/3/2021  11:29 PM            859 text.xex

 

This is on Windows 10, latest VS, Atari800 v4.2.0. It is built using Control-Shift-B (shortcut from original guide post).

If (in `atari800`) I hit `f1` and try to run the XEX from emu menu, I get the same error.

 

On my Mac, befor (and not this way) I've successfully run XEX as an argument to the `atari800` emulator. Not this exact build, I mean just sitting down at the mac and doing the less integrated workflow. So while I'm a little out of water in C my point is I did work this out before. 

 

code:

#include <stdio.h>
#include <unistd.h>

int main(void) {
  printf("hello world\n");
  sleep(8);
  
  return(0);
}

Makefile:

# hello world cc65

# note: This gets run from inside the VD remote dev container,
# therefore it there can not be any targets to run this in `atari800`

all:
	echo "building example"
	cc65 -t atari ./main.c -o text.xex

UPDATE: TYPO... This should be "cl65 -t ..." above. 

devcontainer:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.194.3/containers/alpine
{
	"name": "CC65 Alpine",
	"build": {
		"dockerfile": "Dockerfile",
		// Update 'VARIANT' to pick an Alpine version: 3.11, 3.12, 3.13, 3.14
		"args": { "VARIANT": "3.13" }
	},
	
	// Set *default* container specific settings.json values on container create. 
	"settings": {},

	// Add the IDs of extensions you want installed when the container is created.
	// Note that some extensions may not work in Alpine Linux. See https://aka.ms/vscode-remote/linux.
	"extensions": [],

	// Use 'forwardPorts' to make a list of ports inside the container available locally.
	// "forwardPorts": [],

	// Use 'postCreateCommand' to run commands after the container is created.
	// "postCreateCommand": "uname -a",

	// Uncomment when using a ptrace-based debugger like C++, Go, and Rust
	// "runArgs": [ "--cap-add=SYS_PTRACE", "--security-opt", "seccomp=unconfined" ],

	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
	"remoteUser": "vscode"
}

tasks.json:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "CC65 Make Build",
            "type": "process",
            "command": "make",
            "args": [
                "all"
            ],
            "problemMatcher": [],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

any thoughts?

Edited December 7, 2021 by scottinNH
typo fix

[scottinNH]

On 10/3/2021 at 11:55 PM, scottinNH said:

Request for assistance ?

 

The main issue: The XEX that cc65 builds, will not load., error: "binload: can't open "\text.xex"

After this, the emu loads Self Test (or if I choose 800 ROM, Memo Pad)

 

...Makefile:

# hello world cc65

# note: This gets run from inside the VD remote dev container,
# therefore it there can not be any targets to run this in `atari800`

all:
	echo "building example"
	cc65 -t atari ./main.c -o text.xex

any thoughts?

Wow do I feel dumb. Notice the "cc65" in Makefile? That should have been *cl65*.

Fixed it, and it no longer generates an invalid XEX.

I don't know if what I did is detectible in the software, but quite pleased now ? 

 

Thanks again. If anyone's considering this setup, it wasn't hard per the original instructions. There might have been a couple of hiccups getting VS to see configuration changes, but I exited VS which also exited the container, so next startup was fresh. 

 

Is there a way to package configuration like this? (To me) none of this was lynx-specific and it's probably of value to the regular Atari8 forums (I only found this gem via Google). Cheers.

 

 

Edited October 5, 2021 by scottinNH
typo