Atari Dev Studio for Homebrew Development [Release]

[+Andrew Davie]

Just a quick note on the hover popup with opcode info... where it says "immidiate", it should say "immediate".  It's definitely wrong on "lda". I haven't checked all the other opcodes.

[+mksmith]

1 hour ago, Andrew Davie said:

Just a quick note on the hover popup with opcode info... where it says "immidiate", it should say "immediate".  It's definitely wrong on "lda". I haven't checked all the other opcodes.

Thanks Andrew - will check them for the next release ?

[+Andrew Davie]

 

Post removed.

I'm double-checking what I wrote.

 

 

Edited March 15, 2020 by Andrew Davie

[+splendidnut]

Any chance you can add the ability to set and call a custom build script (Windows batch file or Linux/Mac shell script) as opposed to the makefile?  I already have build scripts written, and I really don't want to have to go thru the process of migrating over to make.

 

OR... give the user the ability to set which file is the main file in a workspace for running thru DASM?  I dislike having to find and switch back to my main assembly file (multi-file project) every time I want to build and run.

 

Thanks.

[+mksmith]

8 hours ago, splendidnut said:

Any chance you can add the ability to set and call a custom build script (Windows batch file or Linux/Mac shell script) as opposed to the makefile?  I already have build scripts written, and I really don't want to have to go thru the process of migrating over to make.

 

OR... give the user the ability to set which file is the main file in a workspace for running thru DASM?  I dislike having to find and switch back to my main assembly file (multi-file project) every time I want to build and run.

 

Thanks.

Hi - well for scripts it's probably just a matter now of determining if a 'script' file is there and activating the appropriate call (.bat and .sh files are used by bB and 7800basic already). Ideally we could give it a specific name (ie. build.bat, build.sh) so it can be scanned for and just run it via the terminal. As with how the Make process works, you would be fully responsible to ensure all your environment is properly configured, launch Stella etc . 

 

All this has me now thinking about having a project file containing some information which would sit in the root workspace folder and handle things such as the determining the compiler, emulator, the main and target filename etc.  Atari Dev Studio was built around the basic (non-project) structure of VS Code and using the active file language to determine what to do. Perhaps that could be advanced a little...

[+mksmith]

A new release (v0.4.1) is now available with the following changes:

• Disposed and re-initialised Make terminal window (Andrew Davie) this should dispose of any running processes...
• Removed Make terminal set path feature as it's no longer required
• #24 Fixed spelling issue in 6502 hover tooltip popup (Andrew Davie)

@Andrew Davie - hopefully the terminal issue will now be resolved and it will close Stella for you.  It now disposes and creates a new terminal each compile - appeared to be the only way to do it. This also fixed an issue where is you manually closed the Make terminal window it didn't come back.

[+Andrew Davie]

24 minutes ago, mksmith said:

 

@Andrew Davie - hopefully the terminal issue will now be resolved and it will close Stella for you.  It now disposes and creates a new terminal each compile - appeared to be the only way to do it. This also fixed an issue where is you manually closed the Make terminal window it didn't come back.

 

Confirming that this is now working as expected.  Very handy update. Thanks!

 

[+mksmith]

Awesome! Thanks for letting me know ?

[+Karl G]

I'm afraid the latest update caused a new issue for me.  For some reason, it has a working directory two directories below my project directory, so it therefore tries to execute "make" in the wrong directory, and fails.  I've tried closing and reopening the source file, and closing and reopening the app, with no change in behavior.

 

Edit: It works normally again after reverting to 0.4.0.

[+mksmith]

6 hours ago, Karl G said:

I'm afraid the latest update caused a new issue for me.  For some reason, it has a working directory two directories below my project directory, so it therefore tries to execute "make" in the wrong directory, and fails.  I've tried closing and reopening the source file, and closing and reopening the app, with no change in behavior.

 

Edit: It works normally again after reverting to 0.4.0.

H Karl - are you opening your project using the Open Folder feature? It sets the working folder off that folder by default.  If you are can attach a pic of your folder structure I can try and replicate.

 

Update: the other thing you can try and open the makefile file and compile that - either way works.

