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.
Development Environments
- Ast A. Moore
- Rick Dangerous
- Posts: 2641
- Joined: Mon Nov 13, 2017 3:16 pm
Re: Development Environments
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.
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.
- Blerkotron
- Dizzy
- Posts: 90
- Joined: Mon Nov 13, 2017 12:36 pm
Re: Development Environments
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.
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.
Re: Development Environments
That looks like some distressingly organised and well-commented code...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.
My Speccy site: thirdharmoniser.com
Re: Development Environments
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?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
- Blerkotron
- Dizzy
- Posts: 90
- Joined: Mon Nov 13, 2017 12:36 pm
Re: Development Environments
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.
- Blerkotron
- Dizzy
- Posts: 90
- Joined: Mon Nov 13, 2017 12:36 pm
Re: Development Environments
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.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?
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"
}
]
}
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"
}
}
]
}
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
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'.
Re: Development Environments
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?
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?
Re: Development Environments
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
SevenFFF / Threetwosevensixseven / colonel32
NXtel • NXTP • ESP Update • ESP Reset • CSpect Plugins
Re: Development Environments
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.
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.