Jump to content
IGNORED

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


Marius

Recommended Posts

Hi there,

 

Once in a while I grab my Mac/65 cart or my Synassembler cart and I write something on my Atari 8bit.

 

Very nice to do, but sometimes I want a bit easier way of creating things, without 'downgrading' to basic or turbo basic.

 

A few weeks ago I got a nice deal here on AtariAge and received both a Mac/65 cart and an Action! cart.

 

I searched on internet and found rather interesting website(s) about Action!

 

But now I was wondering:

 

Are there any people here around that do use Action! from time to time, and also program in Assembler.

Could someone tell me whether it is worth the time to invest this in learning Action!, or is it not a step forward when one already can program in Assembler?

 

Thanks

M.

Link to comment
Share on other sites

I don't program in Action!, but I can't see any higher level language being a "step forward" in any terms other than development speed. The original Action! has a number of practical limitations on project size, I believe, which aren't present in Mac/65. That said, you'd probably be better off exploring one of the cross-assemblers like MADS if you're already a competent Assembly Language coder. Cross-development offers something like the speed of coding in a higher level language, and much easier project management for large undertakings.

 

There's also a cross-compiler for Action! whose name I forget right now, and I'm not sure if it's still being developed.

 

I doubt there's any harm at all in learning Action! if you already code in Assembler - perhaps it will be useful if you want to code up some quick programs without the overhead of writing all your own I/O routines, etc.

Link to comment
Share on other sites

Hi!

 

Thanks for your quick reply. Your response is just saying what my thoughts are. It might be handy for a quick 'thingy' but it will not add anything to my possibilities now.

 

I'm not into cross assembly or anything like that. My fun is spending time behind my Atari, whatever that time-spending is ;)

When I go again behind my PC or Mac I'm again not behind my Atari.

 

That's why I still code and create anything with the Mac/65 assembler cart, and music programs like Chaos Music Composer. I know there are a lot of positive points about coding on cross assembler and related tools, but still... it's not spending time with my atari :D

 

thanks anyway for the suggestion!

Greetz

M>

Link to comment
Share on other sites

I know where you're coming from with regard to cross-platform development, and my own preference would also be to develop directly on the A8. Unfortunately some of my projects are of such a scale that the compile times and source code sizes are just too much for the A8 to manage. I'd love to see a truly integrated development suite for the A8... it's a dream of mine to see something like this running under the GUI (a special compiled language for the GUI, for example), and we will indeed be seeing resource editors and such like running as native GUI apps on the A8 in a year or so. Mind you, MAE is an assembler you might want to look at if you haven't already: it has a fully integrated editor, compiler and debugger right on the A8, and KMK for one has completed some really big projects with it (such as the EDDY disk editor for SDX).

Edited by flashjazzcat
Link to comment
Share on other sites

I did some Action! programming "back in the day" and I think it's a really nice language. The development environment is very easy to use and the code compiles quickly. It produces some pretty efficient 6502 code, although not as tight as hand coded assembly. You can also easily make calls to machine code from Action! if you want to.

Link to comment
Share on other sites

  • 1 month later...

I dream of the day that I win the EuroMillions lottery and then employ a load of you lot to write games for me and the Atari community.

 

The first thing that I've had everyone doing is writing PC/Linux based software for quicker development of Atari software. I've never understood the nostalgia for developing on an A8. Back in 1995/1996, I was writing my one and only released item of software, Football Fantasies. The amount of time it took me to save the code and then reboot, load Turbo Basic and then run all my routines was way too slow, it was painful. Cross development for me is now where it's all at, though we don't have that many tools for doing so. CC65, MADS (which I wish to learn). Then again, modern games are where it's all at, and I'm still stuck in my Atari time-warp. Though I love being in it...

Link to comment
Share on other sites

