Jump to content

Recommended Posts

...

 

Symbol table is annoying. Nothing like having the program working right with the cartridge but then running out of symbol table space when you add the runtime. There are work arounds of course you are really talking a large program with a lot of variables before you even hit the wall. If you know in advance you are going to have a problem it isn't that tough to reuse your variables and edit your RT to only routines you use. IMO this is pretty much standard programming practice too. Just declare your loop counters as global variables and treat them accordingly. You seldom have need for more then a couple of 8 bit and 16 bit volatile values anyway.

 

I work with a lot of 3rd party global symbols in Action! when I am creating applications that run in the BBS Express Pro! environment. Therefore, it's not uncommon to run out of global symbol table space. Yes, it's possible to further split up programs and cull runtime symbols, but as you say, it's annoying (because it slows down the software development process). I'd love to see an Action! upgrade that includes larger symbol tables by default.

 

-JP

 

  • Like 5

Share this post


Link to post
Share on other sites

A feature to allow compiling large programs with automatic bank-switching functions would be great. On the easier side a dedicated print command and/or a bash like memory for recently used filenames for the write editor command would be handy, as would be a compile command accessible from the editor.

 

A modern style copy/paste function (maybe using shift and cursor keys and inverting the selection) allowing to copy/paste of parts of a line only would be handy as well.

 

Inline assembly?

  • Like 2

Share this post


Link to post
Share on other sites

 

I work with a lot of 3rd party global symbols in Action! when I am creating applications that run in the BBS Express Pro! environment. Therefore, it's not uncommon to run out of global symbol table space. Yes, it's possible to further split up programs and cull runtime symbols, but as you say, it's annoying (because it slows down the software development process). I'd love to see an Action! upgrade that includes larger symbol tables by default.

 

-JP

 

 

The V3.6 16K ROM build and the XEX build already use twice the size for the symbol table. The OSS build intentionally remains the genuine original, but you can patch one byte to adapt it.

 

.if fix_stsp_pages = 0

stsp_pages = $08 ; 2K id space

.else

stsp_pages = $10 ; 4K id space

.endif

  • Like 1

Share this post


Link to post
Share on other sites

Anyone fancy making a build of Action! which runs off the SIDE2's external cart? I realise it will require a little ingenuity since SIDE uses the data bus for banking, but since it will shortly be possible to use the SIDE's external cartridge space alongside the U1MB PBI hard disk, it would be nice to have something useful to put there when the user does not require the external loader. Bank register is at $D5E4 (write $00-$1F).

 

I am simply attempting to avoid investing the time in doing this myself. :)

  • Like 1

Share this post


Link to post
Share on other sites

Anyone fancy making a build of Action! which runs off the SIDE2's external cart? I realise it will require a little ingenuity since SIDE uses the data bus for banking, but since it will shortly be possible to use the SIDE's external cartridge space alongside the U1MB PBI hard disk, it would be nice to have something useful to put there when the user does not require the external loader. Bank register is at $D5E4 (write $00-$1F).

 

I am simply attempting to avoid investing the time in doing this myself. :)

 

Hi Jon,

 

I don't plan any banked versions other than the original OSS version. There are regular XEX version for everything else. ACTION! anyways requires a DOS to be present. Or is there a reason why they would not work?

Share this post


Link to post
Share on other sites

I don't plan any banked versions other than the original OSS version. There are regular XEX version for everything else. ACTION! anyways requires a DOS to be present. Or is there a reason why they would not work?

 

I'm aware that Action! requires DOS (why would it not?), but I assume the fact people run CAR images of Action! from multicarts means there's a demand to run the application in ROM, regardless of the fact XEX versions exist. The other reason is that if it is possible, why not?

 

Perhaps you misunderstand what I'm attempting to do (assume that's the reason you mention DOS). The upper half of the SIDE cart is simply a 256K banked cartridge. If something other than the loader (such as Action!) is put there, the cartridge can be run from SDX (via the CAR command) or used with any other DOS booted from disk. The default content of the same ROM space (the loader) does not allow a disk boot simply because it doesn't need to. :)

  • Like 2

Share this post


Link to post
Share on other sites

Further to my prior request for patched ROMs: a kind and talented soul has taken care of the matter. BASIC XL, MAC/65, and Action! ROMs for SIDE will be released with the forthcoming firmware update. :)

Edited by flashjazzcat
  • Like 7

Share this post


Link to post
Share on other sites

Update 2020-05-17

 

https://www.wudsn.com/productions/atari800/action/action.zip


- The Action! program is now called "ACTION.COM" in all disk versions.
- The Action! editor is now included as "ACTIONED.COM" in all disk versions.
- The Action! editor now has a build date, just like Action! itself.
- The Action! editor documention is now included as "ACTION.TXT" in all disk versions.
  https://sourceforge.net/p/atari-action/code/ci/master/tree/JAC/ref/Action.txt
  Feedback is welcome.
- Disk version for DOS XL added.
- Passing command line parameters to the Action! editor now also works in DOS XL.
- Incorrect status text output has been fixed in the Action! editor.
  There had been some places in the source where ASCII/ and ATASCII was mixed up.
- The README.TXT file on the disks now has correct EOL.

 

Note: The version dated 2020-05-17 which was uploaded first still had my (KIL) break points. This is fixed in the current upload. Also the DosXL build of that date had the OS/A+ boot secotors instead of the DosXL bootsectors. Both things are fixed in the build from 2020-05-18.

 

