Category Archives: Mac OS

Setting up the Mac for Commander X16 Assembler development

I have been playing around with C64 assembly for a few months and when I discovered the Commander X16 project I wanted to play. I couldn’t find the tools easily on the Mac so I used my virtual Windows 10 machine.

The Commander X16 project is creating a modern 8-bit hobby computer similar to the Commodore 64. The emulator, ROM, programming guides, etc are available from Github.

Recently I worked out a way to do development on the Mac. I needed several tools. The X16 emulator is available for the Mac. Check out the latest GitHub release. Then I used Visual Studio code from Microsoft.

Then I needed the missing part of the puzzle. A 65C02 assembly compiler that could run on the Mac. The CC65 project includes the assembly tool ca65. The source can be downloaded from GitHub which I did. On the Mac for Git, I use SourceTree. I then got Apple’s Developer Xcode 10.1, I did not get the latest version because my main desktop is only running Mac OS 10.13. Regardless it is big, over 6GB to download and almost 13GB installed. Once Xcode was installed I was able to go into the src directory in the cc65 folder and run the make script which surprised me by working perfectly. 

Mac OS 10 terminal window building the cc65 suite of tools.

I recommend using a GIT tool and keeping an eye on cc65 because it appears to be getting a lot of updates mostly for the X16. So you may need to update your local source and re-make when there are updates.

Now I had the basic building blocks. Now time to configure Visual Studio Code. On the left hand go to the 4 squares icon for extensions. Then in the search bar at the top enter cc65. It should find the ‘ca65 Macro Assembler Language Support’ extension. Click on install.

Visual Studio Code – Finding and Installing cc65 extention

Now I needed to configure tasks to point to the location of my ca65 and x16emu. Go to the Terminal menu and select Configure Default Build Task.

Visual Studio Code – Configure Default Build Task from Terminal Menu.

The next window you can select the default ‘Create tasks.json file from template’

Visual Studio Code – Create tasks.json file from template

Then select ‘MSBuild Executes the build target’

Visual Studio Code – Selecting the MSBuild template.

You should then have default .vscode folder and tasks.json file

Visual Studio Code – Default tasks.json.

I then edited the tasks.json to the below. If you adjust the locations of your ca65 and your x16emu it should work for you too.
Note: You may notice a difference between the image above and the code below. When I initially wrote this post I had just switched to the cc65 suite of tools and I thought using ca65 was the correct command-line tool to create a prg. It isn’t, that created object code which then needs to be linked using ld65. However, it is possible to use cl65 to compile and link.

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "x16-build-ca65",
            "type": "shell",
            "command": "/users/justin/GITHUB/cc65/bin/cl65 --verbose -o build.prg --cpu 65c02 -t cx16 ${file}",
            "args": [
                // 
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "clear": true
            },
            "problemMatcher": "$msCompile"
        },
        {
            "label": "x16-run-prg",
            "type": "shell",
            "command": "/users/justin/Documents/Commander-X16/x16emu_mac-r36/x16emu -prg ${workspaceFolder}/build.prg ",
            "args": [
                // 
            ],
            "group": {
                "kind": "test",
                "isDefault": true
            },
            "presentation": {
                "clear": true
            },
            "problemMatcher": "$msCompile"
        }
    ]
}

Once you’ve typed up some assembly select the file, go up to the ‘Terminal’ menu and select ‘Run Build Task’

Visual Studio Code – Running build task against assembler file

Down in the lower part of the Visual Studio Code window you should see the build messages.

Visual Studio Code – Successfully building a X16 prg

Now you should have a build.prg file listed in your project. You can select this, go to the ‘Terminal’ menu and select ‘Run Task…’ You should then see a list of possible tasks to run. Hopefully, you noticed in the above JSON tasks listing above that I called the 2 tasks “x16-build-ca65” and “x16-run-prg”. If you select x16-run-prg it should run the build.prg you’ve just created. The x16 emulator should launch with your prg loaded.

Note: I did have a problem with running x16emu tasks were the path had a space character. Originally when running x16emu I had a path of “/users/justin/Documents/Commander X16/x16emu_mac-r36/x16emu” and it was reporting an error, file not found at “/users/justin/Documents/Commander” so I changed the directory to include the – character instead and it works.

Visual Studio Code – Successfully launching the X16emu with the created build.prg

I would encourage any feedback or comments to improve this guide.

Disabling time sync on a Mac guest VM

So I wanted to run some old software which wouldn’t work in 2019 and with newer Mac OS versions. On my iMac I have VMware Fusion installed so I installed Mac OS Sierra and installed VMware Tools so I could drag and drop files between the hots and VM. In VMWare Fusion I went to advanced and disabled time sync. Should be pretty simple.

On reboot the guest virtual machine was still adjusting time.

So I opened up terminal, “sudo su -” to give myself full admin rights and searched for the VMware tools “find / -name “VMware*” and found the cli program in “/Library/Application Support/VMware Tools/vmware-tools-cli”

I ran the program “./vmware-tools-cli timesync status” found it was disabled.

I adjusted the time and date and then rebooted the VM. The time and date resynchronises to the current date and time again. 

I did a lot of reading and searching. I reset the time and date to the past and ran “/Library/Application Support/Vmware Tools/services.sh –restart” and watched as the time and date reset to current. Ok, so now I knew the program causing it. It was calling “launchctl load \” and pointing it to the config file ‘/Library/LaunchDaemons/com.vmware.launchd.tools.plist’ Reading the plist file I could see it was starting vmware-tools-daemon.

I did more searching and found the following VMware document

Click to access vmware-tools-user-guide.pdf

This is where I found out a very important detail about the above “Synchronise Time” option above. This option is for periodic time synchronisation. Every minute it will check the guest virtual machine and make sure the time is correct.

However time synchronisation will happen after certain operations are done;

  • When you start the VMware Tools daemon, such as during a reboot or power on operation
  • When you resume a virtual machine from a suspend operation
  • After you revert to a snapshot
  • After you shrink a disk

To fully disabled time synchronisation you need to edit the VMX file. Shut down the virtual machine and then find the VM file for it. Then control click / right click on the file and select “Show Package Contents” you should then see a list of files which make up the package. Control click / right click on the .vmx file and select “Open with” and select TextEdit. How add the below text to disable all synchronising.

tools.syncTime = “FALSE”
time.synchronize.continue = “FALSE”
time.synchronize.restore = “FALSE”
time.synchronize.resume.disk = “FALSE”
time.synchronize.shrink = “FALSE”
time.synchronize.tools.startup = “FALSE”

After this adjust the time and date then restart the guest virtual machine. Your guest VM should now maintain its own time and date.