[+Karl G]

23 minutes ago, mksmith said:

H Karl - are you opening your project using the Open Folder feature? It sets the working folder off that folder by default.  If you are can attach a pic of your folder structure I can try and replicate.

 

Update: the other thing you can try and open the makefile file and compile that - either way works.

Okay when I first upgraded to that version, I did accidentally open the directory in question, thinking I was just navigating to where I wanted to go.  I later closed everything and opened just the file I wanted, but maybe it associated the file with that directory from then on?

 

At any rate, with that clue, I was able to compile my source file successfully by first opening the folder it is in, then clicking on it.

 

Edit: it seems that it only works with the correct folder open now. There no longer seems to be a way to open just the source file and have it find the correct folder for compilation.

[+mksmith]

1 hour ago, Karl G said:

Okay when I first upgraded to that version, I did accidentally open the directory in question, thinking I was just navigating to where I wanted to go.  I later closed everything and opened just the file I wanted, but maybe it associated the file with that directory from then on?

 

At any rate, with that clue, I was able to compile my source file successfully by first opening the folder it is in, then clicking on it.

 

Edit: it seems that it only works with the correct folder open now. There no longer seems to be a way to open just the source file and have it find the correct folder for compilation.

Thanks for the update ? The check for a makefile only checks the root workspace folder currently - not sure how else to do it as if it goes on the current file that may not be what's intended either. If I check both then the root workspace should be the default then if nothing then check the active file path... hmmm.... 

 

The existing bB and 7800basic are always correct because they take the file you are compiling - this is a little different and may require a different workflow.  Will have to think about it ?

[+mksmith]

A new release (v0.4.2) is now available with the following changes:

• Added new welcome message on first run after new update has been applied (allows you to view the change log and can be dismissed).
• Added the following keyboard shortcuts which will activate when you have a bataribasic, 7800basic or dasm language file open:
  - F5 - Build and Run
  - Shift+F5 - Build

I do realise that I probably need to spend a little time on the Sprite Editor but another project is taking up more time ATM than I can allocate to doing this.  I do want (need!) to add the PAL palette definition so I can use it myself so once I get a little more time I shall knock that out (plus I have to delve into javascript).  VS Code has so many features its interesting to find something such as the keyboard shortcuts to add.

[+Andrew Davie]

18 minutes ago, mksmith said:

A new release (v0.4.2) is now available with the following changes:

• Added new welcome message on first run after new update has been applied (allows you to view the change log and can be dismissed).
• Added the following keyboard shortcuts which will activate when you have a bataribasic, 7800basic or dasm language file open:
  - F5 - Build and Run
  - Shift+F5 - Build

I do realise that I probably need to spend a little time on the Sprite Editor but another project is taking up more time ATM than I can allocate to doing this.  I do want (need!) to add the PAL palette definition so I can use it myself so once I get a little more time I shall knock that out (plus I have to delve into javascript).  VS Code has so many features its interesting to find something such as the keyboard shortcuts to add.

Are the keyboard shortcuts configurable?

I use Option-Command-B.  

[+mksmith]

6 minutes ago, Andrew Davie said:

Are the keyboard shortcuts configurable?

I use Option-Command-B.  

I believe so Andrew.  Go into the Code->Preferences->Keyboard Shortcuts and in the search box type 'ads'. You'll find the option ads: Compile source code and run in Emulator (F5) - click on the pencil icon to the left to change.  You could change either as they both just execute the makefile in your case ?

 

F5 is an old Visual Studio favorite  and programmed into my conscience ? 

[+Andrew Davie]

2 minutes ago, mksmith said:

I believe so Andrew.  Go into the Code->Preferences->Keyboard Shortcuts and in the search box type 'ads'. You'll find the option ads: Compile source code and run in Emulator (F5) - click on the pencil icon to the left to change.  You could change either as they both just execute the makefile in your case ?

 

F5 is an old Visual Studio favorite  and programmed into my conscience ? 

I think I used to use it too... but you have to reach ALL THE WAY ACROSS THE KEYBOARD to get to it.  Option-Command-B for me is instinctive because it's almost the closest combination of keys to where my hands are usually at - the touchpad - as you can get . 

 

