This page (revision-5) was last changed on 03-Feb-2023 15:21 by Gromit 

This page was created on 18-Dec-2010 10:38 by Carsten Strotmann

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
5 03-Feb-2023 15:21 9 KB Gromit to previous
4 01-Feb-2011 14:59 8 KB Gromit to previous | to last
3 01-Feb-2011 14:53 4 KB Gromit to previous | to last
2 18-Dec-2010 10:40 146 bytes Carsten Strotmann to previous | to last
1 18-Dec-2010 10:38 108 bytes Carsten Strotmann to last

Page References

Incoming links Outgoing links
Stars in 3D
Stars in 3D

Version management

Difference between version and

At line 1 changed one line
!!! Stars in 3D
!General Information
Author: Donald E. Glover\\
Language: ACTION! \\
Compiler/Interpreter: ACTION \\
Published: ANALOG Computing #20\\
----
I was looking for something to do with my shiny new Action! cartridge when I ran across the article __Stars 3-D__ by Craig Patchett in __ANALOG__ No. 16. To become familiar with the new language, I decided to translate this demonstration program into Action!, a job I thought would take one or two hours. The task eventually took much longer, due to a number of strange quirks associated with the Action! language. I hope this discussion of my problems will save other Action! programmers some hair pulling and nail chewing.
At line 3 changed one line
by Donald E. Glover
My first task was to find a place for the display list (DLIST) and screen memory (STRLIN). I wanted to put them in a safe location, while allowing easy access from Action!-generated code and in-line machine code. I finally decided to put them in Action! arrays whose starting addresses were defined such that the display list and screen memory started on 1K boundaries in high memory. (The Atari cannot easily deal with a display list which crosses a 1K boundary or screen memory which crosses a 4K boundary.)
At line 5 changed one line
Analog Issue 20
Calculations to generate the display list required that the address of screen memory be divided by 256 to obtain the high byte of the address. Performing this division on addresses greater than 32767, unfortunately, gives the wrong answer, since Action! multiplications and divisions always assume they are acting on signed numbers. Try typing:
{{{X PRINTCE(32768/256)}}}
in the Action! monitor and see what you get. After figuring out the problem, I replaced the division by 256 with "RSH 8" (shift cardinal number right 8 bits). The use of this technique can be seen by examining the procedures STRINI() and DLSINI().
At line 7 changed one line
[{Image src='stars3dinaction.gif'}]
The next problem was to insert the addresses of the arrays STRTPH, STRTPL, and STRPOS into the machine language procedure SCROLL(). My initial attempt to do this involved inserting the address during the compilation phase. Using this method, the first instruction in the procedure SCROLL() would be:
{{{$B0 STRTPL; LDA STRTPL,X}}}
To my horror, the addresses of arrays compiled into the code by this technique frequently (but not always) differed from those observed after compilation. Apparently, the addresses of arrays change during the compile phase, and the compiler cannot modify addresses inserted into machine code. The solution was to "POKEC" the addresses into the machine language routines during run time [[see the procedure MAIN90].
At line 19 added one line
I believe everything else in the listing is understandable, because I kept the names of all routines and most of the comments the same as those in the original assembly language listing. A word of warning: this program is designed to work with a machine having 48K of memory. If your machine has less memory, you will have to change the starting address of the arrays DLIST and STRLIN. The place to do this is clearly marked in the listing.
At line 21 added 12 lines
Before finishing, I should mention another couple of Action! peculiarities.
# Negative FOR loops do not work. Try:
{{{FOR COUNTER=5 TO 0 STEP -1}}}in a sample test procedure. It won't work.
# You cannot initialize a variable to a negative number.
{{{TEMP1=[-1]}}}will not work. However
{{{temp1=[[65535]}}}will accomplish the same thing.
# The example on page 123 of the manual doesn't work (at least with Version 3.5 of Action!). PRINTCE(rec. idnum) prints the wrong answer. For some reason, PRINTCE(rec. idnum*1) gives the right answer.
I suspect Action! will never be used to write commercial arcade-style games, because it is just not as efficient at "bit-twiddling" as machine code (try writing the procedure scroll() in Action!). It also does not produce code as compact as that produced by a good assembly language hacker, a definite consideration when trying to stuff a game in an 8K or 16K ROM cartridge. Nevertheless, I feel that the language (perhaps with the help of a few machine language routines) can be used to write games similar in quality to the machine language games found in __ANALOG__ in a much shorter time than usually required. Games written in Action! would also be easier for novices to analyze and understand.
----
This page (revision-5) was last changed on 03-Feb-2023 15:21 by Gromit  Top