Development Environments

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Post Reply
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Development Environments

Post by Ast A. Moore »

Nomad wrote: Thu Apr 05, 2018 11:42 am One thing I cant figure out is how to print the graphics characters in this way though. It would be nice to be able to generate a pdf with the graphics characters left intact.
Well, obviously, you can’t output them to a simple TXT file, so Fuse replaces them with spaces. You can, however, have Fuse generate a PBM of the printout along with the TXT of your BASIC listing. Use LLIST or LPRINT, and both files should be generated.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
Blerkotron
Dizzy
Posts: 90
Joined: Mon Nov 13, 2017 12:36 pm

Re: Development Environments

Post by Blerkotron »

Here's my setup:

Microsoft's 'Visual Studio Code' for editing (it has a plug-in for Pasmo/Z80 highlighting which should also work for most assemblers).
Pasmo for assembling.
SpecEmu for debugging.
BitBucket for source control.

VS Code makes for an excellent Z80 editor, it's not just for modern languages. It's extensible, so I can have highlighted Z80 formatting and easily set it up to call build and run scripts on hotkeys, plus it has built in Git support so I can hook it straight up to BitBucket to keep all my code safe. Then SpecEmu's excellent debugger makes it really easy to breakpoint, single-step, check registers/memory, etc.

It's not quite a fully integrated dev environment, but it's not far off. And there's also a highlighting plug-in for Boriel's ZXBasic - I've used the exact same setup for that too.

Image
User avatar
Morkin
Bugaboo
Posts: 3250
Joined: Mon Nov 13, 2017 8:50 am
Location: Bristol, UK

Re: Development Environments

Post by Morkin »

Blerkotron wrote: Fri Apr 06, 2018 10:49 pm Here's my setup:

Microsoft's 'Visual Studio Code' for editing (it has a plug-in for Pasmo/Z80 highlighting which should also work for most assemblers).
Pasmo for assembling.
SpecEmu for debugging.
BitBucket for source control.

VS Code makes for an excellent Z80 editor, it's not just for modern languages. It's extensible, so I can have highlighted Z80 formatting and easily set it up to call build and run scripts on hotkeys, plus it has built in Git support so I can hook it straight up to BitBucket to keep all my code safe. Then SpecEmu's excellent debugger makes it really easy to breakpoint, single-step, check registers/memory, etc.

It's not quite a fully integrated dev environment, but it's not far off. And there's also a highlighting plug-in for Boriel's ZXBasic - I've used the exact same setup for that too.

Image
That looks like some distressingly organised and well-commented code... :o
My Speccy site: thirdharmoniser.com
User avatar
PeterJ
Site Admin
Posts: 6852
Joined: Thu Nov 09, 2017 7:19 pm
Location: Surrey, UK

Re: Development Environments

Post by PeterJ »

Blerkotron wrote: Fri Apr 06, 2018 10:49 pm
VS Code makes for an excellent Z80 editor, it's not just for modern languages. It's extensible, so I can have highlighted Z80 formatting and easily set it up to call build and run scripts on hotkeys
Hi [mention]Blerkotron[/mention], I have looked at Microsoft Visual Code. It looks promising as it runs on both Linux and Windows. I did try and read the bit about calling external commands to make build calls but I got thoroughly confused! Is there any chance you could expand on this with some examples?
User avatar
Blerkotron
Dizzy
Posts: 90
Joined: Mon Nov 13, 2017 12:36 pm

Re: Development Environments

Post by Blerkotron »

Morkin wrote: Sun Apr 08, 2018 1:24 pm That looks like some distressingly organised and well-commented code... :o
Partly because I do code for a living and partly because it helps greatly while I'm learning. Quite often I come back to routines weeks later and can't remember for the life of me why I did something a certain way, so leaving tons of comments really helps.
User avatar
Blerkotron
Dizzy
Posts: 90
Joined: Mon Nov 13, 2017 12:36 pm

Re: Development Environments

Post by Blerkotron »

