Atari Dev Studio for Homebrew Development [Release]

[+Andrew Davie]

"Have you tried turning it off then on again?"

 

[+Karl G]

The new release is working for me, however Stella doesn't have the execute bit set on the binary. I don't know if this is new to this release or not since I've been launching my own installed version of Stella via my Makefile:

 

Karls-MBP:~ kdgarris$ ls -l .vscode/extensions/chunkypixel.atari-dev-studio-0.4.4/out/bin/emulators/stella/darwin/x64/Stella.app/Contents/MacOS/
total 11304
-rw-r--r--  1 kdgarris  staff  5784952 Mar 23 10:34 Stella

 

[+stephena]

I can check with the released binary later today, but as I haven't changed anything on my end, and it always worked before this, I don't know what it could be.  I do know that if you copy 'Stella.app' with a normal cp command, sometimes the permissions are screwed up.  This is a MacOS thing; there's nothing I can do about it on my end.  And if you copy it outside of a Mac (like in Linux or Windows), similar things may happen.

[+Karl G]

9 minutes ago, stephena said:

I can check with the released binary later today, but as I haven't changed anything on my end, and it always worked before this, I don't know what it could be.  I do know that if you copy 'Stella.app' with a normal cp command, sometimes the permissions are screwed up.  This is a MacOS thing; there's nothing I can do about it on my end.  And if you copy it outside of a Mac (like in Linux or Windows), similar things may happen.

I was able to install and run the official 6.1 MacOS release without any issues.  This issue is specific to the bundling of Stella with the ADS extension, I think.

[+mksmith]

7 hours ago, Karl G said:

The new release is working for me, however Stella doesn't have the execute bit set on the binary. I don't know if this is new to this release or not since I've been launching my own installed version of Stella via my Makefile:

 

Karls-MBP:~ kdgarris$ ls -l .vscode/extensions/chunkypixel.atari-dev-studio-0.4.4/out/bin/emulators/stella/darwin/x64/Stella.app/Contents/MacOS/
total 11304
-rw-r--r--  1 kdgarris  staff  5784952 Mar 23 10:34 Stella

 

 

7 hours ago, stephena said:

I can check with the released binary later today, but as I haven't changed anything on my end, and it always worked before this, I don't know what it could be.  I do know that if you copy 'Stella.app' with a normal cp command, sometimes the permissions are screwed up.  This is a MacOS thing; there's nothing I can do about it on my end.  And if you copy it outside of a Mac (like in Linux or Windows), similar things may happen.

 

7 hours ago, Karl G said:

I was able to install and run the official 6.1 MacOS release without any issues.  This issue is specific to the bundling of Stella with the ADS extension, I think.

 

[Update]

@Karl G  if you are launching Stella via a script then you are responsible to set the permissions using ChMod. I noted Andrew had done this in his example makefile.

 

I will verify ADS is still setting the permissions as we previously added.

[+Karl G]

38 minutes ago, mksmith said:

 

 

 

[Update]

@Karl G  if you are launching Stella via a script then you are responsible to set the permissions using ChMod. I noted Andrew had done this in his example makefile.

 

I will verify ADS is still setting the permissions as we previously added.

Okay; sorry if I missed this, then.  Is there a reason it comes as non-executable? Some security-related reason or somesuch?

[+mksmith]

Just now, Karl G said:

Okay; sorry if I missed this, then.  Is there a reason it comes as non-executable? Some security-related reason or somesuch?

Don't know mate - I just grab them straight off Github and put them in. Initially it was a matter of testing and finding it didn't work on Linux so added the ChMod settings as they came up.  bB and 7800basic require all files used for compilation to be set also.

[+Karl G]

I can add a chmod to my Makefile no problem, but for what it's worth, this is what I found on this page:

Quote

 

Why does vsce not preserve file attributes?

 

Please note that when building and publishing your extension from Windows, all the files included in the extension package will lack POSIX file attributes, namely the executable bit. Some node_modules dependencies rely on those attributes to properly function. Publishing from Linux and macOS works as expected.

 

 

[+mksmith]

5 minutes ago, Karl G said:

I can add a chmod to my Makefile no problem, but for what it's worth, this is what I found on this page:

 

Ah - ok that explains it then. Thanks for the info!

[+mksmith]

Hi everyone,

 

I have an incoming update with the latest Stella release v6.1.1 - just need to do some quick testing on macOS and Linux before I release.

 

