Effectus - New Atari cross-compiler (Alpha stage)

[Gury]

Hmm, added to the to do list. Extensions of existing standard would be good, easily set by some program option. Such ARRAY declaration would be great, also CASE statement would come handy (instead of group of ELSEIFs). Who knows what some future version may bring up!

[greblus]

And here is Linux version with mads as usual.

effectus-0.1.6.tar.gz

[joyfulcoder]

 

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

 

Would this achieve the same results?

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

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

[greblus]

Would this achieve the same results?

[...]

I'm afraid not.

The idea is to put the array contents under specified address, just like:

 

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

[Gury]

Fine, new Linux version is uploaded. Greblus, can you please tell me which target do you use for Linux (32/64-bit) and Linux distribution name? Just for clear info on download page.

 

I will consider the last post suggestions, because we can let the user choose standard or extension version of Effectus. But first we have to make it compatible with Action! as close as possible.

[greblus]

It's i386 static binary compiled on Arch, so it should work on any 32-bit Linux distribution (in a past i made some funny tests with simple static binaries and they worked on linux kernel in version 0.1, if i'll find this vmware image I could try effectus on it )

 

BTW Arch doesn't have a version, it's so called rolling release system (always up-to-date). My main setup is on eeepc right now updated once a month.

Edited July 18, 2014 by greblus

[greblus]

I was thinking about static binaries compatibility on Linux and they'll work most likely on all distributions with glibc2 (which means about 15-years old).

 

