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...
I've attatched a PDF of the AMOS Pro V2.0 Architecture. This is very much a work-in-progress and possibly highly inaccurate in places! Please consider it as a starting point for mapping out the plans for the V2.x and 3.x. And please, please do not hesitate to correct any omissions and rubbish assumptions. I'm expecting to expand the detail down to the code level in easy stages. But I want to get these high-level views as accurate as possible first.
AMOS TOME
The TOME resourcing/reverse engineering project is open to anyone interested.
I'm interested. I'm getting really quite attatched to Resource now I've worked out how to make and incorporate custom symbols files. If anyone else is using Resource, I've made symbols files for AMOS screen functions, the screen structure, window functions and the window structure. I can make these, and any others I put together, available to anyone interested. Just send me a PM.
Author
Topic: AMOSPro re-development general speculation (Read 67439 times)