ACTION-Editor-01.pngACTION-Editor-02.thumb.png.ea6599d1ac51c71f5a5e9cefa4a377fa.png

  • Like 7
  • Thanks 2

Share this post


Link to post
Share on other sites

Great work JAC! Thank you so much! 🙂

 

So, then just the 2 programs are missing for ACTION!:

https://atariwiki.org/wiki/Wiki.jsp?page=Action#section-Action-StillMissingGraphicsUtilitiesLibraryAndShapeEditor

 

and the buglist to zero:

https://atariwiki.org/wiki/Wiki.jsp?page=Action Bugsheet#section-Action+Bugsheet-3

 

On the other hand, you already have proved the rumor, that Clinton Parker has used every(!) byte possible in the cart. Therefore, no place for changes or updates, until we increase the cart size itself...

goteam (animated).gif

  • Like 1

Share this post


Link to post
Share on other sites

Is it possible to compile a "compiler only" or "compiler and library only" version? 

Share this post


Link to post
Share on other sites
6 hours ago, slx said:

Is it possible to compile a "compiler only" or "compiler and library only" version? 

To what end ? Most of the editor could be removed, and I think the built-in library could also probably be removed but why ?

Share this post


Link to post
Share on other sites

Well, due to the fact, Alfred has shown for us how to extract the editor out of it, the compiler should be possible, too. Why not?

 

Alfred did us a great favor with the editor, which is very good for the native Atari programs and can therefore be used even with other programs.

 

My idea with the Ultimate BASIC is exactly for these reasons. Take from all programs the best codes and join them all together... ;-)

https://atariwiki.org/wiki/Wiki.jsp?page=Ultimate Basic

Share this post


Link to post
Share on other sites
4 hours ago, Alfred said:

To what end ? Most of the editor could be removed, and I think the built-in library could also probably be removed but why ?

I had a rather vague idea that it would be interesting to port Action! to other 6502 based systems (notably the BBC Micro) which could use the same compiler but would obviously need completely different editors and adapted libraries. 

Share this post


Link to post
Share on other sites
2 hours ago, slx said:

I had a rather vague idea that it would be interesting to port Action! to other 6502 based systems (notably the BBC Micro) which could use the same compiler but would obviously need completely different editors and adapted libraries. 

Yes, you could probably do that. The compiler makes use of a few routines from the editor for reading source lines from either the buffer or a file, but pretty much all the rest of the editor could go. Ripping out the internal system library should be pretty easy, delete 4 lines of code and throw away the big internal tables. The compiler makes no assumptions about the machine, it ought to be usable on any 6502 platform.  About the only dependencies I can think of are, you need a few zero page ranges, on the Atari I think it s$8X, $Cx and $Ax, and the compiler assumes that there is always a heap space following the binary. It's a pretty vanilla system.

  • Like 3

Share this post


Link to post
Share on other sites

I like the idea of a version with the editor gone, or at least something that could open Action directly in the monitor prompt instead.

 

What I am thinking is a more efficient cross-development environment, where the emulator is called by an external editor and only compiles files from the disk. I know there is the possibility to load it based on a snapshot directly there like @zbyti does, but I imagine removing the editor would free more memory space for the program itself. wouldn't it?

 

I think such a stripped down version would only make sense in the cartridge format.

 

On a side note, is there instruction on how one can build Action! from the source himself?

 

Cheers

 

 

 

Share this post


Link to post
Share on other sites
52 minutes ago, pedgarcia said:

I imagine removing the editor would free more memory space for the program itself. wouldn't it?

Action! it's switchable cartridge, if you only compile from disk under monitor you not gain much more free space over what you can use in such situation. Writing a parser/lexer and cross-compiler based on existing Action! sources for @dmsc or @tebe should be walk in the park ;) but they have their own projects... :]

Edited by zbyti
walk in the park

Share this post


Link to post
Share on other sites
2 hours ago, funkheld said:

can you start action!-37-programs from disk with a runtime?

greeting

Like with the standard Action! you have to compile with a disk version of the runtime to get a stand-alone binary.

Share this post


Link to post
Share on other sites
9 hours ago, pedgarcia said:

I like the idea of a version with the editor gone, or at least something that could open Action directly in the monitor prompt instead.

 

What I am thinking is a more efficient cross-development environment, where the emulator is called by an external editor and only compiles files from the disk. I know there is the possibility to load it based on a snapshot directly there like @zbyti does, but I imagine removing the editor would free more memory space for the program itself. wouldn't it?

 

I think such a stripped down version would only make sense in the cartridge format.

 

On a side note, is there instruction on how one can build Action! from the source himself?

 

Cheers

 

 

 

The build scripts and launch files are part of the github repo:

 

https://sourceforge.net/p/atari-action/code/ci/master/tree/JAC/build/

 

if you really want to go into cross-development with an Action! style language, you should use MAD Pascal. You can basically translate Action! into Pascal with a few substitutions.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks @JAC!. Yes, you have a good point about the MAD Pascal option. My current objective is more finding what is possible with Action just because I want to learn it, more than developing something for the Atari, but for a full cross-compiler environment I agree that MAD Pascal would be a better choice.

 

Cheers

 

Share this post


Link to post
Share on other sites
On 10/23/2020 at 1:00 AM, JAC! said:

if you really want to go into cross-development with an Action! style language, you should use MAD Pascal. You can basically translate Action! into Pascal with a few substitutions.

If I understood it correctly, then this is how the later versions of Effectus by @Gury work.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...