I agree that cross-development is way quicker and developing large projects on the A8 itself would probably be too costly in terms of time (and wits) nowadays, but do miss writing code on the target hardware. I'm in the uneasy situation of only using my Ataris to test programs developed on the PC. Back in the day, I used to develop development tools on the Atari, and actually use them. I wrote a text editor and a macro assembler and then set about using them to write a word processor... happy days. It's not that I don't have a gas using WUDSN and MADS, but the real hardware's inactive while this is taking place. :)

Link to comment
Share on other sites

I've never understood the nostalgia for developing on an A8.

 

Well... it is rather easy to understand. My Hobby is spending time with my Atari :D ... so when I program something to run on the Atari, I want to write that ON my Atari. The writing on the XL keyboard... the assembling with the Mac/65 cart.... wachting my old CRT television screen... debuggin the code with my BlackBox and/or the DDT debugger in the Mac/65 cart... it's all fun.

 

Back in 1995/1996, I was writing my one and only released item of software, Football Fantasies. The amount of time it took me to save the code and then reboot, load Turbo Basic and then run all my routines was way too slow, it was painful.

 

First of all. I do not use Basic. I'm using Mac/65 and/or my Synassembler cart. Both brilliant assemblers, even compared to Crossassemblers they are great. Next to that: I have an Atari with a huge ramdisk. It's amazing how fast this is. Next to that: testing some code on the real thing is really as fast (or perhaps even faster) compared to crossassembling. I write a routine... I jump to my debugger (DDT) or to DOS and I give the RUn command. Boom... there I see the result of my code. I jump back to my code. I make some changes, assemble (lightning fast) and BOOM there I'm testing my code AGAIN. Even complete data blocks (like background music, or screen data) can remain in memory all the time, and don't need to be loaded every time.

 

That Mac/65 cart is a genius thing on it's own too btw. You can switch it on and off by software command (with Qmeg OS it is even more easy to do that); it has Assembler AND debugging tool on one cart.

Ofcourse: extremely large projects... they probably are easier developed on Crossassembler. But not everything is that big!

 

Yesterday I wanted to write a tool that downloads the Time and Date from the RTC in the Ultimate 1MB upgrade. Well... to write a tool for this specific hardware... hmmm it is definitely easier to write this on the real thing! I succeeded within 1 hour. From scratch!

 

And again: this all fun is spent behind the real thing. First class Atari 8bit quality time. I do not like to trade this for even more time behind my PC or Mac.

 

Last:

My point is, that when you would simply try to learn Mac/65 or Synassembler. Upgrade your Atari 8bit with some stable ramdisk, Qmeg OS. Get yourself a Mac/65 cart (or a MaxFlash 1MB cart to flash it with Mac/65 or Synassembler). You'll be VERY surprised how versatile your own Atari Development Enviroment is!

  • Like 1
Link to comment
Share on other sites

Well... it is rather easy to understand. My Hobby is spending time with my Atari :D ...

 

Well, I can understand that! It's just the speed of it that stops me! I'm slow enough developing something anyway!

 

First of all. I do not use Basic. I'm using Mac/65 and/or my Synassembler cart. Both brilliant assemblers, even compared to Crossassemblers they are great...

 

It sounds like that you have a far better set up Atari environment than I have, so I can see why you would like to develop on the Atari.

 

My environment consists of:

Multiple Atari's, all standard models, no RAM extensions.

1 x 1050 disk drive (non functioning)

XC12 cassette player

Assembler Editor cartridge

