As part of this year’s Retro Challenge, I’ve been writing Z80 assembly language. I wanted to cover what tools I’ve been using to do this on my Mac.
Visual Studio Code is a great programmer’s text editor from Microsoft. It’s free and has a lot of extensions. I use the Z80 Assembly extension. This provides syntax highlighting for my code.
SjASMPlus is a free Z80 assembler. I use this to assemble my source code into a binary file. In your source code you need to include an OUTPUT statement. This is the filename of the output binary file. To keep things easy I use the same filename as source code, but with a different extension. It is capable to splitting the output into multiple files, but that is too advanced for me at the moment.
I then need to get this binary file onto my RC2014. To do this I use z88dk-appmake from the Z88DK development tools. This can take the binary and turn it into Intel formatted hex. This can then be pasted into a hexloader on the RC2014. SCM has one built in.
Visual Studio Code offers Tasks, which lets us run jobs directly inside Visual Studio Code. I have created several tasks. One runs SjASMPlus on the current file. One runs z88dk-appmake on the generated binary to create the hex file. One uploads it to the RC2014. One runs it on the RC2014. There is also a combined build task that runs assembles, transfers, and runs the current code on the connected RC2014.
I make some assumptions in this tasks.json file.
I assume this is always connected to my RC2014 Classic 2 on a fixed device that is already connected using minicom. I could include stty commands in the tasks.json file to configure the connection. However, I always have minicom open in another window so this isn’t needed.
I assume I’ve always set the OUTPUT to be the same filename as the source code, just with a .z80 extension.
I assume the code has been assembled to address $9000.
The individual tasks work well, but the combined task that chains them together can sometimes fail. The issue here seems to be when I cat the hex to the RC2014. I’ve found piping this through an echo instead of directly redirecting to the device is more likely to succeed. If this fails, I manually cat the hex file to the RC2014 in a shell window.
I’ve found these tasks have really sped up my development time.
This is my current tasks.json setup for Visual Studio Code RC2014 development.
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "RC2014: sjasmplus",
"type": "shell",
"command": "sjasmplus --fullpath ${file}",
"group": {
"kind": "build",
"isDefault": false
},
"options": {
"cwd": "${fileDirname}"
},
"presentation": {
"group": "RC2014"
}
},
{
"label": "RC2014: appmake",
"type": "shell",
"command": "z88dk-appmake +hex --org 0x9000 -b ${fileBasenameNoExtension}.z80",
"group": {
"kind": "build",
"isDefault": false
},
"options": {
"cwd": "${fileDirname}"
},
"presentation": {
"group": "RC2014"
}
},
{
"label": "RC2014: Deploy to SCM",
"type": "shell",
"command": "cat ${fileDirname}${/}${fileBasenameNoExtension}.ihx | echo > /dev/tty.usbmodem06351",
"group": {
"kind": "build",
"isDefault": false
},
"options": {
"cwd": "${fileDirname}"
},
"presentation": {
"group": "RC2014"
}
},
{
"label": "RC2014: Run on SCM",
"type": "shell",
"command": "echo -e \"g 9000\r\n\" > /dev/tty.usbmodem06351",
"group": {
"kind": "build",
"isDefault": false
},
"options": {
"cwd": "${fileDirname}"
},
"presentation": {
"group": "RC2014"
}
},
{
"label": "RC2014: Build",
"dependsOrder": "sequence",
"dependsOn": ["RC2014: sjasmplus", "RC2014: appmake"],
"group": {
"kind": "build",
"isDefault": false
}
},
{
"label": "RC2014: Build, Deploy, and Run",
"dependsOrder": "sequence",
"dependsOn": ["RC2014: sjasmplus", "RC2014: appmake","RC2014: Deploy to SCM","RC2014: Run on SCM"],
"group": {
"kind": "build",
"isDefault": true
}
}
]
}