Effectus - New Atari cross-compiler (Alpha stage)

[Gury]

 

Pointers just seem so cool. I've seen some suggestions not to use them due to instability of the original implementation, but I see many potential use cases for them .

Another thing I noticed: in the Action reference manual the specification of an array is:

 

<ident> {(size)} {=<addr> | [ <values> ] | <str const>]

 

thus I can write:

byte array a=$A000 (this seems unsupported in effectus yet) and then assign values:

a(1) = 1

a(2) = 2

[and so on]

 

That's a good thing when you need to fill some data dynamically, but I was always also dreaming about something like:

 

byte array a = $A000 [1 2 3 ... ]

 

No copying of data necessary, just static table defined at compilation time, eg for DL or something. But it's an extension of the original specs

Hello greblus,

 

try new version, which includes support for such arrays (declared and pointed to some memory address, for example byte array a=$A000). Examples are put in Examples page under Arrays, sets, types, pointers. The files are arrmem.eff and arrmemc.eff.

 

Also included is very basic support for SCompare function for comparing two strings and functions InputB, InputC and InputI for inputing numbers. The notes about new version are here. There you will find what restrictions still remain for this functions.

 

I used UPX utility to shrink Effectus executable approximatelly 3x the size of original binary.

 

Other request about arrays will be implemented in some other version as extended feature of Effectus.

 

Greetings

[greblus]

Hello greblus,

 

try new version, which includes support for such arrays (declared and pointed to some memory address, for example byte array a=$A000). Examples are put in Examples page under Arrays, sets, types, pointers. The files are arrmem.eff and arrmemc.eff.

Attached here is a special release for Linux (compiled under the open sky). More tests when I'll be a bit more sober

 

Thank you!

effectus-0.1.7.tar.gz

Edited July 27, 2014 by greblus

[Gury]

Hehe, greblus! Party, special occasion?

 

Anyway, your package version is uploaded to Download repository. It's good you are sober enough for posting and visiting here

[greblus]

Gury, it's one week off for a substitute (cause it's way too short) of summer holidays with wife and kids

 

And BTW, arrays with direct address declaration seem to work fine.

Edited July 28, 2014 by greblus

[greblus]

And here is my last VBXE example with direct array addressing.

 

Cheers,

W.

vbxe2.eff.zip

vbxe2.atr

[Gury]

Waw, you actually put it in use in the example code. But can you please direct me what I am doing wrong to run your ATR image? I'm using Altirra with VBXE set, but when disk image runs, it only shows Error: No DOS. Is it empty?

[greblus]

Gury, it's not an auto-boot disk. Best would be to use SDX. I've made an archive once in a past, it's here:

 

http://hostuje.net/file.php?id=34a8399e8ed6f5f103ab1be9986d4fb0

 

