Beta update for BeebAsm VSCode extension

[tomhelm]

Hi all

I’ve been working on a major update to simondotm’s Beeb VSC extension for Visual Studio Code.

When I started using BeebAsm, I found the extension in the marketplace. The syntax highlighting and set-up of build / test tasks was very helpful. I soon found myself wanting other features as my code base grew, especially those that help navigate through a large file or collection of files, so started looking into how to contribute to the extension project.

There is now a version that hopefully is mostly there ready for anyone who would like to try a beta version. I developed it on a Mac but have tried briefly under Windows and it seems okay.

Updates

• Syntax highlighting fixes for numbers and new BeebAsm commands that were added since the current extension was made
• Brought the tasks.json format up-to-date

New features

• Diagnostics i.e. underlining lines with problems (using a TypeScript conversion of parts of BeebAsm to find errors without having to compile)
• Code completions (BeebAsm functions and commands + symbols and labels within the workspace)
• Hover (on opcodes, symbols, labels, functions and commands)
• Function signature information for “intellisense" style hints as you type
• References (goto definition, peek definition, find all references & rename refactoring)

How to use
The extension needs to know the initial file that will be sent to BeebAsm so that it can follow INCLUDE links to get the entire code base. Setting this up is the same way as setting up the build task for Beeb VSC i.e. press F10 then select the file (it will offer all files with extension .6502, .asm or .s). Alternatively use the command palette and select “BeebVSC: Create new build target”. This will create a settings.json file local to your workspace folder (in a .vscode folder, the same as tasks.json) with the source file name saved for future reference.

With that set, you should be able to access all the regular VSCode features as listed above.

The beta releases are available to download here: https://github.com/tommy9/beeb-vsc/releases. I’ll add new versions as fixes are made until it is looking good enough to release properly. You should be able to install the .vsix file through the command palette "Extensions: install from VSIX..." or just dragging the file onto the extensions side panel also worked for me.

[PeterC]

I just wanted to say thanks for working on this extension. Development environment set up without any issues.

Although I don't do as much as I would like, I had been manually editing the tasks.json file using the original version of the extension.

One thing, is there anyway you can extract or assume the title of the assembled binary on the SSD rather than defaulting to Main'?

I have a source called BIG.6502 that creates a target binary called BIG that is placed on an image called BIG.SSD

I know I can edit the save command at the end of the source to output as Main or the edit tasks,json to create a !Boot with the required file name without any trouble, it's just in this case creating a boot file that runs BIG automatically might be an expected behaviour.

Regardless, thank you again for updating the extension.

Peter

[tomhelm]

Thanks for the note and suggestion Peter.

Good idea about coming up with a better approach than just having a default of 'Main'. One option would be to use base it on the target file name as you suggested. Then we could scan the target assembly file for any SAVE commands and add those as additional options. Then when setting up the compile target, we would first ask for the target assembly file as we already do, then for the file to run from the !Boot file. If there is only one option, we could just use that directly, otherwise present a list to the user.

I'll have a go at adding this over the weekend. Thanks.
Tom

[tricky]

Hi I wrote one for visual studio as I've used that since before it was visual studio and couldn't get on with vscode. viewtopic.php?t=27490 I look forward to borrowing some ideas as I couldn't get some of the expressions right before I lost interest
Yours sounds excellent.

[tomhelm]

One thing, is there anyway you can extract or assume the title of the assembled binary on the SSD rather than defaulting to Main'?

I've just released a new version which should add this functionality. It will be triggered when creating a new target, first it will check for the target assembly file as it does now, then it should check for the file to launch on boot.

https://github.com/tommy9/beeb-vsc/releases

Hi I wrote one for visual studio as I've used that since before it was visual studio and couldn't get on with vscode. viewtopic.php?t=27490 I look forward to borrowing some ideas as I couldn't get some of the expressions right before I lost interest
Yours sounds excellent.

I've not experienced extensions for Visual Studio but hopefully it is relatively similar enough, assuming the teams within Microsoft talk to each other . The syntax highlighting is done with only the language file 6502.tmLanguage.json. The more fancy features like code completions, symbol renaming and references depend on the language server protocol which I believe VS also supports but is probably quite an exercise to port.

[tricky]

I think I ended up with the JSON version as it had more features than the other alternative, but failed to get labels and label references fully working.

[PeterC]

I've just released a new version which should add this functionality. It will be triggered when creating a new target, first it will check for the target assembly file as it does now, then it should check for the file to launch on boot.

Tom,

Just checked and it all looks good.

I deleted tasks.json, settings.json and BIG.SSD

First pass I left the source as it was, On pressing F10 the plugin offered me two target choices of BIG so thought one must be the name of the 6502 file and the other was taken from the SAVE command in the BIG.6502 file.

Pressing F7 I ended up with the expected BIG.SSD that on pressing F9 autoran the binary BIG when loaded into the emulator.

