Ultimate Amiga

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 3 4 [5] 6   Go Down

Author Topic: AMOSPro re-development general speculation  (Read 22071 times)

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Posts: 425
  • WINUAE Amiga User
Re: AMOSPro re-development general speculation
« Reply #60 on: November 26, 2012, 06:16:57 PM »

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 :P).

That would be the sensible route to take.  It still strikes me as ending up with a 'not AMOS' product though.   :'(

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

I've asked before what features people want for an AGA AMOS.  And I suppose the reply "All of it!" is fair enough. :)  A separate collation thread for info would be great.  I've already got some stuff on AGA that covers chipset detection, bit-planes and the colour register usage.  But nothing all that meaningful on the 'productivity' modes for Multisync output (640 x 480, 800 x 600 and 1024 x 768).

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

Don't bother - already done it using the editor sub-language in AMOS  ;).  I needed the routines to allow for comments in the DBL editor. 

The DBL editor loads, saves and converts between:
  • DBL format (+ DBL comments)
  • ASC format for AMOS Merge (+ AMOS Basic comments - hence the comment detector routines)
  • Compacted format directly into and out of a Resource Bank (unintelligible and no comments!)
It needed the DBL 'comments' feature in the editor to ensure people document their code fully (same songbook MadAngus  ;)).

Quote
*.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.

The AMOS editor already does all this!  MadAngus - time to get your hands dirty in AMOS ;).

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

Good idea as long as it doesn't get too  fragmented.  Suggest two broad main categories to draw a firm line between them:
  • AMOS Pro 2.x (defined as original AMOS fixed + AGA support with possibly windowed editor for productivity modes)
  • AMOS Pro 3.x (defined as AMOS fixed + AMOS windowed editor using Picasso96 + possibly 'not AMOS' any more  :'()
« Last Edit: December 08, 2012, 10:42:45 AM by MadAngus »
Logged
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

MadAngus

  • There is no spoon.
  • Site Admin
  • A500
  • ****
  • Karma: 5
  • Offline Offline
  • Posts: 497
  • AMOS Docs / AIAB Dev
    • AIAB (Amiga In A Box)
Re: AMOSPro re-development general speculation
« Reply #61 on: November 27, 2012, 08:51:48 AM »

Quote
It still strikes me as ending up with a 'not AMOS' product though.
AMOS Pro 3.x -> 'not AMOS' any more.
Sorry folks but I don't see how it can be possible to keep any new AMOS in a way that maintains how everyone feels about Classic Amos. Change the interface and immediately you change the way it looks and feels. Change the compiler architecture and your into a whole new world of differences.

Future versions will inevitably move away from what AMOS is. However there is processes that can be used to alleviate that.

That is, fork the development into two streams ClassicAMOS and NewAMOS. Any features implemented into NewAMOS that fits with 'The AMOS we all know and love' can be down-streamed and incorporated into ClassicAMOS.

If a NewAMOS feature would result in ClassicAMOS equating to "It's not AMOS Jim... I-Just-canny-do-it", then don't downstream the feature.

This would require that two product names and version streams are used for development.

Product names:
ClassicAmos and AMOS 3.x (examples only)

Versioning:
For ClassicAmos we would follow bruceuncles versioning recommendations (see the first post and here). This must remain Old-Sytle with only appropriate features implemented and/or down-streamed from AMOS 3.x.
  • AGA support
  • Running in a workbench window, just that, no other change to the interface.

For AMOS 3.x we fork after ClassicAmos V3.0 and start at 0.x
At this point the differences would become apparent and inevitable, with no restriction on the features implemented.
  • A skinnable interface could be implemented with an optional classic theme giving the style and look of ClassicAMOS which would go some way towards keeping the feel of classic AMOS.
  • Cybergraphics extension.
  • in-line assembly source
  • in-line c source
  • Easy AMOS Tutor : ported to an AMOS 3.x Extension.
  • TOME Extension: Reverse engineered for use in AMOS 3.x.
  • Optimized architecture
    • register based/stack based
    • Better Procedure vs. GOSUB
    • Supplant extension commands when extention not available QRAND/RND.
    • More from this post -> Here
    • More will be available from the code review

bruceuncle you are right in one of your posts comments, I need to get all this centralised, looks like i'll be busy over the Christmas holiday's.


More on Cybergraphics support. 'not AMOS' any more. (cont.)

If a feature is perceived to not fit into the core environment and/or should not be part of the core then it can be developed as an extension.

Let's consider the reality. The majority Amiga is the A1200 in which Cybergraphics support is of little use. A hypothetical trapdoor RTG card is not justification for support. That leaves us with UAE's and the question of Cybergraphics support in these, will it work out of the box?

Considering this Cybergraphics support should be developed as an extension with a graphics switch coded into the core OCS/ECS/AGA/Cybergraphics.

Is there at all any feasibility of supporting Indivision capabilities, or is that just pie in the sky.

-----------------------------------------------------

Final Note: AGA
Ag-a-doo-doo-doo, push pixel, shake the screen
Ag-a-doo-doo-doo, push pixel, grind an enemy
To the left, to the right, jump up and down grap the power up.
Blah, blah, I know it doesn't rhyme. :P

Anyway, the point is regardless of what cometh in future AMOS versions, AGA is the most sought after feature. As such:

Developers:
Need to declare their priority

Working on an AGA extension.
or
Source review and bug fixing.
Stage2: AMOS Pro V2.1 with bugs fixed and updated docs.  Nothing changed by way of additional functionality.  This is the stable base to build the next stage upon.

Documenters:
A list of known AMOS bugs and a compendium of AGA data is needed as the top priority, preferably before or shortly after the source is released.

Bruceuncle can you ratify this 'Final Note', Yes/No.
« Last Edit: December 08, 2012, 10:43:08 AM by MadAngus »
Logged
My shadow says otherwise.

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Posts: 425
  • WINUAE Amiga User
Re: AMOSPro re-development general speculation
« Reply #62 on: November 27, 2012, 09:49:45 AM »

Quote
Bruceuncle can you ratify this 'Final Note', Yes/No

Having to type this on my'phone due to severe thunderstorms.  Everything wired in the house is disconnected.

Give me a desktop any day. ::)