(click on "pobierz plik". It contains Altirra with Side SDX flashed in it.

 

Hope this helps, if not, when I'm back home I'll make a zip with all what's needed.

 

Cheers,

W.

[greblus]

Hi again.

 

Here is an Altirra in portable configuration with this example already on D1:

 

Simply unzip it and run Altirra. It's updated to Altirra 2.5.

 

Cheers,

W.

Altirra.zip

[Gury]

Hej greblus,

 

thank you for the image. Unfortunatelly, when I run your Altirra setup and run VBXE2.XEX, blank screen appears. I also tried to attach disk image you posted previously. With no success

[flashjazzcat]

Try using the "X" command at the SDX prompt: "X VBXE2.XEX". Works well here. The program loads data under the cart area ($A000-$BFFF), hence "X" is required.

Edited July 29, 2014 by flashjazzcat

[Gury]

Waw, it works now!!! Amazing, great to see VBXE working example coded in Effectus.

 

Thank you both!

 

And apologies for my unknowledge, because I never used SDX OS before, but read about it in magazine (old SpartaDOS).

[greblus]

Would this achieve the same results?

PROC data1536=1536()
  [ 1 2 3 ... ]
RETURN

PROC main()
  byte array a = 1536
  ; use a
RETURN

 

Joyfulcoder: I'm sorry, I didn't check your suggestion carefully before, but better late then never (It won't work with Effectus yet). It's really interesting approach and I'm able to compile it and run it, but accessing such array elements is always returning zeroes so I'm wondering what am I doing wrong

 

And when experimenting with some other code I noticed one limitation of arrays: they can be indexed from 0-255 only (unless I'm wrong), so a good implementation of pointers would really help a lot

Edited August 2, 2014 by greblus

[greblus]

Here is an Altirra in portable configuration with this example already on D1:

And for the sake of correctness I noticed two typos in my example, one in xdl the other one in blitlist, they're noticable on the real hardware only as the memory is not cleared by the blitter and there is some garbage before and after picture. Altirra seems to clear VBXE's memory so it's not visible.

vbxee1.zip

Edited August 2, 2014 by greblus

[joyfulcoder]

Joyfulcoder: I'm sorry, I didn't check your suggestion carefully before, but better late then never (It won't work with Effectus yet). It's really interesting approach and I'm able to compile it and run it, but accessing such array elements is always returning zeroes so I'm wondering what am I doing wrong

 

And when experimenting with some other code I noticed one limitation of arrays: they can be indexed from 0-255 only (unless I'm wrong), so a good implementation of pointers would really help a lot

 

Sorry, I did not test the code snippet I posted. I only went by what I remembered reading in the Action! manual. The address portion of a PROC or FUNC declaration will let you specify the address of where the PROC or FUNC resides in memory but apparently such a declaration does not let you then define a body and have the body put at that location upon loading. Instead the body is still stored where the compiler is currently storing code/data. That is why it compiles and runs but you only get zeroes.

 

Example:

PROC data=1536()

PROC main()
  Poke(1536,96)
  Print("Hello")
  data()
RETURN

If the Poke is removed then the call to data will cause problems. Perhaps Effectus could expand on this syntax and let the body, if any, that follows be put at the specified address.

[ricortes]

Pretty rusty but I thought the hard data locations could be done with using the program location feature IIF you use the compile to disk option/hack. There's still a bit of waste in that Action always supplies an INIT vector and a RTS at the end so a few adjustments have to be made.

 

*BUT* it isn't a huge problem because of the way Atari/DOS works. A binary save followed by COPY /A to append the files would work just fine.

 

Action was modified under FTE to change the way it worked a bit. Originally it only used the DOS INIT locations which really made it versatile. For example, you could have a program that would load page six with data then terminate and another separate program that would use the data like you call for in your example. Using the DOS append function, you could make one big file. They could both use the same load address since the first one to execute was no longer needed after it did its business. There was an incompatibility problem with SDX IIRC, something like the program would run twice, so the init was changed to run.

 

There's a couple of ways of doing this. If you want an example for the original version of Action or the modified, let me know.

[greblus]

Yes, In fact I was experimenting a bit in a past with Symbol Table Lister and using cat/type to join binary files, there is also a binary file loader for Action! which I modified slightly to load up to specified initad (type or cat will join complete files):

 

http://blog.greblus.net/2013/06/19/loader-do-linkowanych-binarek-action/

(unfortunately in polish).

 

So as you said: it can be done in many ways. Such binary blob with data in known locations can be attached and used easily.

[Gury]

Ok, the example like this, which I tested, returns zeroes in Action!...

PROC DATA1536=1536()
[ 1 2 3 ]
RETURN

PROC MAIN()

BYTE ARRAY A=1536

PRINTBE(A(0))
PRINTBE(A(1))
PRINTBE(A(2))

RETURN

Effectus currently does not support nor compile such code. When it does, another question arises. Should such code simulate zeroes to equal Action! result and the correct values as an extension?

 

Greblus, do you think it should create the code like this, as you proposed?

org $600
.array a .byte 
 1,2,3
.enda

And I also tested Action! code as you mentioned some posts above:

 

byte array a = $A000 [1 2 3 ... ]

 

Action! compiles such code and actually shows close to expected results, but I had to change the address to work with my Altirra default setup.

 

We have to brainstorm which way to go...

Edited August 2, 2014 by Gury

[greblus]

Gury.

 

So now, this code works fine:

 

proc main()

byte array ia = $A000 

 int a=$A000 
 int b=$A001
 int c=$A002

 ia(0) = 1
 ia(1) = 2 
 ia(2) = 3

 printbe(a)
 printbe(b)
 printbe(c)

return

but this:

 

proc main()
byte array ia = $A000 [1 2 3]

 int a=$A000 
 int b=$A001
 int c=$A002

 printbe(a)
 printbe(b)
 printbe(c)

return

generates asm code like this:

 

 .array ia_eff_ .byte = $ff
 1, 2, 3
 .end

so we end up with zeroes as the array is not under specified address.

 

This could be a nice extension to allow for byte array ia = $A000 [1 2 3]

and data to be placed under specified address.

 

Another question is: whether it's possible to extend indexing of arrays. Currently in effectus the index can be from 0-254.

 

If it's about:

 

proc data = $A000()
 [1 2 3]
return

I don't like it as it looks like inline assembly , but it could be written as:

 

proc data = $A000()
 byte array a = [1 2 3]
 ;rest of procedure's body goes here if needed
return

and placed starting from specified address.

 

Currently (according to Action! reference manual) a procedure or function can have an address specified, but the procedure/function code will be placed somwhere else in memory. The question is: can it be changed? I think yes

[Gury]

Ok, I will study the possibilities for array usage.

 

About indexing of arrays... Currently, Effectus has hard-coded value for array limit in such cases, but this can be removed, because Mads allows it.

 

From this:

IA_eff_ = $8000 .array [255] .word

 

to this:

IA_eff_ = $8000 .array .word

 

Mads specifically states:

If INDEX is omitted, the range is determined by the number of input values.

 

So, the max index limit can be removed in cases like this and probably in other occasions, too. I will check the code.

 

Aslo, pointers are of primary priority now, which will probably be fixed and recoded in the next branch version of Effectus.

[greblus]

Gury.

 

Thank you for your efforts! And I'll be eagerly waiting for further news about effectus development.

 

Cheers,

W.

[starwindz]

I am very interested in the game programming by Action! and Effectus. I have several questions about Effectus project.

[Questions about Action!]

1. Where is the proper .cart file of Action! for running under Altirra?

2. Following .act files can be imported to Action! running under Altirra?

: .Act files from joyfulcoder.net ( http://joyfulcoder.net/atari/action/code/ )

: .Act files from memopad( http://joyfulcoder.com/memopad/ )

3. What is the weak point of Action! compare to ML?

4. Professional games such as Donkey Kong can be created by Action!?

5. Action! can create .xex file or .atr file? .Xex and .atr files can be exported to PC OS?

[Questions about Effectus]

6. What are unsupported syntax and functions of Action!?

7. Atr file can be created by Effectus? (And how to?)

8. Professional games such as Donkey Kong can be created by Effectus?

9. Multi-color sprite game can be created by current version of Effectus?

[General questions]

10. Are there any kind of sprite and sound creator for Atari 800 games?

Edited October 13, 2014 by starwindz

[ricortes]

1. http://atariage.com/forums/topic/185505-action-for-emulator/

2. My guess would be yes.

3. Only ~70% of the speed of assembly. In a survey of languages used, I think Action! came out at only 3% used it so info/help is pretty dilute. The bright side is it seems like 100% of that 3% that is still around can be found here.

4. Yes. HomePak, Food fight, several other games and utilities were done in Action!

5. Yes, you would work with an Atari DOS/Disk, real or .ATR to load and save your programs.

6. Syntax is mostly Pascal like with a little bit of C. The things that are missing are some data constructs and inline assembly. You also don't get an assembly language intermediate file to tinker with like you would with some other languages like C.

7. Easy enough to import a file into with an emulator. Just use the H: drive option to copy from a PC directory to an .ATR

8. Should not be a problem.

9. Should not be a problem.

10 Yes, most of the old tools were pretty weak. You will have to pick ones and learn how to use them. Some of the new ones are really good but target their output for a specific assembler as an example.

 

Ultimately it is an individual's choice. My Action! set up, when I was still actively programming<sic> was a pretty specific set up. SDX cart so I could have access to BASIC or ASM/ED with Action! cart plugged into the SDX. Something like a 720k 3.5" drive for source code, 256k 800XL or 1200XL.

 

*BUT* I was one of the first to defect to cross assemblers on a PC, if you don't count Atari where they did everything on a DEC. I could see why people would/could choose Effectus over Action! just for the speed and features of doing code on a PC.

[+MrFish]

3. Only ~70% of the speed of assembly. In a survey of languages used, I think Action! came out at only 3% used it so info/help is pretty dilute. The bright side is it seems like 100% of that 3% that is still around can be found here.

 

I think it was more like 6%, but I don't know how accurate the numbers are, since the poll was posted in the programming forum when it was only accessible outside the main forum here. At that time many people either didn't know about the forum at all or rarely ventured to check in on it. Probably be a good idea to run the poll again now.

 

 

4. Yes. HomePak, Food fight, several other games and utilities were done in Action!

 

Interesting. I knew quite a few homebrew games had been done with it, but I didn't realize a higher-profile commercial game like Food Fight had been produced using it. Where did you find out the information about it? I was looking on Atarimania, and they list it as pure machine language -- not compiled Action or otherwise.

[+MrFish]

10. Are there any kind of sprite and sound creator for Atari 800 games?

 

There are quite a few different Atari based sprite editors. Here's one that you can use on your PC though. It was created by the programmer of the recent Atari Blast -- if I'm not mistaken.

 

Atari Player Editor

 

 

There are also quite a few Atari music and sound editing tools. Most notable are...

 

PC Based: RMT

 

Atari Based: CMC, MPT, TMC

Edited October 14, 2014 by MrFish

[starwindz]

@ricortes, MrFish

Thank you very much for your kind advice. I think l have to learn more about Effectus/Action!

Thank you again.