PeterJ wrote: Sun Apr 08, 2018 1:31 pm I have looked at Microsoft Visual Code. It looks promising as it runs on both Linux and Windows. I did try and read the bit about calling external commands to make build calls but I got thoroughly confused! Is there any chance you could expand on this with some examples?
Sure - VS Code is a bit bare-bones when it comes to config, it expects you to be happy editing .json files so it's not quite as user-friendly as some. The good news is that once you've set them up you don't need to touch them again.

You need to select a folder where your source will live. Once there, choose 'configure default build task' from the Tasks menu (it will appear when you hit alt if it's not visible by default) and then choose 'create tasks.json file from template' from the pop-up that opens and then select 'others' (because we're going to feed it a script file). That'll make a file for you with practically nothing in it, like this:

Code: Select all

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo Hello"
        }
    ]
}
I replaced the contents of that file with a configuration like this (most of which was ripped from Internet examples), which sets up both the build and the test/run tasks:

Code: Select all

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "pasmo",
            "command": ".\\make.cmd CosmicJanitor",
            "type": "shell",
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": true,
                "panel": "shared"
            }
        },
        {
            "label": "test",
            "command": "c:\\games\\emulators\\spectrum\\specemu\\specemu.exe",
            "args": [
                "c:\\dropbox\\code\\speccy\\CosmicJanitor\\CosmicJanitor.tap"
            ],
            "type": "shell",
            "group": {
                "kind": "test",
                "isDefault": true
            },
            "problemMatcher": [],
            "presentation": {
                "echo": false,
                "reveal": "never",
                "focus": false,
                "panel": "shared"
            }
        }
    ]
}
Most of the options in there you won't need to worry about, but the bits which are custom to building Speccy code should stand out pretty well. The build task runs a Windows batch file called make.cmd and feeds it the game name as a parameter. That file lives in the root of the folder we selected at the start and looks like this (but yours could look like anything you like, obviously):

Code: Select all

@echo off
setlocal
set PASMODIR=C:\Dropbox\Code\Speccy\_Tools\Pasmo

"%PASMODIR%\pasmo" --alocal --tapbas --name CosmicJanitor %1.asm %1.tap %1.symbol

endlocal
The test task is even simpler - it basically locates and runs SpecEmu and feeds it the .tap file that Pasmo generates as an argument.

With the tasks.json file saved, I can now hit CTRL/Shift-B to run a build. CTRL/Shift-P opens the tasks menu, and you should find that 'run test task' is the first entry in there - selecting it should run SpecEmu and fire up the .tap file.

This config persists just for this project, so if you set up a new one in a new folder you'd need to copy the file across or generate a new one.

Hopefully that makes some sense - please ask if anything seems weird or unclear. It might seem a bit unfriendly (and it is) but literally it's the only bit of config I've done apart from installing the Pasmo plug-in - everything else is 'out of the box'.
User avatar
djnzx48
Manic Miner
Posts: 729
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

Re: Development Environments

Post by djnzx48 »

Thanks for the VS Code suggestion. I wasn't a fan of it when it was first released but it turns out it's well suited to Spectrum development and a nice editor overall.

Has anyone tried using the Zeus IDE's built in debugger? It sounds like it would be really useful as you can see the source while you're debugging, but when I try it I just get garbled screen output and weird bugs. Even writing to the display gives errors like "Illegal write to 48D3".

EDIT: OK I found out what the problem was: I had hidden my loader program in the loading screen, so trying to write to it must have registered as an error. I also had some code located directly after the attribute area at $5B00, that was seemingly being overwritten by some BASIC system variables or something. Is there a way to get around this?
User avatar
Seven.FFF
Manic Miner
Posts: 735
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

Re: Development Environments

Post by Seven.FFF »

I would uncheck Trap On Error unless you’re going to going to use the mem_* diectives to set the access flags for all your memory addresses. This is what’s triggering your Illegal Write error.
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins
User avatar
djnzx48
Manic Miner
Posts: 729
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

Re: Development Environments

Post by djnzx48 »

Thanks, that solved the problem! I discovered what was causing the memory corruption as well - I had a DI instruction in the loader but not in the main program, so the BASIC interrupts were writing over code.

I just have one other question: is it possible to get procedures to show up in the symbol table with all the other labels? Right now I'm using procedures for each separate routine but it becomes difficult to deal with them if you can't find out where they are in memory easily.
Post Reply