CC65 development in Visual Studio Code

[LX.NET]

After some 5+ years of Atari Lynx development using Visual Studio I noticed that it always was a hassle to setup the environment, and that other enthusiasts often got stuck at this part. Also, VS is limited to Windows while the toolkit (BLL+newcc65 and CC65) are not, supporting Linux and MacOS as well.

 

I have been experimenting with Visual Studio Code as a cross-platform IDE and also with Remote Containers to easily setup a dev environment on a new device. 

Looking for some feedback (is it useful) and improvements (when it is).

 

What happens when you use Remote Containers is that a isolated environment is setup, using a Docker image as a template for a container. We will be creating a special image for CC65 with the CC65 stack and sprpck built from the Git repositories, making sure we can get the latest tool whenever we rebuild the image. The image is built once, which takes a little bit of time, and reused afterwards. Your source code of the Lynx project is linked inside the container. Effectively, you will be working inside a container (with all tools installed inside it) and the source code "mounted". Visual Studio Code runs from your machine's host OS, but is pretending to be working inside the container. 

 

Getting started

To get started, download and install Visual Studio Code for your OS: https://code.visualstudio.com/download

Next, follow this article to setup Docker for container support: https://code.visualstudio.com/docs/remote/containers

 

For now I have created a Dockerfile with CC65.

Open the folder with your CC65 source code in VSCode.

Open the Command Palette (F1 or CTRL+Shift+P) and choose: Remote-Containers: Add Development Container Configuration Files...

Next, choose Alpine (you can pick any other Linux distribution, but the Dockerfile (see later) will be slightly different.

 

 

A new folder '.devcontainer' will be created with a devcontainer.json file and a Dockerfile (for our container image that will get the CC65 and sprpck tooling).

 

Change the contents of Dockerfile to be:

 

# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.154.0/containers/alpine/.devcontainer/base.Dockerfile

 

# [Choice] Alpine version: 3.12, 3.11, 3.10

ARG VARIANT="3.12"

FROM mcr.microsoft.com/vscode/devcontainers/base:0-alpine-${VARIANT}

 

RUN apk update && \

    apk add --no-cache --virtual .build-deps git build-base

RUN mkdir -p /sdk

WORKDIR /sdk

RUN git clone https://github.com/cc65/cc65.git

RUN git clone https://github.com/42Bastian/sprpck.git

WORKDIR /sdk/cc65

RUN nice make -j2

RUN make install PREFIX=/usr

WORKDIR /sdk/sprpck/src

RUN make

RUN install sprpck /usr/bin

WORKDIR /sdk

 

 

If you want another Linux distro, you will have to change the apk commands in the Dockerfile to be apt or whatever is applicable.   

 

Reopen the folder in a development container: Remote-Containers: Remote in Container

 

 

You should now see the bottom of the screen change:

to 

(For the name to be CC65, I changed the name in devcontainer.json from Alpine to CC65)

 

From the Terminal window you can now use all CC65 tools.

Notice how the Terminal window is automatically inside the root of your source code folder, but now from within the container. If you would try to use CC65 from outside the container, it would not be there (unless you installed it already). The tooling is only available inside your container, not polluting your host OS. The beauty of it is that the .devcontainer folder can be part of your Git repo, allowing everyone to rebuild the toolset you have used (with specific versions), without having to download binaries, install things, setup environments and so on. It is done from the Dockerfile per codebase.

 

Pressing Ctrl+Shift+B will trigger a build (you can also select Terminal, Configure Tasks from the top menu). Let a tasks.json file be created under the .vscode folder and change the content to: 

 

{

    // 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

            }

        }

    ]

}

 

You can create additional tasks for Clean and Install as well.

If all goes well, you should be able to press Ctrl+Shift+B again for a Build and see whether the Makefile (should be in the root of your source tree) gets used.

 

 

Some questions: 

• Which Linux distro do you like best for development?
• What tools are missing for you (given the CC65 stack for now)

 

Please let me know if this is enough to get everyone started.

[LX.NET]

@Bastian Schick: is there a repo for newcc65 sources in GitHub, and does your lyxass repo contain the 64 bit fixes by @sage?

This will help create a similar Dockerfile for BLL. 

[42bs]

lyxass works well on 64bit platforms. Though the folder structure is different from sprpck. 

newcc65 is not on GitHub. But I think Karri has it on bitbucket.

 

[LordKraken]

How many people are still using newcc65 aside from me and Fadest?

