Jump to content
Sign in to follow this  

Question about Action array size

Recommended Posts

Hi, I recently started using OSS's Action, but I've run into some problems. In short, is there a limit on the size of arrays? I find that when I try to create a BYTE ARRAY of >256 elements, the compiler starts each array only a few bytes apart (as if it is ignoring the MSB of the size.)

To expand a bit... I was trying to do a Life simulation and wanted to create several linked lists. I've since concluded that can't be done since the language doesn't seem to be able to dynamically allocate memory. So I decided to do a sort of pseudo-linked-list, creating a record with CARDs for capacity and current size and a BYTE for the start of a virtual x,y coordinate array. Then I created a BYTE ARRAY to hold the record with the virtual array and declared the record and assigned it the address of the BYTE ARRAY. When I tried to Zero() the arrays, I ran into trouble, and when I investigated further I found the problem mentioned above. (I've appended the code below to clarify.)

When I run this with a BYTE ARRAY size of 256, it creates three arrays and prints out the starting addresses:

which is as expected.
But if i increase the BYTE ARRAY size to 257, it prints:
with the arrays overlapping...

I didn't see any mention of an array size limit in the manual (and they even show a 1000 byte array in the advanced record example.)


I'm running this on the Atari800 emulator (3.1.0) in 800XL mode with the Action 3.5 cart on a Linux Mint 18.1 laptop.


Thanks for any help you can offer.


-- Jeff



; pseudo-linked-list



LIST live=_ba1
LIST newLive=_ba2
LIST adjacent=_ba3

PROC initLists()

[email protected](live.xy)
PrintF("%H%E", ptr)
; Zero(ptr,ARRAY_SIZE-4)

[email protected](newLive.xy)
PrintF("%H%E", ptr)
; Zero(ptr,ARRAY_SIZE-4)

[email protected](adjacent.xy)
PrintF("%H%E", ptr)
; Zero(ptr,ARRAY_SIZE-4)

PROC main()

Share this post

Link to post
Share on other sites
start $3000 :


SET $E =$3000

SET $491=$3000


from $2000 to $3000 = $1000 free

or ramtop down.

and you have memory that does not bother anyone


Edited by funkheld

Share this post

Link to post
Share on other sites

BYTE arrays (and alias CHAR arrays) are Action!'s means of doing strings. The 0th element contains the string length, 0 to 255.


That said, there's not really any bounds checking in Action!. I would think it would allocate whatever amount of space you specified. Odd that it doesn't seem to do so in your case.

Share this post

Link to post
Share on other sites

What you're seeing is one of the optimizations that Action! does. For a byte array 256 elements or less, Action! knows it can use LDA $addr,X addressing, so the array is allocated in place. If it's more than 256 bytes, then it has to be handled via zero page the same way Pointer types are handled. So in the case where you allocate more than 256 elements, Action! stores the size of the array in a linked list during compilation, plus two bytes for the pointer. That's why you see the array's four bytes apart. The actual data of the array is at a different address. Action! chains all large arrays together during compile because it doesn't know where they can go until it finishes codegen. Once the last RTS is inserted, it runs the chain of arrays and allocates them, if they had a size specified.


So for a byte array of 256 or less, you get codegen like:

LDY index

LDA array,y


but for a larger array you end up with



lda array

adc index

sta temp1

lda array+1

adc index+1

sta temp1+1

ldy #0

lda (temp1),y

  • Like 4

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.

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.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...