I know Mac/65 .. is Action! worth the efforts to learn it?

[Fox-1 / mnx]

Try this, this time:

 

20 FOR I=1 TO 100
30 BPUT #11, ADDR+I, RND(0), 2
40 NEXT I

 

Note: Code above fills a random value table in the extended RAM. Try these 3 lines with assembly code (took me only 10 seconds to write it)

 

I'm not into riddles or anything, but yes, in MC it requires some more lines because you'll have to open and close the IOCB yourself but where I need 12 bytes for that you'll need over 8KB (or 24KB or something like that) to do the same thing because you need (Turbo-)BASIC to be loaded first.

 

b.t.w: As $D3xx is untouched, your example doesn't do anything with extended RAM...

 

 

This maybe due to the fact that some programmers do not come from a commercial background where productivity is as important (or more) then technical wizardary and one can not always afford to spend years on coding an application.

 

"Productivity" and "commercial background" are irrelevant when coding on Atari 8-Bit, which is what I'm talking about. All my statements don't apply to commercial coding on modern systems.

 

 

Also, I don't have anything against TurboBASIC. It's been used to write some of the better games, usually "CTB" compiled afterwards, but sooner or later the programmers hit a wall when trying to do things that are simply not possible. They slowly start to implement MC data, bit by bit, only to hit the next wall after a while: out of memory. It has been this way in the past and it still happens today.

[+Stephen]

Try this, this time:

 

20 FOR I=1 TO 100
30 BPUT #11, ADDR+I, RND(0), 2
40 NEXT I

 

My point is, when coding time and coding productivity is important, why do I have to reinvent the wheel with assembly code. Small program size and maximum performance are not always the only objective when coding. For some reason, a lot of hard-core programmers do not understand that. This maybe due to the fact that some programmers do not come from a commercial background where productivity is as important (or more) then technical wizardary and one can not always afford to spend years on coding an application.

Just to play devil's advocate here (because I am not arguing your point). Looping in BASIC is beyond slow. We'll use a similar example to yours above. Let's try clearing a tiny 3-pages of memory, which is not even enough to hold a full font definition. Just under 5 full seconds. Now, since clearing RAM is something that may needed to be done often, I wrote a relocatable routine in ASM which takes 2 parameters (page aligned location in RAM to begin clearing, and the number of pages to clear). The code is a scant 25 bytes. Most of this is used to clean up the stack so a return to BASIC can be made. The code is relocatable and clears the RAM in .004 seconds. This is nearly 1200 times faster than the BASIC routine. I would say it was well worth the few minutes it took me to write up the routine. If you're interested, check out my full blog post.

 

This is definitely a case of find the slow portions of a project and optimize them.

[atari8warez]

I'm not into riddles or anything, but yes, in MC it requires some more lines because you'll have to open and close the IOCB yourself but where I need 12 bytes for that you'll need over 8KB (or 24KB or something like that) to do the same thing because you need (Turbo-)BASIC to be loaded first.

 

I hate to repeat myself, but "Size and Speed" aren't always the main objectives when writing code

 

b.t.w: As $D3xx is untouched, your example doesn't do anything with extended RAM...

 

That example code is in BASICXE, it moves bytes into bank 2 of extended memory. Obviously you have to be in Extended Memory Mode which is by the way also accomplished with 1 statement which is simply EXTEND (simple eh!, no memory locations to remember). Above code as you can imagine was not a complete program, I only wanted to illustrate what can be achived with 3 lines of BASIC. That RND function alone is worth several lines of Assembly code.

 

"Productivity" and "commercial background" are irrelevant when coding on Atari 8-Bit, which is what I'm talking about. All my statements don't apply to commercial coding on modern systems.

 

Again i was only trying to understand a hard-core programmer's mindset. For one thing Atari is a slow machine with small memory so it's somehow understandable to stretch the limits, nonwitstanding the limitations of Atari however I have to revisit the thought of "Solution for the Problem at hand" which means selecting the right programming tool for the project. Assembler, where speed and memory size are limiting factors, higher level language where programming time and ease is paramount. Commercial programmers are simply more aware of these requirements due to the nature of their business.

 

Also, I don't have anything against TurboBASIC. It's been used to write some of the better games, usually "CTB" compiled afterwards, but sooner or later the programmers hit a wall when trying to do things that are simply not possible. They slowly start to implement MC data, bit by bit, only to hit the next wall after a while: out of memory. It has been this way in the past and it still happens today.

 

