Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bruceuncle]

SamuraiCrow:

Are you referring to the compiler only or the entire system?

The FLINE interrupt architecture is primarily of use to the compiler as it enables that 'cherry picking' of routines to include in the final executable.  That cuts down on executable size considerably.  The same method is used for the interpreted code and affects all AMOS architecture as all extensions have to use that method.  All the compiler does (sic) is put together the chunks of library code used by a program and add in optimisations etc.  Which begs the question, "If the libraries were traditional _LVO format, would the user be happy with 100k plus executable size for a one line AMOS Basic prog?"

The FLINE method was also recommended by Motorola as suitable for "extending the instruction vocabulary of the processor".  Which is fine as long as the interpretation overhead is not too costly.

SamuraiCrow:

using another extension format in AmosPro 3+

A speed improvement could be gained by re-writing AMOS Pro and the extensions.  I regard an AMOS Pro V3+ as "whatever the community decides it wants".  As long as a V2+ exists that supports the backward compatibility with the Easy and Creator versions and existing extensions.

I still maintain that AMOS was NOT intended as a solution to all requirements in its own right.  It's designed to have machine code embedded where performance is an issue.

For a quick comparison, try the performance difference between:

Print A$

in AMOS Basic and the assembler version:

<with A1 pointing to a null terminated string>
WiCall Print

Try adding in some of the AMOS-specific embedded print commands (e.g. $1B, 'X', $30+XCoord,$1B,'Y',$30+YCoord to position the cursor) and it flies compared to doing the same in AMOS Basic using Locate X,Y.

HungryHorace:

errr....  any news? at all?

At this rate, I'll have all the code "Resourced" before anything happens 

Looking over the 1.3 sources, is it just me or is amos.library conspicuous by its absence?  A vital piece of the jigsaw.  Anyway, as it's V1.3, I've already Resourced the V2.0 file and, because of the way it's structured, it's easy to add in the entry lables from the amos includes (the data area and library offsets seem to have remained unchanged for backward compatibility).  If anyone's interested (and you have Resource) I can post the *.RS files...  They're incomplete as my main purpose was understanding some of the AMOS Basic instruction behaviour for the docs.  But they are "interesting"  .

[SamuraiCrow]

Regarding linker libs vs. Amos' FLine interrupts, the way a linker works is that it takes a library made up of smaller object files and only adds the object files that are actually used by the code.  It shouldn't generate 100k executables for single lines of code.  If each subroutine were in a separate object file and a linker library generated from those object files, it would be very similar to the way that Amos only pulls in the subroutines used.  I'm trying to figure out which way would actually suit our purposes better.

Using a linker is usually preferred because the Make utility in C or Assembly can compare datestamps of object files and only update the ones needed when compiling.  Personally, though, I think we could do better.  I know that LLVM can do link-time optimization if the object files are LLVM's bitcode files.  GCC has a similar function in GCC 4.x .

[bruceuncle]

SamuraiCrow:

Regarding linker libs vs. Amos' FLine interrupts

Yes, the ideal would be a linker that recognises the FLINE interrupts and applies the appropriate relative relocations.  But that would mean writing a custom tool to do it (= new AMOS Compiler 3.x?).

I haven't looked at the V2.0 compiler in any detail yet as it's not in my scope (but very tempting to digress a little  ).  It may well be doing something like that already but I would speculate not (without a shred of supporting evidence) as it would have been easier to keep it within the existing interrupt architecture.  I may have a little peek next time I'm fed up with the test/document/test-and-find-hidden-stuff/re-document cycle of work.  It seems many times that when I've got something nailed down in the docs, I find something 'extra' that's not documented!

Recap:

• V2.x Only Realistic Option: Stages 1 and 2 as originally proposed with the deliverable being AMOS Pro V2.xx (= keep exisitng architecture, fix bugs, optimise as far as possible within existing architecture, document thoroughly).  No further development within that architecture excepting any necessary further bug fixes and Extensions.
• V3.x Option 1: After considering the cost versus benfits of changing that architecure, redevelop AMOS Pro with a completely different architecture.  Upside being a performance increase.  Downside being incompatibility with existing progs and extensions.
• V3.x Option 2: Retain existing architecture and leaving 'as is' for the interpreter.  Re-writing the compiler to act more as a sophisticated linker using that exisitng architecture (greenfield, but a lot more hard work).  Upside being full compatibility with existing progs and extensions.  Downside being that it would do nothing for the interpreter performance.
• V3.x Option3: Somewhere in between those two extremes.

