Atari Dev Studio for Homebrew Development [Release]

[+Andrew Davie]

Probable bug:

When I do a build via my hotkey (Opt+Command+B), if I'm focussed on a ".asm" window, all works.

But if I'm focussed on a ".h" window, it gives me the following error...

 

 

[+mksmith]

On 4/4/2021 at 2:15 PM, Andrew Davie said:

Probable bug:

When I do a build via my hotkey (Opt+Command+B), if I'm focussed on a ".asm" window, all works.

But if I'm focussed on a ".h" window, it gives me the following error...

 

 

Hi Andrew - apologies for the late reply. 

 

I'll take a look at what's going on there - it may be that it's not using the correct folder/path when searching for the makefile.  One question - any of those files are in the root folder or sub-folders?

 

[+Andrew Davie]

31 minutes ago, mksmith said:

Hi Andrew - apologies for the late reply. 

 

I'll take a look at what's going on there - it may be that it's not using the correct folder/path when searching for the makefile.  One question - any of those files are in the root folder or sub-folders?

 

I have a mixed C/asm project, which gets a bit confusing when they both use ".h" files.

Would be nice to have the build just call the make regardless of the file extension/type.

 

[+Andrew Davie]

33 minutes ago, mksmith said:

Hi Andrew - apologies for the late reply. 

 

I'll take a look at what's going on there - it may be that it's not using the correct folder/path when searching for the makefile.  One question - any of those files are in the root folder or sub-folders?

 

Files are in the project root directory. Their association is to either "dasm" or "C". When I hotkey-build on ".asm" or "Makefile" all works. When I hotkey-build on C or ".h" nothing happens, regardless if the ".h" is a "dasm" file or a "C" file. What I'd like to happen, actually, is the build to happen on hotkey *regardless* of the file type/association in the window.  But, failing that, ".h" associated to "dasm" should behave the same as ".asm" associated to "dasm".

 

[+mksmith]

Ok thanks Andrew.  It sounds I'll need to add some further file types to the MakeFile association. Will check that out thanks mate.

[+Karl G]

I was researching how I could comment multiple lines of code with semicolons, and I discovered that the language definition files for batari Basic and 7800Basic don't define a line comment like the DASM language definition does. I think it would be good to add these, either with a semicolon or REM:

 

    "comments": {
        // symbol used for single line comment. Remove this entry if your language does not support line comments
        "lineComment": ";",
        "blockComment": ["/*", "*/"]
    },

 

[+mksmith]

14 hours ago, Karl G said:

I was researching how I could comment multiple lines of code with semicolons, and I discovered that the language definition files for batari Basic and 7800Basic don't define a line comment like the DASM language definition does. I think it would be good to add these, either with a semicolon or REM:

 

    "comments": {
        // symbol used for single line comment. Remove this entry if your language does not support line comments
        "lineComment": ";",
        "blockComment": ["/*", "*/"]
    },

 

Thanks Karl - I'll check that out!

[+mksmith]

On 4/7/2021 at 1:35 PM, Andrew Davie said:

Files are in the project root directory. Their association is to either "dasm" or "C". When I hotkey-build on ".asm" or "Makefile" all works. When I hotkey-build on C or ".h" nothing happens, regardless if the ".h" is a "dasm" file or a "C" file. What I'd like to happen, actually, is the build to happen on hotkey *regardless* of the file type/association in the window.  But, failing that, ".h" associated to "dasm" should behave the same as ".asm" associated to "dasm".

 

Hi Andrew,

 

Been doing some checking on this. The base dasm association contains the .h reference, so by default if you select the 'Make' compiler for dasm then it will search for the appropriate make file (at least I does for me on Windows).  It may be that VS Code is not always associating .h with dasm (or that VS Code on macOS is slightly different than Windows in some manner - my virtual environment is not up and running currently) as you are finding with mixing c/dasm.  The first part of the compile validation is using the file association to determine which 'language' to use then in the case of dasm validating whether to use the default, custom or makefile so the message does seem a little odd in that regard.

 

The whole file association thing is great in theory but is really not working for how I have configured/hack-in the makefile process. I have again been considering the 'project' process we had previously discussed so that it doesn't use the file association when you use the ADV build/rum hotkeys. I'm going to take a bit of a look over the next few weeks but am thinking of having a settings option to select the following:

 

* use a 'project' file (containing the base config)

* use the makefile/shell/bat process

