Print

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

[MadAngus]

Discussion and speculation thread for AGA Support in the ClassicAMOS project.

Once a clearer picture and some definitive decisions are made by the developers AGA project milestones can be added to the 'AGA Development project' thread.

[MadAngus]

Snippet by MadAngus:

AGA support and other features:
AGA support, who doesn't want it!

However, to attempt to begin implementing AGA enhancements too early in the development cycle may lead to problems fixing old code while new code is being injected. Such as changes to original core code to allow integration of the new AGA code whilst trying to fix an old bug that related to that original core code.

As has been said, trying to dictate what people work on during the course of the development is absolutely out of the question for this project, there will be none of the "We know best" or "we won't implement that because we don't want to work on it/agree with it/like it" attitudes in this project.

So how to accommodate the desires for AGA support and other features (Including optimised code)?

We have been provided with the solution to that problem, Extensions thank you Francois.

This would allow anyone who wishes to develop alternative optimised code or features and role them into an extension (or even an alternative AMOSPro), and at a later date and if feasible role them into the core code. So if anyone decides to work on other things outside of this projects boundaries, know that you will be welcome to submit your work for integration at some point, it would also be appreciated if you would submit your work.

With all documentation being made available to everyone, your projects could follow an inline development process, i.e. as new fixes are applied to the core code you could in turn test your code against the changes. Would make implementation at a later date simpler.

[MadAngus]

Snippet by bruceuncle:

But the point MadAngus made is very pertinent:

We have been provided with the solution to that problem, Extensions thank you Francois.

All the more reason to maintain a stable core for the product.  While we're doing Stage 1 and Stage 2, we don't want to do anything to upset any parallel development going on in Extensions.  People can then have confidence that their own efforts will be stable and useable in the future.  (Preferably without having to re-compile against a changed set of system equates ).

[MadAngus]

Snippet by 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?

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.

[MadAngus]

Snippet by Hungry Horace:

C- Any AGA support for AMOS would benefit from a new AGA expansion of TOME.


I dont' know about anyone else, but I know what functions of AGA I would like to see (since it was asked before).....

- AGA screen modes, up to 256 colours, as a direct swap for the existing (i.e. 'normal' screen modes)
- AGA screen modes to support similar 'neat' functions of AMOS such as FADE etc. plus basic commands like LOAD IFF
- AGA Hardware Sprite adaptions, to allow the additional numbers /sizes etc that the AGA Chipset allows
- AGA Software Bob adaptions, maybe to include optimisations which would improve ECS/OCS Bob performance

[MadAngus]

Snippet by SamuraiCrow:

• Easy AMOS Tutor : ported to an AMOS Evolution Extension.

i am glad to see this in the discussion - obviously consideration must be given to the fact that
A- TOME is an excellent addition to AMOS
B- There are existing limitations (max. no. of tiles limit, minimum tile size limit) which I expect people would like to see expanded
C- Any AGA support for AMOS would benefit from a new AGA expansion of TOME.


I dont' know about anyone else, but I know what functions of AGA I would like to see (since it was asked before).....

- AGA screen modes, up to 256 colours, as a direct swap for the existing (i.e. 'normal' screen modes)
- AGA screen modes to support similar 'neat' functions of AMOS such as FADE etc. plus basic commands like LOAD IFF
- AGA Hardware Sprite adaptions, to allow the additional numbers /sizes etc that the AGA Chipset allows
- AGA Software Bob adaptions, maybe to include optimisations which would improve ECS/OCS Bob performance

Adding to this, the full 24 or even 25 bit (one for genlock transparency) palette operations would be a good addition to AmosPro's AGA support.

Here's a thought:  Do we want datatype-based image loader support?  That would bump the requirements for running the software from Workbench 1.3 to 3.0 or better or AROS 68k.  The reason I'm asking is that libPNG supports 8-bit images but offers better compression than IFF.  Also, AROS uses PNG images for icons.

[MadAngus]

Snippet by MadAngus:

AGA
Thanks Hungry Horace and SamuraiCrow, that gives some focus to the development of the AGA extension. Any developer can start writing some experimental/test code based on those requests if they feel the need to dabble.
(Note: preferred license is BSD (BSD templates Here), Apache 2.0 if you want copyleft)

