Spectrum Computing

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.

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.

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.

That looks like some distressingly organised and well-commented code...

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?

Morkin wrote: ↑Sun Apr 08, 2018 1:24 pm That looks like some distressingly organised and well-commented code...

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.

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:
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:
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):
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'.

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?

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.

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.