I had a lot of fun with qemu and Slackware today (my first and the best linux distro ever) as at the begining I thought that the main requirement would be the ELF format, so I installed Slackware 1.0.1 (it's pre linux-1.0 era somwhere around 1993), then Slackware 2.2.1 (linux 1.2 with ELF binaries support, 1995 distro) and finally my first heavily used and abused Slackware 7.0 (1999) which is already quite modern distribution with glibc2 and 2.2 kernel . All these work beautifully even by today's standards. If someone is interested i can upload qemu images somwhere and here is the effectus and mads running on Slackware 7.

[Gury]

Great info, greblus. It is good to see stuff working on different platforms and OSes. Good luck with your discoveries!

 

And what I discovered... Mads macros are great for some tasks where other ways would complicate things. I will use them for some new and old routines, depending on the nature of the task.

[d3bug]

One thing that seems to limit Action is the lack of a FLOAT type. It makes precision math neigh impossible in Action!. Do you think maybe while you are adding other features or maybe bugfixes maybe add FLOAT as a variable type? Yes I know floating point math is slow, BUT sometimes you just need to calculate the number of photons hitting a moon at a precise angle

 

Seriously though I think FLOAT would be a very nice addition, and the floating point math routines could be hand coded for speed.

 

Thank you for all your hard work on this project. I am seriously looking into using Action! for a game I am considering developing (Just waiting on legal authorization). It's based on the AD&D world (something we never officially saw from SSI) on the Atari 8bit platform.

[tschak909]

Well, honestly, why the hell would you want to do floating point math on a 6502? It's awkward in every possible way. For 99% of what one would THINK you would need floating point math, a small bit of fixed point routines would do the job just as effectively.

 

-Thom

[ricortes]

The floating point routines are part of the Atari OS. They really aren't that hard to learn how to use. I base that statement on I have used them both from Action! and assembly language and I'm a pretty low bar.

 

I would guess it takes less then an evening to learn how to use them. Procedure is almost identical to using CIOV type calls. You just set up what and where, jump to the routines, and the results end up where you pointed.

[flashjazzcat]

For 99% of what one would THINK you would need floating point math, a small bit of fixed point routines would do the job just as effectively.

 

This demonstrably true. Move the decimal point n places to the right and you can usually do the job with some long ints.

[Gury]

One thing that seems to limit Action is the lack of a FLOAT type. It makes precision math neigh impossible in Action!. Do you think maybe while you are adding other features or maybe bugfixes maybe add FLOAT as a variable type? Yes I know floating point math is slow, BUT sometimes you just need to calculate the number of photons hitting a moon at a precise angle

 

Seriously though I think FLOAT would be a very nice addition, and the floating point math routines could be hand coded for speed.

 

Thank you for all your hard work on this project. I am seriously looking into using Action! for a game I am considering developing (Just waiting on legal authorization). It's based on the AD&D world (something we never officially saw from SSI) on the Atari 8bit platform.

There is one excellent example of floating point math in Mads package in directory math (library) and an example in examples\Libraries\fp\. It uses fast FP library, not depending on OS. I have a plan to integrate it in Effectus as an extension.

 

I am looking forward for your game. Good luck!

Edited July 23, 2014 by Gury

[d3bug]

Well, honestly, why the hell would you want to do floating point math on a 6502? It's awkward in every possible way. For 99% of what one would THINK you would need floating point math, a small bit of fixed point routines would do the job just as effectively.

 

-Thom

..... I'm sorry, you were saying?

[d3bug]

This demonstrably true. Move the decimal point n places to the right and you can usually do the job with some long ints.

unless of course what is past the decimal point is about 15 digits long.... like in calculating rays.... but this is all academic. The point of Action! is to make things easier not more complicated. What is the point of having NO OPTION of FP math? I can't think of a single reason not to allow the USER to CHOOSE to use it or not... can you?

[tschak909]

You're demonstrating yourself, an idiot, who has never done any practical programming on the 6502.

 

You can approximate what you need for a circle's area calculation by doing fixed point math and tables.

 

-Thom

[d3bug]

There is one excellent example of floating point math in Mads package in directory math (library) and an example in examples\Libraries\fp\. It uses fast FP library, not depending on OS. I have a plan to integrate it in Effectus as an extension.

 

I am looking forward for your game. Good luck!

That sounds great! I think it would be a nice addition. Effectus already is a wonderful cross tool, and this will only make it better... I have a question also for anyone, but particularly you since you are a developer familiar with more than one platform:

 

When coding ML, you know how when you jump to one byte location is does one thing (whatever it is made to do), but if you were to jump as a different byte offset, it would do something else (or crash more than likely)? Anyway, a long long time ago in a state far far away (back in the day) I had the idea in my head it would be possible to make an assembler that would be smart enough (with multiple passes more than likely) to code in such a way as to overlap routines as much as possible so that for example you had two routines... each is 32 bytes long, and you call the first one at $4000, you could call the second one at say for example $400B and because of the overlap and the offset odd location it would be only 53 bytes long instead of 64.... I don't know if I am explaining this correctly or not, but I think you may understand.

 

So, you think it would be possible to eek out a few less bytes with no loss in routines with a very efficient assembler like what I am talking about?

 

/random thoughts

[d3bug]

You're demonstrating yourself, an idiot, who has never done any practical programming on the 6502.

 

You can approximate what you need for a circle's area calculation by doing fixed point math and tables.

 

-Thom

perhaps you missed the ": P" at the end... now who is the id10t?

[+Stephen]

unless of course what is past the decimal point is about 15 digits long.... like in calculating rays.... but this is all academic. The point of Action! is to make things easier not more complicated. What is the point of having NO OPTION of FP math? I can't think of a single reason not to allow the USER to CHOOSE to use it or not... can you?

Not trying to argue, but with a maximum screen resolution of 320*200, and a practical resolution of 160*200, can you please demonstrate why you would need 15 digits of precision?

 

BTW - if you want to see an incredible ray caster running at 20 frames per second and using 256 colours, do a quick search for Project M 2.0

[flashjazzcat]

What is the point of having NO OPTION of FP math? I can't think of a single reason not to allow the USER to CHOOSE to use it or not... can you?

I'd prefer none to the historically half-baked attempts at FP support in (for example) many A8 C compilers, which managed FP values as six byte char arrays. However, since this is a cross-compiler, if FP can be implemented seamlessly as a data type without the coder having to make explicit calls to the FP library, then great. But you should note I did not take the stance that FP MUST be omitted in this instance, but that operations which ostensibly require FP can usually be accomplished without it. Therefore the assertion that no FP "makes precision math nigh on impossible" is to overstate the case for its inclusion. Moreover, to be really versatile, more than just 16-bit integer to FP conversion is required. I recently wrote a partition editor which had to represent megabytes as 32-bit numbers to four decimal places. The OS FP routines were useless in this case, and I realized it was preferable (and not that difficult) to write short custom functions to perform the conversions.

 

Of course, if FP can be integrated in a cross-compiler so that its use is as seamless as in BASIC, and it's faster, and supports type conversion between long integers, then it's the most powerful and versatile proposition of all - no argument with that.

[d3bug]

Not trying to argue, but with a maximum screen resolution of 320*200, and a practical resolution of 160*200, can you please demonstrate why you would need 15 digits of precision?

 

BTW - if you want to see an incredible ray caster running at 20 frames per second and using 256 colours, do a quick search for Project M 2.0

 

NEEDing 15 digits of precision was really not the point. (no pun intended)

Having the OPTION was.

More choice iis better than less choice.

[d3bug]

I'd prefer none to the historically half-baked attempts at FP support in (for example) many A8 C compilers, which managed FP values as six byte char arrays. However, since this is a cross-compiler, if FP can be implemented seamlessly as a data type without the coder having to make explicit calls to the FP library, then great. But you should note I did not take the stance that FP MUST be omitted in this instance, but that operations which ostensibly require FP can usually be accomplished without it. Therefore the assertion that no FP "makes precision math nigh on impossible" is to overstate the case for its inclusion. Moreover, to be really versatile, more than just 16-bit integer to FP conversion is required. I recently wrote a partition editor which had to represent megabytes as 32-bit numbers to four decimal places. The OS FP routines were useless in this case, and I realized it was preferable (and not that difficult) to write short custom functions to perform the conversions.

 

Of course, if FP can be integrated in a cross-compiler so that its use is as seamless as in BASIC, and it's faster, and supports type conversion between long integers, then it's the most powerful and versatile proposition of all - no argument with that.

so, in essence, we agree...

 

Just one thing I have been trying to get across: regardless of how difficult it is to write a routine yourself (all programmers have different levels of skill in ML), the point of Action! is to make things simpler, not to make you handcode routines (otherwise why not simply write the whole thing in ML right?... I mean graphics manipulation is MUCH simpler in pure ML/ASM after all).

[flashjazzcat]

Just one thing I have been trying to get across: regardless of how difficult it is to write a routine yourself (all programmers have different levels of skill in ML), the point of Action! is to make things simpler, not to make you handcode routines (otherwise why not simply write the whole thing in ML right?... I mean graphics manipulation is MUCH simpler in pure ML/ASM after all).

Sure, if it is easier, unlike the historical FP implementations I referred to. I'm sure it will be.

[ricortes]

..... I'm sorry, you were saying?

 

The way it 'sorta works for graphics output to the screen.

314 => INT

screen size of 320x200 or 160x200 means the maximum diameter you can have is 320-200-160 or things go off screen or byte/int again. Figure 100 squared or 10000 which is an int. Since you want to multiply them, prescale the 10000 or go with long integers.

 

I hope you can see though there just isn't a lot of need to do surface area of a circle in 99% of programming. INTs give you accuracy of ~1 part in 32k so you are pretty much at the limit of measurement i.e. you need a pretty fine set of calipers that can measure the difference between 3.2001 cm and 3.2000 cm.

 

The technical staff at the company I worked was about 1/3 engineers, 1/3 chemist, and 1/3 biologist. The chemist and biologist would laugh our asses off when an engineer would get out their HP calculator, then try to weigh out 1232.0351 grams! Worked there decades and there was no way to convince the engineers to do it anyway any other way.

 

Just taking what our IT people did as an example, they insisted on using the right tool for the job. For instance, if you said you needed calculations that required floating point, they would write the program in FORTRAN.

 

There's nothing wrong with floats in Effectus, its just that they are available in a lot of other languages. You have the entire series of BASICS from Atari to Turbo to MMG to OSS. There are several versions of C available with some floating point support. Another seamless and viable way of using them would be Pascal.

[d3bug]

 

The way it 'sorta works for graphics output to the screen.

314 => INT

screen size of 320x200 or 160x200 means the maximum diameter you can have is 320-200-160 or things go off screen or byte/int again. Figure 100 squared or 10000 which is an int. Since you want to multiply them, prescale the 10000 or go with long integers.

 

I hope you can see though there just isn't a lot of need to do surface area of a circle in 99% of programming. INTs give you accuracy of ~1 part in 32k so you are pretty much at the limit of measurement i.e. you need a pretty fine set of calipers that can measure the difference between 3.2001 cm and 3.2000 cm.

 

The technical staff at the company I worked was about 1/3 engineers, 1/3 chemist, and 1/3 biologist. The chemist and biologist would laugh our asses off when an engineer would get out their HP calculator, then try to weigh out 1232.0351 grams! Worked there decades and there was no way to convince the engineers to do it anyway any other way.

 

Just taking what our IT people did as an example, they insisted on using the right tool for the job. For instance, if you said you needed calculations that required floating point, they would write the program in FORTRAN.

 

There's nothing wrong with floats in Effectus, its just that they are available in a lot of other languages. You have the entire series of BASICS from Atari to Turbo to MMG to OSS. There are several versions of C available with some floating point support. Another seamless and viable way of using them would be Pascal.

 

You said the F word!!!

Actually, I do like Pascal... it kind of fits with my precision personality... however, I do love the fact that Action!/Effectus translates to ASM/ML instead of some stupid pcode crap that is little better than interpreted BASIC... The problem with most High level languages (with very few exceptions) is that most compile to P-Code with a runtime lib and what amounts to an interpreter. That is why I like Action!/Effectus... it's not like most of the others. There was another which is from the Commodore world, not well known, but from a Disk Magazine called LOADSTAR. It was called ZIP BASIC. It had many limitations not the least of which was that you could only have 1 command per line, and another was that it was written in BASIC, and had to compile whatever was in memory up to line number 31998 (everything after was ZIP BASIC), It was FAST though... I'll give you an example:

10 FOR F=1024 TO 2023
20 POKE F,A
30 NEXT F
40 A=A+1
50 IF A > 255 THEN A=0
60 GOTO 10

Now the above example in BASIC would take about 10min to run through all 256 characters poked to the screen RAM. ZIP BASIC would get ahold of it and it would take about 1 second to run through all 256 characters. The only time the "runtime library" was used was for math (floating point mainly).... aside from that, it wrote it to pure ML. I love that kind of efficiency... write in a high level language and filter it down to pure ML.