action! Going into Action! - A noob perspective

[zbyti]

24 minutes ago, rsh said:

Thank you I will play around with it,  Your method seems way more elegant than the wiki.  Looks like with your version you don't need to swap PORTB OS bits.. cause your just there in main memory all the time..  Very cool!!  I am trying to free memory up and this looks like a real solution.  

 

I was trying to figure out how to compile into 130XE extended ram bank(s) and run code from there lol, but that seems like a real pain in axx..   Have you ever tried to do that, curious? 

and you can use memory on ZP $0-$7F then you turn off the SYSTEM

 

I remember (but not much, I stooped using Action! while ago) it was hard to use banked memory because Acion! uses this RAM window, but if you try hard you can set directive and compile Action! code to this area but in my opinion its not worthy your work.

Edited November 3, 2022 by zbyti

[Jeff Reister]

On 7/20/2020 at 1:21 AM, zbyti said:

For 3 reasons:

 

1. to save memory by picking exactly what I need from runtime

2. to make binary (xex file) working without cartridge

3. speed

 

I use one of those runtimes (I belie von Jeff Reister was the one) but noticed what SETBLOCK procedure is 3x slower then PROC on Action! cartridge, I'll fix this later.

I don't suppose anybody is using my public domain ACTION! runtime package anymore since the official runtime package from OSS is freely available.  I wrote it back in the late 80's and haven't thought about it since then.  However when I saw your post about SETBLOCK being so slow, I wanted see for myself.  You are right.  It is 3x slower than the cartridge.  MOVEBLOCK is also slow, but only about 2x slower than the cartridge.

I suppose it shouldn't bother me that something I wrote 36 years ago was less than optimal, but it does.  I guess I wasn't that concerned about execution speed at the time.

 

Anyway, I was bothered enough by the slowness that I wanted to fix it.   Fortunately I was able to find the source code (which I lost decades ago), the required tools and the Altirra emulator.  It was kind of fun to revisit Atari 8 bit programming for a weekend.

I've attached an updated runtime source file with much faster versions of SETBLOCK and MOVEBLOCK.  I didn't make any other changes.  I'm calling it revision B, hence the lower case b in the file name. 

 

RUNTIMEb.ACT

[rsh]

On 7/26/2023 at 7:54 PM, Jeff Reister said:

I've attached an updated runtime source file with much faster versions of SETBLOCK and MOVEBLOCK.  I didn't make any other changes.  I'm calling it revision B, hence the lower case b in the file name

Sweet thank you.  I will definitely use it.   I working on game now and using runtime lib seems to eat the local symbol space up during compile.  I don't understand this cause all the procedures are assembly with =* in them.  Once local filled your hosed.  Global you can adjust but not local.   Any insight on what Action it's doing?

[Jeff Reister]

On 8/25/2023 at 12:33 PM, rsh said:

Sweet thank you.  I will definitely use it.   I working on game now and using runtime lib seems to eat the local symbol space up during compile.  I don't understand this cause all the procedures are assembly with =* in them.  Once local filled your hosed.  Global you can adjust but not local.   Any insight on what Action it's doing?

Sorry for the late response.

I assume the compiler is giving you an Error 4 "Local variable symbol table full"?  I hope you have figured out what's going on because I don't think I'll be much help.  If you did I'm curious what the problem was.

I could be wrong, but I don't think including RUNTIMEb.ACT in your program should use up any local symbol table space.

Is it possible your compiled code is so big that it is overwriting the symbol table?  I think this can happen if you compile while you have a fairly large amount of source code in the editor (see section 4.4 "Available Space" in the ACTION! manual).  So one thing to try is save your source code to disk, reboot, then compile your source code from disk (e.g. C "MYGAME.ACT").

[rsh]

On 9/10/2023 at 1:43 PM, Jeff Reister said:

Is it possible your compiled code is so big that it is overwriting the symbol table?  I think this can happen if you compile while you have a fairly large amount of source code in the editor (see section 4.4 "Available Space" in the ACTION! manual).  So one thing to try is save your source code to disk, reboot, then compile your source code from disk (e.g. C "MYGAME.ACT").

Thanks for response....It's not that, this program has long been too big for the editor.  Can only be compiled from disk.  Reboot seems to be a common requirement as sometimes it will compile and run other times it compiles and crashes on run.   I haven't figured it all out yet why it's happening with local... It appears the compiled code with cartridge routines vs runtime routines do things

differently.  I'm stuck with doing things like shrinking the runtime and variable crunching to get around it.  

[jhusak]

If you're doing 6502 assembly snippets in Action!, you don't have to struggle anymore. Just use this simple assembler and copy-paste the result 

 

https://github.com/jhusak/sasm6502

 

Needed it, whipped it up last night, added labels today. Enjoy, Action! folks!

Edited January 24 by jhusak

[TGB1718]

I had troubles compiling this on Ubuntu:-

 

gcc -Wall sasm6502.c util.c -o sasm6502
/usr/bin/ld: /tmp/ccBpm0es.o: in function `Util_round':
util.c:(.text+0x892): undefined reference to `floor'
collect2: error: ld returned 1 exit status
make: *** [Makefile:2: all] Error 1

 

I had to add -lm to the Makefile to link in the math library

 

all:
        gcc -Wall sasm6502.c util.c -lm -o sasm6502

 

It seems to compile code correctly, will try it with Action tomorrow.

[jhusak]

21 hours ago, TGB1718 said:

I had troubles compiling this on Ubuntu:-

 

gcc -Wall sasm6502.c util.c -o sasm6502
/usr/bin/ld: /tmp/ccBpm0es.o: in function `Util_round':
util.c:(.text+0x892): undefined reference to `floor'
collect2: error: ld returned 1 exit status
make: *** [Makefile:2: all] Error 1

 

I had to add -lm to the Makefile to link in the math library

 

all:
        gcc -Wall sasm6502.c util.c -lm -o sasm6502

 

It seems to compile code correctly, will try it with Action tomorrow.

Ok, thank you. I have added this to Makefile. I prepared this on MacosX so I missed it.

 

I have used sasm6502 several times already, during optimizing one of my games

Edited January 25 by jhusak