I deleted the tasks.json, settings.json and BIG.SDD, then changed the save command in the .6502 source to output a binary called PETER, Pressing F10 gave the choice of BIG or PETER, I chose PETER and after pressing F7 then F9, I ended up in the emulator autorunning the PETER binary.

Thank you, that appears to cover all the bases in 'expected' behaviour.

Peter

[VectorEyes]

Hi Tom,

To re-iterate what others have already said: Thanks for driving Beeb-related VSCode extension development forward!

I currently use Simon's BeebVSC extension and I thought I would take a look to see if I could get your new version working with my current code. However am already hitting a few snags. I use a make-based build process that invokes BeebAsm multiple times over several different passes, and the files that are included in the build depends on which pass is being run. To make it even worse, both 6502 source, and binary blobs, from earlier passes are fed back into later ones, sometimes with other tools processing them in between.

Everything is done via a top-level "Main.6502" file. However I couldn't really work out how to get your extension working within that framework. I already have my tasks.vscode set up to run various shell scripts that invoke make, which runs BeebAsm, so I can't really 'add a BeebVSC target', which seems to be a central part of getting it all working.

I'm just wondering whether there might be any way to support this kind of multi-pass approach? I appreciate that it's probably not really the intended use-case.

Thanks!

[tomhelm]

Hi VectorEyes

It is definitely an objective to support more complex code bases like yours. I avoided it so far as I was torn between exactly how to support it in the best way.

You should be able to get partial support currently by adding a settings.json to your .vscode folder alongside the tasks.json. It would look something like this:

Code: Select all

{
    "beebvsc": {
        "sourceFile": "/Users/tom/Documents/Beeb/Projects/Golf/main.6502",
    }
}

