Blog about learning Action

[Savetz]

I've decided to spend 30 days teaching myself the Action! language, and I'm blogging my progress at http://atariaction.tumblr.com

 

I just posted Day 3, a failed attempt at string manipulation. (Riveting, I know!)

[+Stephen]

Good luck.

[hatchcliff]

Great Blog!

 

I liked Action! and used it a lot for about five years from 1984. I never did find out how to generate executable files that would run without the cartridge - so your day 2 contribution was particularly interesting to me.

 

The procedure you described works a treat on my simpler programs, like this one for calculating perfect numbers (which have the property that they are the sum of their own factors, e.g. 6 = 1 + 2 + 3):

 

PROC main()

 INCLUDE "D1:RUNTIME.ACT"

 CARD x,t,n

 Graphics(0)
 Setcolor(1,0,0)
 Setcolor(2,0,10)
 Setcolor(4,2,4)
 PrintE(" ")
 PrintE("Finding Perfect Numbers:")
 PrintE(" ")

 FOR x=3 TO $FFFE
 DO
   t=0
   FOR n= 1 TO x/2
   DO
  IF x MOD n = 0 THEN
    t=t+n
  FI
   OD
   IF t=x THEN
  PrintCE(x)
   FI
 OD
RETURN

 

I haven't managed to get it working on some of the more complex programs yet. Maybe I need to try the other runtime libraries, or perhaps I've used constructs that just aren't supported. I will see if I can pin down the problem.

 

P.S. I liked the labyrinth pattern too.

[+Gemintronic]

You mentioned running your programs stand alone strips many features away. Are you actively attempting to recreate the existing commands/library?

[JonnyBritish]

Making sure you know about the Action! content on this site - http://theultimatebenchmark.org/

[Savetz]

@cliff — yeah, there are a few other things that aren't supposed to work in runtime code, for instance multiplication and division and mod. I think instead of a = b * c you would have to do a = MultiplyBy(b,c) ... assuming your runtime library included a MultiplyBy function. But then again your sample code uses division — x/2 — and you say it works. So ... I don't know what that's about.

 

@theloon — no, I'm not attempting to recreate the existing commands in a runtime library. It seems like that's already been done and there's no reason I should reinvent the wheel.

 

@Jonny — thanks for the link. Wow, there's clearly a lot there.

 

I just posted Day 4. http://atariaction.tumblr.com

 

By the way, tumblr is awesome for a quick and dirty blog like this one. Really impressive.

[hatchcliff]

I obtained copies of the other runtime libraries from the link above (thanks Jonny). The original OSS library works best for me, and all the problems I encountered earlier have disappeared. There doesn't appear to be any problem with *, / or MOD operators.

 

I imagine the libraries all have their own strengths and bugs/omissions, and it's a matter of finding the best one for each application (and possibly for each cartridge version too - mine is 3.6).

 

Thanks for posting your Blog. It's great to have discovered how to make these executables after so many years. When Action! was released (well before the age of the Internet) it was easier to get stuck on technical details like this.

[Savetz]

Awesome to have all three runtime libraries.

 

Of course it was easier to get stuck on technical details — 30 years ago, we didn't have the entire corpus of Action source code and documentation ever published at our fingertips. On the other hand, 30 years ago Action was relevant.

[w1k]

added into bookmarks, thanks!

[a8isa1]

I obtained copies of the other runtime libraries from the link above (thanks Jonny). The original OSS library works best for me, and all the problems I encountered earlier have disappeared. There doesn't appear to be any problem with *, / or MOD operators.

 

I imagine the libraries all have their own strengths and bugs/omissions, and it's a matter of finding the best one for each application (and possibly for each cartridge version too - mine is 3.6).

 

Thanks for posting your Blog. It's great to have discovered how to make these executables after so many years. When Action! was released (well before the age of the Internet) it was easier to get stuck on technical details like this.

@cliffh

 

I believe the *, /, MOD issue applied to CARD variables only and the issue is a real PITA.

 

I think (sorry, my memory is sketchy) Jeff Reister's PD runtime had trouble with arrays at a fixed location, e.g. BYTE ARRAY Cartridge($4000)=$8000.

 

I don't recall if I tested this with Carsten Strotmann's (sp?) runtime library. Unfortunately, can't locate this library and Carsten's (aka CAS) wiki/xwiki seems to be gone.

 

@Savetz

 

 

I was just perusing your blog.

 

I've been tinkering with Action! from the very beginning. I was unaware negative step values in FOR loops didn't work.

 

I suggest Larry Serflaten's (sp?) Action! tutorials they were great. They are available on JoyfulCoder's website which I see you already discovered.

 