Very much agree with your post MadAngus.  And the moniker "Classic  AMOS" fits well with other Amiga titles.

It's the heavy tie-in to Amiga hardware that makes AMOS what it is.  Extending into other hardware or alternative libraries breaks that tie-in.
Logged
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

MadAngus

  • There is no spoon.
  • Site Admin
  • A500
  • ****
  • Karma: 5
  • Offline Offline
  • Posts: 497
  • AMOS Docs / AIAB Dev
    • AIAB (Amiga In A Box)
Re: AMOSPro re-development general speculation
« Reply #63 on: November 27, 2012, 11:06:36 AM »

Just to be clear the AMOS 3.x fork I'm proposing is targeted at the Amiga OS and Hardware not any other architecture.
« Last Edit: December 08, 2012, 10:43:26 AM by MadAngus »
Logged
My shadow says otherwise.

Hungry Horace

  • Amorphous Blue-Blob Man
  • Site Admin
  • A4000T
  • ******
  • Karma: 305
  • Offline Offline
  • Posts: 3,283
  • Don't forget... Ameboid's need love too!
    • Amiga Online
Re: AMOSPro re-development general speculation
« Reply #64 on: November 27, 2012, 08:33:08 PM »

  • Easy AMOS Tutor : ported to an AMOS 3.x 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
« Last Edit: December 08, 2012, 10:43:41 AM by MadAngus »
Logged
Quote from: KillerGorilla
because winuae is made of code and your amiga is made of stuff

Hungry Horace's Artwork Available
Buy my work

http://twitter.com/horaceandspider

SamuraiCrow

  • compile-time wierdo
  • Forum Mod
  • A1200
  • *****
  • Karma: 3
  • Offline Offline
  • Posts: 839
  • Compile-time wierdo
Re: AMOSPro re-development general speculation
« Reply #65 on: November 27, 2012, 08:43:39 PM »

  • Easy AMOS Tutor : ported to an AMOS 3.x 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.
« Last Edit: December 08, 2012, 10:44:57 AM by MadAngus »
Logged

MadAngus

  • There is no spoon.
  • Site Admin
  • A500
  • ****
  • Karma: 5
  • Offline Offline
  • Posts: 497
  • AMOS Docs / AIAB Dev
    • AIAB (Amiga In A Box)
Re: AMOSPro re-development general speculation
« Reply #66 on: November 27, 2012, 09:23:18 PM »

The term ClassicAMOS = Classic AMOS Professional

Actually "Easy AMOS Tutor" should say:

Easy AMOS Tutor : ported to a ClassicAMOS Extension and an AMOS 3.x Extension.
This is the project I will be working on as a goal for my assembler education.


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.


AMOS TOME
The TOME resourcing/reverse engineering project is open to anyone interested.

Copyright of any code through resourcing/reverse engineering remains with Aaron Fothergill. Apache 2.0 license I think would be best for this. I'm sure there will be a comment or two on this.

Here is the email request, includes reverse engineering request, sent to Aaron Fothergill and his response. So legally we know were we stand.

Quote
Hi Joseph,

Thanks for contacting me, glad to see there's still AMOS activity out there :)

Feel free to use the TOME manuals and software as well as the AMOS club newsletters.