* use file association (existing)

 

The first two options should/will allow the user to 'take over' the editor and select a compiler/build process to use for any file currently open.  

 

[+Andrew Davie]

13 minutes ago, mksmith said:

Hi Andrew,

 

Been doing some checking on this. The base dasm association contains the .h reference, so by default if you select the 'Make' compiler for dasm then it will search for the appropriate make file (at least I does for me on Windows).  It may be that VS Code is not always associating .h with dasm (or that VS Code on macOS is slightly different than Windows in some manner - my virtual environment is not up and running currently) as you are finding with mixing c/dasm.  The first part of the compile validation is using the file association to determine which 'language' to use then in the case of dasm validating whether to use the default, custom or makefile so the message does seem a little odd in that regard.

 

The whole file association thing is great in theory but is really not working for how I have configured/hack-in the makefile process. I have again been considering the 'project' process we had previously discussed so that it doesn't use the file association when you use the ADV build/rum hotkeys. I'm going to take a bit of a look over the next few weeks but am thinking of having a settings option to select the following:

 

* use a 'project' file (containing the base config)

* use the makefile/shell/bat process

* use file association (existing)

 

The first two options should/will allow the user to 'take over' the editor and select a compiler/build process to use for any file currently open.  

 

 

Sorry, I meant to update on this.

The first issue I reported (where dasm-associated files were not building) was actually because they were in a subdirectory (main/) and there literally was no makefile there. I solved that by putting a "redirect" makefile in that subdirectory (i.e., "(cd .. & make)") which worked fine.  But my main issue is that I have code which combines C and assembler files (with the added confusion that both use ".h").  If I associate the C and .h files with dasm, then all works perfectly - I can build. But I lose the "intellisense" stuff on the C files. I can't cmd-click on a variable and go to its source. And worse, the syntax highlighting is all wrong (dasm-style-for-assembler instead of C-style-for-c). So the code looks ugly indeed.

My current solution is to leave it all as "dasm" as it's quicker for me to modify/build.

But if I *really* want the proper colour/syntax highlighting and intellisense, then I have to switch the association to "C" and lose the ability to build when that file is in the focus. In that case, I switch to the makefile and hit build, and then switch back.

 

 

 

 

 

[+mksmith]

Thanks for the update mate ?  The .h file is clearly tricky due to the association - would it eventually be best to have that restored to the 'C' file association for editing purposes?  I think allowing the VS Code to keep it's base file associations for languages might be best and then have the ability to override/set the compiler quickly might work nicely. I'm thinking of adding a sidebar tab to manage the basics for ADS so you don't have to access the settings to select the compiler.

 

I'm surprised it's not finding the root/parent makefile as that's what I intended but nice job getting that working.

 

 

[newtmonkey]

@mksmith

 

Thank you so much for this!!!!  I've been teaching myself to code over the last year and a half, starting with Python then moving to C# and Unity/C#.  I've just been going through textbooks, following the lessons and learning a lot, but hesistant to take the first step into actually coding my own application.  That all changed today (just now in fact), thanks to your Dev Studio (and the 7800 basic Guide)! 

 

I can't express how awesome it felt to get my own game with my own graphics (well, "graphic") running on my actual 7800 played through the Dragonfly cart.  Really a dream come true for a guy who grew up playing 7800 games!  It's not much, but I've got a non-animated sprite moving around the via joystick control.  Really more of a HELLO WORLD thing than anything, but the skeleton is there for me to start adding background tiles, animation, enemies, etc.

 

I had a very bad day Friday, one of the worst since the world went to pieces over the last year or so, but thanks to you and Atari Dev Studio, I have a big smile on my face and can't wait to start adding more and more to my game.  Thank you so much!!!!!!!

Edited April 17, 2021 by newtmonkey

[+mksmith]

@newtmonkey Hi thank you so much for your kind words.  Of course most of the credit goes to our illustrious devs such as Mike, Fred, Stephen and others for coding and maintaining all the tools ADS pulls together.  I, like you are very happy to be able to just install the extension, type some stuff and push some buttons and know I can see my efforts straight away and now we also have carts such as Dragonfly, Concerto and Harmony to see it on the real thing.

 

I love the community here for it's openness to share experiences and tools to help each other and ADS is my little contribution to that.

 

Happy coding!!

[newtmonkey]

Thanks also to the devs for all these great tools!!