[LX.NET]

 

8 hours ago, 42bs said:

lyxass works well on 64bit platforms. Though the folder structure is different from sprpck. 

newcc65 is not on GitHub. But I think Karri has it on bitbucket.

 

I will use a combination of Karri's repo and BLL from your GitHub then. 

Anyone have a less than trivial source code project to compile against newcc65 and BLL? Lordkraken perhaps? 

[LordKraken]

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

[+jgkspsx]

I'm in the middle of setting up my toolchain and am following Alex Thissen's introduction guide using Visual Studio (I assume that's @LX.NET?) and cc65, so I assume I would be using it too until I learn I should use something else. I know that guide is quite old at this point - is there a more recent guide? I can use anything and am not beholden to any IDE, though I am going to miss having autocomplete ?

 

I do love Sublime, so I would be interested in your setup, @LordKraken... but I like VSCode too.

[+karri]

5 hours ago, 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

MegaPak I was a combination of Newcc65 and BLL games. I could try to compile it with the docker tools.

[LX.NET]

@Karri, I have tried to get a new Dockerfile that uses your atarilynx repository to build the newcc65 source code.

This time I chose for Ubuntu (focal version), to experiment with another Linux distribution than Alpine.

 

I am getting a couple of errors when I try to compile cc65 (from newcc65) and ra65:

 

vscode ➜ /sdk/lynx/tools/newcc65 (master ✗) $ sudo make install
make[1]: Entering directory '/sdk/lynx/tools/newcc65/cc65'
gcc -O3 -Wall -ffast-math -fomit-frame-pointer   -c -o expr1.o expr1.c
In file included from expr1.c:16:
code-65.h:45:15: error: unknown type name ‘intptr_t’
   45 | void immedgbl(intptr_t i);
      |               ^~~~~~~~
expr1.c: In function ‘op_assoc’:
expr1.c:452:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  452 |   return ((int)ops->gen);
      |           ^
expr1.c: In function ‘hie_internal’:
expr1.c:482:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  482 |    if ( (gen = (void *)op_assoc((this_tok = curtok), ops)) )
      |                ^
make[1]: *** [<builtin>: expr1.o] Error 1
make[1]: Leaving directory '/sdk/lynx/tools/newcc65/cc65'
make[1]: Entering directory '/sdk/lynx/tools/newcc65/ra65'
gcc -pipe -O3 -fomit-frame-pointer -Wall -DUNIX -s -o xgen.o -c xgen.c
xgen.c: In function ‘frag_gen_size’:
xgen.c:472:7: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]
  472 |    if (offset > 124) /* too big? */
      |       ^
xgen.c: In function ‘init_gen’:
xgen.c:928:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  928 |   segment[3].objsize = (int)
      |                        ^
xgen.c:929:19: error: lvalue required as left operand of assignment
  929 |   segment[0].base =
      |                   ^
xgen.c: In function ‘out16’:
xgen.c:151:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
  151 |   write(output_fd, two_bytes, 2);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
xgen.c: In function ‘out8’:
xgen.c:158:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
  158 |   write(output_fd, two_bytes, 1);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [makefile:26: xgen.o] Error 1
make[1]: Leaving directory '/sdk/lynx/tools/newcc65/ra65'
make[1]: Entering directory '/sdk/lynx/tools/newcc65/runtime'
ra65 runtime.m65

 

I also had to remove the -m486 flags for the gcc compiler.

 

Can we fix these errors (and warnings)? Are you getting these too?

Also, would it be an idea to separate the newcc65 repo out of the big atarilynx repo as well so we can compose a different toolchain by combining bll, newcc65, sprpck, lyxass from the latest version (in addition to the frozen toolchain inside atarilynx repo)?

[+karri]

Thanks! I have not been using newcc65 inn ages. But I have a feeling that these is familiar. I may have fixed this when Carl re-released MegaPak I some time ago. I check...

[LX.NET]

@karri You might be able to find this Dockerfile content useful for creating a Dev Container with your tooling, focussing on CC65:

 

# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.154.2/containers/ubuntu/.devcontainer/base.Dockerfile

 

# [Choice] Ubuntu version: bionic, focal

# [Choice] Debian version: buster, stretch

ARG VARIANT="stretch"

FROM mcr.microsoft.com/vscode/devcontainers/base:0-${VARIANT}

 

# Install additional OS packages for build tooling and SSL libraries

RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \

     && apt-get -y install --no-install-recommends build-essential libssl-dev

 