There are certainly more options.  Heck, we're programmers!  So anything is do-able.  It's just a case of how much effort we're willing to expend on it  .

Let's keep speculating...

And when we get our grubby hands on the V2.0 sources, we'll know a lot more.  ("When".  I did say "When".  Any news yet?  Anybody?)

[bruceuncle]

Looking over the 1.3 sources, is it just me or is amos.library conspicuous by its absence?

It's in the AMOS 1.23 sources - W.S

A quick compare with V2.0 shows a few extra entry points.  More important to me is that I've finally got definitions of all the undocumented Print <Esc>+"xx" and Print <control code> actions used in AMOS Pro.  E.g. Did you know you can scroll a window just by embedding control codes? 

There's some very useful ones there plus some new ones added for V2.0.  I'll have to dig a bit deeper to find out what the new ones do (Chr$($1B)+"Jx" has me intrigued).

All these are used with Print Chr$($1B)+:
B, C, D, E, I, J, K, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z
All these are used as single control characters Chr$(n):
7, 8, 9, 10, 12, 13, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31

Happy now and back to update the docs.   

[Spellcoder]

errr....  any news? at all? 

I havn't heard from Pietro for a few weeks, last time I heard from him he said he was cleaning up the distribution to it's original state. I've been very busy the last few weeks with work and personal stuff and also don't want to push Pietro too much on finishing up the distribution. Just now I've email him again to ask about the progress.

[MadAngus]

Cheers for the update Spellcoder.

The theme for everyone here is patience.

[Spellcoder]

Thanks for being so patient! Pietro has finished up the distribution and will release the sourcecode during the Pianeta Amiga 2012 meeting (in Italy) which is held from 30 nov to 2 dec. So we'll only have to wait two more weeks, seems quite doable after all those year .

[bruceuncle]

Quote from Spellcoder:

Pietro has finished up the distribution and will release the sourcecode during the Pianeta Amiga 2012 meeting (in Italy) which is held from 30 nov to 2 dec.

Many thanks for the update.  The suspense has been unbearable .  That's a great result.  Very happy now  .

One of my earlier posts about Print control codes:

I'll have to dig a bit deeper to find out what the new ones do (Chr$($1B)+"Jx" has me intrigued).

Chr$($1B)+"J"+Chr$($30+BitMask) - switches individual bit-planes on or off as far as AMOS Print output is concerned.  BitMask represents the required state for each bit-plane - %1 is on, %0 is off.  Gives some very interesting results as, whilst a bit-plane is switched off, none of the window commands act on that bit-plane as they all pass through the same code in amiga.library.  Can't think of a practical use for it yet but it can be very pretty  .

Try this, one line at a time, from Direct mode with the output directed to the default screen:

Print "Some message or other"
Print Chr$($1B)+"J"+Chr$($30+%001);
Clw
Print Chr$($1B)+"J"+Chr$($30+%111);
Clw

See what I mean?

And a warning.  Chr$($1B)+"K1"  switches you into graphics character mode (block drawing symbols used for lines and borders, etc).  Very useful but has a bug.  It can't be switched off using Chr$($1B)+"K0" as that in itself will also be printed as graphics characters!  Two critical characters in this mode, Chr$($00) and Chr$($1B), are replaced by Chr$($9D) and Chr$($9E) to get around the problem of them clashing with 'end-of-string' and 'escape' respectively.  The problem is that they will never be interpreted as control codes in graphic character mode anyway.  They just keep printing as graphic characters!  Haven't found a way to turn it off yet...

AMOS Pro V3.x:

As far as AMOS Pro 3.x goes, I'm currently interested in any 'patched' versions of amiga.library for AMOS Pro V2 that are floating around out there.  So if anyone's got a verison of amiga.library that is higher than V2.0 or is supposed to have been patched, please post a copy.  Reason being that the patches are very visible as they had to be done in situ without the source being available.  (I use a file differencer in hex mode and they show up fine.)  So they represent some bug fixes that have already been attempted.  At the very least, they point to where problems may lie.