'Quick' disks (which I can't use now), unless I use my PC based copies of it that I bought from DGS.

 

Though I haven't done any Atari programming in quite a while, I like to work with CC65 as my cross compiler and I really want to pick up MADS as I have hand created 6502 Assembly before, using ca65.

Link to comment
Share on other sites

  • 5 months later...

 

Well... it is rather easy to understand. My Hobby is spending time with my Atari :D ... so when I program something to run on the Atari, I want to write that ON my Atari. The writing on the XL keyboard... the assembling with the Mac/65 cart.... wachting my old CRT television screen... debuggin the code with my BlackBox and/or the DDT debugger in the Mac/65 cart... it's all fun.

 

 

I certainly do understand your feelings, unless it is a programming project that is beyond A8s capabilities, I would prefer to develop on Atari too. After all this is all about Atari and that's where the fun and nostalgia is.

 

However, if what you want is "easier" and "faster" development compared to Mac/65, I would consider using Turbo Basic an "upgrade" and not "downgrade" over Mac/65.

If you don't need the absolute max speed for performance and lower level access to the computer's innards, higher level languages always offer a lot more convenience features and development speed compared to assemblers. So instead of learning a new language from scratch I would just consider using Turbo Basic.

Link to comment
Share on other sites

I think TurboBasic, compared to MAC/65, definitely is a downgrade.

 

Always need to load TB first to run the final program, doesn't run with most disk based SpartaDos versions, less available memory, code runs much slower than MC, far less control over graphics, DList, DLI and VBI.

 

Programming simple stuff in MAC/65 is as easy as with TurboBasic. Just a matter of using the right instructions.

Link to comment
Share on other sites

I think TurboBasic, compared to MAC/65, definitely is a downgrade.

 

Always need to load TB first to run the final program, doesn't run with most disk based SpartaDos versions, less available memory, code runs much slower than MC, far less control over graphics, DList, DLI and VBI.

 

Programming simple stuff in MAC/65 is as easy as with TurboBasic. Just a matter of using the right instructions.

 

Doesn't TB create a standalone executable? I thought it's not an interpreter. Honestly I haven't used it much in the past and my comparaison was actually between an assembler and a high level language rather than between Mac/65 and TB. If it doesn't run with disk based SD that may be a turn off for sure.

 

I do disagree however that an assembler is easier to program than a high level language. Maybe it is so for a die-hard assembler coder but not for other programmers. A simple comparaison and a branch can take up to 3 lines of code, the same task (and actually more) can be accomplished in 1 line of code with a high level programming language and one doesn't need to concern himself with stacks and addressing modes etc.... I think the best approach is to choose the most favorable language for the task at hand...

Edited by atari8warez
Link to comment
Share on other sites

I think TurboBasic, compared to MAC/65, definitely is a downgrade.

 

Always need to load TB first to run the final program, doesn't run with most disk based SpartaDos versions, less available memory, code runs much slower than MC, far less control over graphics, DList, DLI and VBI.

 

Programming simple stuff in MAC/65 is as easy as with TurboBasic. Just a matter of using the right instructions.

 

Doesn't TB create a standalone executable? I thought it's not an interpreter. Honestly I haven't used it much in the past and my comparaison was actually between an assembler and a high level language rather than between Mac/65 and TB. If it doesn't run with disk based SD that may be a turn off for sure.

 

I do disagree however that an assembler is easier to program than a high level language. Maybe it is so for a die-hard assembler coder but not for other programmers. A simple comparaison and a branch can take up to 3 lines of code, the same task (and actually more) can be accomplished in 1 line of code with a high level programming language and one doesn't need to concern himself with stacks and addressing modes etc.... I think the best approach is to choose the most favorable language for the task at hand...

No stand alone executable. There was a TBXL compiler, but it still required the separate runtime environment. It's a great version of BASIC, but no BASIC will ever be a substitute for ASM. That being said, I do my current coding using TBXL and ASM snippets where I really need speed.

Link to comment
Share on other sites

but no BASIC will ever be a substitute for ASM...

 

Again, each language has it's place in programming and must be chosen according the task at hand, for ease of programming however higher level languages are far ahead of any assembler. I am just trying to imagine how big and complicated AspeQt source code would have been, had it been written in assembly language. Of course Atari has less resources and power than a PC, so to get the last bit of performance from such a machine requires using an assembler.

 

And thanks for the info on TB compiler, I must have forgotten that there is a separate compiler for it.

Edited by atari8warez
Link to comment
Share on other sites

Doesn't TB create a standalone executable? I thought it's not an interpreter.

 

It doesn't. It's indeed an interpreter,

 

 

I do disagree however that an assembler is easier to program than a high level language. Maybe it is so for a die-hard assembler coder but not for other programmers.

 

Die hard "C" coders don't get assembly. Die hard perl programmers don't get Visual Basic. Die hard COBOL programmers... etc...

 

 

A simple comparaison and a branch can take up to 3 lines of code, the same task (and actually more) can be accomplished in 1 line of code with a high level programming language and one doesn't need to concern himself with stacks and addressing modes etc....

 

You can't think in "lines". You need to think in instructions, or better, the way you construct routines.

 

Basic:

 

10 X=0

20 POKE 712,X

30 X=X+1

40 IF X<>255 THEN GOTO 20

50 END

 

 

Assembly:

 

LDX #0

LOOP STX 712

INX

CPX #255

BNE LOOP

BRK

 

 

Same effect, just different ways to "write it down". Difference is that the BASIC way needs 8KB plus some bytes while the MC way is under 16 bytes.

 

 

I think the best approach is to choose the most favorable language for the task at hand...

 

I can't argue that as it's just true.

Link to comment
Share on other sites

but no BASIC will ever be a substitute for ASM...

 

Again, each language has it's place in programming and must be chosen according the task at hand, for ease of programming however higher level languages are far ahead of any assembler. I am just trying to imagine how big and complicated AspeQt source code would have been, had it been written in assembly language. Of course Atari has less resources and power than a PC, so to get the last bit of performance from such a machine requires using an assembler.

 

And thanks for the info on TB compiler, I must have forgotten that there is a separate compiler for it.

I completely agree! This is why I have to currently do BASIC + ASM - not quite smart enough yet to do 100% assembly :) Maybe one day I'll get there.