I personally have no issues with bumping the requirements to Workbench 3.0 for the AGA extension.

[MadAngus]

Snippet by bruceuncle:

Many thanks for all the input guys. 

These comments apply to Classic AMOS:

Regard this as 'thinking out loud'.

From what I've read (repeat, read, not actually dabbled in yet  ) integrating everything AGA except the productivity resolutions and the more extreme 'other' resolutions should be relatively straightforward.  (Does anyone actually use 1280x256/200 et al?).

As soon as we talk about resolutions other than 640x256/200 the problems begin to stack up.  We would need to define what we mean by a 'windowed editor'.  As I see it there are two alternatives:

• AMOS Editor, etc. as a fixed-size 640x256 floating window.  Looks reasonably straightforward.
• AMOS Editor, etc. as a resizable floating window.  Not so simple.  The Editor code is heavily coupled to its fixed size.  May require a complete rewrite.

Which then begs the question "What would we want for AMOS output?"  That is, should a program output to a floating window (i.e. not AMOS's current concept of a window) or full screen at the programmer's whim?  Yeah, yeah.  I know the answer's "Yes to all of it!" but try to think of consequences at the AMOS Basic Language level - the instructions required and their ease of use.

One option:

The AMOS architecture suggests a rewrite of amos.library to enable all these features as it's mainly that library that interfaces directly to the hardware.   If it was a fully decoupled system (more like an OO system) that would be the only change needed.  (Not quite a true statement as I've yet to meet an OO system that does not make some assumptions about other objects. )

It would not realistically be practical to move AMOS architecture to an OO model (feasible, but not practical if we want results sooner rather than much, much later  ) .  However it may suit the current architecture to incorporate AGA into amos.library rather than as an extension.  This would give maximum flexibility to the programmers of extensions and would help decouple AGA spcifics from the core AMOSPro_xxx.Lib files.  The AMOSPro.Lib file would be rewritten to choose whether AGA is appropriate for the specific existing AMOS Basic screen, window, graphics, text, sprite and bob instructions that would be affected (most of them  ).  Not that that choice would automatically allow any instruction, any time.  It should politely decline inappropriate usage with an error as usual.  But also transparently adjust parameter requirements. 

As an example, on an ECS system, something like Screen Open 1,640,256,256,Hires should give a meaningful error whilst being allowed if the system is AGA.

If the main implementation is in amos.library, I would expect that the resulting AMOS Basic AGA instruction set would include:

• Querying the environment to ascertain chipset, etc.  I.e. Get device capabilities.
• All the rest of the AGA instructions.  Up to the programmer to do the right thing and get the capabilities of the system before using AGA.

There's also the possibility of using the launcher (AMOSPro) to query the capabilites and limit the language accordingly.

Another option:

Same as for the option above, the main implementation to go into amos.library.  But the AMOS Basic Language implementation is put into an Extension.  For discussion, I'll christen this AMOSPro_AGA.Lib.

This would remove the burden on the programmer to query the environment - that would be the domain of the extension.  The necessary code for AGA would still lie within amos.library but would be dormant unless the AGA extension invokes it.  The assumption being that the programmer is using the AGA extension because they are targetting that specific environment.  Therefore they know what they want and how to get it.  The extension should elegantly decline AGA instruction usage in a non-AGA environment.

The big disadvantage with this approach is that AMOS Basic instructions that already exist, but would be affected by the capabilities of an AGA environment, would need to be repeated in the extension.  For example Fade (implemented in AMOSPro.lib) and Aga Fade (implemented in AMOSPro_AGA.Lib).