One more question for everyone to ponder (and hopefully post replies to  ).  I've previously asked what aspects of AGA do people want integrated into an AMOS Pro V3.x.  The extra colours?  The screen modes?  All of it?

This time I want to know "Is anyone interested in the Picasso96 additions?"  In other words, a windowed version of AMOS for that environment.  A whole different ball game but one that may be worthwhile.

And thanks again to Spellcoder for a great outcome.   

[bruceuncle]

And a warning.  Chr$($1B)+"K1"  switches you into graphics character mode (block drawing symbols used for lines and borders, etc). ... Haven't found a way to turn it off yet

As the AMOS Pro Includes offsets are still valid for AMOS Pro, this will turn it off:

Doke Leek(Leek(Areg(5)-$A0)+$AA)+$80,0

Which is the equivalent of this assembler:

* offset for current screen's structure address
T_EcCourant  equ     -$A0

* offset for current window's structure address
EcWindow     equ     $AA

* offset for graphic character mode flag ($0000 = Off, $0001 = On)
WiGraph      equ     $80
 

             move.l  (T_EcCourant,a5),a4
             move.l  (EcWindow,a4),a5
             move.w  #0,(WiGraph,a5)

The equates only shown for clarity.  These would normally come from the AMOS Includes files.

[MadAngus]

One more question for everyone to ponder (and hopefully post replies to  ).  I've previously asked what aspects of AGA do people want integrated into an AMOS Pro V3.x.  The extra colours?  The screen modes?  All of it?

This time I want to know "Is anyone interested in the Picasso96 additions?"  In other words, a windowed version of AMOS for that environment.  A whole different ball game but one that may be worthwhile.

All of it? Yes.

I would suggest that all AGA documentation be collated into a single archive and a detailed study of what the AGA chips capabilities and features are. this should be broken down into appropriate categories.

These categories/features etc. can then be reviewed here as to what should be implemented first.

Developers could do it blind but I wouldn't want to be the person who has to link it all into a library.

As for the Picasso96 additions, what can it do? What does it bring to the AMOS table? Need more details on this as well.

Bruceuncle asked about code module headers e.g.
(edited for space )
'*********************************************
'*    Interface Program Editor               * 
'*    For AMOS Pro V2.0                      *
'*    AMOS Factory                           *
'*    www.ultimateamiga.co.uk                *
'*    author: bruceuncle                     *
‘*      date: August 2012                    *
'*********************************************

Once I get back into my computer (doing a chkdsk at the moment) I'll post the module and function headers I use and set a minimum requirement.

I'll also set some basic coding standards. e.g. no hieroglyphic code you know the kind where every syntax shortcut known to man is used making it neigh on unreadable to the point of obfuscation.

[bruceuncle]

As for the Picasso96 additions, what can it do? What does it bring to the AMOS table? Need more details on this as well.

I'm no Amiga historian (my last contact was an A2000 before AGA, etc came along) so this may be wildly inaccurate  .  Having too much fun with AMOS to chase up the details - maybe someone else knows more inside info and how widespread its use is?

As far as I've seen, Picasso96 allowed the Amiga add-on graphics boards to be used to their full extent.  Hence the sort of resolutions you see in the AmigaSys and AmiKit systems.  It would mean a windowed version of AMOS to exploit it fully and I've no idea what it would do to sprites, bobs and the like.  The docs specifically state that programs using the Amiga libraries should be compatible - which AMOS definitely does not!  So presumably a complete re-write for the Picasso96 API would be needed.  Anyone know more?

Requires Kick 3.x, 68020, lots of memory and one of the supported cards (or a decent emulator  ).

Also have no idea what the copyright/licensing is for it.  It seems to be freely available.  Mine came with Amiga Forever and is used in their AmigaSys and AmiKit systems.

See http://amigate.8m.com/picasso96.html for some details.  Plenty more on the 'net - just Google away...

[MadAngus]

Picasso96 licensing.