I also have a couple of additional changes which will require some testing so they will come in the next one.  Apologies for the delay as I'm still working on another project currently which taking up a bit of my spare time.

[+mksmith]

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

• Updated Stella to 6.1.1 (Windows, Linux, macOS)
• Added initial items for macOS Touch Bar - Build, Build & Run (Generation2Games)
• Added missing set romsize intellisense item: 144k (7800basic)

I added some initial support for the macOS touch bar - nothing too major but just need confirmation they work (worked on a touch bar emulator in my VM) before we go any further.  Also my Linux VM borked itself so I wasn't able to test the new Stella release but saying that it's the easiest change of the 3 so thinking it should work.

 

I also don't know if the makefile.bat change is working from the past couple of releases - that needs more checking as I think i'll need to change how that works compared to the makefile.sh and makefile processes.

 

[+mksmith]

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

• #16 [Done] Added NTSC and PAL palettes for the 2600 (MikeBrownEmplas) 
• #17 [Done] Added ability to create 2600 sprites (added sizing, colors and palettes) and export them to batari Basic or assembly format (MikeBrownEmplas)
• #23 [Done] Rotated palette display to show vertically instead of horizontally (various)
• #29 [Done] Added Palette (region) selector to Palette window. Added PAL palette and updated NTSC palette to match A7800 (warm)
• Updated Project dialog for better selection of sizing ranges for the 7800 where steps follow expected boundaries (multiples of 4 for width and 8 for height). Also added 2600 ranges (8 for width and 1-256 for height)
• Updated loading of projects to validate the console and total colors of the file being loaded.  Added console to properties when saving a project.
• Updating loading and saving of projects, palettes, images and source to use the workspace root folder as a starting location if none is provided.

So this build focuses on the Sprite Editor adding a number of long-standing features I should have already added a long time ago such as additional palettes and 2600 features ? 

 

This one is particularly for the 2600 users as you can now create and export single color sprites out to batari Basic or assembly source code.  If I haven't got this quite right or missed other formats please let me know.  Apologies for the long wait but the sprite editor is reasonably complex as parts of it live in different projects due to the communication between VS Code as it's web views + I don't really enjoy dabbling in js.  Anyway apart from missing DPC+ coloring this should work pretty well for just about everyone now.

 

[+TwentySixHundred]

3 minutes ago, mksmith said:

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

• #16 [Done] Added NTSC and PAL palettes for the 2600 (MikeBrownEmplas) 
• #17 [Done] Added ability to create 2600 sprites (added sizing, colors and palettes) and export them to batari Basic or assembly format (MikeBrownEmplas)
• #23 [Done] Rotated palette display to show vertically instead of horizontally (various)
• #29 [Done] Added Palette (region) selector to Palette window. Added PAL palette and updated NTSC palette to match A7800 (warm)
• Updated Project dialog for better selection of sizing ranges for the 7800 where steps follow expected boundaries (multiples of 4 for width and 8 for height). Also added 2600 ranges (8 for width and 1-256 for height)
• Updated loading of projects to validate the console and total colors of the file being loaded.  Added console to properties when saving a project.
• Updating loading and saving of projects, palettes, images and source to use the workspace root folder as a starting location if none is provided.

So this build focuses on the Sprite Editor adding a number of long-standing features I should have already added a long time ago such as additional palettes and 2600 features ? 

 

This one is particularly for the 2600 users as you can now create and export single color sprites out to batari Basic or assembly source code.  If I haven't got this quite right or missed other formats please let me know.  Apologies for the long wait but the sprite editor is reasonably complex as parts of it live in different projects due to the communication between VS Code as it's web views + I don't really enjoy dabbling in js.  Anyway apart from missing DPC+ coloring this should work pretty well for just about everyone now.

 

Cheers mate, thanks for the continuous development of this tool. I can't wait to dive in and check out all the new 2600 features ?

[+mksmith]

2 minutes ago, TwentySixHundred said:

Cheers mate, thanks for the continuous development of this tool. I can't wait to dive in and check out all the new 2600 features ?

Pleasure mate - apologies for taking so long to add.  Hopefully the DPC+ coloring will come along soon.

[+TwentySixHundred]

13 minutes ago, mksmith said:

Pleasure mate - apologies for taking so long to add.  Hopefully the DPC+ coloring will come along soon.

Not a worry - no stress. It's easy enough to change the values after in code anyway.

[+Karl G]

On 4/7/2020 at 2:19 AM, mksmith said:

I added some initial support for the macOS touch bar - nothing too major but just need confirmation they work (worked on a touch bar emulator in my VM) before we go any further.

 

I meant to reply to this before, but it works like a treat here!

 

[+mksmith]

Thanks Karl ? I need to see if I can either hook into the VSCode compile buttons or remove them for mine.

[+mksmith]

@Random Terrain @EvoMikeUK

Hey guys, just referring back to your post abck in the bB forum about the palettes and vertical layout.  This has now been done in Atari Dev Studio:

 

Lots of changes mainly for 2600 editing - also thanks RT for your page as I took the palette values directly from them ?. Still need to look at DPC+ but images can now be created and exported to bB or assembly code. 

[+mksmith]

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

• Fixed issue where 7800basic was not handling .list.txt files as expected based on preference selections
• Fixed issue where spacing on custom compiler paths failed to compile (bB, 7800basic, dasm)
• Fixed an issue with setting custom dasm path related to the recent changes
• Updated the initialisation process to display messages in the compile log when custom compilers have been chosen. For warning or error messages pop-ups are also displayed.
• Added missing 7800basic keywords: switchpause, changecontrol, drivingposition0, drivingposition1, 2buttonjoy, 1buttonjoy, lightgun, paddle, trakball, driving, keypad, stmouse, amigamouse, atarivox, keypad0key0, keypad0key1, keypad0key2, keypad0key3, keypad0key4, keypad0key5, keypad0key6, keypad0key7, keypad0key8, keypad0key9, keypad0keys, keypad0keyh, keypad1key0, keypad1key1, keypad1key2, keypad1key3, keypad1key4, keypad1key5, keypad1key6, keypad1key7, keypad1key8, keypad1key9, keypad1keys, keypad1keyh
• Updated hover tooltips for 7800basic keywords

This is a 'how could I have missed that' build with some of the issues I found ? Anyway another release closer to perfection ?

 

[+Karl G]

Great work as always.  I'm using ADS for all of my Atari 2600/7800 coding now.

 

I was messing around with the sprite editor, and I noticed that it doesn't seem to be exporting Atari 2600 sprites correctly regardless of whether I choose batari Basic or assembly for the export.  Here's an example of an 8x8 sprite, and the output.  In addition to the output being incorrect on the lower lines, it is only putting 7 bits on each line.

 

 

;Created using Atari Dev Studio

Sprite1:
	.byte %1111111 ;
	.byte %0111111 ;
	.byte %0011110 ;
	.byte %0001100 ;
	.byte %0001100 ;
	.byte %0011110 ;
	.byte %0111111 ;

 rem Created using Atari Dev Studio

 sprite1:
 %1111111
 %0111111
 %0011110
 %0001100
 %0001100
 %0011110
 %0111111
end

 

[+mksmith]

Doh - add that to the 'can't believe it missed that' list ???? Thanks Karl will fix that shortly ?

[+mksmith]

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

• Fixed issue exporting images to batari Basic and assembly with incorrect width and height (karlg)
• Added a 'Show on Startup' checkbox to the Project dialog. The editor will default to your last settings (Note: I need to work out how I can store these outside the current installation)

Thanks @Karl G for the find ?

[+Karl G]

9 minutes ago, mksmith said:

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

 

• Fixed issue exporting images to batari Basic and assembly with incorrect width and height (karlg)
• Added a 'Show on Startup' checkbox to the Project dialog. The editor will default to your last settings (Note: I need to work out how I can store these outside the current installation)

Thanks @Karl G for the find ?

That was fast!  Unfortunately, I have one more related report/request: bB sprites should be upside down, unless they are intended for the DPC+ kernel.  Assembly sprites are usually upside down as well for efficiency reasons.  My request is to add a third export target for DPC+ which would have the rightside-up export that you have now, and switch the other two to have the lines be upside down.

[+mksmith]

1 hour ago, Karl G said:

That was fast!  Unfortunately, I have one more related report/request: bB sprites should be upside down, unless they are intended for the DPC+ kernel.  Assembly sprites are usually upside down as well for efficiency reasons.  My request is to add a third export target for DPC+ which would have the rightside-up export that you have now, and switch the other two to have the lines be upside down.

Ah right - didn't realise that as I only did DPC+ Sounds good - will do that later today as I have some work on presently ?

[+Andrew Davie]

Have upgraded. The new version disappears/kills the output window when doing a build/run.

Unfortunately, this window is something quite useful to me - I like to see all the diagnostics from the build.

Can this be an option/fixed, please?