Where you would just need to replace the path to the file targeted with one of the files that gets compiled by BeebASM (the format is if you are on Linux/Mac and would be more like "c:\\Users\\path\\main.6502 for Windows). The way it works is that whenever a source file is changed in VS Code, it does a re-parse starting from the file referenced in the settings.json file, opening all INCLUDE references as necessary.

This should give you the various new features that depend on label and symbol references but only for files referenced from this one compile target. Then you could switch to another BeebASM target to work on those related targets by modifying the settings.json entry.

For now there is no command to just set up this settings.json file without also creating the tasks.json which would be a problem for complex cases. However, creating it manually will still work, until such point as I add a specify command to setup the settings.json entries. Longer term, I'd like to change the settings.json to include an array of base source files, so that it can work with an entire code base which does multi-stage compilation. One easy option would be to require the user enter all the include files under the each compile target, so the system would know their exact relationship. A nicer way would be to do an initial parse of all the compile targets to construct a relationship mapping to include files that is cached in memory.

[simonm]

Really great work here Tom

I will make some efforts to get a new official version released asap.

Many moons ago I was thinking there was so much cool stuff we could do with an official plugin, such as integration with Tom Seddon's B2 emulator, which has a nice local http based API, and fun stuff like memory dumps, emulation, video RAM displays, debugging etc.

I generally feel like this project would be an ideal candidate for the stardot github community to adopt, and I will be giving some consideration for how we might achieve that too.

[dp11]

Just been using this . Syntax highlight doesn't appear to know about "bra" 65c02 instruction.

[tomhelm]

Just been using this . Syntax highlight doesn't appear to know about "bra" 65c02 instruction.

Thanks for reporting. I've checked that a few other 65c02 instructions are missing from the syntax highlighting (CLR, DEA, INA, TRB, TSB) and we don't have hover information for any 65c02 instructions either. It won't take me long to fix.

[dp11]

Just been using this . Syntax highlight doesn't appear to know about "bra" 65c02 instruction.

Thanks for reporting. I've checked that a few other 65c02 instructions are missing from the syntax highlighting (CLR, DEA, INA, TRB, TSB) and we don't have hover information for any 65c02 instructions either. It won't take me long to fix.

Can it look for the cpu directive to work out which CPU highlighting should be used?

PS excellent work!

[tomhelm]

Can it look for the cpu directive to work out which CPU highlighting should be used?

The syntax highlighting will always apply to the 65c02 instructions as those are just a list in the TextMate grammar. However, the parser will check if those are valid and give squiggly underlines to indicate a syntax error if they are used without the `CPU 1` command being in the code. In theory it is possible to override the highlighting using the parser, so that's a possible future enhancement so those opcodes could be used as variable names without highlighting for regular 6502 code.

[tricky]

Presumably the text mate gamer could be selected by file extension. Say, 65c02 for the extra bits?

[VectorEyes]

Presumably the text mate gamer could be selected by file extension. Say, 65c02 for the extra bits?

There’s quite a few files that contain both 6502- and 65C02-specific code depending on the status of other variables/definitions, so I’m not sure you’d want to base the assumed CPU on the file extension.

[VectorEyes]

Also, thanks Tom for your advice about getting it up and running by pointing it at a specific “main” source code file. Will give it a go this weekend and see how it likes multiple-pass assembly with different include directives in the different passes.

[simonm]

Hi folks, just a quick update that I've merged all of Tom's updates into the extension repo and published the v0.1.0 to the official marketplace so it can be installed directly from within vscode.

I also added some CI to automate all of the release process, so will be super easy now to keep the updates coming since we have a bit of momentum going on it.

Cheers
Simon

[simonm]

btw since initially creating this plugin (8 years ago!! ) I've switched from Windows to Mac
I've added an issue here in the repo, to invite ideas for a dev environment setup for Mac.
If anyone has suggestions they'd be very welcome to add comments there! thanks

[ChrisB]

Thanks for this. I've been using it for a day or so and there are a few niggles. Any chance they can be looked at?

This version seems slower to recognise labels. So if I type ".abcd" then type "beq ab" then "abcd" isn't given. I can't seem to see the logic here - it seems inconsistent.

It also seems too keen to offer keywords. EQUB makes no sense here.

Sometimes the suggestions are just plain odd.

indexing oddity.png (4.06 KiB) Viewed 544 times

This version seems less able to detect 6502 files with me having to manually st the language

Lastly I've added the "main" file and I get lots of "hover" prompts (although these seem to be of limited use just showing ".label") - but none of the included files show these.

[kieranhj]

I second Chris’s comments. The updated version very quickly offers me keywords (which I can remember anyway because these never change) but no longer offers me labels (which I can’t, because they change with every program).

[tomhelm]

Chris & Kieran, thanks for the notes about issues. I'll hopefully be able to fix over the next week.

We're basically passing vscode all the potential things that could be used for completions i.e. all beebasm built-in functions and commands, all the symbols and labels that are found in parsing the code. Then vscode is left to filter based on how well they match whatever is typed in. Actions I need to look at:

• Make sure list of beebasm commands is just the command, not the example parameters (I think this is why 'ab' is leading to suggest EQUB a, [b, c, ...] with a very loose match
• Filter out internal label or symbol names based on scope, in particular the suffixes that beebasm uses to allow the same symbol or looping variable in different scopes.
• For the speed in offering labels, I think there may be an easy way to cut this in half (we use beebasm's two pass scan of the code to pick up labels and symbols first, then check everything can be resolved on the second pass), so should be able to provide the labels after the first pass.

Feel free to open an other issues spotted either here or on the GitHub repository https://github.com/simondotm/beeb-vsc/issues

[tomhelm]

This version seems less able to detect 6502 files with me having to manually st the language

Specifically on this point, I could reproduce with file extension .6502 not being recognised first time but .asm and .s were fine. We register all 3 as part of the extension configuration. Digging into the vscode settings, I found I had .6502 explicitly mapped for some reason:

Deleting this entry got things working as expected. It may have been caused by some internal changing of the language ID but I'm not sure why it would only affect this one.

[simonm]

Hi folks,
Just to let you all know that there's a new v0.2.1 release of this extension, and the big news is that we now have an integrated JSBeeb emulator!

https://marketplace.visualstudio.com/it ... m.beeb-vsc

This feature lets you preview any ssd or dsd files in your workspace nice and easily!

https://github.com/simondotm/beeb-vsc/b ... mulator.md

Feedback and feature suggestions are very welcome here. Thanks to Matt G for giving his blessing to use JSBeeb in the extension, and thanks also again to Tom Helm for his awesome help with the code development features in the extension.

Enjoy

[archie456]

Can I make a suggestion for the new release:

- When you specify a Source File, it saves this information in settings.JSON... The source file is saved with an absolute path. The problem is that if you move your code folder you then get errors everywhere (as it can't find the source file)... If the extension could save the file information with a relative path what would solve the issue. I tend to move my folders around fairly regularly.

Great work! Thanks!

[tomhelm]

Can I make a suggestion for the new release:

- When you specify a Source File, it saves this information in settings.JSON... The source file is saved with an absolute path. The problem is that if you move your code folder you then get errors everywhere (as it can't find the source file)... If the extension could save the file information with a relative path what would solve the issue. I tend to move my folders around fairly regularly.

Great work! Thanks!

Thanks for the suggestion! Using the full path was a bad decision I made but an easy fix. I already made the fix in the development branch a few days ago. There are a couple of other small issues I plan to address, then should be able to prepare a new release with this include.

[tomhelm]

We’ve just released a new version with the change to use relative paths by default. It won’t change existing settings.json files automatically so please edit it if you want portability.

Can I make a suggestion for the new release:

- When you specify a Source File, it saves this information in settings.JSON... The source file is saved with an absolute path. The problem is that if you move your code folder you then get errors everywhere (as it can't find the source file)... If the extension could save the file information with a relative path what would solve the issue. I tend to move my folders around fairly regularly.

Great work! Thanks!

[archie456]

Excellent, thanks for your hard work!