Analog Computing (originally, A.N.A.L.O.G.) also ran a good series of Action! articles. PDFs for all issues of this mag are available somewhere. (Sorry, I don't have a link ATM).

 

-SteveS

Edited December 11, 2012 by a8isa1

[+JAC!]

Make sure you bookmark this: http://wiki.strotmann.de/wiki/Wiki.jsp?page=ACTION

 

Carsten Strothmann (cas) is a big fan of (... <special adjective> ....) programming languages and he teaches us ACTION! at least once a years of the ABBUC annual meeting :-)

if you need support, he'll be help also for sure. And if your project grows so big that you run ouf of RAM, I can give some advice.

[Synthpopalooza]

Back on topic ...

 

I have also been looking into Action! myself, especially regarding things like VBI's and DLI's. I found this bit of info:

 

http://www.atarimaga...withaction.html

 

Might need to play with this some more ... The thing that is interesting is that DLI's and VBI's can be written at the Action! language level, without needing to know ML, with the exception of the code needed to save and restore the VBI temp registers.

Edited December 12, 2012 by Synthpopalooza

[Synthpopalooza]

Not to derail the topic too much ...

 

But I have been experimenting with Action!, trying to modify Bill Kendrick's Gem Drop game ... when I try to compile, it works, but then when I go to run the program, it drops to DOS and crashes. Any ideas what could cause this?

Edited December 14, 2012 by Synthpopalooza

[hatchcliff]

I believe the *, /, MOD issue applied to CARD variables only and the issue is a real PITA.

 

I used the following program to spot-check a few *, / and MOD operations on CARD variables, and I still can't see any problem:

INCLUDE "D1:RUNTIME.ACT"

PROC main()

 CARD x,y,z

 x=4573
 y=10

 z=x*y
 PrintCE(z)

 z=x/y
 PrintCE(z)

 z=x MOD y
 PrintCE(z)

 PrintE("Press any key to finish")
 InputB()

RETURN

 

I generated three executables (using the OSS, Jeff Reitser and Peter Finzel runtime libraries) and they all give the correct answers:

 

I wonder if the problem might relate to errors in early versions of Action! or the runtime library, which were subsequently fixed. Or could it just be misinterpretation of the known restrictions that Kevin referred to on day 2 (as listed on joyfulcoder, see tutorial 11, point 4)? I haven't tested this, but if I understand correctly, these restrictions only apply if you are generating executables without including a runtime library.

[a8isa1]

Interesting.

 

I can not cause an error to be generated.

 