Version 1.25 is AnyWare (http://aminet.net/package/driver/video/Picasso96_1.25)
AnyWare, i.e. not commercial or ShareWare. No distribution restrictions.

Version 2.00 is shareware (http://aminet.net/package/driver/video/Picasso96)
No distribution restrictions as long as the the archive is complete and none of the files within is changed. BBS notes may be added.

Specific permission is not given to distribute single files from v2.00 archives and integrate them into a separate package.

Picasso96 AMOS Support.
Yes I believe we should add it not just for emulation software, but for the hypothetical situation an RTG card is developed for the A1200 expansion slot.

For both AGA and Picasso96 I will initiate a document/data collation project. Will start this after Christmas, giving me a chance to get AMOS Manuals Phase 1 complete and AIAB relaunched.


For coding standards covering such things as prefixes and suffixes I'll need to dig out some industry standards and tweak them to this project and for the languages used:
For this sort of thing:
   e.g. Prefixes:
      m = Module level
      g = Global/Public

Yes I know lots of code will have to be re-factored but this will be necessary to ensure all developers can read each others code.

Also commenting of code is compulsory, as in many cases it will be quicker to re-right the code rather than attempting to decipher the authors algorithms.

This will not be one of those Open-Source projects that the only way to understand the code is for each developer to figure it out for themselves, seen too many projects fail because of this. From the code comments full developer/contributor documented will be written by myself, bruceuncle and/or any other volunteers.

Below I have provided some Module and Function Header guidelines (also provided as an attached text document):

Developers must provide the minimum headers although the full headers would be preferred for documentation purposes. Developers at their own discretion can provide headers at a level between the minimum and full version, albeit in the specified format.

Of particular note is the copyright and license these must be filled in otherwise the code will not be accepted. Please do not use the Public Domain moniker. At a minimum the license should be BSD two clause, no advertisement clause. I have attacked the OSI 'BSD two clause' and 'BSD two clause' templates if you wish to use these.

This will have to be tweaked for the language used whether it be C or assembler:

Module Header

Full Module Header
*-----------------------------------------------------------------------
*-- Module        : [Module File Name]
*-- Description   : [Primary purpose of the module]
*-- Copyright (C) : [Name of copyright holder]
*-- Author        : [Names of Programmers/Authors]
*-- License       : [Module License]
*-- Created       : [First Release Date]
*-- Last Modified : [Latest Revision Date]
*-- REVISION      : [Revision Number]
*-- Notes         : [General information/instructions for the programmer]
*--               :
*-- Written for   : [Name of target application]
*-- Rev. History  :
*--               : [Release Date] -- Original.
*--               : [Release Date][ -- ][Update summary]
*--               :              [ -- ][Update summary cont.]
*--               :
*-- Instantiation :
*--               :[Instruction/steps necessary to include/call this module]
*--               :
*-- Dependencies  :
*--               :[Required libraries/modules to compile/use this module]
*--               :
*-- Methods       :
*--               : [Method Name (args)]
*--               : - [Short Method Description]
*--               :
*-----------------------------------------------------------------------

Example Full Module Header
*-----------------------------------------------------------------------
*-- Module        : INITIALISEAPP.PRG
*-- Description   : Initialises the ExGames database
*-- Copyright (C) : Joe Gilmour
*-- Author        : Joe Gilmour
*-- License       : BSD
*-- Created       : 07/03/2002
*-- Last Modified : 17/04/2002
*-- REVISION      : Revision:  0.04
*-- Notes         :
*--               : Contains routines to:
*--               : Initialise all forms, array and objects on application startup.
*--               :
*--               :
*-- Written for   : dBASE for Windows 5.7
*-- Rev. History  :
*--               : 07/03/2002 -- Original.
*--               : 01/04/2002 -- Added arrays for initialising game review data.
*--               : 04/04/2002 -- Added arrays for initialising collectors notes data.
*--               : 17/04/2002 -- Optimized code, Used "NEW Array (rows, cols)" instead of
*--               :             using the grow method to set the size of arrays.
*--               :
*-- Instantiation :
*--               : set procedure to initialiseapp.prg additive
*--               :
*-- Dependencies  :
*--               : center.prg
*--               :
*-- Methods       :
*--               : Procedure FindGameName(SearchMethod, SearchGName)
*--               : - Check for a games existance
*--               :
*-----------------------------------------------------------------------

Minimum Module Header
*-----------------------------------------------------------------------
*-- Module        : [Module File Name]
*-- Description   : [Primary purpose of the module]
*-- Copyright (C) : [Name of copyright holder]
*-- Author        : [Programmer/Authors name]
*-- License       : [Module License]
*-- Created       : [First Release Date]
*-- Last Modified : [Latest Revision Date]
*-- REVISION      : [Revision Number]
*-----------------------------------------------------------------------

Example Minimum Module Header
*-----------------------------------------------------------------------
*-- Module        : INITIALISEAPP.PRG
*-- Description   : Initialises the ExGames database
*-- Copyright (C) : Joe Gilmour
*-- Author        : Joe Gilmour
*-- License       : BSD
*-- Created       : 07/03/2002
*-- Last Modified : 17/04/2002
*-- REVISION      : Revision:  0.04
*-----------------------------------------------------------------------


Function/Procedure Header

Full Function/Procedure Header
*-----------------------------------------------------------------------
*-- Function      : [Function Name]
*-- Description   : [Primary purpose of the module]
*-- Copyright (C) : [Name of copyright holder]
*-- Author        : [Names of Programmers/Authors]
*-- License       : [Module License]
*-- Created       : [First Release Date]
*-- Last Modified : [Latest Revision Date]
*-- REVISION      : [Revision Number]
*-- Notes         :
*--               : [General information/instructions for the programmer]
*--               :
*-- Written for   : [Name of target application]
*-- Rev. History  :
*--               : [Release Date] -- Original.
*--               : [Release Date][ -- ][Update summary]
*--               :              [ -- ][Update summary cont.]
*--               :
*--               :
*-- Calls         :
*--               : [Other modules/functions this function calls]
*--               :
*-- Called by     :
*--               : [Other modules/functions this function is called by]
*--               :
*-- Usage         :
*--               : [Instruction/steps necessary to include/call this function]
*--               :
*-- Returns       :
*--               : [Returned variable and type]
*--               : - [Short description of returned variable]
*--               :
*-- Parameters    :
*--               : [Parameters/Arguments used by this function]
*--               : - [Short description of parameter/argument]
*--               :
*-----------------------------------------------------------------------

Example Full Function/Procedure Header

Procedure UpdateGameSet(GameIDNum)
*-----------------------------------------------------------------------
*-- Function      : UpdateGameSet
*-- Description   : Saves an updated game entry to the database
*-- Copyright (C) : Joe Gilmour
*-- Author        : Joe Gilmour
*-- License       : BSD
*-- Created       : 10/03/2002
*-- Last Modified : 05/04/2002
*-- REVISION      : Revision:  5
*-- Notes         :
*--               : Saves an updated game entry to the database tables from data stored in the arrays.
*--               :
*-- Written for   : dBASE for Windows 5.7
*-- Rev. History  :
*--               : 11/03/2002 -- Original
*--               : 12/03/2002 -- Added arrays for initialising admin data.
*--               : 01/04/2002 -- Added arrays for updating game review data.
*--               : 05/04/2002 -- Added arrays & Code to update collectors notes data.
*--               : 23/04/2002 -- Split code into two procedures one for initialising the arrays and
*--               :             one for saving the array values to the database
*--               :
*-- Calls         :
*--               : None
*--               :
*-- Called by     :
*--               : Any
*--               :
*-- Usage         :
*--               : UpdateGameSet(GameIDNum)
*--               :
*-- Returns       :
*--               : None
*--               :
*-- Parameters    :
*--               : GameIDNum
*--               : - index number of the game to update
*--               :
*-----------------------------------------------------------------------

Minimum Function/Procedure Header
*-----------------------------------------------------------------------
*-- Function      : [Module File Name]
*-- Description   : [Primary purpose of the module]
*-- Copyright (C) : [Name of copyright holder]
*-- Author        : [Programmer/Authors name]
*-- Created       : [First Release Date]
*-- Last Modified : [Latest Revision Date]
*-- REVISION      : [Revision Number]
*-----------------------------------------------------------------------

Example Minimum Function/Procedure Header
*-----------------------------------------------------------------------
*-- Function      : UpdateGameSet
*-- Description   : Saves an updated game entry to the database
*-- Copyright (C) : Joe Gilmour
*-- Author        : Joe Gilmour
*-- Created       : 07/03/2002
*-- Last Modified : 17/04/2002
*-- REVISION      : Revision:  0.04
*-----------------------------------------------------------------------

[SamuraiCrow]

Picasso96 AMOS Support.
Yes I believe we should add it not just for emulation software, but for the hypothetical situation an RTG card is developed for the A1200 expansion slot.

For both AGA and Picasso96 I will initiate a document/data collation project. Will start this after Christmas, giving me a chance to get AMOS Manuals Phase 1 complete and AIAB relaunched.

I disagree.  Picasso96 patches the OS in such a way that certain very valuable routines such as the WaitTOF function in Graphics.library do not function correctly.

Also, if P96 support is added in about AmosPro 4 or 5, I'd suggest that it be limited to the Cybergraphx 3.0 subset that P96 supports internally.  That way it will be easier to maintain compatibility with the open-source graphics card routines in AROS 68k (known as Cybergraphics.library, spelled non-phoenetically).

Keep in mind also, that P96 is currently owned by Hyperion Entertainment and the latest versions are only available for OS 4.x on PPC.  Likewise the Cybergraphx 4.x routines are owned and distributed by the MorphOS team.

Graphics card support is a hairy issue.  Especially since PC-style graphics cards are not even remotely equivalent to Amiga chipset functionality.  They left 2D acceleration behind in favor of 3D acceleration.

Even when it was plainly evident that the Mattathias project was too big, one of the main issues was that emulation of Amiga graphics chips using shaders was too difficult.  That means for most purposes, graphics card support and Amiga chipset support are an either-or proposition.  I'd rather hold out hope that there will be a new FPGA-based chipset that bridges the gap between AGA and graphics cards.

[bruceuncle]

Picasso96 AMOS Support.
Yes I believe we should add it not just for emulation software, but for the hypothetical situation an RTG card is developed for the A1200 expansion slot.

For both AGA and Picasso96 I will initiate a document/data collation project. Will start this after Christmas, giving me a chance to get AMOS Manuals Phase 1 complete and AIAB relaunched.

I disagree.  Picasso96 patches the OS in such a way that certain very valuable routines such as the WaitTOF function in Graphics.library do not function correctly.

Yeah.  The more details I see on Picasso96, the more I'm inclined to agree with your disagreement.

I also want to be sure we don't lose sight of what AMOS Pro 3.x is all about (to me anyway ).  AMOS worked and is popular because it made the 'original' Amigas accessible to many more people than was possible with other programming languages (Blitz probably excepted, but I've never used it).  Anything that departs too far from that base is not AMOS any more.  So, I can see worthwhile improvements in developing further within those boundaries.  But it does not make sense to me to try bending it to environments that diverge too far from the 'original'.

I think you may end up with an Amiga Emulator for an Amiga running something like Picasso96! 

AMOS relies heavily on direct access to an Amiga's hardware.  So 'adapting' to alternative Amiga hardware and operating systems or add-ons would be a nightmare!  (It also uses self-modifying code  which may play havoc with a 680xx with an instruction cache!  But that's just one of those things to be fixed...)