RUN mkdir -p /sdk

WORKDIR /sdk

RUN git clone https://bitbucket.org/atarilynx/lynx.git

 

WORKDIR /sdk/lynx/tools

RUN make -f Makefile.deb

WORKDIR /sdk/lynx/tools/cc65

RUN make -f make/gcc.mak install

 

Paste that when you added the Remote container files and it should build a container with your tooling available.

 

Anyone using sprpck, please let me know. It will need some additional instructions to build the image

 

[LX.NET]

For those working in BLL+newcc65 use this:

 

# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.154.2/containers/ubuntu/.devcontainer/base.Dockerfile

 

# [Choice] Ubuntu version: bionic, focal

# [Choice] Debian version: buster, stretch

ARG VARIANT="focal"

FROM mcr.microsoft.com/vscode/devcontainers/base:0-${VARIANT}

 

# Install additional OS packages for build tooling and SSL libraries

RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \

     && apt-get -y install --no-install-recommends build-essential libssl-dev

 

RUN mkdir -p /sdk

WORKDIR /sdk

 

RUN wget http://bjoern.spruck.net/lynx/newcc65_mod.tgz

RUN git clone https://github.com/42Bastian/lyxass.git

RUN git clone https://github.com/42Bastian/sprpck.git

RUN git clone https://github.com/42Bastian/new_bll.git

RUN git clone https://github.com/42Bastian/lynx-encryption-tools.git

 

# newcc65 

RUN tar -zxvf newcc65_mod.tgz

WORKDIR /sdk/newcc65

RUN make install