[+Karl G]

Does anyone else remember Alt-F9, Control-F9?  ?

[+mksmith]

45 minutes ago, Karl G said:

Does anyone else remember Alt-F9, Control-F9?  ?

No ? which app was this with? Ah the memories of youth ?

[+Karl G]

3 minutes ago, mksmith said:

No ? which app was this with? Ah the memories of youth ?

Turbo C, and probably the other Borland compilers from late 80s/early 90s.

[Lillapojkenpåön]

A weird thing just happened to me, I clicked compile and run as usual, but it never got further than this

Starting build of simple_collision_prevention_with_detection_for_variable_speed 3.bas...

 

So I think I tried clicking it again and it said, compile process was already running, need to kill it with ads: kill build process,

so I tried that and a vs pop-up said that it failed, I tried compiling again, and it says that the file is being used by another process.

 

I restarted the computer and the same thing happened again.

 

EDIT:

I just uninstalled and deleted all old versions, and installed it again and it works now.

Edited March 19, 2020 by Lillapojkenpåön

[+mksmith]

8 hours ago, Lillapojkenpåön said:

A weird thing just happened to me, I clicked compile and run as usual, but it never got further than this

Starting build of simple_collision_prevention_with_detection_for_variable_speed 3.bas...

 

So I think I tried clicking it again and it said, compile process was already running, need to kill it with ads: kill build process,

so I tried that and a vs pop-up said that it failed, I tried compiling again, and it says that the file is being used by another process.

 

I restarted the computer and the same thing happened again.

 

EDIT:

I just uninstalled and deleted all old versions, and installed it again and it works now.

Very strange mate - sounds like the compiler locking up and VS Code not being able to release the process.  Keep an eye on it ?

[Lillapojkenpåön]

It happens when I change a variable to a constant in the standard kernel

 

    const hmm = 4

    ;dim hmm = l

    ;l=4

 

The variable just held that number

[+splendidnut]

On 3/15/2020 at 6:53 PM, mksmith said:

Hi - well for scripts it's probably just a matter now of determining if a 'script' file is there and activating the appropriate call (.bat and .sh files are used by bB and 7800basic already). Ideally we could give it a specific name (ie. build.bat, build.sh) so it can be scanned for and just run it via the terminal. As with how the Make process works, you would be fully responsible to ensure all your environment is properly configured, launch Stella etc . 

 

All this has me now thinking about having a project file containing some information which would sit in the root workspace folder and handle things such as the determining the compiler, emulator, the main and target filename etc.  Atari Dev Studio was built around the basic (non-project) structure of VS Code and using the active file language to determine what to do. Perhaps that could be advanced a little...

 

For executing script files, I'd think it'd be better just to have a setting/preference instead of the app auto-magically scanning for a "build" script.  This would give the user complete control over.  Visual Studio Code appears to track settings separately by user, workspace and directory.  With directory given the highest priority.

 

Though it is a shame that there is no project support in Visual Studio Code... that really makes me question the purpose of it, as that makes it just another multi-file text editor with syntax highlighting, something we already have plenty of.  We need more "project-management" based editors!  Maybe it's just me... asking too much of the software I use

 

Anyways, thanks for looking into the matter.

[+Andrew Davie]

55 minutes ago, splendidnut said:

Though it is a shame that there is no project support in Visual Studio Code... that really makes me question the purpose of it, as that makes it just another multi-file text editor with syntax highlighting, something we already have plenty of.  We need more "project-management" based editors!  Maybe it's just me... asking too much of the software I use

 

 

It picked up straight away that I was using git on my project, and integrated git.  So, it's a little bit more than what you say.

I'm happily using it in VSC on my "project". So for me, I've lost nothing by moving from Atom, and gained a fair bit.

 

[+Karl G]

I've made the switch, too - I had been using BBEdit. I miss the command-line integration with BBEdit, but the advantages outweigh that. Not too many editors have 6502 assembly, batari Basic, or 7800 Basic support for syntax highlighting, etc. I like being able to edit, build and run without switching between windows so much.