Aaron


On 21 Aug 2012, at 10:09, Joseph Gilmour <<removed>> wrote:

> <div id="menuspacer"> &nbsp </div>Your Name: Joseph Gilmour
>
> Your Email:<removed>
>
> Subject: AMOS TOME
>
> Message: Hi,
>
> Hope I have the correct person. I have been informed that you may be Aaron Fothergill the Author of the AMOS TOME extension, if not please inform me of this and accept my apologies for the mistake.
>
> There are a couple of projects aimed at bringing back and updating AMOS by Francois Lionet, which are xAMOS a 100% reimplementation of AMOS in C++ under development by Mequa and the AMOS Manuals / AMOS Pro Resource Kit Project under development by myself aka MadAngus. These projects can be found at http://www.ultimateamiga.co.uk
>
> Francois has given permission to re-engineer the software and redistribute the manuals in PDF and other formats.
>
> Could you let me know if you would permit the redistribution of AMOS TOME software and manual and the AMOS Newsletters on Amiga related sites, primarily UltimateAmiga.co.uk.
>
> Also would you permit the reverse engineering of AMOS TOME for inclusion in AMOS development enviroments, xAMOS isn't the only one.
>
> Unfortunately this is a belated request of which I do apologise (we got ahead of ourselfs), as AMOS TOME software and manual and Volume 1 of the AMOS Newsletters are already on the site. Should this meet with your disapproval and wish them removed from Ultimate Amiga please let me know and this will be done as soon as possible. Also if this is the case Volume 2 of the AMOS Newsletters will not be released.
>
> Thank you for your time.
>
> Regards,
>
> Joe
« Last Edit: December 08, 2012, 10:45:11 AM by MadAngus »
Logged
My shadow says otherwise.

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Posts: 425
  • WINUAE Amiga User
Re: AMOSPro re-development general speculation
« Reply #67 on: November 28, 2012, 12:04:58 AM »

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. ;D)

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.  :o  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.

Quote
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.
« Last Edit: December 08, 2012, 10:45:39 AM by MadAngus »
Logged
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

MadAngus

  • There is no spoon.
  • Site Admin
  • A500
  • ****
  • Karma: 5
  • Offline Offline
  • Posts: 497
  • AMOS Docs / AIAB Dev
    • AIAB (Amiga In A Box)
Re: AMOSPro re-development general speculation
« Reply #68 on: November 28, 2012, 12:12:56 AM »

Locking topic for 5 mins so i can move it to the new board Here ->  AMOS Professional Re-Development

Topic unlocked.

All discussion should be kept within the AMOS Professional Re-Development -> General Discussion child board for now.
« Last Edit: November 28, 2012, 12:15:52 AM by MadAngus »
Logged
My shadow says otherwise.

MadAngus

  • There is no spoon.
  • Site Admin
  • A500
  • ****
  • Karma: 5
  • Offline Offline
  • Posts: 497
  • AMOS Docs / AIAB Dev
    • AIAB (Amiga In A Box)
Re: AMOSPro re-development general speculation
« Reply #69 on: November 28, 2012, 01:00:15 AM »

Quote
I so own the recent post list. ;D

At least for now. ;)

Quote
Moving threads at 1:00 am MadAngus?

Looks like you also so own the 'glutton for punishment' list  ;D
I suppose I set myself up for that. ;D


For ClassicAMOS
AMOS Editor, fixed-size 640x256 floating window. Preferably does not lock the workbench out.
Output to a fixed-size 640x256 floating window. Again, preferably does not lock the workbench out.

Go for fixed first, see how it works in use. If it does we keep ClassicAMOS within the Classic framework but gain a perceivable benefit.

For AMOS 3.x
AMOS Editor, etc. as a resizable floating window.

OO model
Maybe in AMOS 3.x but not in ClassicAMOS. ClassicAMOS must remain within the Classic framework.

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

I'll create a separate topic for AGA tomorrow (after i get some sleep) and consolidate many of the comments from this discussion in the first post.

We need to remember some developers will not want to work on bug fixing alone. AGA is going to be an itch they just got to scratch.

And remember Do Not post in the ClassicAMOS Development/AMOS 3.x Development boards. Not yet, they are not ready.

AMOS 3.x, has anyone got a better name or are we going to just use that for the official name. Haven't had any suggestions.
« Last Edit: December 08, 2012, 10:44:19 AM by MadAngus »
Logged
My shadow says otherwise.

SamuraiCrow

  • compile-time wierdo
  • Forum Mod
  • A1200
  • *****
  • Karma: 3
  • Offline Offline
  • Posts: 839
  • Compile-time wierdo
Re: AMOSPro re-development general speculation
« Reply #70 on: November 28, 2012, 01:38:42 AM »