RUN install bin/* /usr/bin 

 

# BLL

ENV BLL_ROOT="/sdk/new_bll/"

 

# lyxass

WORKDIR /sdk/lyxass

RUN make

RUN install lyxass /usr/bin

 

# sprpck

WORKDIR /sdk/sprpck/src

RUN make

RUN install sprpck /usr/bin

 

# Lynx encryption tools

WORKDIR /sdk/lynx-encryption-tools

#RUN make

#RUN install * /usr/bin

 

 

As you can see, the last two instructions have been commented out, pending a pull request for @42bs to fix the compilation of the lynxenc, lynxdec tooling

 

[LX.NET]

It would be good to confirm two things:

• Are the changes made by @sage in lyxass covered in the newer version by @42bs?
• Can we put @sage's newcc65 sources in a Git repo (do you have a Git repo somewhere or should we put it at github.com/42Bastian for example?)

Alex

[42bs]

@sage's changes are somehow merged. I think my version is the latest. Esp. it supports 64bit math (needed for the Jaguar).

[LX.NET]

Thanks for accepting the pull request, @42bs

I will update the container image. 

On another note:

I saw that the environment variables for CC65INCLUDE and CC65LIB are not set in the container image yet. Also, there seem to be some errors in building the newcc65 source code for libsrc. Perhaps @sage can help here. I will report the errors later today.

Tackling this, we can also use c code from newcc65. Right now, I have been able to successfully build .asm with lyxass, and use the tooling for lynxenc and lynxdec. 

Almost there. 

 

I would appreciate some feedback on whether all libs and executables are in their proper place. Not a Linux person, so do not have a clue whether it is okay. 

Thanks

[42bs]

Ouch Docker on Windows needs Hyper-V or WSL2. I guess I stick with my VirtualBox VMs unless I find some info if WSL2 and cygwin work together.
 

[LX.NET]

Hyper-V shouldn't be that much of a problem, or are you running Windows 10 Home? 

[42bs]

11 minutes ago, LX.NET said:

Hyper-V shouldn't be that much of a problem, or are you running Windows 10 Home? 

Win10 Professional. But I wonder, what is the benefit of a Docker file v.s. a VM image? I understand, in the Docker-Image it is kind of Linux, right?
As you have git clone/make etc. in the script, will it be executed every time you launch the Docker image?
(You see, I did no really dig into this. So I am outing me as a complete noob.)

[LX.NET]

On 1/25/2021 at 1:04 PM, 42bs said:

Win10 Professional. But I wonder, what is the benefit of a Docker file v.s. a VM image? I understand, in the Docker-Image it is kind of Linux, right?
As you have git clone/make etc. in the script, will it be executed every time you launch the Docker image?
(You see, I did no really dig into this. So I am outing me as a complete noob.)

A Docker file is a description to build an image. This is a one-time activity that is performed by the tooling. Afterwards, a container instance is started based on the image. It has resemblances to a Virtual Machine (container instance) and its VM image (container image). There are crucial differences between VMs and containers however. VMs offer hardware virtualization, where containers do software virtualization.

 

The case for containers is that it allows a developer to have its own source code for the Atari Lynx project and the toolchain he/she is using as well. If you having a container image (or the Docker file that produced it) allow a frozen toolchain that can be reproduced many years later. 

 

Having said that, the current Docker files I showed earlier get the latest sources of the tooling and compiles it. This means they are not frozen, but provide an always up-to-date toolchain when the image is rebuild. We could choose to create and share a docker image in a public place, much like GitHub (it could be Docker Hub for example). Then a developer could download a Docker image (e.g. CC65:2.19, or newcc65:feb2021) and have a frozen toolset. The container is containing all of the tools and is very lightweight when compared with VM images. It is a security boundary and doesn't 'contaminate' your system. In other words, you can easily run multiple containers with different versions of the toolchain side-by-side. Karri could have his own CC65 2.13 stack and still look at code that I am building on 2.19, without having to reinstall it on his development machine. It comes with my code and in a container that can be thrown away.

 

Hopefully this helps a little to get a better understanding of the possibilities.

 

I will create a repository at github to hold Docker files for environments. Probably something like https://www.github.com/AtariLynx/devcontainers.

 

Alex 

 

[+karri]

This is the best invention since sliced bread! Thanks for doing this.

[+karri]

On 1/25/2021 at 1:48 PM, LX.NET said:

Hyper-V shouldn't be that much of a problem, or are you running Windows 10 Home? 

I am currently in the process of buying a Windows laptop with a large screen (Lenovo Legion 5 17,3" https://verkkokauppa.com/fi/product/65091 ). This gaming laptop comes with Windows 10 Home version. Is it easily upgradable to Windows Pro or is it ok to install Docker on top of WSL2?

 

What I would like to have is a Windows laptop able of running Unreal development environment, Blender latest version plus running Ubuntu in a VirtualBox envirenment.

 

Actually I will retire from my daily work in end of May. So I want to learn some modern techniques. Working with the Lynx has been cool, but perhaps getting to know modern stuff like Vulkan, EEVEE, node-based rendering pipelines, shaders, tessellators, tensor-cores, AI, whatever, would be fun now as I should have more time on my hands. I already got the Vulkan drivers to work on a Raspberry Pi 400. The Blender game engine also works. But there are so many technical obstacles in developing accelerated graphics on a Pi that I decided to go with NVidia RTX 2060 instead. It is discounted now as the RTX 3000 series is coming out.

 

Any comments are appreciated before I fork out €1600 for a laptop.

[42bs]

I'd recommend to plugin in 32GB. But only FHD? Or do you want to use an external 4K screen?

And maybe pick win10 Pro directly.

I personally do not like notebooks with num-pad, as it means you can not sit centered in front the screen.

 

Me, I prefer small notebook screens, as I have a 4K screen and keyboard on the desktop and a light (ok 1.5kg) notebook for traveling.

 

There is a reseller for retoure-DELL notebooks which have quiet good prices: https://frog.pl/

[42bs]

26 minutes ago, karri said:

Actually I will retire from my daily work in end of May.

Retire like in "going into pension"?

[+karri]

3 minutes ago, 42bs said:

Retire like in "going into pension"?

Yes. Sorry for my bad English. I signed a Japanese working contract that expires when I turn 65. As my calendar is already completely filled up with Peter Pan rehearsals in June and performances in July I thought that going into pension would solve a lot of my time conflicts.

[+karri]

13 minutes ago, 42bs said:

I'd recommend to plugin in 32GB. But only FHD? Or do you want to use an external 4K screen?

And maybe pick win10 Pro directly.

I personally do not like notebooks with num-pad, as it means you can not sit centered in front the screen.

 

Me, I prefer small notebook screens, as I have a 4K screen and keyboard on the desktop and a light (ok 1.5kg) notebook for traveling.

 

There is a reseller for retoure-DELL notebooks which have quiet good prices: https://frog.pl/

Thanks for the tips. I have a bad habit of dragging my laptop with me and watch Netflix when I take a bath. That is why I want a big laptop screen. I also do not want to invest in more hw so this would be my only computer after May.

 

If I get a 4K screen at some point in the future then I probably invest in a desktop computer at the same time.

 

I decided to buy from Finland because I get an extended 3 year warranty for free. The question is just what to buy...