The point is probably not worth much discussion at this stage.  Just getting AMOS Pro V2.0 upgraded to V2.x to fix bugs and optimise is going to be a large chunk of work (to put it mildly).  So I don't think we'll be discussing AMOS Pro V3.x in any determined way until after that.

For coding standards covering such things as prefixes and suffixes I'll need to dig out some industry standards and tweak them to this project and for the languages used:
For this sort of thing:
   e.g. Prefixes:
      m = Module level
      g = Global/Public

Yes I know lots of code will have to be re-factored but this will be necessary to ensure all developers can read each others code.

Also commenting of code is compulsory, as in many cases it will be quicker to re-right the code rather than attempting to decipher the authors algorithms.

Great stuff for C and ASM.  No problems with space in those environments for copiously commenting the code.

But AMOS is an altogether different environment.  There's a need with large programs for a 'comment culler' to cut the size down.  So you end up with two copies - one commented, the other uncommented.   This would be a very different case if the AMOS Compiler worked reliably!  But we'll fix that won't we?

I've suggested some standard in the introduction for the AMOS Reference Manual.  This is an extract of the Variables topic where I make some suggestions with the reasons why:

Variables

AMOS Basic Variables must follow these rules:

• Variable Names must begin with a letter.
• The only characters that can be used in a Variable Name are upper-case letters, numbers and the underscore (_).  A single character suffix of # or $ is allowed and denotes the variable's type.
• A Variable Name with no suffix is an Integer type.
• A Variable Name with a # suffix is an Single- or Double-Precision type.
• A Variable Name with $ suffix is a String type.
• The maximum length for a Variable Name is 255 characters.
• A Variable Name must not begin with the characters from an AMOS Keyword.  E.g. PRINTER_NAME is illegal as it starts with the AMOS Basic Instruction Print.

