We all know that using Amos has its drawbacks. Take the size of executable programs produced by the compiler. If you compiled one line of Amos code it would come out at around 54k. This alone has put off many would-be Amos programmers. What about the speed of Amos? Even compiled some programs are simply not fast enough. Are you tired of people not taking your programs seriously because they are written in Amos? Then read on....
DISGUISING AMOS
Without a doubt there is still a stigma attached to programs written in Amos. Up until a couple of years ago Europress Software (publishers of Amos) insisted that every Amos program released had to declare that it was written in Amos on the programs title screen. As Europress no longer have an interest in the Amiga market you could do yourself a favour by displaying the Amos logo at the end of your program, I am sure Europress wouldn't mind too much. Of course you should be proud that your program is written in Amos but if you are trying to get a commercial release this may well count against you.
Here are some more tips for hiding your program's origins?
The Orange default screen. Just before your program starts proper the user gets a one or two second glimpse of a horrid orange screen, what a give-away! In case you didn't know here is how to avoid it:
In the compiler, set "Create default screen" to "NO". Then open up a screen at the start of your program;
Screen Open 0,320,200,16,Lowres
Flash Off: Curs Off: Cls 0
The Ctrl-C break allows users to stop your program and return to WorkBench, some other languages do this too, but to put the boot in Amos also displays a requester saying "Program Interrupted". Use "Break Off" in your program to stop the Ctrl-C break. Only do this just before compiling though.
The Amiga-A key combination allows the user to switch from Amos to WorkBench and back again. Use Amos Lock to disable this, unless you need multitasking.
Filename extenders like ".Abk" are also a right give-away. Amos does not require you to use them, so change them to something more mysterious like ".PAK" or ".WIZ"
The Amos file requester is pretty naff (even the Pro one) so use a custom made one or use an extension like INTOS from OTM to access the ASL file requester or similar.
NEVER, EVER use the "Bell" "Shoot" or "Boom" instructions, they sounds naff anyway, use your own sound samples instead.
There are plenty more tips on this subject, I will try to bring you some more in a future instalment.
MAKING EXECUTABLES SMALLER
There are only a few options open to us here. The most obvious is the Amos.Library. A three line Amos program of 100 bytes compiles to a massive 54K with the library included in the code. The same 100 byte program without the Amos.Library included in the executable program comes out at a more reasonable 8K. So if you do your maths you will see the Amos.Library is around 46K in length. The Amos.Library is still needed in the "Libs" directory of the disk your program booted from of course. The advantages of having the Amos.Library inside your program is that if you crunch your executable the library will get crunched too, saving disk space. An alternative could be to use PowerPacker Patch or CrunchMania patch to crunch your Libs, but this may be a bit over the top.
The next step is to crunch the executable. There are various filepackers around like PowerPacker, CrunchMania and Imploder. All of these do a good job and are available from any P.D Library (Try 17 Bit on 01924-366982)
Warning: Do NOT on any account use the "Squash" option from the Amos Pro compiler, it is badly bugged, most larger programs will report an out of memory error and return to WorkBench. The filepackers mentioned above will all comfortably beat the "Squash" option, most of the time anyway.
If you are using a lot of banks in your program a good way of reducing the size of your final program would be to load the banks in as and when needed. This method obviously slows done the operation of your program because of disk access time. One way to speed up loading data files would be to copy some or all of the required banks into the Ram disk before your program starts proper (on the title screen maybe) and load/delete each bank as necessary. The loading time during the program will be faster than a hard drive! You will have to watch memory very closely though.