That means those programmers were not fully aware of the capabilities and limitations of the tools they were using and started off with the wrong one. So it's not really the fault of the tool chosen but rather a shortsightedness/lack of knowledge on the part of the programmer.

Edited June 27, 2012 by atari8warez

[Marius]

But to get back ontopic... anyone who can tell something about ACTION? That's what my question was about in the first place

 

I like turbobasic a lot. Especially the way it formats a listing, is really COOL. But... I am with Fox-1: I want that my final program is an standalone executable.

 

I like Assembler a lot too... especially Mac/65 and Synassembler. but indeed... sometimes I want a little more convenience.

 

So... tell us about Action!

[atari8warez]

Just to play devil's advocate here (because I am not arguing your point). Looping in BASIC is beyond slow. We'll use a similar example to yours above. Let's try clearing a tiny 3-pages of memory, which is not even enough to hold a full font definition. Just under 5 full seconds. Now, since clearing RAM is something that may needed to be done often, I wrote a relocatable routine in ASM which takes 2 parameters (page aligned location in RAM to begin clearing, and the number of pages to clear). The code is a scant 25 bytes. Most of this is used to clean up the stack so a return to BASIC can be made. The code is relocatable and clears the RAM in .004 seconds. This is nearly 1200 times faster than the BASIC routine. I would say it was well worth the few minutes it took me to write up the routine. If you're interested, check out my full blog post.

 

This is definitely a case of find the slow portions of a project and optimize them.

 

I am in total agreement with you Stephen, you are doing the right thing. Where speed is important, you are using the right tool to overcome the limitation (i.e. Machine Language code). In fact back in the day, I've done the exact same thing:

 

I wrote an ENTERable code segment as a BASIC language tool for "Formatted Input Entry". BASIC, IMO is terrible when it comes to data entry from the screen. You can't control the length, type and positioning of the input. You have no means of masking it either. So I decided to write that tool and it was obvious that BASIC is pretty slow under certain circumstances, so I did the exact same thing you did, used ML code where speed was important.

Edited June 27, 2012 by atari8warez

[atari8warez]

But to get back ontopic... anyone who can tell something about ACTION? That's what my question was about in the first place

 

I like turbobasic a lot. Especially the way it formats a listing, is really COOL. But... I am with Fox-1: I want that my final program is an standalone executable.

 

I like Assembler a lot too... especially Mac/65 and Synassembler. but indeed... sometimes I want a little more convenience.

 

So... tell us about Action!

 

Sorry no experience with Action Marius, but I've heard it's fast, that alone however was not enough to pique my interest to learn a whole new language, maybe someone with hands on experience in Action can chime in.

 

If you have experience with "C" language, why don't you try that instead. Learning curve will be much faster. In the past I used LightSpeed C, ACE C and Deep Blue C, and some of those produce stand alone executables. (Ace C has a compiler, the others I don't remember).

 

I wrote a home security app with C, which used the Atari as the main controller for Window/Door security switches. Joystick ports were used to read the sensors.

Edited June 27, 2012 by atari8warez

[+Stephen]

But to get back ontopic... anyone who can tell something about ACTION? That's what my question was about in the first place

 

I like turbobasic a lot. Especially the way it formats a listing, is really COOL. But... I am with Fox-1: I want that my final program is an standalone executable.

 

I like Assembler a lot too... especially Mac/65 and Synassembler. but indeed... sometimes I want a little more convenience.

 

So... tell us about Action!

Sorry Marius - didn't mean to veer off topic. I unfortunately have no experience with Action!. I think A8ISA1 used or still uses it. I'll see if I can nudge him over here.

[Fox-1 / mnx]

But to get back ontopic... anyone who can tell something about ACTION? That's what my question was about in the first place

 

Only thing I did with action! was examining source codes, routines and equates and translated the info to a format I could use with MAC/65.

 

While creating a stand-alone executable from ACTION! code a run-time will be added, making your code larger than necessary. IIRC you can tweak the run-time by deleting routines of which you are sure your code doesn't use them.

 

For timed things or cycle-exact routines you still need to use machine code. Stuff like your last project can't be done in ACTION!

 

 

 

I like turbobasic a lot. Especially the way it formats a listing, is really COOL. But... I am with Fox-1: I want that my final program is an standalone executable.

 

Turbo-BASIC has it's place. Sometimes I use it to convert some data by reading a file from disk to write it to another file, containing the data I need but these are just quick and dirty tools I don't even keep. In fact, if I need such a thing I use stock BASIC in most cases as it at least runs with Sparta-DOS.

 

I don't like to depend on external programs to run something so no BASiC-XE or BASIC-XL for me.