[+mksmith]

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

•  Updated Stella to v6.5.3 (Windows, Linux [Deb], macOS). Note: Linux 32-bit is currently v6.2

[Bradsco]

First of all, thank you mksmith for this fantastic set of tools. One question though...

 

To successfully compile multi-file 7800basic projects, is the only solution to use a makefile or is there something else I'm missing in the usage?

 

Honestly I'd prefer one click compilation.

[+mksmith]

1 hour ago, Bradsco said:

First of all, thank you mksmith for this fantastic set of tools. One question though...

 

To successfully compile multi-file 7800basic projects, is the only solution to use a makefile or is there something else I'm missing in the usage?

 

Honestly I'd prefer one click compilation.

Hi Bradsco!

 

Thanks for taking a look at Atari Dev Studio!  Out of the box ADS is designed to compile and run for both bB and 7800basic.  The scripting side of it really is for the more advanced users who want a bit more control.

 

Currently filename conventions in VS Code dictate what compiler is used.  So for 7800basic I'd recommend using .78b as your extension then you don't have to doing anything else out of the box.

 

Eventually I do want look at some sort of config file but that is a while away as life is way too busy currently.

 

Have fun!

 

 

[Bradsco]

Hey mksmith thank you for the quick reply.

 

Yes, I've made it a practice to use .78b extension and that works perfectly. What I'm after is to have the source for a game split between multiple .78b files. For instance, a source file for each bank. If I'm not mistaken I'm seeing other projects that do something similar to this. Is it possible to have ADS handle multiple file like this?

[+mksmith]

5 minutes ago, Bradsco said:

Hey mksmith thank you for the quick reply.

 

Yes, I've made it a practice to use .78b extension and that works perfectly. What I'm after is to have the source for a game split between multiple .78b files. For instance, a source file for each bank. If I'm not mistaken I'm seeing other projects that do something similar to this. Is it possible to have ADS handle multiple file like this?

Ah sorry I missed that.  That was a feature I really desired myself but it will require a pre-processor to combine the file to then be compiled by 7800basic. 

 

What you could try is using regions to expand/collapse by bank (I do use this!)

 ;#region BANK2: MAIN GAME CODE

 ... code ...

 ;#endregion

Don't forget there is also the Outline window which allows you to locate methods etc (make sure you change the initial sort to get it in actual order).  There is also some other intellisense feature built in if that helps.

[Bradsco]

7 minutes ago, mksmith said:

Ah sorry I missed that.  That was a feature I really desired myself but it will require a pre-processor to combine the file to then be compiled by 7800basic. 

 

What you could try is using regions to expand/collapse by bank (I do use this!)

 ;#region BANK2: MAIN GAME CODE

 ... code ...

 ;#endregion

Don't forget there is also the Outline window which allows you to locate methods etc (make sure you change the initial sort to get it in actual order).  There is also some other intellisense feature built in if that helps.

That sounds like a great solution. I've gotten far enough along that having to scroll up and down a single large file is cumbersome, but I will definitely start using regions. Thanks again!

[+TwentySixHundred]

Nice! Feels like a lifetime since i have fired up ADS and thrown down some code. Really need to find some time and hoping things settle IRL so i can continue my projects. Good to see you're still keeping this extension up-to-date ?

[SlidellMan]

Hey, Windows Defender found what appears to be malware in 7800filter.exe and 7800makecc2.exe. It may be something worth looking into.

[+mksmith]

30 minutes ago, SlidellMan said:

Hey, Windows Defender found what appears to be malware in 7800filter.exe and 7800makecc2.exe. It may be something worth looking into.

Thanks mate - it's a bit of a false/positive thing that pops occasionally within Windows Defender - if you just allow those as they happen it's all good.  Frustrating for sure but nothing we can really do anything about.

[SlidellMan]

I've been getting "Cannot open includes.7800 for reading" when I try to compile my latest vertical shooting rewrite. In all honest, I am at a loss at what is causing it, and how to fix it.

[+mksmith]

On 6/30/2021 at 4:29 AM, SlidellMan said:

I've been getting "Cannot open includes.7800 for reading" when I try to compile my latest vertical shooting rewrite. In all honest, I am at a loss at what is causing it, and how to fix it.

Hey mate - can you send me your latest source and I'll take a look.

[ZippyRedPlumber]

Hi, new to using this, let alone visual studio. How do you compile & test roms?