Link to comment
Share on other sites

With assembly language, re-usable code libraries take the weight off. I think the most intimidating thing about starting assembly language is that all the BASIC statements (PRINT, OPEN, etc) need to be reimplemented. Once you build up a library of routines, however, you can get to the stage where you can knock together small applications pretty fast. The actual logic flow of an assembly program (as evidenced by Fox's snippets) isn't really all that different. Replace GOSUBs with JSRs to your library code and you're just about there.

 

Of course assembler is a complete b*****d to debug without an emulator, however. :)

Edited by flashjazzcat
Link to comment
Share on other sites

wow... this grew out to a serious thread...

 

All contributers: thanks a lot!

 

I agree with Fox-1 that using a basic (whatever kind) is a step backward. I'm getting along rather well with Assembler. I'm not a genius, but I'm also not a novice anymore.

 

The point is, that I have seen very nice programs written in action. They run fast and I had the idea that Action would be handier to program in than Assembler.

 

I have not made my decision yet. It's great to have a choice anyway.

Link to comment
Share on other sites

You can't think in "lines". You need to think in instructions, or better, the way you construct routines.

 

Basic:

 

10 X=0

20 POKE 712,X

30 X=X+1

40 IF X<>255 THEN GOTO 20

50 END

 

 

Assembly:

 

LDX #0

LOOP STX 712

INX

CPX #255

BNE LOOP

BRK

 

 

Same effect, just different ways to "write it down". Difference is that the BASIC way needs 8KB plus some bytes while the MC way is under 16 bytes.

 

 

:thumbsup: Trick answer Fox (does it have anything to do with your nick ;) )

 

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)

 

or just try this one line:

 

XIO 11,#1,0,0,"D1:MYFILE.TXT"

 

 

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.

Edited by atari8warez
Link to comment
Share on other sites

I completely agree! This is why I have to currently do BASIC + ASM - not quite smart enough yet to do 100% assembly :) Maybe one day I'll get there.

 

Don't underestimate your intelligence ;) . You don't need to be a genious to write assembly language programs, you just need immense patience, lot of spare time, and a rock-hard dedication :grin:

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

Guest
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.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...