Note that there is no requirement to define a Variable before it is used (the Dim statement used in other Basic dialects has a completely different meaning).  So, in long programs it is very easy to mis-type a Variable Name without the mistake being picked up when the program, is checked.
As AMOS Basic can use both Global and Local Variables, it is strongly recommended that some Naming Convention is used, especially for long programs.  Otherwise, it can be difficult to keep track of the scope of each Variable.
Using a prefix convention is especially useful as it avoids any problems with Variable Names beginning with AMOS Basic Keywords.  Note that any Extensions added after a program has been written may give problems as it will add a whole new set of Keywords.  Some of these may clash with previously legal names unless a prefix convention has been used.

Suggested Naming Convention
The Naming Convention show below is just a suggestion as to what may be appropriate:

G_	A Variable with Global (or Shared) Scope.
L_	A Variable with Local Scope.
P_	A Parameter for a Procedure (used in the Procedure's definition).
F	Used in conjunction with any of the above, a Boolean or Flag Variable that only has values of True or False.  E.g.  PF_ would denote a Boolean Parameter.
C	Used in conjunction with any of the above, a Constant.  AMOS Basic has no constant declaration statement as used in some other dialects of Basic.  However it is sometimes useful to use a Variable to do the job of a Constant.  E.g.  GC_MAX_LENGTH=30 might be used so that all code using that value (30) uses the Variable Name GC_MAX_LENGTH instead.  The code is easier to read and, if the value of 30 is changed later in development, it only needs to be changed in one place.

For Procedures and Labels the same naming rules apply.  And there is the same problem of avoiding Procedure Names that begin with an AMOS Basic Keyword.  Using an underscore (_) as a prefix to all Procedure and Label Names avoids this.
Some examples:

     Rem Examples of a Naming Convention
     Rem This is NOT a program - don't try to run it!
     Global G_HIGH_SCORE
     G_HIGH_SCORE=0
     '
     Global GF_SHIELD_ON
     GF_SHIELD_ON=False
     '
     Global GC_MAX_ALIENS
     GC_MAX_ALIENS=15
     '
     Procedure _DO_INVENTORY[PF_INCLUDE_SPELLS]
     '
     If X>GC_MAX_X Then Inc DX:Dec X

Having just written (still am) a long, long AMOS Basic program, the above rules have made it a lot easier to keep track of what's being used and where.  The point about no variable declaration and checking is very important.  Without careful docs and partitioning, the whole thing can become a nightmare of spaghetti code.

I'll have some software ready for release this side of Xmas.  So see what you think of the sources.

[MadAngus]

Also, if P96 support is added in about AmosPro 4 or 5, I'd suggest that it be limited to the Cybergraphx 3.0 subset that P96 supports internally.  That way it will be easier to maintain compatibility with the open-source graphics card routines in AROS 68k (known as Cybergraphics.library, spelled non-phoenetically).

Maintenance and compatibility always win the day. Added to the licensing issues (Hyperion, MorphOS ) SamuraiCrow's recommendations would be the more practical approach.

In fact I would recommend that support be restricted to AROS 68k Cybergraphics.library if possible/feasible. The less reliance on closed sourced environments the better.
Task: Discussion topic for the experienced developers (i.e. not me ).

As for the version 2.x development I still want an AGA extension so AGA research will be my focus for 2.x. I already have a collection of AGA reference material to start the AGA data collation task.
Task: Initiate an AGA document/data collation project.

comment culler: It is quite likely that something along those lines has already been written.
Task: search pd disks and other resources for such a utility.

*.amos editor: An amiga code editor utility/plugin to convert *.amos files to text files and vice-versa.
Task: Dig out the *.amos file format spec if I've got it and determine feasibility.

Task: (MadAngus) Improve discussion area. Create an AMOS 3.x child board and separate feature threads for discussion each potential feature.