action! Going into Action! - A noob perspective

[pedgarcia]

Hi all,

 

I had played a bit with Action! more than a year ago, basically putting it to run and compiled a Hello World application. I remember that I read the very complete wiki about the language and being a little overwhelmed by the amount of versions and options.

 

Today, I decided to start looking into it again with the objective to write some articles for my website about it and also finally learn something about Atari 8-bit programming in general. 

 

With that in mind, I'd like a little help from you guys answering (or pointing me to the right direction) these questions (all referring to information from the atariwiki.org page):

 

1. What version should I use? I see there is the ZIP file containing the recently compiled 3.7 version with some fixes and versions for cartridge and disk. Is this the right one to start with, or should I stick with 3.6? Or it really doesn't matter

2. In case I want to create standalone programs, what runtime should I be using? My guess is for the "unprotected copy of the original disk from a good soul from AtariAge" but I'd like to confirm.

3. What would be a nice development setup (using the Atari or an Emulator, no cross-compiling for now) if using disks? First disk for the editor/compiler? Second disk as work disk? What about many other modules/libraries listed on the wiki?

4. I want to try some graphic programming, so Player/Missile is something that I would like to try, etc. I see there is a PM link (https://atariwiki.org/wiki/Wiki.jsp?page=Player Missile) but there is also a PM module inside one of the disks (I just can't recall which one right now)

 

I am also doing some research trying to answer the questions myself, but some input from here would be valuable.

 

 

Thanks in advance!

 

Edited January 30, 2021 by pedgarcia

[+hloberg]

check this out.

I did a multi-part on learning Action! and posted some useful utilities in the 2nd installment.

I will say though, in the end, I found Action! to be not much faster than compiled Turbo BASIC and a lot harder to program in. that's why I haven't posted any games in Action!

Edited December 7, 2019 by hloberg

[funkheld]

The Turbo Basic Compiler does not recognize the commands like "Save" and "Load". These commands are important for a programming language.

 

 

Greeting

 

 

[funkheld]

I play with 70 years (old man) too! action.
is a wonderful thing. I took the 3.7.

for an xex I take the sys.act

I only use the drive "d" with altirra
c"test.act" and  w"test.xex" in the !action.

greeting

this is the my sys.act for the compilat : https://atariwiki.org/wiki/Wiki.jsp?page=ACTION Runtime von Jeff Reister

 

BYTE RTS=[$60] 

INCLUDE "D:SYS.ACT"

PROC SQR(INT N)
  PRINTIE(N*N)
RETURN

PROC MAIN()
  INT N,M
  FOR N=1 TO 10
    DO
    PRINTF("%I SQUARED IS ",N LSH 1)
    SQR(N+N)
    OD 
  DO
  OD  
RETURN

Edited December 8, 2019 by funkheld

[pedgarcia]

On 12/7/2019 at 4:00 PM, hloberg said:

check this out.

I did a multi-part on learning Action! and posted some useful utilities in the 2nd installment.

I will say though, in the end, I found Action! to be not much faster than compiled Turbo BASIC and a lot harder to program in. that's why I haven't posted any games in Action!

This is pretty cool, my idea is to create a series of articles in the same line, but from the perspective of who is also learning. I am also open for collaboration if you are still interested in the language, since you mentioned the Turbo BASIC XL performance, etc

 

What I like about Action! it the fact that it was a language created and used only on the Atari (afaik). 

 

My objective at the end is to me, and anyone that follows the articles would be able to right something with Action! , preferable using graphics etc

 

 

Cheers

 

Paulo

 

[pedgarcia]

On 12/8/2019 at 11:07 AM, funkheld said:

I play with 70 years (old man) too! action.
is a wonderful thing. I took the 3.7.

for an xex I take the sys.act

I only use the drive "d" with altirra
c"test.act" and  w"test.xex" in the !action.

greeting

this is the my sys.act for the compilat : https://atariwiki.org/wiki/Wiki.jsp?page=ACTION Runtime von Jeff Reister

 

 

BYTE RTS=[$60] 

INCLUDE "D:SYS.ACT"

PROC SQR(INT N)
  PRINTIE(N*N)
RETURN

PROC MAIN()
  INT N,M
  FOR N=1 TO 10
    DO
    PRINTF("%I SQUARED IS ",N LSH 1)
    SQR(N+N)
    OD 
  DO
  OD  
RETURN

 

Hi, I am not sure if I completely followed what you've done. So you have only one disk image containing the SYS.ACT file only?

 

For your use, you don't need any other provided .ACT file?

 

Thanks

 

 

 

 

 

 

[+hloberg]

14 minutes ago, pedgarcia said:

This is pretty cool, my idea is to create a series of articles in the same line, but from the perspective of who is also learning. I am also open for collaboration if you are still interested in the language, since you mentioned the Turbo BASIC XL performance, etc

 

What I like about Action! it the fact that it was a language created and used only on the Atari (afaik). 

 

My objective at the end is to me, and anyone that follows the articles would be able to right something with Action! , preferable using graphics etc

 

 

Cheers

 

Paulo

 

at the moment I'm concentrating on my TI-99/4a but you can use anything you wish from my blog for your articles. It's not a hard language to learn if you know Pascal or 'C'. you might want to download my resources from part 2. there are several versions of the runtime floating around, the one I post, I believe, is the best one. good luck and I like your blog.

Edited December 16, 2019 by hloberg
added

[funkheld]

in !action can compile it with "C:test.act" and save it on the disc with "w:test.xex".

greeting

[pedgarcia]

25 minutes ago, hloberg said:

at the moment I'm concentrating on my TI-99/4a but you can use anything you wish from my blog for your articles. It's not a hard language to learn if you know Pascal or 'C'. you might want to download my resources from part 2. there are several versions of the runtime floating around, the one I post, I believe, is the best one. good luck and I like your blog.

Hi, thanks! I certainly will. 

 

You brought up an interesting point with the many runtimes. I read about them but didn't get to the point where I fully understand the differences. Good tip about the one in your article.

 

" I like your blog." - Thank you very much

 

Cheers

[pedgarcia]

19 minutes ago, funkheld said:

in !action can compile it with "C:test.act" and save it on the disc with "w:test.xex".

greeting

Gotcha. I will try something similar!

 

thanks

[Ray Gillman]

I noted what a lot of programs on the 8-bit started to do through the later years was to utilize disk space and stuff like page 6 memory to keep a transferable image of some "core variables" and then they would be better able to workaround the severe memory limit and variables limits by having these programs pass the baton to the next program.  So you'd have a set of variables be loaded or understood to be in certain PEEK locations and they could then have each program in the application collection of programs load the next module and it would fire up by grabbing some core variables and so on it would go.

This is reflected in many later programs as well such that the "World Builder" or "Character Editors" were always separate programs but dealt with the same core variables and data.  Many would often even have the Flashy music and graphics of the first start screen be in a temporary Startup program which would go away after the intro was done wowing the user with flashing colors and sounds

Edited December 17, 2019 by Ray Gillman

[+slx]

On 12/7/2019 at 10:00 PM, hloberg said:

I will say though, in the end, I found Action! to be not much faster than compiled Turbo BASIC and a lot harder to program in. that's why I haven't posted any games in Action!

I find it elegant that Action! allows to tie variables to hardware registers which saves a lot of PEEKs and POKEs. Strings are harder and less flexible than BASIC and the absence of bounds checking on indices and arrays means there's a much bigger chance of overwriting something important if you get an index wrong. 

 

Are you sure about the compiled Turbo BASIC speed comparison? Depending on the application library-less code should be much faster and you can even do VBlank interrupt routines in Action! 

[Gury]

I suppose he said that by not checking the facts first. Action! is closest to machine language of all Atari high languages.

 

[Alfred]

Action! can slow down if you use pointers, because every pointer reference becomes:

 

LDA myvar

STA $AE

LDA myvar+1

STA $AF

LDY #0

LDA ($AE),Y

actual code starts

 

so if you're using pointers or dereferenced pointers a lot, you will see significant overhead. Records I think are the worst because not only does it load the pointer there's the math to calculate the offset from the record base and add that to the pointer.

 

 

Edited January 10, 2020 by Alfred

[+Stephen]

Great tip.  It really does show on these older machines, the only way to get full use of them was via pure "to the metal" code.  It was certainly this way up through the Jaguar.  Only when the PlayStation came out in what - late 95, was there a decent C based SDK.  Even the Nuon required hand packed assembly to get anything decent from it (on a multi-element, parallel 128-bit VLIW CPU at that).  Ask Minter about coding and debugging T3K sometime.

[777ismyname]

On 1/9/2020 at 3:34 AM, Gury said:

I suppose he said that by not checking the facts first. Action! is closest to machine language of all Atari high languages.

 

I’ve seen people claim the same while using Action! with the inbuilt OS line drawing routines, which I’ve dealt with as well. Using an alternative library sped up the line drawing by 2x. Besides something like this, Action! is very, very fast. 

[pedgarcia]

On 1/9/2020 at 10:38 PM, Alfred said:

Action! can slow down if you use pointers, because every pointer reference becomes:

 

LDA myvar

STA $AE

LDA myvar+1

STA $AF

LDY #0

LDA ($AE),Y

actual code starts

 

so if you're using pointers or dereferenced pointers a lot, you will see significant overhead. Records I think are the worst because not only does it load the pointer there's the math to calculate the offset from the record base and add that to the pointer.

 

 

Wow, I would assume that the use of pointers would be actually good in terms of performance. So instead of pointers, what would be the best strategy without going down to inline assembly?

 

Thanks

 

 

[+slx]

On 1/20/2020 at 12:46 AM, pedgarcia said:

Wow, I would assume that the use of pointers would be actually good in terms of performance. So instead of pointers, what would be the best strategy without going down to inline assembly?

 

 

Probably arrays. There's a lot of Action! documentation at Atari Wiki.

[damosan]

11 hours ago, slx said:

Probably arrays. There's a lot of Action! documentation at Atari Wiki.

Arrays with certain content and under a certain size.  The problem is centered around grinding 16bit quantities (the addresses) on an 8bit computer.  I've recently started playing with assembly on the Atari, and as a long time C programmer, I wrote C style assembly code i.e. "take this 16bit pointer, increment by two, get the next word, ...repeat..." AAAAAAND my code was dog slow.

 

With the help of some folks here I changed that pattern to using the X or Y register as an index into a memory region of data I was interested in.  Well...things started speeding right up.  Then if you align your arrays to start on page boundaries life becomes a bit easier/faster.  Another key is to Lookup More and Calculate Less.

 

Programming these old machines is fun.

 

D.

[pedgarcia]

Hm ok, I think I understand now. It is probably too early for me to get to the point this would be a limitation, even considering the overhead. I currently wrote two introductory articles about the language, but I will only publish them when I know more, and also have more articles to post (my target is 10 at first).

 

I've been poking around the language and the Atari Wiki has indeed a lot of documentation as well as program examples, etc. I am digging deep there

 

I will post the links here as soon as possible to hopefully get feedback from you all.

 

 

 

[damosan]

On 1/29/2020 at 10:33 PM, pedgarcia said:

I currently wrote two introductory articles about the language, but I will only publish them when I know more, ...

I wouldn't worry about that too much - if the examples in the text work as advertised then post away.

[pedgarcia]

You are right, @damosan. I am finishing the 3rd article, so I have a buffer and will start posting them probably this weekend. 

 

[pedgarcia]

After a hiatus due to moving to a new house and all what is happening, I am back with this project. I am currently writing an article showing the graphic functions using GR7 and came up with a very simple program is BASIC and the equivalent in Action! This is the Action! one:

 

proc init()
  CARD I
  GRAPHICS(7+16)
  SETCOLOR(0,4,8)  ;REM USE COLOR 1 (PINK)
  SETCOLOR(1,7,4)  ;REM USE COLOR 2 (BLUE)
  SETCOLOR(2,0,14) ;REM USE COLOR 3 (WHITE)
  SETCOLOR(4,7,8)  ;REM BCKGROUND (LIGHT BLUE)
  COLOR=1
  PLOT(10,10)
  DRAWTO(149,10)
  COLOR=2
  DRAWTO(10,85)
  COLOR(3)
  DRAWTO(149,85)
  FOR I=1 TO 60000 
  DO
    ; nothing inside this loop!
  OD
  GRAPHICS(0)
RETURN

 

Comparing with BASIC, you almost don't see any difference in the graphics plotting speed, which I am assuming is because the standard Action functions are calling the same built-in routines BASIC calls. Is that correct?

 

Also, I see in the AtariWiki some fast graphics routine for GR8 and 15. Are you guys aware of something for GR7 ? 

 

THanks

 

 

[svhovater]

 

so, funkheld, I realize this is an old topic, but I'm learning action! too.

 

I note that somewhere I read that in order to produce a standalone binary, the statement

BYTE RTS=[$60]

 

had to be before I include the runtime.act.

My question is.. why?

 

thanks

Steve

 

[zbyti]

2 hours ago, svhovater said:

I note that somewhere I read that in order to produce a standalone binary, the statement

BYTE RTS=[$60]

 

had to be before I include the runtime.act.

My question is.. why?

include runtime.act should be the first line of your program (it's recommended for safety reason) if you want to make com/xex file. btw. what is the purpose of this RTS variable? to replace RETURN keyword? to use opcode? in that case I recommend define rts="[$60]" .

 

BYTE RTS=[$60] make some lda #$60 sta $xxxx for no reason. runtime.act don't use such variable then if your declaration will be before or after include runtime.act nothing changes.

Edited July 15, 2020 by zbyti
no reason