OSS ACTION! programming language

[a8isa1]

Definitely it is necessary to test and be aware all possible traps in making independent Action! executables. I tested it and for now with good success. If parameters were the issue, arrays passed to procedures are another solution to this as Larry suggests.

Sorry, I guess I wasn't clear, myself. Two bytes total. That's one CARD, or one INT, or two BYTE parameters. The issue has to do with where Action passes the parameters. If they were passed on the 6502 stack then all would be well but they are not. I've got to re-read the tutorial again and track down the other article that describes writing code that doesn't need a run-time library.

 

BTW, three pages earlier in the manual (page 63 in version 3.6) I found this, "TECHNICAL NOTE: the Action! Compiler does comparisons by subtracting the two values in question and comparing the difference to 0. This method works correctly with one exception -- if you are comparing a large positive INT value with a large negative INT value, the outcome could be wrong (since INTs use the highest bit as the sign bit)!!!!

 

- Steve Sheppard

[Gury]

No problem, it is clear now

 

 

More parameters, multiply/division and shift issues are fixed in alternate runtime libraries (Carsten's for example, which is very complete). I don't care if I depend on the runtime library, I will use and maintain the one which works, fix many problems and improve many functions from ordinary Action! library. The example is PrintF function, which you also confirmed it is better in this library.

[Gury]

Damn, my fingers were faster than me, I didn't finished the post yet

 

Anyway, thanks for visiting us on Atari chat yesterday, a8isa1. We will talk again about Action! and updates which can be done to the library. See you next time.

[Gury]

I am hooked! OSS ACTION! Toolkit is real blessing for developers. Floating point arithmetics, graphics, player missile graphics... Updated and feature rich functions like PrintF for formatting text, which works on any device now, not just text mode... The use of PMG is really very simple. The routines are useful enough, but you can improve them even further.

 

http://www.strotmann.de/twiki/bin/view/APG...ssActionToolkit

 

In addition to Carsten runtime library:

http://www.strotmann.de/twiki/bin/view/APG...onSysRuntimeAlt

 

It is time for new routines and a new game...

[cas]

Carsten, can you give me some short explanation? In SPACE newsletter ACTION! tutorial, http://space.atari.org/news9508.html, author explains what you must be aware of when making program without the

need of cartridge installed.

 

I am aware runtime library replaces cartridge library, but he indicates you MUST not use any multiplication or division. For this there are replacement routines in runtime library, but that means no use of *, /? The shift routines have similar issues, with no more than 4 shifts at a time. He also states that you can't use routines with more than 2 parameters, he advices using array where all necessary values can be retrieved by function.

 

I made some examples, using graphics routines of my own with more than 2 parameters (4, more exactly), and the program worked without any problems. It appears your alternate runtime fixes this problem? I also noticed the use of =*, which simply means ACTION! parameters are maintained directly from the Accumulator and X register. This is great feature.

 

Thanks for any reply,

Gury

 

Hi Gury,

 

I never had any Problems using multiplication and more that 2 Parameters when using stand-alone ACTION! Programs. So far my programs worked without cart after including either of the replacement libraries.

 

Carsten

Edited September 27, 2006 by cas

[Gury]

Hi Cas,

 

Thanks for confirmation. The mentioned tutorial made me thinking, but these worries are over, because it really just focus on building programs from scratch without any libraries (also a8isa1 agreed). Indeed, your library works perfectly, I made several tests with success. I plan some projects and ACTION! suits me perfectly as it is somehow similar to Pascal.

 

I also noticed that more frequently used routines have to be short because of cycle issues. I mean, it is no use in making special routine for checking keys as it can be done directly in main loop with declaring for example ch=764. I like the way ACTION! defines constants, which are also good for inline assembly if you don't like pure hex or decimal numbers in arrays, & % (AND OR) logical operators, type declarations... Really great language for the time!!!

[Gury]

I just need information about the following...

 

ACTION! can compile directly from disk, so there is no need to compile whole code from memory. What is the limit for produced executable code, how large programs can be, is memory limit 48K? Or there is a way to use more than this with, for example, Atari 130XE? In other case I will have to find other solutions, for example, program/data overloading and so on.

[cas]

I just need information about the following...

 

ACTION! can compile directly from disk, so there is no need to compile whole code from memory. What is the limit for produced executable code, how large programs can be, is memory limit 48K? Or there is a way to use more than this with, for example, Atari 130XE? In other case I will have to find other solutions, for example, program/data overloading and so on.

 

Not the full 48K. To be able to compile from Disk, you need as DOS (and if you don't have a DOS FMS in ROM like in the BiboMon or SDX, you have a disk based DOS that takes up $700-$2100 (apprx)). Then ACTION! needs space for lookup tables (variables, identifiers etc). And the ACTION! Cart itself takes 8K between $A000-$BFFF, and then there is the Screenbuffer for Graphics 0 and the Display List. So you might have space for some 30 K of binary code when compiling from disk. Appendix A of the ACTION! Handbool has a memory map of ACTION!

 

However you can compile from disk to disk with this Patch:

http://www.strotmann.de/twiki/bin/view/APG/ActCompileToDisk

 

I have never tried it, but it might be worth testing.

 

Of course you can write Overlays and load you programs in chunks. Here is how to load binary "com" files from ACTION!

http://www.strotmann.de/twiki/bin/view/APG/ActionBload

 

On an XL/XE machine, you can try to use the RAM under the OS ROM

http://www.strotmann.de/twiki/bin/view/APG/ActionRamXLXE

 

When compiling ACTION! code, you can change the offset with memory location $B5/B6

 ; change offset
	SET $B5 = $1000
  ; example: offset=4096

 

so ACTION! will compile the code to run at $1000, instead of the current free space above DOS.

 

Carsten

Edited November 8, 2006 by cas

[Gury]

This help is most appreciated, thanks.

 

I don't have the original ACTION! cartridge, of course, so I am emulating it as ATR image as D1: and project disk as D2: with DOS 2.5. I will check these utilities, I checked some of them before, but didn't know how useful they can be. I will test compilation from the memory location you suggested. Overlaying and loading extra binaries will come handy when the nature of larger project will need them.

 

I like the convenience of emulator as I can speed up compilation time by 700% - 1000% sometimes

 

In ACTION you are allowed to do something like this:

 

BYTE ARRAY PM_data(7)=[60 66 255 255 255 66 60]

 

but I found out I can do this without declaring dimension:

 

BYTE ARRAY PM_data=[60 66 255 255 255 66 60]

 

then using this array in a variable, directly assigned to particular memory location. So I guess this is ok because ACTION direct memory assigment allows things like that. I also like the freedom of its usage, in three different ways: with pointers, direct assignment of memory locations to variables or just using POKE command, which I don't use intentionaly.

Edited November 8, 2006 by Gury

[cas]

This help is most appreciated, thanks.

 

I don't have the original ACTION! cartridge, of course, so I am emulating it as ATR image as D1: and project disk as D2: with DOS 2.5. I will check these utilities, I checked some of them before, but didn't know how useful they can be. I will test compilation from the memory location you suggested. Overlaying and loading extra binaries will come handy when the nature of larger project will need them.

 

You shouldn't use the Disk-cracked Version of ACTION!. It is more a demo that cracking ACTION! was possible, but not of much use today, it's eating up too much Memory. Try to get a ACTION! ROM Image (ACTION.ROM) of the Cartridge and use that in an Emulator. You will run in all kinds of problems with the Disk version.

 

On an real Atari XL/XE, I recommend the Turbo Freezer 2005 Cartridge Emulation, which can "emulate" a real ACTION! Cart in Hardware (among other cards, and you can save and restore your machine, much like suspend to RAM or suspend to DISK on modern PC's)

 

Carsten

[cas]

 

 

In ACTION you are allowed to do something like this:

 

BYTE ARRAY PM_data(7)=[60 66 255 255 255 66 60]

 

but I found out I can do this without declaring dimension:

 

BYTE ARRAY PM_data=[60 66 255 255 255 66 60]

 

then using this array in a variable, directly assigned to particular memory location. So I guess this is ok because ACTION direct memory assigment allows things like that. I also like the freedom of its usage, in three different ways: with pointers, direct assignment of memory locations to variables or just using POKE command, which I don't use intentionaly.

 

Yes, because ACTION! knows the size by the initialization data specified.

 

POKE is inefficient in ACTION! (compared to direct access), because it's a library routine. It's more for the people coming from BASIC.

 

Carsten

[cas]

Hi Gury, don't use the above $1000 Memory location example for testing, as it would normally collide with DOS. Use some address in high memory, like $8000.

 

Carsten

Edited November 8, 2006 by cas

[Gury]

You shouldn't use the Disk-cracked Version of ACTION!. It is more a demo that cracking ACTION! was possible, but not of much use today, it's eating up too much Memory. Try to get a ACTION! ROM Image (ACTION.ROM) of the Cartridge and use that in an Emulator. You will run in all kinds of problems with the Disk version.

 

On an real Atari XL/XE, I recommend the Turbo Freezer 2005 Cartridge Emulation, which can "emulate" a real ACTION! Cart in Hardware (among other cards, and you can save and restore your machine, much like suspend to RAM or suspend to DISK on modern PC's)

 

Carsten

Ok, I found the ACTION! ROM image on http://www.magelair.com/atari_8bit_stuff.html. I tested it and it works perfectly. I guess the author of the patch took special care, editing the code and compiling is faster. No special speed ups needed.

 

Sure, no POKEs, just pure direct memory accesses and pointers where needed.

 

Here is another updated site for ACTION!, besides your great site Carsten, on http://joyfulcoder.net/atari/action/

[a8isa1]

Hey Gury,

 

Here's a new trick to gain you extra memory.

 

Since you are already using an emulator (I'm assuming Atari800Win Plus) you can use the H: drives as tools to produce code that runs lower in memory. The advantage of using the H: drives is that you do not need to load DOS. You get a much lower MEMLO ($700). Most of the extra memory is available for your own program.

 

Programs seem to compile to $E08 using this technique.

 

I've tried to create executables having a lower load address (than $E08) using Action offsets but have had no luck producing working code.

 

- Steve Sheppard

Edited November 8, 2006 by a8isa1

[Gury]

Hi all,

 

I have a question for any Action! maestro... Finally my bigger project realized, but when I included runtime library, severe problems arised. I have never had any problems with smaller programs, but now, with a serious, bigger program, I often get Action! error number 61: Out of symbol table space. I am aware that this means I am out of stack memory resources for PROCS and variables, but what's next, what's the solution to this? A8isA1, can you please tell me again which library can be used to fix that? We talked about that, but I forgot the name of the library.

 

If those problems continue, I will maybe switch to Quick or maybe assembler. But, I like Action!, it's great.

[cas]

Hi all,

 

I have a question for any Action! maestro... Finally my bigger project realized, but when I included runtime library, severe problems arised. I have never had any problems with smaller programs, but now, with a serious, bigger program, I often get Action! error number 61: Out of symbol table space. I am aware that this means I am out of stack memory resources for PROCS and variables, but what's next, what's the solution to this? A8isA1, can you please tell me again which library can be used to fix that? We talked about that, but I forgot the name of the library.

 

If those problems continue, I will maybe switch to Quick or maybe assembler. But, I like Action!, it's great.

 

Hi Gury,

 

I have several Ideas:

 

in all cases: remove unnecessary routines from the runtime. For example if you don't use sound in your program, remove all sound commands.

 

a) create a bigger Symbol Table, see http://www.strotmann.de/twiki/bin/view/APG...nBigSymbolTable

 

b) split you program in smaller, logical pieces (for example intro, initialization, menu, part1, part2, finish). Compile them to different memory locations as described in the ACTION! Manual and link them together with an external linker. Import the procedures that needs to be called from other parts in all source-codes. You can find the routine locations from a symbol listing. Or with the "?" command in the Monitor. I remember that I had a Symbol Lister somewhere. I'll look for it and upload it to the Wiki.

 

c) reuse variables, use more local variables and less global variables. Refactor your code.

 

I had never that problem, I only run out of memory some times.

 

Carsten

Edited January 6, 2007 by cas

[Gury]

Your help is always appreciated Cas, thank you. I will buy you a beer if I go to next ABBUC party and meet you there

 

Of course, I do make my program code modular whereever possible. I will use the routine you described and I will see the new results. But please tell me, does this routine have to be run before my program, or my program calls the BigSymbolTable()?

 

I have already cut down unnecessary routines from runtime library, I use memory addresses directly wherever possible (stick, trigger, sound...). I will think about global variables, because I use many of them for which I think could be localized. Compiling smaller pieces to different memory locations will also be considered. Is the manual on your site the one you suggest to look at?

[cas]

Hi Gury,

 

I found the ACTION! Symbol Table lister and put it in the Wiki with some Instructions at

http://www.strotmann.de/twiki/bin/view/APG...mbolTableLister

 

I used it to create a Symbol Table for the standard ACTION! Runtime Library. First I developed my programs with the normal cart. Once the program was finished and debugged, I included the Symbol Table Import File (example at the end of the page referenced above) to my source, compiled my source and wrote the binary to disk. Then I started a Linker/Packer (I used Thorsten Karwoths PowerPacker from the MacroAssembler130XE Package) and lined a precompiled Runtime Library and the program binary. That saved some development time.

 

Carsten

[cas]

Your help is always appreciated Cas, thank you. I will buy you a beer if I go to next ABBUC party and meet you there

 

Of course, I do make my program code modular whereever possible. I will use the routine you described and I will see the new results. But please tell me, does this routine have to be run before my program, or my program calls the BigSymbolTable()?

 

I have already cut down unnecessary routines from runtime library, I use memory addresses directly wherever possible (stick, trigger, sound...). I will think about global variables, because I use many of them for which I think could be localized. Compiling smaller pieces to different memory locations will also be considered. Is the manual on your site the one you suggest to look at?

 

I never used the Big Symbol Table patch. From the code I guess you load the Big Symbol Table Patch just after booting the A8 with the ACTION! Cart. The Patch will compile and when run it will adjust the Symbol Table and restart the ACTION! Cart. You can then compile your Program. Of course you will now have 255 Byte less of program memory that is now used by the Symbol Table, however that will be a good tradeof.

 

Reducing the global variables should help alot, as I think only global variables (incl. Proc and Func) will go into the symbol table, local variables will be managed on a stack.

 

Carsten

[Gury]

Thanks for the advice Cas. Most of the troubles were global variables. I also tested the BigSymbolTable() procedure and it worked well.

 

Live long, Action!

[Gury]

deleted

Edited January 7, 2007 by Gury

[Gury]

Cas, your runtime library is great, but there is one thing which could be fixed. SCopy routine has a very small bug (or maybe this is not the case and I am wrong). The statement dest(u+1)=source(u) should be amended to dest(u+1)=source(u+1), because dest variable gets as the next element the length of the source variable. It should be better go directly to the first element of the source string variable. But anyway, I use the original procedure from OSS now, which works perfectly:

 

PROC SCopy=*(BYTE ARRAY d,s)

[$A085$A186$A284$A0$0$A2B1$A091$8F0$A8$A2B1$A091$88$F9D0$60]

Edited January 7, 2007 by Gury

[Gury]

I must say I am really satisfied with the performance of the Action! language. After making clear how to handle global variables as Carsten suggested, I have no problems at all any more. Just make sure you have more local variables than global ones. That way you can have freedom for more PROCs and FUNCs. And use command line to compile larger files directly from disk without first reading them.

 

Action! is amazing... fast, structured, very flexible and powerful as you want it to be. The next step will be maybe volksForth, but for now, Action! is my winner. With it anything is possible, the only limit is your imagination and creativity.

Edited January 12, 2007 by Gury

[cas]

.... Action! is my winner. With it anything is possible, the only limit is your imagination and creativity.

 

Then there would be no reason for Forth. What you cannot do in ACTION!, is to change the compiler from the language itself. That is, you cannot change ACTION! into an Object Oriented ACTION!, or you cannot make it support functional programming. It is and will ever will be an PASCAL/C like compiler language.

 

Changing the compiler from the language is one of the bit more freedom you have in Forth, but at the cost of re-learning programming

 

Carsten

[Gury]

 

Changing the compiler from the language is one of the bit more freedom you have in Forth, but at the cost of re-learning programming

 

Carsten

Yeah, I know, in Forth you can make new programming structures (like WHILE, REPEAT clauses, TYPEs and ARRAYs) and new languages. Forth was mentioned many times in ANALOG and ANTIC magazines as very powerful language but unfortunatelly user base was too small for this language to have better impact.