Maybe a hybrid of the first option and the second would be preferable?  That is, existing AMOS Basic instructions re-implemented to suit AGA in AMOSPro.lib and AGA specific instructions (ones that don't currently exist) implemented in AMOSPro_AGA.Lib.

As you've probably gathered by now, I'm pretty well convinced that the success of AMOS Pro V2.x will depend on the AMOS Basic Language perspective.    In any case, food for thought...

[MadAngus]

Snippet by MadAngus:

AGA amos.library/extension
Would it be better to keep AGA as an extension for initial development and bug tracking thus decoupling it from the ClassicAMOS clean up. Then integrate as part of 'Stage4: AMOS Pro V3.0'.
Developers please discuss and decide on this and bruceuncles optional development tracks (previous post).

[MadAngus]

Snippet by SamuraiCrow:

Ummm... floating windows are asking for punishment.  Methinks that palette collisions and color cycling will prevent us from making it a floating window.  The resizable floating windows will require that we get the graphics card support done first since graphics cards don't use palettes at all.  It would be nice to have a flippable screen that lets you click in the upper-right corner instead of hitting left-Amiga a to get back to it.

OO should be left to other programming languages.  If I wanted it object-oriented, I'd be using AmigaE or PortablE instead of AmosPro.  Besides, the new extension format in Amos Evolution can be made more flexibly than the old one.

Do we really want to make AGA support an extension?  We could adapt the token table to list the old commands as Old_Fade for the ECS/OCS palette entries and then use the Fade command with long integers as palette entries as the default.  Converting from the old format to the new one is as simple as multiplying the red, green, and blue values by 17 so that they proportionately scale from 0 to 255 instead of 0 to 15.  (17=$11 thus converting the 4-bit nybbles into 8-bit bytes without errors in color. Eg. $47C will become $4477CC.)  Of course, AOS 3.x goes totally overboard by using 96-bits of palette entries in the new ROM versions when 24 bits will do.

[MadAngus]

Snippet by bruceuncle:

Do we really want to make AGA support an extension?

Probably not.  To be more specific, AMOSPro.Lib could quite happily encapsulate both the existing and the new instructions for AGA support.  There's no need to deprecate instructions as long as the system capabilities are automatically determined by the AMOSPro launcher (to setup the appropriate Editor and Monitor format) and by AMOSPro.Lib (to transparently switch any affected 'old' instructions between AGA and non-AGA).  The tasks for each then become something like:

For AMOSPro:

• Query system capabilities and store in suitable additions to the AMOS data area (a5).
• Launch the Editor in a format appropriate to the capabilities.
• Assume that the Editor then has full knowledge of its environment from the AMOS data area (a5).
• Assume the same for the Monitor when the Editor launches it.

For AMOSPro.Lib:

• Assume that AMOSPro.Lib has full knowledge of its environment from the additions to the AMOS data area (a5).
• AMOSPro.Lib should take full advantage of this info in its initialisation code.  E.g. rearranging any of its own data to suit the environment.  This could range from simple 'adjustments to constants' through to possibly switching parameter definitions in the token table.
• For each AGA-affected existing AMOS Basic instruction, the 'old' ones, action it according to the current environment (including parameter variations and limits).
• For each new AGA AMOS Basic instruction, according to the current environment either action it or forbid it.
• The token table should be able to accomodate these requirements without too much trouble.  Problems would arise if Instruction Numbers were changed though.  Calls from other libraries and extensions expect these to be constant.

It would also be preferable to delegate all actual hardware access to amos.library in order to fully decouple AMOSPro.Lib from the hardware.  The reponsibilities being:

amos.library:

• All hardware access according to environment.
• The existing library entry points for System, Screen and Window would have to remain unchanged for compatibility with extensions.  They would, however, be environment aware and act accordingly.
• New entry points added as appropriate for environment functions amd any AGA-only functionality.

The level of abstraction provided by the existing amos.library functions already appears to be appropriate.

AMOSPro.Lib:

• Token lookup and interpretation only.
• No direct hardware access, all requirements to be met by amos.library.

The above is preferable as an objective.  But only as long as ity doesn't impact performance to any great degree.

[MadAngus]

And finally an actual post be mesome.

Now that you have re-read all that could you now go back and and re-read the second and third post. Are you sure you don't want to start with an AGA extension first?

[MadAngus]

Post here any links and resources that could be used for developing AGA support into AMOS.

Thought I had more than this, apparently not, I may have deleted stuff during my recent file clearout, oops!

Links:
Mysterious Ways - How to Code the Amiga - AGA Chipset
www.amiga-stuff.com General chip info
Action's Guide to AGA-Fixing!

Amiga AAA chipset
This article from amigahistory.co.uk gives a clear breakdown of the differences between the AAA (Advanced Amiga Architecture) chipset and the AA chipset (renamed to AGA).
So if you come across documentation and your not sure if it relates to AAA or AGA then this will help.

A guide to Guru Meditation Error Codes
You are definitely going to need this.


Files:
68k and AGA registers references & The Source-diskmagazine.rar (Attached)
Includes:
Specification for the Advanced Amiga (AA) Chip Set (aga2.lha)
Programming AGA hardware - lot of techy stuff here (aga.lha)
And other stuff, can't exactly remember where I got these files from.

agaguide.zip (Attached)
This is the "Aga guide", written by TFA. It explains all the new features of the AGA chip compared to ECS/OCS, and how to use them.

AA-Lisa-Specification (ENG).pdf (Attached)

The following specification docs are (I believe) available on the EAB server. If I find the location I'll add a link. They are large downloads as they are image scans 60-200MB per file.
Specifications_AA_png
Specifications_AGNUS_NTSC
Specifications_AGNUS_png
Specifications_CIA_png
Specifications_DENISE
Specifications_GAYLE_png
Specifications_LISA_png

[bruceuncle]

Now that you have re-read all that could you now go back and and re-read the second and third post. Are you sure you don't want to start with an AGA extension first?

I have thought long and hard about this.  I put myself in the position of the average AMOS programmer and asked: "What would I want to see out of all this techo stuff they're waffling on about?"  It's probably easier to answer the negative side of that question: "What wouldn't I like to see?!"

• I wouldn't want to have to do anything to existing programs - they should run and compile just like they always did.
• I wouldn't want to have to learn too-large a set of new instructions just to use AGA capabilities.  Especially where those instructions are effectively duplicates of existing ones but have different parameter limits.  I mentioned this previously in the AGA Extension alternative:

  The big disadvantage with this approach is that AMOS Basic instructions that already exist, but would be affected by the capabilities of an AGA environment, would need to be repeated in the extension.  For example Fade (implemented in AMOSPro.lib) and Aga Fade (implemented in AMOSPro_AGA.Lib).

  I would just want to use Fade.  So no deprecated instructions and only AGA-specific instructions where absolutely necessary.
  
• If I program extensions or use machine code routines embedded in AMOS, I don't want to have to recompile against new equates files for it to still work.  This one's harder to implement as existing equates and offsets would need to be retained (including the current limitations, but read on) for this to work.  New stuff would have to be added to extend, but not replace, the existing equates and offsets.  And duplicate some data where AGA lifts those limits - the data residing in both the existing, unchanged, set and the new AGA set.

These thoughts incline me heavily towards the 'all in one' approach of not using an extension.

I think there is also a substantial programming advantage in doing all the hard work in the core libraries:  amos.library and AMOSPro.Lib.  It would be easier to manage the development as the tight coupling imposed by fully optimised assembler programming is in one of two places:  The hardware access implemented in amos.library and the instructions implemented in AMOSPro.Lib.  I may be fooling myself.  It's more a gut feeling.  But I've learnt to trust those over the years. 

All the above is purposely pitched at a high level.  I'm well aware that AMOS has a few peculiarities that we could discuss ad infinitum.  But my aim here is to get the goalposts firmly defined rather than worry about the details of how the actual code will implement those ideals.  At the machine-code level, there's always a way to implement stuff - a bit like the ultimate Lego set really.     The only constraints for implementing an idea at the machine-code level are complexity, performance and size.

There's always the alternative of the hybrid approach if the above is too daunting:

That is, existing AMOS Basic instructions re-implemented to suit AGA in AMOSPro.lib and AGA specific instructions (ones that don't currently exist) implemented in AMOSPro_AGA.Lib.

But I suspect that that would only result in an extension which we may prefer to slip into AMOSPro.Lib anyway (ok, ok - my prejudices are showing again ).

[bruceuncle]

Many thanks MadAngus.  I hadn't got anywhere near as many.