The issue is printed in version 2 of the manual (with a correction in the version 2 errata of bugsheet #3).

 

The corrected paragraph should read,

 

"TECHNICAL NOTE: using the '*', '/', or "MOD" operands result in an INT

type, so multiplication of very large CARD values (>

32767) will not work correctly."

 

This corrected paragraph confused me when I first saw it but I notice now, looking at the errata for version 1 of the manual (I no longer own this version) the words, "result in an implied INT type", instead.

 

The latter example is a lot clearer.

 

As far as I know, Version 2 of the manual was still being supplied with the final version (3.6) of the Action! cartridge and therefore the issue would still exist.

 

I do not know whether or not the OSS runtime library addressed this issue but I do believe bugsheet #3 is the final set of corrections for the reference manuals.

 

I also do not know if the companies who later acquired the rights Action! ever published a fully corrected manual. I only ever possessed the two original OSS published manuals

 

Regarding the restrictions in Larry's Action! Tutorial, part 11, I believe most, if not all, of these tutorials were published before OSS announced the Runtime Library. Larry was demonstrating how one might go about producing standalone code without the benefit of such a library.

 

-SteveS

[a8isa1]

Interesting.

 

I can not cause an error to be generated.

 

The issue is printed in version 2 of the manual (with a correction in the version 2 errata of bugsheet #3).

 

The corrected paragraph should read,

 

"TECHNICAL NOTE: using the '*', '/', or "MOD" operands result in an INT

type, so multiplication of very large CARD values (>

32767) will not work correctly."

 

This corrected paragraph confused me when I first saw it but I notice now, looking at the errata for version 1 of the manual (I no longer own this version) the words, "result in an implied INT type", instead.

 

The latter example is a lot clearer.

 

As far as I know, Version 2 of the manual was still being supplied with the final version (3.6) of the Action! cartridge and therefore the issue would still exist.

 

I do not know whether or not the OSS runtime library addressed this issue but I do believe bugsheet #3 is the final set of corrections for the reference manuals.

 

I also do not know if the companies who later acquired the rights Action! ever published a fully corrected manual. I only ever possessed the two original OSS published manuals

 

Regarding the restrictions in Larry's Action! Tutorial, part 11, I believe most, if not all, of these tutorials were published before OSS announced the Runtime Library. Larry was demonstrating how one might go about producing standalone code without the benefit of such a library.

 

-SteveS

Correction:

 

I see Larry's Action! Tutorials were published in the mid '90s so I'm not sure why the need for part 11's list of restrictions. Clearly the runtime library would be preferable for making standalone executables.

Edited December 16, 2012 by a8isa1

[a8isa1]

I used the following program to spot-check a few *, / and MOD operations on CARD variables, and I still can't see any problem:

INCLUDE "D1:RUNTIME.ACT"

PROC main()

CARD x,y,z

x=4573
y=10

z=x*y
PrintCE(z)

z=x/y
PrintCE(z)

z=x MOD y
PrintCE(z)

PrintE("Press any key to finish")
InputB()

RETURN

 

I generated three executables (using the OSS, Jeff Reitser and Peter Finzel runtime libraries) and they all give the correct answers:

 

 

I wonder if the problem might relate to errors in early versions of Action! or the runtime library, which were subsequently fixed. Or could it just be misinterpretation of the known restrictions that Kevin referred to on day 2 (as listed on joyfulcoder, see tutorial 11, point 4)? I haven't tested this, but if I understand correctly, these restrictions only apply if you are generating executables without including a runtime library.

I tried once more.

 

In your example changing x=45730 and y=4573 I get the following results:

63450 for the multiplication. $F7DA in hexadecimal. Overflow but would be correct since the true product would be $C76F7DA

45730/4573=65532 for the division. Wrong.

45730 mod 4573=4. Also wrong.

 

Same results whether or not the OSS runtime library is used.

 

-SteveS

[hatchcliff]

I tried once more.

 

In your example changing x=45730 and y=4573 I get the following results:

63450 for the multiplication. $F7DA in hexadecimal. Overflow but would be correct since the true product would be $C76F7DA

45730/4573=65532 for the division. Wrong.

45730 mod 4573=4. Also wrong.

 

Same results whether or not the OSS runtime library is used.

 

-SteveS

 

That is a real surprise! The / and MOD operators work correctly with some cardinal numbers but not others.

 

I agree, the same result is produced with or without using the runtime library - so the problem isn't especially related to standalone code. I imagine the same implementation of these operators is embedded in both the cartridge and the library.

[kenjennings]

Savetz: Your day 13 problem is easy to solve:

 

...With one ship, I had been using Player 0 and Missile 1, so the changing color of the thrust fire didn’t affect the color of the ship. With two ships, I can use Players 0 and 1, and Missiles 2 and 3 — or just one of those, shared, if I don’t mind adding a little flicker. But with four ships, at least one of the ships ends up wildly changing color as Missile color changes....

 

http://en.wikipedia....R_.24D01B_Write

 

Just set bit 4 (value $10) in shadow reg GPRIOR $26F (CTIA/GTIA hardware reg PRIOR $D01D) to enable fifth player. When Fifth Player is enabled the missiles get their color from COLPF3 (hardware reg $D019/shadow COLOR3 $2C7) instead of the associated player color register. Then you can use Players 0 to 3 for ships, and Missiles 0 to 3 for flames.

[Savetz]

@Ken — thanks. I plan to get back to the project this week, and finish the 30 days by the end of January. Been busy playing Planetfall (so far: finished it but not the optimal ending) and scanning Creative Computing Magazines for archive.org.

[ascrnet]

Thanks for the blog is very interesting, but you can place the action! you use for your tests?

 

and I wrote the example of day 1, and does not work on the monitor by typing the letter R (buzzing sounds only and does nothing).

 

Altirra emulator I use is 2.10.

 

regards

[ascrnet]

and I wrote the example of day 1, and does not work on the monitor by typing the letter R (buzzing sounds only and does nothing).

 

already found the solution, I was missing a step:

 

C (compile first)

R (run finally)

 

in case anyone feels the same.

 

regards

[Synthpopalooza]

One thing I would like to know:

 

For example, in BASIC, if you wanted to use a machine language routine, a DLI routine, or VBI, you would normally put the code into DATA statements and then use a routine to POKE the values in memory. How would this be done in Action?

 

Also, is there a function in Action to read and access the address of a string, like ADR(S$) in BASIC?

 

And lastly, is there a way to do the equivalent of a USR call in Action?

[+JAC!]

In ACTION! either:

 

Define

PROC CIOV=$E456 (BYTE AREG,XREG)

for routines where you know the address and then simple write CIOV($03,$10)

 

or use code blocks "[ ... ]" for inserting short own routines. They are inserted directly during compilation.

 

 

[$40 $0D $51 $F0 $600]

BYTE b1,b2,b3

['A b1 342 b3 4+$A7]

DEFINE on=1

[54 on on+'t $FFF8]

 

I recommend having a look at the RUNTIME.ACT which mainly consists of code like that.

Edited January 14, 2013 by JAC!

[cas]

Making sure you know about the Action! content on this site - http://theultimatebenchmark.org/

 

Well, the better URL for the ACTION! stuff is http://atariwiki.org (if anyone cares, atariwiki.org is now DNSSEC secured! Jay! Hobby meets work)

 

The "theultimatebenchmark.org" is for the Forth Benchmarking project. Today both are hosted on the same wiki, but the Benchmarking project might get it's own system soon.

 

-- Carsten

Edited January 16, 2013 by cas