For ClassicAMOS
AMOS Editor, fixed-size 640x256 floating window. Preferably does not lock the workbench out.
Output to a fixed-size 640x256 floating window. Again, preferably does not lock the workbench out.

Go for fixed first, see how it works in use. If it does we keep ClassicAMOS within the Classic framework but gain a perceivable benefit.

For AMOS 3.x
AMOS Editor, etc. as a resizable floating window.

OO model
Maybe in AMOS 3.x but not in ClassicAMOS. ClassicAMOS must remain within the Classic framework.

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

I'll create a separate topic for AGA tomorrow (after i get some sleep) and consolidate many of the comments from this discussion in the first post.

We need to remember some developers will not want to work on bug fixing alone. AGA is going to be an itch they just got to scratch.

And remember Do Not post in the ClassicAMOS Development/AMOS 3.x Development boards. Not yet, they are not ready.

AMOS 3.x, has anyone got a better name or are we going to just use that for the official name. Haven't had any suggestions.

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 3.x 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.
« Last Edit: December 08, 2012, 10:44:39 AM by MadAngus »
Logged

bruceuncle

  • AMOS Dev
  • A500
  • *****
  • Karma: 6
  • Offline Offline
  • Posts: 425
  • WINUAE Amiga User
Re: AMOSPro re-development general speculation
« Reply #71 on: November 28, 2012, 07:49:00 AM »

    OO should be left to other programming languages.

    Completely agree.   One of the main requirements for Classic AMOS is to improve performance.  And OO abstractions are not renowned for speed.

    Quote from: SamuraiCrow
    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.

    I've purposely left the AMOS Pro Compiler out of the above discussion to try and avoid confuding the dicussion too much.  (And probably failed by waffling on too much anyway ::).)  The Compiler is not a 'happy chappie' in its current state, at least not for me.  The stuff above also applies to it though.
    Logged
    Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

    ghizzo

    • A600
    • *
    • Karma: 1
    • Offline Offline
    • Posts: 2
    • Generic Amiga User
    Re: AMOSPro re-development general speculation
    « Reply #72 on: December 01, 2012, 06:10:43 PM »

    Hi!

    I'm Pietro Ghizzoni... as promised i've released the AMOSPro sources. Actually they aren't on Aminet. Here in Italy there is now the Pianeta Amiga 2012 show. I've released the sources during the DevCon conference. Now you can download them from the Pianeta Amiga site http://www.pianetaamiga.it

    It's good to see so many brave coders ready to update AMOS like i and the AMOS NG team dreamed to do years ago. But be ready to discover that the AMOS sources are really bad structured, there aren't docs and the sources are not commented  :'( In other words upgrade it means rewrite it 100%.

    Good Luck!  ;)
    Logged

    bruceuncle

    • AMOS Dev
    • A500
    • *****
    • Karma: 6
    • Offline Offline
    • Posts: 425
    • WINUAE Amiga User
    Re: AMOSPro re-development general speculation
    « Reply #73 on: December 01, 2012, 06:42:30 PM »

    Many, many thanks for the release Pietro.

    What will be the license under which we can work on re-development?  MadAngus will want to know for all the legalese involved ::).

    Quote
    But be ready to discover that the AMOS sources are really bad structured, there aren't docs and the sources are not commented  In other words upgrade it means rewrite it 100%.

    Don't worry  ;).  We'll fix it!  8).  I've had many, many years experience in pulling stuff apart and putting it back together again  :).

    Thanks again Pietro.  This has been a much anticipated release.   Now, has my download finished yet? ...
    Logged
    Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

    ghizzo

    • A600
    • *
    • Karma: 1
    • Offline Offline
    • Posts: 2
    • Generic Amiga User
    Re: AMOSPro re-development general speculation
    « Reply #74 on: December 01, 2012, 07:26:53 PM »

    Many, many thanks for the release Pietro.

    What will be the license under which we can work on re-development?  MadAngus will want to know for all the legalese involved ::).

    You can use them for non-commercial purpose. Everything based or derivated from the AMOSPro sources must be released as free software.

    Quote
    But be ready to discover that the AMOS sources are really bad structured, there aren't docs and the sources are not commented  In other words upgrade it means rewrite it 100%.


    Don't worry  ;).  We'll fix it!  8).  I've had many, many years experience in pulling stuff apart and putting it back together again  :).

    Thanks again Pietro.  This has been a much anticipated release.   Now, has my download finished yet? ...

    Good work then! I'm still using Amos... i'll wait the next update! :) Now i spend my time developing Android Apps... it's funny like the great Amiga 500 period with the first AMOS The Creator ;)
    Logged
    Pages: 1 ... 3 4 [5] 6   Go Up