Ultimate Amiga

Network Boards => AMOS Professional Re-Development => AMOS Factory => General Discussion => Topic started by: bruceuncle on September 06, 2012, 08:57:41 AM

Title: AMOSPro re-development general speculation
Post by: bruceuncle on September 06, 2012, 08:57:41 AM
This thread is a holding place for the discussion of hacking, updates and future versions of AMOSPro for Amiga 68k.

This discussion will take place over the next year, so do not expect much if anything in the first few months.

[Edit by MadAngus]



Quote
You will nagged by WinUAE to update the Picasso96 rtg library.

What exactly have you got WINUAE trying to emulate MadAngus?  Sounds like the AmiKit or AmigaSys add-ons or something like.  I had so many minor bugs trying to use these environments that I just gave up - I needed a rock-solid stable environment for AMOS Pro V2.0 tinkering.  Ok, so you lose the AGA stuff, but bog-standard AMOS Pro just reverts it to a standard screen anyway.

My reasoning is that we have to get AMOS Pro documented fully in its out-of-the-box form running in its intended environment before undertaking any 'improvements'.  So, I'm emulating an A4000 with Workbench 3.1 and not using any Super Hires or AGA.  Absolutely no problems. 

Next step is to then start pushing into other environments and AGA possibilities.  But if we don't get the baseline sorted, we're more than likely to just flounder as we try to 'improve' the product down the track. 

In software enhancement terms:

Stage 1:  AMOS Pro V2.0 as released and fully documented
Stage 2:  AMOS Pro V2.1 with bugs fixed and updated docs
Stage 3:  AMOS Pro V2.2 with approved1 extensions and updated docs
Stage 4:  AMOS Pro V3.0 for AGA and fully documented
1 - meaning 'adds worthwhile improvements' and with any bugs fixed

Or something very similar.  Staged releases would probably mean intermediate version releases (e.g. V2.1.1, V2.1.2, etc.).  But the process should be a well-defined route from what was released (AMOS Pro V2.0) and where we'd like it to go (presumably AMOS Pro using AGA capabilities and with extra worthwhile extensions as part of the 'standard' package).

I know we haven't discussed any of this, so I may be barking up the wrong tree?  :) 
I just like stability.  8) 
Lots and lots of stability.  8) 8)
It's hard enough without the ground shifting, so I'll be staying bog-standard until my current tasks are over.   ;)

What are your views on where we go after docs?
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 06, 2012, 04:31:50 PM
I've got two setups one similar to yours, Workbench 3.1 and not using any Super Hires or AGA, except emulating an A1200 and using ECS, for testing the documentation as I work through it. The second setup is with AIAB and a maxed out emulation speed purely for fun and learning stuff.

Your right AIAB is sort of like a lite version of AmiKit, AmigaSys, and Classic Workbench. I prefer it.

I just need too finish vol2 of the newsletters and upload them, then it's phase two for the docs, about three months work. I'll need to make some changes to the Phase plan in the 'Summary of the AMOS Manuals project goals:' [Edit] Done.

Quote
rock-solid stable environment for AMOS Pro V2.0 tinkering. 
Yep, that's what the first setup is for. And for any serious hacking work as I don't want addons confusing any memory watch lists, etc.

Quote
What are your views on where we go after docs?

Next step is to then start pushing into other environments and AGA possibilities.  But if we don't get the baseline sorted, we're more than likely to just flounder as we try to 'improve' the product down the track.

In software enhancement terms:

Stage 1:     AMOS Pro V2.0 as released and fully documented
Stage 2:     AMOS Pro V2.1 with bugs fixed and updated docs
Stage 3:     AMOS Pro V2.2 with approved1 extensions and updated docs
Stage 4:     AMOS Pro V3.0 for AGA and fully documented
1 - meaning 'adds worthwhile improvements' and with any bugs fixed

Or something very similar.  Staged releases would probably mean intermediate version releases (e.g. V2.1.1, V2.1.2, etc.).  But the process should be a well-defined route from what was released (AMOS Pro V2.0) and where we'd like it to go (presumably AMOS Pro using AGA capabilities and with extra worthwhile extensions as part of the 'standard' package).

[Edit] Read my next post

From the 'AMOS Pro Resource Kit Project Breakdown/Plan.' (http://www.ultimateamiga.co.uk/index.php/topic,9479.msg43964.html#msg43964) you'll see ->

Related Projects (Don't hold your breath!): [Edited 22/08/12]
Easy AMOS Tutor : ported to an AMOS Pro Extension. (BSD License)
AGA-H : AMOS Pro AGA Extension for accessing the AGA hardware. (BSD License)
TOME Extension: Reverse engineered for use in development environments. [Added 22/08/12]

These are some features that I would like to see being implemented as extensions or directly integrated in to the hacked source code. There is a whole array of possibilities that could be considered, initially I would agree with stages 1-4 as written, small steps, stage by stage.

There is one exception to the small steps, stage by stage, and that's xAMOS. The little documentation I had put together for jAMOS was total and utter tosh that the Big delete button got battered. Now I'm getting back into things I want to get some decent introductory docs written for this and a basic Eclipse IDE for it, then the above Related Projects can be ported and added as plugins at some point. No timescale, we'll see how I get on.

Assuming we can agree that the Primary goal's is the four stages, we can discuss each stage in detail closer to the time work starts on them. Stage 1 will be completed this year and then it's into some serious hacking and writing for me.


One last thing until the next thing ;D, Hungry Horace has just uploaded a full install of AMOSPro v2.00 which includes the updates and compiler I think, as said in the post I will give this a little test and report back with some detail.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 07, 2012, 11:09:51 PM
Quote
What are your views on where we go after docs?

Let me Start again. I got carried away ::)

Quote
Stage 1:     AMOS Pro V2.0 as released and fully documented
Stage 2:     AMOS Pro V2.1 with bugs fixed and updated docs
Stage 3:     AMOS Pro V2.2 with approved1 extensions and updated docs
Stage 4:     AMOS Pro V3.0 for AGA and fully documented
1 - meaning 'adds worthwhile improvements' and with any bugs fixed

Stages 2 to 4 were never intended as a progression of the resource kit project.

The original intention was to release AMOS Pro V2.0 with the converted classic manuals.

It is then the intention to restructure these manuals into a resource kit document set and include any new information.

Once the restructure is complete, the goal is to then create a new AMOS development environment on x86 architecture for FreeBSD, Windows and AROS platforms, with cross-compiler targets of FreeBSD, Windows, AROS and AmigaOS-68k. Then port the resource kit to this development environment.

The ultimate goal is to have an extensive set of documentation for the new development environments.

I never had any plans to update AMOSPro, The only changes to AMOSPro that I am hoping to eventually achieve was the two extensions below:
1.) Easy AMOS Tutor (from EasyAMOS) : ported to an AMOS Pro Extension. (BSD License)
2.) AGA-H : AMOS Pro AGA Extension for accessing the AGA hardware. (BSD License)

An updated AMOSPro Dev environment (Stages 2 to 4) is not something I want to focus on or take the lead on. However if you want to take the lead on Stages 2 to 4, as listed at the beginning of this post, you could start a new AMOSPro Re-Development thread at some point. I'd then be happy to provide the documentation support and any hacking and development work that falls within my abilities at any given time. Although I would prefer to concentrate on those two extensions.

The Primary goals in the first post have been updated to more accurately define the progression of this documentation project.


[And now for something completely different]
The little documentation I had put together for jAMOS was total and utter tosh that the Big Nuke Button got battered. Now I'm getting back into things I want to get some decent introductory docs written for this and a basic Eclipse IDE for it.  No timescale, we'll see how I get on.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on September 08, 2012, 09:26:54 AM
I suppose the important bit missing from those stages is the full stop after Stage 4.   ;D

My philosophy is based on the following.  I've done it as dot points as it's easier for me to express it this way:
So, I see us mainly as "singing from the same song book" (I hate that expression but I'm getting over a nasty dose of bronchitis and the grey matter's gone to sleep - again!)

Where I probably differ is that I have a "polish it until it shines" approach to the existing software.  So, for extensions, I'd prefer to reverse-engineer and pick out the best bits.  And add the AGA capability, if possible, as an extension.  Having only skimmed the surface of the vast set of extensions available, I may change that view!  But it seems that, although there are many innovative and useful bits there, not all are necessary or useful.

To be continued...  (The new Dr Who  8) series is on telly over here in 5 minutes - gotta go)
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 08, 2012, 05:07:50 PM
Lots of good points there.

Quote
...moving away from the Amiga architecture for a language like AMOS will inevitably end up with something that isn't AMOS.
Your right, Deimos was never meant to be a pure AMOS development environment. I want something that is free (£0), open-source, viable for commercial companies to use (EPL\BSD License) and can compete with the best of the best. If it takes 10 years to achieve this then so be it.

However, I didn't want to feel or give the impression that I was abandoning the Amiga community. This is why I have put so much focus on producing an extensive set of docs for AMOS and Classic Amiga as it is now being called. That is also why Mequa's xAMOS is so important in that it will be a 100% reimplementation of AMOS, which I can then add as a plugin to Deimos and provide an Amiga compatibility setting, allowing development for Classic Amiga.

I'm all for development of AMOSPro+ as it fit's with the ethos of another project I want to do (Hardware based), a bit of the old and a bit of the new, but AMOSPro+ will be your project. 8)

Quote
What meaning do some of AMOS's instruction set have in a non-Amiga environment?
I'll let you know when I have an answer to that ;)
Title: Re: AMOSPro re-development general speculation
Post by: Spellcoder on September 14, 2012, 06:31:25 AM
Before someone spends days diving into resourced code, I'd like to note I've contacted Pietro Ghizzoni three weeks ago about releasing the AMOSPro sourcecode (Francois Lionet doesn't have the sourcecodes himself anymore). He said he would ask Francois Lionet for permission to post the sourcecodes on Aminet. I've mailed him again now to ask about the progress. So let's keep our fingers crossed ;).
(he also noted Chris Hodges and Jean-Baptiste Bolcato also have the sourcecode, so for now at least it's good to know there's some backups of the sourcecode floating around)
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 15, 2012, 02:29:35 AM
You are my hero,

Big kiss  :-* :-*

yuch!

Excellent work, fingers crossed. ;D

Quote
Before someone spends days diving into resourced code...
Bruceuncle don't look, Opps, too late.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on September 18, 2012, 05:38:04 AM
Awesome!   8)
I'd been ill over the last couple of weeks and only had access to my smartphone.  Couldn't remember my bl@*dy password and (on purpose) don't run email on the 'phone.  So I could look but couldn't speak  :'( .
If this works out, it will be a tremendous contribution to the AMOS fraternity.
Thanks a million Spellcoder.  Will be keeping all available appendages crossed, willing this to come off without a hitch.
Quote
Bruceuncle don't look, Opps, too late.
MadAngus - too late!  ;D
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 18, 2012, 10:10:12 AM
@Spellcoder
If Pietro Ghizzoni does get the sourcecode onto aminet please ask him if he has a webpage that he would like to be added to the acknowledgements list alongside his name.
Title: Re: AMOSPro re-development general speculation
Post by: Spellcoder on September 18, 2012, 10:32:38 AM
Quote from: MadAngus on September 18, 2012, 10:10:12 AM
@Spellcoder
If Pietro Ghizzoni does get the sourcecode onto aminet please ask him if he has a webpage that he would like to be added to the acknowledgements list alongside his name.

I will do that.
A little update: no response from Francois yet at his gmail address, so Pietro now tried mailing him at the clickteam email address (which I used to contact Francois a few years ago). Also Pietro found the AMOS & AMOSPro sources again, so now whe'll just have to wait for Francois to respond.
Title: Re: AMOSPro re-development general speculation
Post by: Spellcoder on September 24, 2012, 07:22:59 PM
Great news! I've just today received permission from Francois to have Pietro release the sourcecode :D.
Title: Re: AMOSPro re-development general speculation
Post by: Hungry Horace on September 24, 2012, 08:53:53 PM
yay!!  am very excited about the prospect of an improved AMOS Pro for classic amiga users!

AGA support... faster bobs.... err... ;)


Great work Spellcoder! Look forward to having it hosted here!
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 25, 2012, 12:40:07 AM
Quote
Great work Spellcoder! Look forward to having it hosted here!

I'll second that, excellent.  Spellcoder is 8)
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on September 25, 2012, 12:54:30 AM
And I'll third it!  (MadAngus's reply came through while I was typing mine  ;D).

Wow!  What wonderful news to wake up to.  I'd been checking this thread on my 'phone every morning trying hard to ward off the disappointment if this did not work out.
Brilliant work Spellcoder!  8) 8) 8) 8) 8) 8) 8) 8) 8)

I'll repeat here (in lieu of a full 'mission statement') an updated statement from what I originally posted on the Manuals thread.

In software enhancement terms:
Stage1:  AMOS Pro V2.0 as released and fully documented.  This is the "still point" from which development can proceed.  The documentation is well on its way and is databased.  So I can pull sets of bugs and weird behaviour out with simple queries.  That's the groundwork for the next stage.
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.
Stage3:  AMOS Pro V2.2 with approved§ extensions and updated docs.  Nothing changed by way of additional functionality.  For the extensions, I'd prefer to reverse-engineer and pick out the best language-relevant§§ bits from the vast array of existing ones (and bring them into V2.x format).  This may well result in just one 'language' extension that is cherry-picked from the 'best of the rest'.  With the source now available, this could also be stuffed back into the original AMOSPro.Lib if space restrictions aren't broken in the process.  For Extensions that are specialised, start an 'approved extensions' register.  This would be added to as each one is checked, versioned, fixed if necessary, documented and put into the public domain with some kind of 'approved' sticker.
Stage4:  AMOS Pro V3.0 for AGA and fully documented.  Don't know enough about the AGA chipset to understand whether this means a re-write of the core AMOS Pro or whether it can be implemented using an Extension.  I suspect the former as, from what I've reverse-engineered so far, Pro V2.x is heavily tied into the restrictions of the pre-AGA chipsets.  Not to worry.  We may just end up with AMOS Pro V2.2 and AMOS Pro AGA V3.0  ;) .
Stage5:  Stop enhancements development except for bug fixes.  All further development handed over to Extensions.
 
  § - Meaning 'adds worthwhile improvements' and with any bugs fixed.
  §§ - Meaning 'adds to the core AMOS functionality' and with any bugs fixed.  I can see this leading to heavy debate as to what is 'core functionality'  ;D .  Let's just leave it with the obvious ones:  AMOSPro_TOME.Lib is not core, AMOSPro_Compiler.Lib is  :-\ .  Now stand back and watch the fireworks!

Or some very similar schedule.  Staged releases would probably mean intermediate version releases (e.g. V2.1.1, V2.1.2, etc.).  But the process should be a well-defined route from what was released (AMOS Pro V2.0) and where we'd like it to go (presumably AMOS Pro using AGA capabilities and with extra worthwhile extensions as part of the 'approved' package).

All the above is aimed squarely at the classic Amgia environment - either real or emulated.  If it's any use to AMOS developments in other environments, that's all good.  But this particular project is Amiga-only.  See also my comments in this thread on why I believe AMOS and the Amiga belong together  ::)  http://www.ultimateamiga.co.uk/index.php/topic,9418.msg44342.html#msg44342 (http://www.ultimateamiga.co.uk/index.php/topic,9418.msg44342.html#msg44342)
At all costs, we need to avoid the 'Versions Nightmare' and 'DLL Hell' experiences that used to be common in the WIntel environment.

I'm happy to pull all the threads together with, hopefully, some help from any interested parties.

I'm very happy this morning  :) :) :)
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 26, 2012, 03:12:13 AM
I'm looking forward to getting this code as it will be a great environment to test my knowledge of 68k Assy as I learn.

Now to light some fireworks...

Quote
Now stand back and watch the fireworks!

Oh don't forget the bonfire which I shall now feed with two wardrobes, an old couch, and a butane gas bottle. :P

First and most important of all is any additional core code licensing. Assuming the AMOS Pro source code is released under the same license as the other code, BSD style as quoted below, I would argue that any contributed code that is to be compiled into the core package be submitted with a similar BSD license. If not, additional code should be provided in the form of an extension.

Quote
Clickteam provides the source code AMOS as a courtesy to the Amiga
computer community. You are allowed to edit and modify the source code,
add new features, remove sections of code and recompile it to produce
modified final products.

 Any product made from the original source code should contain this
written notification:

 "Contains parts of AMOS source code, originally written by François
Lionet and published by Europress Software Ltd. Contact the original
authors at http://www.clickteam.com." 


And there's more..


Quote
Stage1:     AMOS Pro V2.0 as released and fully documented.
Once the code is available we should make sure that the code is actually the 2.0 version released, or call the compiled version of the released code v2.01.

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

Quote
Stage3:     AMOS Pro V2.2 with approved§ extensions and updated docs.  Nothing changed by way of additional functionality.  For the extensions, I'd prefer to reverse-engineer and pick out the best language-relevant§§ bits from the vast array of existing ones (and bring them into V2.x format).
If by reverse engineer you mean write from scratch equivalent functions, then yes. However if this means Resourcing other code to derive the functionality and code, then absolutely not, for copyright reasons.

Quote
For Extensions that are specialised, start an 'approved extensions' register.  This would be added to as each one is checked, versioned, fixed if necessary, documented and put into the public domain with some kind of 'approved' sticker.
I think this should be provided in a format similar to that of the Eclipse.org Market place. Where users can select extensions by category, license etc from a web page. An offline full package of all freely distributable extensions could also be provided.

Quote
Stage4:     AMOS Pro V3.0 for AGA and fully documented.
Keep as an extension until the AGA chipset is fully understood and full compatibility and functionality has been implemented.

Quote
Stage5:     Stop enhancements development except for bug fixes.  All further development handed over to Extensions.
Completely disagree. On the basis that there will probably be a significant list of feature requests from users. Many of these will be file format support requests, but you simply need to look at the Blitz variants to see were the development requests could go.

Quote
...But this particular project is Amiga-only
That's fair enough, but I am quite sure that this project if seen to be maturing will be forked for the AROS x86 environments, and that would lead to the 'Versions Nightmare' and 'DLL Hell' you speak off.

Quote
...AMOS functionality... AMOSPro_TOME.Lib is not core,...
I would agree with this. Especially as TOME gets redeveloped and enhanced, updating an extension library would be a lot easier. I did mention that I asked permission to reverse engineer this when I asked for permission for the Manual ;).

Obviously there would have to be fixed processes like code standards, code submission and review procedures etc.
    There are however some attitudes in projects I've come across that grate my teeth. Such as the "We know best" and the "we won't implement that because we don't want to work on it" I really can't stand. This is something to avoid, leave the EGO at the door sort of thing.
    I would suggest that a system whereby all requests must be implemented either as core or as extensions, as long as it is feasible to do.
    I have seen voting systems for this although they are aimed at accepting or rejecting a feature request, OpenOffice does this and rejected the request for split pane functionality, their method of achieving this is ridiculous, to say the least.
   The voting system should be open to all registered members (not just a group member) and should decide which feature, functionality or otherwise is implemented first. They way I have defined it in my notes is each core developer commits to a feature set (say 12 feature requests) made up of the following

3 features of the core developers own choice
5 from the top voted features
2 from the median
2 from the least voted
All features must be completed before the core developers own selection will be implemented.
This is summerised from my notes.

One feature I would like to see implemented is a new standard Amiga interface that worked within a window on the workbench. ;D

I'll leave it there for now, I could go on for another fifty pages on this. ;)
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on September 26, 2012, 02:43:23 PM
Aieee!  What did you put in those two wardrobes and old couch apart from the butane bottle MadAngus?  Bonfire going great!   ;D

I agree with most of what you've posted MadAngus.
Above all, there has to be stability in the core product, otherwise the whole concept of AMOS's flexible extension model falls in a heap.  That's what I meant by avoiding the 'DLL Hell' experiences in the earlier WIntel environments.  Whatever we do should not break these current AMOS Pro abilities:

1 - As far as I can tell from the various patches, etc that I've looked at, V2.0 is what we're talking about.  The Compiler mentions 2.x simply because they really did get the latest version into release.  Then there were no more.  I suspect that by calling it 2.x there they avoided having to revise the (then) printed docs.  (We take the ability to easily modify and re-distribute electronic docs these days a bit too much for granted  :).)  I've found variants but they're all 'patched'.  That is the whole slab is identical to the original with a few very small changes written in situ without disturbing the original offsets, etc.  They have to be that way because otherwise, without access to the sources, the whole code chunk would fall in a heap.  They may be useful bug fixes (I haven't looked yet - I'm still up to my neck with other doc stuff, which I think essential before we do anything).  Anyway, V2.0 is V2.x etc.  I'm happy to go with V2.0 as it suggests a more constuctive versioning.
Quote
If by reverse engineer you mean write from scratch equivalent functions, then yes. However if this means Resourcing other code to derive the functionality and code, then absolutely not, for copyright reasons.
Ever since I were a wee naive lad learning COBOL  :-[ I've learnt to program from examples.  Even back then, I would pour over other people's program listings absorbing good and novel techniques and best practice.  I've been the same in all other programming environments since (no, I haven't got any friends  ;D ).  I'm currently re-learning both 68k asm and AMOS.  I've grabbed all available source code and poured over it.  I've used Resource to get into code for which I've got no source.  Yes, the functionality and ideas I will plagiarise but not the code.  I can usually improve that  :).
Anyway, fear not.  Anything I do myself will always be submitted through you guys for approval (maybe consider yourselves appointed as official custodians of 'approved' AMOS stuff?). 
Quote
Completely disagree. On the basis that there will probably be a significant list of feature requests from users. Many of these will be file format support requests, but you simply need to look at the Blitz variants to see were the development requests could go.
I agree with your right to disagree and disagree in turn  :o.  The AMOS Pro Extension model is fine.  There is nothing that you could do in the core that you can't do functionally with an appropriate extension except change the Editor and Monitor.  All other tools are AMOS progs and the same comment applies.  AMOS is AMOSPro.Lib and the other standard Libs in the release.  It was smart thinking for them to disengage the Editor's restrictions (640 width Hires screen with fixed toolbars, etc) from the language itself.  V2.0 did that and managed to retain backward source code compatibility with the other two products.
This requires a bit more explanation as I think it's something we have to acknowledge as inviolate.  Its tied in with this:
Quote
bruceuncle wrote:
Stage4:     AMOS Pro V3.0 for AGA and fully documented.

MadAngus wrote:
Keep as an extension until the AGA chipset is fully understood and full compatibility and functionality has been implemented
Having successfully decoupled the Editor and Monitor from the language, what next?  I strongly suspect that the intention was to go AGA by just changing the Editor and Monitor to operate at either AGA full-screen resolutions or as a resizable window.  So I may be completely wrong as I'm relying on intuition rather than facts, but I think we'll find the same thing.  That's why I speculate that we'd end up with two final products - V2.xx for non-AGA and V3.xx for AGA.  There's no technical reason why they couldn't share the same Libs including AMPOSPro.lib.  An AMOSPro_AGA.Lib would also work with both as long as developers in V2.xx didn't mind a 640x256 environment to work in  ;D.
Quote
One feature I would like to see implemented is a new standard Amiga interface that worked within a window on the workbench.
Agreed - see above.

I won't waste space by quoting all that good stuff at the bottom of your post.  I'm all for it.  Managing it would be a nightmare  ::).

Now back to the stuff I'm supposed to be doing which needs to be completed before any of this could start anyway.  I'm still very happy.  :)
Title: Re: AMOSPro re-development general speculation
Post by: SamuraiCrow on September 26, 2012, 04:42:59 PM
Wow!  I'm impressed!  This is excellent news!

Sorry I've been away so long... especially after hearing this!

Since I've been gone I've had a programming job lined up and lost it.  I'm now working at a major retail store chain by unloading boxes and pulling palettes around.

If there's any hope of making the compiler optimize code better let me know.  That was always one of the shortcomings of Amos code.  I have heard that AmosPro does bit-shift optimization of multiplies but not much else.

Is there much to the AmosPro code generator?
Title: Re: AMOSPro re-development general speculation
Post by: Sidewinder on September 26, 2012, 07:31:57 PM
My my.  This is excellent news!

I guess now I can shelve my plans to write a new AMOS Pro interpreter and compiler in C.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 26, 2012, 09:15:20 PM
Quote from: bruceuncle
Aieee!  What did you put in those two wardrobes and old couch apart from the butane bottle MadAngus?  Bonfire going great!   ;D
Some lighter fuel, a few illegal bangers and the proverbial two gallons of petrol in a container, unopened, which hasn't exploded yet. ;) I'm actually looking forward to some heated debate on this. Choose your weapons, my favorite is my enginneers hammer whom I have named, Meaty-Beaty-Big-And-Bouncy The IV, of course the classic half brick is also a good option. ;D

I would like to get one thing out of the way first, and that's who is the DE-facto project lead on this.

Unless there is any objections, I nominate bruceuncle (already volunteered) as project lead. Personally, I simply do not have the programming skills to take this role on.

As project lead, bruceuncle would have/make the final decisions on any project management processes, code implementations strategies etc. Of course final decisions would be after due diligence with the community. I say this because management committee voting systems will delay and scupper this project as is the case with many other open-source projects.

What I want and believe is needed is someone who will say, OK debate is over, here is the pros and the cons and here is the decision. A benevolent tyrant system, is that OK with you my Lord Vetinari. :D

Quote from: bruceuncle
Now back to the stuff I'm supposed to be doing which needs to be completed before any of this could start anyway.  I'm still very happy.  :)
I will re-emphasise what I have previously stated. This discussion will take place over the next year. Yes there is much to be done before the redevelopment is begun in earnest, but we do want and need as many opinions as possible to get a feel for the desires of the community. I don't know who earnest is, never met him, so don't ask.

Stupid questions and bad ideas are most welcome. As long as the questions/ideas are related to the development of AMOSPro 3.x.
Any questions such as "What is the meaning of life", should be asked in a seperate thread.

I'm puting forward the suggestion that we use  "AMOSPro 3.x" as the projects working title.

Quote from: SamuraiCrow on September 26, 2012, 04:42:59 PM
Wow!  I'm impressed!  This is excellent news!

Sorry I've been away so long... especially after hearing this!

Since I've been gone I've had a programming job lined up and lost it.  I'm now working at a major retail store chain by unloading boxes and pulling palettes around.

If there's any hope of making the compiler optimize code better let me know.  That was always one of the shortcomings of Amos code.  I have heard that AmosPro does bit-shift optimization of multiplies but not much else.

Is there much to the AmosPro code generator?
Sorry to here about the job not happening :'(. Good that you still have work as I can't get a damn thing.

When the source code is uploaded, it can then be studied in detail and the answers to your questions will no doubt become apparent. These questions can be added to the list of need to knows.

Quote from: Sidewinder on September 26, 2012, 07:31:57 PM
My my.  This is excellent news!

I guess now I can shelve my plans to write a new AMOS Pro interpreter and compiler in C.
It would be of significant benefit to this project if you signed up as a core developer.

SamuraiCrow, Hungry Horace, Spellcoder, FOL, and everyone else, if you want to volunteer and signup for roles or even a suasage-ona-stick, it would be great to have you. You could sign up to a role as interested but not yet committed.

There's, Documenter, core developer, contributing developer, project manager, website designer, beta testing, the man with the big stick (Project Lead) and any other anthropomorphic personifications that you may think appropriate.

Quote from: bruceuncle
I won't waste space by quoting all that good stuff at the bottom of your post.  I'm all for it. Managing it would be a nightmare  ::).
True, volunteers to take up certain roles would be required.

As for a project website as apposed to a forum, that should be no problem as I'm sure FOL will be more than happy to host it. It would also make sense to have the project website here with the forum along side all the other AMOS stuff that's here.

We can argue about the design of the website here aswell. >:(  :P
Com'on ahe'd, if ye fink yor 'ard enough

All arguments and fighting will follow the Dimac rules of engagement. Anybody below a Fifth Level Master of Dimac should be polite. Please mind your Klatchian when posting.

Additional debate topics:
Language used, stick with 68k assy or port to c.
Could any of the xAmos code be used.
Should development of implementations be designed to be portable so that xAmos can make use of them.

Point of note:
Do not shy away from big ideas or suggestions, these can be achieved through milestone plans. Also the project will not get sidetracked or swamped by clever ideas. The milestone management system or whatever is in place should make sure that small steps from the base code is followed.
Title: Re: AMOSPro re-development general speculation
Post by: Hungry Horace on September 26, 2012, 09:27:15 PM
cool discussion.

Couple of minor comments to chip-in if i may?

You guys talk about implementation of improvement, tied into 'approved' extensions.

Where do you stand with regards to extension commands that duplicate (but are more efficient) AMOS commands?

For example.... AMOS  has a 'RND' command, but this is replaced by AMCAF's 'QRND' in practical usage.

Now... In your opinion, with the proposed development programme...

- Does AMOS 3.0 (hypothetically)  support both commands?   
- Does it recognise 'QRND' even without AMCAF loaded-in, and operate with it's own "new" faster 'RND' command?
- Does the user have to remove QRND from his code and re-write it as RND?
- Is the new, faster AMOS 3.0 RND code based on resources AMCAF code, or is it possible to have the AMCAF source released and fully integrated into AMOS?
- Does someone have to write new, faster, RND code from scratch???

You get where I am going with this, I am sure!! Just throwing it out there ... ;)


Although AGA is the great potential benefit of a source release, I would be equally (maybe more) supportive of the development in terms of final-product output speed... more efficiently produced code.  BLITZ has been described by some people as jsut a clever set of ASM Macros.... and thus why it produces good, fast, programmes... why shouldnt AMOS3.0  be like this, but with the commands and interface we all know and love? 

Wouldn't you love to just re-compile your old AMOS code in a new version and suddenly find it so much faster?

Wouldn't you love to not need to scour through optimisation 'tips' and just get on with writing your programs? For example, I am constantly frustrated by using GOSUBs where i could/should be using nice tidy procedures... sometimes only 1 or 2 lines long!

I happy to help out in development where I can, but i imagine it would mostly be the testing side, as I am working on (another) electrical engineering qualification over the next two years.... not really much time to program ASM!

p.s. my view is Amiga Classic, and ASM output should alway be the 'core' ... the 'heart' of AMOS... with other implementations (C etc) as happy (and now easier?) by-products.... but that's a personal opinion.

Anyway....

IF AGA = TRUE THEN GOSUB PAAAAARTY!  :D
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 26, 2012, 10:15:51 PM
Quote
Where do you stand with regards to extension commands that duplicate (but are more efficient) AMOS commands?
If possible integrate them. (see below for more detail...)

Quote
For example.... AMOS  has a 'RND' command, but this is replaced by AMCAF's 'QRND' in practical usage.

Now... In your opinion, with the proposed development programme...

- Does AMOS 3.0 (hypothetically)  support both commands? 
- Does it recognise 'QRND' even without AMCAF loaded-in, and operate with it's own "new" faster 'RND' command?
- Does the user have to remove QRND from his code and re-write it as RND?
- Is the new, faster AMOS 3.0 RND code based on resources AMCAF code, or is it possible to have the AMCAF source released and fully integrated into AMOS?
- Does someone have to write new, faster, RND code from scratch???

You get where I am going with this, I am sure!! Just throwing it out there ... ;)

All original commands should remain for compatibility to older code, if they could be optimised without braking compatibility, I do not see why not.

AMCAF is GPL, which would mean the entire AMOSPro would have to be converted to GPL. Linking is one way with the GPL, you cannot link from any other licenced code to GPL'ed code it is simply not permitted, except in the case of fork/exec. Of course we do not yet know exactly which Licence AMOSPro will be released under so this is a moot point at the moment. Please let it be BSD. :-\

However AMCAF could be integrated if the licence was changed. I won't ask, I consider it an insult to ask an author to change their licence. Just my view. ::)

Otherwise AMCAF compatible functions or optimised functions would have to be written from scratch.
[Edit 27/09/12] Got this totally wrong, AMCAF is not GPL, it is closed source, previously shareware now released freely to the Amiga community. My apologies to Chris Hodges and the community for this mistake.

Your queries come down to whether or not the parser/Tokeniser is optimised/designed to cater for these.

There is no reason why a more optimised function cannot be written and added under a different function name and the parser/Tokeniser updated with the new function name.
    Alternatively the parser/Tokeniser could be modified to recognise alternative implementations with an IDE setting of use "optimsed functions" or "use legacy compatibility".
    So you would use the RND command and together with the IDE setting the parser/Tokeniser would use the original legacy RND function or an optimised RND function.
    The parser/Tokeniser could also be modified to recognise an external function set (from extensions) and check if the extension was loaded, if not use an alternative (preferably optimised) internal function and provide a warning tag in an output log window.

Quote
Although AGA is the great potential benefit of a source release, I would be equally (maybe more) supportive of the development in terms of final-product output speed... more efficiently produced code.  BLITZ has been described by some people as jsut a clever set of ASM Macros.... and thus why it produces good, fast, programmes... why shouldnt AMOS3.0  be like this...

...Wouldn't you love to just re-compile your old AMOS code in a new version and suddenly find it so much faster?
I think you are suggesting precedence being given to produce more optimised and efficient functions and compiler rather than nice new features. I believe that is how bruceuncle wants to proceed in the early stages and I would agree. Get the core functionality fixed and fully optimised and then build on that.

I am suggesting features be suggested to aid in milestone release management. i.e. were is it going.

Quote
..., but with the commands and interface we all know and love? 
By this do you mean keep the original interface.
I would therefore suggest that the interface has a dual mode using separate libraries. A classic interface and an updated interface. I would however agree that the classic interface takes precedence during the initial development cycles through to version 3.0.

Quote
Wouldn't you love to not need to scour through optimisation 'tips' and just get on with writing your programs?...
We should consider integrating these tips to save devs time.

Quote
...For example, I am constantly frustrated by using GOSUBs where i could/should be using nice tidy procedures... sometimes only 1 or 2 lines long!
Could you provide some sample code for this (preferably commented) so it can be added as either a BUG or a feature update. This would give a reference to work from when the issue was being addressed.

Quote
p.s. my view is Amiga Classic, and ASM output should alway be the 'core' ...
Noted.

Quote
Anyway....

IF AGA = TRUE THEN GOSUB PAAAAARTY!
This is also a big want for me too.
This does lead to another point/suggestion that should be made. Developers do not have to become core developers to submit code etc. They can work on any feature, only that core developer code from a feature set is implemented first.
    So if I wanted to develop this separately from the main development I could but it would only be implemented after the current selected feature sets have been implemented, and only if there was time in the release schedule.
   Remember the development [EDIT] development management system hasn't been fully developed, peer reviewed and ratified by Lord Vetinari.

In development management, everything is a feature, a bug fix, an optimised function, a new function or interface element. In this case a feature is just a thing.


bruceuncle will no doubt be along to add his views.

I have just been informed that my dinner is in the dog. ::) women.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on September 27, 2012, 12:57:55 AM
Feeling the heat from this bonfire already  ;D.

Very nice to see so much interest being stirred up.

Thanks for the Design Process docs MadAngus.  I was always a lousy project manager.  Much preferred to get my hands dirty instead.  However, politically, I lean towards the 'benevolant dictator' model.  The problems being that "All power corrupts.  Absolute power corrupts absolutely."  :)

Rather than go through this point by point from the replies, I'll add a few bits to the existing, rather patchy, mission statement:

Anyway, gotta go as I'm running late for an appointment.  Thanks to everyone for the feedback and enthusiasm.  I'll be back ...  8)
Title: Re: AMOSPro re-development general speculation
Post by: Hungry Horace on September 27, 2012, 11:09:01 AM
@ MadAngus

To clarify, with regards to optimaisations, i was largely referring to those documented by Spellcoder, which includes the procedure vs. gosub route.

http://www.amigacoding.com/index.php/AMOS:Optimizing
http://www.amigacoding.com/index.php/AMOS:Optimizing_Miscellaneous
http://www.amigacoding.com/index.php/AMOS:Optimizing_Coding_Style

I have tested it, and it is true, AMOS is slower with procedures than with gosubs! 

Anything to get the emphasis away from "you need to do this to make it work/better/quicker" and back towards the natural intuitive way AMOS can allow you to code, should be encouraged with any future developments (i beleive) as it  not only frustrates those of us who like to code in this lovely language, but the speed issue (or lack of optimisation) is usually the first "belittleing" of AMOS that happens from coders of other languages!

I'd also like to say that my comment about the classic interface shouldnt mean i wont welcome any change, but bear in mind, if you lose too much of it (for example going back to a raw test editor!) then you will lose some of what makes AMOS .... well... AMOS!

Title: Re: AMOSPro re-development general speculation
Post by: SamuraiCrow on September 27, 2012, 03:58:42 PM
@Hungry Horace
The QRnd function on the AMCAF extension is just like Rnd(65535) but without the modulo operator used to bring it into range.  I wouldn't be surprised if the QRnd function was just a rebadged AMOS Rnd function with that single change.

The subroutine procedure vs. Gosub argument has to do with the way that AmosPro passes parameters to the procedure.  It is purely stack-based.  In order to get it to be as fast as, say... SAS/C, it would need to be totally reengineered to use register-passing.  All extensions would need to be reengineered to take those changes into account as well.

@Mad Angus
Who ever said that AMCAF was GPL?  I thought it was closed-source or at least it was, last I knew.  I realize I've been off the scene for a while but I don't see any source code for the AMCAF extension on Aminet.  Has Chris Hodges rereleased it as GPL?

@Thread
Let's consider what's realistic compared to what isn't:  XAmos is a C++ based interpreter with plans to write a compiler that will generate C++ codes.  It would require GCC running on the Amiga to be able to compile, assuming it will still be C++ code.  If not, VBCC could be used if it was rewritten in C or something.

In the past I had high hopes that the Clang compiler for LLVM could be used on the Amiga but it requires 2 GiB to link in its current state, meaning that a Classic Amiga would never be able to recompile its own source code.  Also, Clang is a 22 MiB executable file on x86 and I doubt it would be much smaller on 68k.  This leaves us with an ugly implementation of GCC as being the only free C++ compiler for Amiga.

I know that Mequa had said in the past that since the XAmos project is BSD licensed, extension capabilities wouldn't be necessary in his interpreter.  I think he has similar plans for the compiler.  I'm all for Mequa doing what he wants with his own code but mixing it with a project written entirely in 68k Assembly such as AmosPro would break the bank in terms of both system requirements and development time unless Mequa or somebody figures out how to make a shared library or linker library out of his routines so that they can be linked externally.

I think getting AGA capabilities into AmosPro is a more realistic first step.  There have been numerous attempts at AGA extensions for AmosPro with varying degrees of success.  Let's just concentrate on that for now.  Do we want to totally redo the compiler though?  I'd recommend it if there's enough manpower to do it.

Let's talk.  Any further thoughts?
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 27, 2012, 04:15:41 PM
Quick post in response to AMCAF being GPL.

After checking I realise I got this totally wrong, AMCAF is not GPL, it is closed source, previously shareware now released freely to the Amiga community. My apologies to Chris Hodges and the community for this mistake.

The previous post comment about this has been struck out.

Going out to sign for a new car, I'll stick my neb in about the rest when I get back.
Title: Re: AMOSPro re-development general speculation
Post by: Sidewinder on September 27, 2012, 05:15:20 PM
Quote from: SamuraiCrow on September 27, 2012, 03:58:42 PM
I think getting AGA capabilities into AmosPro is a more realistic first step.  There have been numerous attempts at AGA extensions for AmosPro with varying degrees of success.  Let's just concentrate on that for now.  Do we want to totally redo the compiler though?  I'd recommend it if there's enough manpower to do it.

Let's talk.  Any further thoughts?

I agree with Sam about rewriting the compiler/interpreter.  If the source code is in a similar condition to the Creator sources already available then there is much cleanup to be done.  Making things register based would certainly speed it up and there is room for more efficient code generation.  A more system friendly design strategy would help modernize it too.  I think it may be time to start with a clean slate, and only use the source code as a complete reference for compatibility requirements.  (Although, after further consideration, using the current source code would be best to begin with, but before the 3.0 release the entire source code should be reviewed, cleaned up, documented, modularized, and updated.)

Implementing AGA would also be a worthy first step.  There are a hundred different features and changes I'd like to see, but updated code generation and AGA are the two big ones in my book.

And I would like to volunteer as a primary developer, if there are still openings.
Title: Re: AMOSPro re-development general speculation
Post by: Hungry Horace on September 27, 2012, 07:42:30 PM
Quote from: SamuraiCrow on September 27, 2012, 03:58:42 PM
@Hungry Horace
The QRnd function on the AMCAF extension is just like Rnd(65535) but without the modulo operator used to bring it into range.  I wouldn't be surprised if the QRnd function was just a rebadged AMOS Rnd function with that single change.

The subroutine procedure vs. Gosub argument has to do with the way that AmosPro passes parameters to the procedure.  It is purely stack-based.  In order to get it to be as fast as, say... SAS/C, it would need to be totally reengineered to use register-passing.  All extensions would need to be reengineered to take those changes into account as well.


I think the point I was making is being lost a bit, with focus on the examples I gave.... QRND and Procedure vs. GOSUB  were arbitrary examples of one replacement function, and one structural optimisation.

I could just have easily stated DRAW and TURBO DRAW, and using  REPEAT/UNTIL instead of FOR/NEXT.... even the terrible slow-down that occurs when using multidimensional arrays. The function example doesnt have to come from AMCAF at all!

My point is that the genuine improvements in what AMOS needs (i think) are not in it's commands or functions, it's possible to already achieve things that appear beautiful with AMOS.... It's the final code it produces as a result, and the results they achieve that AMOS is measured against with it's competitors.

I said it earlier, and I'll say it again - AMOS gets knocked (and sometimes deservedly so) because of the poor speed and performance of it's code... this is a shame, because it's actually an incredibly elegant language!

I'm not claiming that access to the source-code is a magic solution to this 'problem'.... but it has to be a lot of help, and I hope that whoever takes on this mammoth challenge (because lets not pretend it's any less than that!!) has these kind of considerations in mind :)



Quote
I think getting AGA capabilities into AmosPro is a more realistic first step.  There have been numerous attempts at AGA extensions for AmosPro with varying degrees of success.  Let's just concentrate on that for now.  Do we want to totally redo the compiler though?  I'd recommend it if there's enough manpower to do it.

Dont get me wrong, I think AGA functions are a very worthy 'early' aim.... and certainly one that would bring AMOS out-of-the-dark....
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 27, 2012, 08:58:00 PM
Welcome aboard Sidewinder. +1 Core Developer

Sidewinder is there a specific area of AMOS that you would prefer to be working on.

There is no limit on numbers, anybody can work on anything they want and submit it anytime. Obviously this would have to managed.
I'm not a developer in this project, not got the skills :'(

To achieve everyone's wishlist, this project would have to be managed, with rules, code standards, implementation/work schedule, milestones etc. This may not be popular but it has been stated that the goal is a Horse not a Camel.

I'm volunteering as Project Manager, this would be an administrative role (not a decision making role), collating information, keeping any plans and design processes upto date, documentation updates, project website updates, asking questions that make you senior developers eyes role etc. :D

When I say collating information this also includes scouring every AMOS thread/post in existence including the mailing lists for anything that will help.

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

Optimisations: How will we know what we need to work on and why.

I propose that a comparison list of AMOSpro and extension functions is created including other issues as highlighted by Hungry Horace. This list will highlight each AMOSpro function and it's equivalent in other extensions see sample table below.

AMOSPro   AMCAF
RND   QRND

From this table functions/process that are better optimsed are noted and documented, with further research indicating why the optimisation is better. For example:

Hungry Horace states:
AMOS  has a 'RND' command, but this is replaced by AMCAF's 'QRND' in practical usage.

This is followed up by SamuraiCrow's statement:
The QRnd function on the AMCAF extension is just like Rnd(65535) but without the modulo operator used to bring it into range.

This information changes our table to:
AMOSPro   AMCAF   Ext Better       Better Why
RND   QRND   Yes   The QRnd function is just like Rnd(65535) but without the modulo operator used to bring it into range.

Many areas of the AMOSPro and the extensions will require further research into the precise cause of weak implementations and any necessary steps that would be required to resolve the issue.

@Hungary Horace: This also applies to the final code performance issue, what, why and where are the weaknesses that result in the interpreter/compiler generated code not performing as well as the competition. A research task for someone to take on when the code is available. Does Devpac have a profiler, is there one that can be used for this task?

With the necessary work load for each issue known and collated, areas to focus work on can be manged and scheduled.

We do have the advantage that Lonewolf10 has already produced an extensive list of extension functions and has documented many of them. In addition the AmigaCoding team has already collated a lot of information.

This does not mean that work could not begin on specific features such as AGA or even an alternative interface, but when it is being put together it will have to be managed.

Q, Which code repo to use?
SVN, GIT, HG, CVS

Alternative interface:
There is only one way I can see this working. Firstly focus on keeping the classic interface as is until a much later stage. Then if desirable design an alternative optional interface, in such a way that the program can start up with the interface of choice.
    If features of the alternative optional interface is deemed suitable to be implemented into the classic interface and will not result in the loss "of what makes AMOS .... well... AMOS!" Then port them across.
Title: Re: AMOSPro re-development general speculation
Post by: Sidewinder on September 27, 2012, 09:26:34 PM
Thanks MadAngus.  I'm very interested in code generation and optimization, so I could focus on those areas.  But I'm a versatile programmer so I can do whatever needs to be done.

I think you'd make a good Project Manager.  We do need standards, rules, and plans.

Determining what to optimize should probably involve a complete code review once the source is released.  Various programmers/individuals could suggest improvements and those request could be compiled into a priority list.

Regarding repo, I'll vote for SVN or CVS.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on September 27, 2012, 09:40:32 PM
Quick note:

Any standards, rules, and plans get peer reviewed by the community and ratified by the project lead after any necessary modifications are made.

[Edit] [Edit again]Tommorow night This weekend* I will be building a small summary of views expressed so far for further debate along side any new points of view.

So please have your half bricks ready. Anybody who manages to hit me wins a Gonk. ;)


[From Edit] *I'm updating the AIAB download page at the moment, get that done and I'll move back onto this.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on October 01, 2012, 11:25:15 PM
The discussion to-date has highlighted some specific areas as follows:

Code review:
To facilitate a common development environment whereby everyone is working from common knowledge, the entire source code should be reviewed, cleaned up, documented, modularized, and updated (Known bugs fixed).
    Sidewinder

This reflects the statements and initial suggestion by bruceuncle as to what the initial milestones should be.
Quote
In software enhancement terms:
Stage1:  AMOS Pro V2.0 as released and fully documented.  This is the "still point" from which development can proceed.  The documentation is well on its way and is databased.  So I can pull sets of bugs and weird behaviour out with simple queries.  That's the groundwork for the next stage.
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.
    bruceuncle

As it will take some time to review the code the Stage 1 milestone could continue as it is at the moment with the documentation set (currently being written) and version 2.0 being released together as the initial resource kit.

However for the Stage 2 milestone a two part goal could be the primary focus.

a.) The actual code is reviewed and documented.

The documentation would most likely be in the form of comments for each block/line of code. It would be beneficial if these comments were not overly cryptic in their meaning and written as if talking to a laymen. It Can be difficult to understand someone else's logic when it is not simplified for general understanding.

Also someone has to pull these comments out into developer/contributor documentation.

If possible the code should be modeled. As AMOS isn't an object model architecture, it's would be difficult to model it using UML, however it may be possible to produce block diagrams showing function dependencies (other functions etc.), additional models could also be produced were appropriate and relevant. Basically use UML techniques. How does it all fit together, definitely requires further feasibility analysis/thought.

b.) Code updated (Known bugs fixed)

For this a comprehensive list of known bugs will be required.
This would require that all sources of information, AmigaCoding, forums, mailing lists, bruceuncles work etc. be trawled and be collated. A job for some lucky volunteer(s). I did volunteer for this didn't I, sigh!

With this bug documentation at hand, contributors would have a basis for discussion as to which libraries/bugs to prioritise and delegate.


Optimisation:
Lots of comments on this.

Here are some comments (not in any predetermined order) to capture the theme of optimising and it's considerations. There are more in the thread.

Quote
If there's any hope of making the compiler optimize code better let me know.  That was always one of the shortcomings of Amos code.  I have heard that AmosPro does bit-shift optimization of multiplies but not much else.
    SamuraiCrow
Quote
Where do you stand with regards to extension commands that duplicate (but are more efficient) AMOS commands?

...Wouldn't you love to not need to scour through optimisation 'tips' and just get on with writing your programs? For example, I am constantly frustrated by using GOSUBs where i could/should be using nice tidy procedures... sometimes only 1 or 2 lines long!
    Hungry Horace
Quote
In order to get it to be as fast as, say... SAS/C, it would need to be totally reengineered to use register-passing.  All extensions would need to be reengineered to take those changes into account as well.
    SamuraiCrow
Quote
Putting in 100 hours work to gain 1 millisecond performance is a waste of resources
    MadAngus
Quote
maintain support for current code in AMOS Pro, AMOS The Creator, Easy AMOS, Supports both the 1.3 and 2.x1 extension formats
    bruceuncle
Quote
All original commands should remain for compatibility to older code, if they could be optimised without braking compatibility, I do not see why not.
    MadAngus

So from the comments in the thread we surmise this into two categories

a.)What to optimise.
This really comes down to analysis of two types, Visual perspective and Profiling.

With visual perceptive (qualitative analysis) it is simple a case of comparing one technique to another and seeing if the difference can be detected visually while the program is running.

Profiling would most likely be the preferred method whereby measures of space (memory) or time complexity of program, the usage of particular instructions, or frequency and duration of function calls can be analysed and turn show the weakest areas of the program. Any qualitative analysis could also be verified by this technique.
Wikipedia is my friend

In additional the benefit of any optimisation should justify the workload that it entails.

b.) Compatibility
I doubt we would be very popular if any optimisations implemented would render all past code redundant requiring the rewrite of said code or extensions to work in the new distribution.

Unless compatibility considerations are completely disregarded, re-engineering the code using alternative techniques may not be the way to go.


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.

AMOS Pro interpreter and compiler in C
Quote
I guess now I can shelve my plans to write a new AMOS Pro interpreter and compiler in C.
    Sidewinder
In regards to the above, I wouldn't say that, you could develop a new AMOS Pro interpreter and compiler in C and make it compatible with old amos code or you could work on an optimised AMOS Pro interpreter and compiler and submit it for integration into the core code. The options are yours to choose.

Here are a few areas that could come under the inline development environment. (Actually their on my wishlist)
AGA support.
TOME Resourced and redeveloped.
Alternative interface.
EasyAMOS tutor for AMOSPro.


Other questions raised:

Which code repo to use, if any? SVN, GIT, HG, CVS
Discuss pros and cons and preference. Maybe a poll.

Language used, stick with 68k assy or port to c.
In the first instance it may be best to stick with the current code language (68k assy) during stage 1 and 2. After these stages a port to c debate could be started.

Could any of the xAmos code be used.
Should development of implementations be designed to be portable so that xAmos can make use of them.
Simple answer, no, as the workload required to port to and from xAMOS would be at the detriment to the actual AMOSPro project.


Project management:
I think I'm running out of my Daily Man Word Count!

Based on the docs I attached on the bottom of this post -> Here (http://www.ultimateamiga.co.uk/index.php/topic,9520.msg44399.html#msg44399), I'll draw something up and submit it. You may want to download these and provide comments/criticisms etc.

Other things to think on:
Project Website
Feature voting system
'Official' versioning system

Plagiarism aside what do you think?


Finally -

Wheres our local hero Spellcoder, we would really appreciate yours and Lonewolf10's opinions, especially with the amount of work that has been done on AmigaCoding and your exquisite knowledge.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on October 02, 2012, 01:51:06 AM
Thanks for such a comprehensive overview MadAngus.   8)  And thanks to everyone providing comments and suggestions - keep them coming.

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

Step1   Collate all the responses and requests.  MadAngus already doing a good job with this.  I think we need a separate repository for all this stuff as there is useful commentary going on in other threads.  We'll lose it if we don't centralise it soon.
Step2   Agree the deliverable model - AMOS Pro Vx.x
   Isn't the final model just this?:

AMOS Pro Core
  Launcher
  Editor
  Monitor
  Compiler
  LIBS:amos.library
  AMOS private specialised library set (helpers) - All *.Libs not prefixed AMOSPro
  AMOS public library set (the language itself) - All *.Libs prefixed AMOSPro
All other functionality is implemented through Accessories written in AMOS itself (if you see my point  :))

This provides the boundary line for what is 'in' the project and what is 'out'.  The 'scope' of the project.
Step3   Document the above and that's Stage 1 complete.
Step4   Using the same scope:  fix bugs;  fix 'unusual' behaviour but only where it will not break existing code;  optimise where possible without breaking the model.  Document all the changes.

And I would definitely rule out register passing for parameters here.  Not just for the effort involved in changing the entire model, but because it's not that overhead that slows AMOS down (see end of this post).  And, as I've previously stated in this forum, Francois went to a lot of trouble to allow easy integration of machine-code into an AMOS program.  Where AMOS is too slow for you, that's the time to learn a bit of assembler and speed it up yourself.  If it's a specific set of functionality, maybe even write an extension.
Step4   Document the above and that's Stage 2 complete.

The above is a lot of work  ::), so I won't speculate any further.  There are many routes that could be taken after that work is complete to get to an AMOS Pro V3.x.  I would hope that we'll have the experience after the above load of work to know which is best at that time.

But the point MadAngus made is very pertinent:
Quote
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 :)).
In the meantime, we're information mining.  So any references people feel would be useful, from this and any other forums, please let us know.  We also don't want to re-invent the wheel  :-[ as there's a lot to do already!

Note on performance in AMOS.
Any compiler has to make compromises.  It doesn't 'know' what the programmer intended, so it has to treat all high-level instructions as equal.  It may attempt to 'recognise' some common programming constructs and choose to use a different method to gain a little speed.  But the extent of that functionality is limited by cost versus gain.
The 'hit' on performance is a cost-per-instruction in the compiler.  (And much more obvious in an interpreter where it includes operator tokenising and look-ups - all small, but significant, 'time wasters' when compared to assembler code.).
So, if an instruction is very powerful and can do a lot of work, it can appear to be very fast.  All its code is machine-code dedicated to doing that complex task as fast as possible.  For example, Copy Start,Finish To Destination  is fast because its cost-per-instruction is pretty negligible compared to what it does. 
At the other end of the spectrum, Rol.l Number,BinaryValue is only a few machine-code instructions.  The overhead of its cost-per-instruction hit is much higher compared to what it does.  Bear in mind that this includes fetching the BinaryValue from the variable storage.  Tiny but significant as, if you programmed it yourself in assembler, that Rol.l would be in context and would probably only involve registers.
Don't get the wrong impression.  I'm all in favour of doing whatever we can to get the best possible performance out of compiled (and interpreted!) AMOS.  I just want people to realise that there are obvious limits and to see what those limits are.

So I'll keep pushing my own agenda  ::)  "If AMOS isn't fast enough, do it in assembler and integrate it!" 

Use AMOS to do the grunt work setting up an application.  Then optimise any necessary bits with integrated assembler.  If you're getting that close to performance issues in an app, the step to assembler is pretty easy.  You're probably already doing some rough pseudo-assembler with Peek, Poke, Deek, Doke, Leek, Loke, Rol.l, Rol.w, Rol.b, Bchg, Btst, Bset, etc, etc anyway. :)
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on October 02, 2012, 04:58:36 PM
Devils Advocate:

Quote
Note on performance in AMOS...
Yea, I know I don't know what I'm talking about, more's the fun. Folks if you disagree with bruceuncle's agenda then profile/document your ideas and prove that they should be implemented. Evidence based.

Now I'm going to jump into the bunker before bruceuncle lobs a grenade my way. :o
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on October 03, 2012, 02:50:21 AM
Quote
Yea, I know I don't know what I'm talking about.
After doing some reading of documents and the Dragon book, I've been thinking about the above comment I made.

I have serious doubts about my suitability as any kind of project manager. This is obviously due to my lack of knowledge of 68000 assembler, the AMOS architecture and compiler/interpreter development in general.

The possibility of a new AMOSPro release has happened far sooner than I expected. I believed that this would take place around the end of next year giving me a year to do some intense studying in relation to this project.

With the likelihood of the source being available within the next couple of months there is no possibility that i could be upto speed to do this role justice or keep up with the technical discussions that are no doubt going to take place.

I'm going to withdraw myself from this role and step back, I'll continue with the general documentation side of things in the AMOS Manuals / AMOS resource kit so I'll still involved in that sense.

Instead I am going to focus on the learning side of things with the aim of researching and developing some of the wishlist items that I have, i.e. 'Alternative interface', 'EasyAMOS tutor for AMOSPro', 'TOME Resourced and redeveloped' and 'AGA support'.

As these are side projects I can progress on them at my leisure as my knowledge increases.

Not to fear, If i think I have something to contribute during the development I will jump right in. :)
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on October 03, 2012, 07:17:00 AM
I wouldn't worry too much about the timescale MadAngus.  It will probably take around twelve months before anyone understands the V2.x sources.  This is a complex system and I don't think anyone will be able to jump right in and make immediate value-judgements on where to go with it in terms of change.

I'm assuming (always a bad mistake - "All projects fail on assumptions.") that the Stage 1 and Stage 2 approach will be the necessary grounding in AMOS Pro architecture that we'll all need before we can move it into V3.x in any meaningful way.  And I can't see that happening inside of that timescale.  I've done enough 'looking around' in V2.x to see that it does differ significantly from the public V1.3 sources currently available.  So even someone steeped in that knowledge is going to find it 'challenging'.  Add in the French-English translations required to understand some of the comments and it gets time-consuming to say the least.  It's one thing to generate complex source whilst in the middle of programming something.  It's another thing entirely to understand that source years later without any access to the thoughts and processes that went into the design.

Anyway.  I'd vote for MadAngus to retain project management of the documentary stages.  He does a great job with it and has more energy than I've seen around lately.  When it gets to the actual change-management stages and understanding the code/architecture/intent required for that task, I'm pretty sure another year will have passed and maybe MadAngus might feel different then?

And we need someone to collate all these requests right now, don't we?

In the meantime, when the sources are available, if anyone wants to jump right in and play with stuff, then there's no reason not to.  Just bear in mind that, to me at least, the major objective of the project is to make available an 'approved' AMOS Pro software set that people can rely on.  That's all.  And I think that fits very well with the objectives of the AMOS Pro Resource Kit Project that MadAngus has so heavily promoted and pushed along.

PS.  I'm the world's worst project manager.  It took me years to achieve that happy state.  I'm happy to stay that way.  ;D
Title: Re: AMOSPro re-development general speculation
Post by: Hungry Horace on October 03, 2012, 07:24:42 PM
Quote from: Spellcoder on September 24, 2012, 07:22:59 PM
Great news! I've just today received permission from Francois to have Pietro release the sourcecode :D.

Just going back to the all-important element of this that it is all too easy to lose track of.... any news on the actual source release?
Title: Re: AMOSPro re-development general speculation
Post by: SamuraiCrow on October 04, 2012, 12:28:31 AM
MadAngus:
The Dragon Book is a hard book to get through.  I wish I had a copy though.

If time is a concern for AMOS 3.0, I'd suggest looking into some compiler middleware such as LLVM to take care of the optimization.  Sidewinder had expressed an interest in making an AROS 68k backend for LLVM.  Since he made the x86 LLVM cross compiler for AROS, he's probably the most qualified person to talk to on the subject.  I think the hardest part would be producing Amiga Hunk-style binaries instead of the ELF binaries used by AROS.

BruceUncle and Thread:
The problem with trying to update the AMOS compiler is that it generates non-optimal Assembly code internally.  All of the function/procedure calls use stack-based parameter passing.  Register loading optimization is not a trivial task to get encumbered with Assembly code writing.  I think the best way to fix it is to look into another open-source compiler with more extensive optimization techniques regardless of the language it's written in.

If AMOS 3.0 generated C source code or some other intermediate code like LLVM bitcode, we could use the optimizer of that compiler to get around the shortcomings of AMOS' primitive code generator.  The main obstacle to this is that advanced compilers require more memory to operate than what the average Amiga has.

Optimizing assemblers such as VAsm or DevPac only do a "peephole" optimization technique while a macro-optimizing compiler can do much more advanced rearrangement of code including branch-elimination, register-loading optimization, function inlining, an occasional loop-unroll, and others.

Of course this will have nothing to do with the 2.1 release of AMOS but I propose that the 2.1 release be the last version of AMOS to try to compile on a 1 Meg system.  This will give the compiler room to operate when generating much more optimal code.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on October 04, 2012, 04:12:50 AM
Quote
Of course this will have nothing to do with the 2.1 release of AMOS but I propose that the 2.1 release be the last version of AMOS to try to compile on a 1 Meg system.
Agreed.  And thanks for the feedback.

I'm pretty convinced that we need to get to V2.1 before we decide how to get to V3.x.  There are some problems with AMOS Pro that are nothing to do with performance - compiler crashes, inconsistent limits, 'odd' behaviour, other bugs, etc.  I think we need to fully understand how to fix all that within the current architecture before throwing it open to any approaches that attempt to fix performance issues by changing the architecture.

That gives us the stable base on which to build.  I don't think it would be much fun trying to both fix bugs and radically change the architecture at the same time.  We've also got to understand what effort would be involved in any post-V2.1 developments.  We may be in a non-commercial environment but I see no point in spending an excessive amount of time to shave milliseconds here and there.  That effort would be far better spent on rationalising extra functionality.  And encouraging integration of machine-code in an AMOS app where speed becomes an isssue.  I'm definitely not saying we don't so any optimisation (it would be hard to resist  ;) ) but we need to keep it in perspective.

My own wish would be an ability to add in-line assembler to AMOS.  Something simple along the lines of Asm On  and Asm Off instructions with everything between being DevPac syntax (for source compatibility with the AMOS includes).  And using the existing Areg  and Dreg  instructions to communicate.  Not as a core language feature, but as an Extension.  I remember seeing something mentioned about an AMOS assembler way, way back in time.  Anyone know if it went anywhere?

There's a lot of interest in AGA support.  Could those interested define what aspects of AGA they want to use?  I've only just started looking at what's involved with AGA (more precious time stolen when I should be documenting, but all work and no play... etc.)  Came across this page which looks interesting:
http://www.mways.co.uk/amiga/howtocode/text/aga.php (http://www.mways.co.uk/amiga/howtocode/text/aga.php)

I'm new to today's Amiga environment.  So I may well come across stuff that's old hat to some people in this forum.  Please let me know  :)
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on October 04, 2012, 05:40:08 AM
I'll just have classify it as a challenge, time to slay the Dragon.

It seems to me from reading these posts there are two ideologies developing indicating that v2.1 AMOSpro could get forked into two architectures. Which is not a bad thing. :)

Quite possibly as follows.

Note: User code: The code that a user developes for their own project (not the internal code of AMOSPro).

AMOSpro Classic:
AMOSpro as is whereby bug fixes are implemented and any optimisations/additions that provide a distinct performance gain or user/developer benefit are integrated, AGA support for example. Of course optimisations/additions should be compatible with the 2.1 model and user code.

AMOSpro (Add working title here):
A complete new architecture developed (for the Amiga) based on the current model (even loosely). It would be sensible to add a constraint to this in that it supports, compiles and and is backward compatible to any legacy user code from AMOSPro classic.

For me project management would stop at the AMOSPro Classic architecture and enhancements. For a complete new Amiga AMOSPro architecture someone else can take up the project management reins.

Quote from: MadAngus on September 09, 2012, 04:49:48 AM
This thread is a holding place for the discussion of hacking, updates and future versions of AMOSPro for Amiga 68k.
I would like to remind everyone that this thread is for discussing any AMOSPro ideologies, architectures, potential enhancements etc, etc, as I suspect many of them will cross over.

When it comes time to focus on the development within a specific framework a new thread will be created for that purpose with this one being used as a reference point.

Nothing is fixed here, consider this a think tank.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on October 06, 2012, 02:03:00 AM
On a little side note, I would like to highlight that my referral to Dimac in a previous post is a martial art referenced in the book The Book Of Ultimate Truths by Robert Rankin.

Author of:
The Sprouts That Ate Christmas.
The Occult World Of XML And Norman.
The Haberdashery Book Of Weaponry.
and other such books that may or may may not exist.


Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on October 09, 2012, 12:48:24 AM
For anyone interested in 68000 optimisation, I've attached the Instruction Execution Times pages from Motorola's 68000 manual.

Makes interesting reading if you've never tried working out how many clock cycles your code is taking.  Take particlar note of the cost of interrupts - all the internal calling from one relocatable-code-block to another in the *.Libs files uses the FLINE interrupt.  It's the cost involved for having a small executable when the code's compiled.

[Edit by MadAngus 9/10/12] Nothing serious. Changed the attached file name, filled the spaces with underscores. The download system truncates the name to the first found space and leaves everything else out including the extension. It's the same file.
Title: Re: AMOSPro re-development general speculation
Post by: SamuraiCrow on October 09, 2012, 05:55:01 AM
Keep in mind that AMOS was based on the earlier STOS Basic for the Atari ST.  AMOS may still contain evidence of Atari ST-isms as a result.  I think those FLINE interrupts may be one of them.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on October 09, 2012, 06:52:01 AM
Quote
I think those FLINE interrupts may be one of them.

Trouble is, they're what's used to make each 'instruction chunk' independantly relocatable.  So the compiler can 'cherry pick' just the code it needs for the program it's compiling.  Which saved a lot of space as the usual alternative is to plonk the whole library into the compiled executable.  Also allows a 'scatter load' into available memory instead of having to have a contiguous slab available for a full library load.

It's what I refer to as 'the existing architecture' as it's pretty fundamental to the way V2.x works.

Any ideas as to how else to implement relocatable 'instruction chunks'?

If the core AMOS Pro libraries were re-written (not a pleasant task!) to resemble traditional LVO_ libraries, you'd get quite a reduction in the 'per instruction' overheads at the expense of needing more memory.  The big downside of that approach is that all existing extensions would be affected and require re-writing!

Maybe a hybrid approach would work:  AMOS Pro 'core' libraries re-written but the Interpreter and Compiler still able to handle the existing FLINE Extension libraries.  This 'two-faced' approach seems to have been used to enable both AMOS Pro V2.x and V1.3 libraries to still both work despite different formats and 'instruction numbers' for the tokens (deduced from a bit of exploration, so I may be wrong).
Title: Re: AMOSPro re-development general speculation
Post by: SamuraiCrow on October 15, 2012, 03:14:55 PM
If using a standard linker and object files are not going to work easily, then what are the other options?  I don't think many people are running on 1 meg systems any more if additional memory is required.

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

--edit2--
Sidewinder and I discussed a few weeks ago that there might be the possibility of using another extension format in AmosPro 3+ that gets around the extension slot limitation of the AmosPro 2.x so that the older format could be used only with a backward-compatibility "harness" to get it to work.
Title: Re: AMOSPro re-development general speculation
Post by: Hungry Horace on October 15, 2012, 04:37:25 PM
Quote from: Hungry Horace on October 03, 2012, 07:24:42 PM
Quote from: Spellcoder on September 24, 2012, 07:22:59 PM
Great news! I've just today received permission from Francois to have Pietro release the sourcecode :D.

Just going back to the all-important element of this that it is all too easy to lose track of.... any news on the actual source release?

errr....  any news? at all?  :-\
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on October 15, 2012, 08:09:01 PM
SamuraiCrow:
Quote
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:
Quote
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:
Quote
errr....  any news? at all?
At this rate, I'll have all the code "Resourced" before anything happens  ;D

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"  ;).
Title: Re: AMOSPro re-development general speculation
Post by: SamuraiCrow on October 16, 2012, 06:59:48 PM
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 .
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on October 17, 2012, 12:05:22 AM
SamuraiCrow:
Quote
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:

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

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?)
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on October 18, 2012, 10:27:23 PM
Quote
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.   :)
Title: Re: AMOSPro re-development general speculation
Post by: Spellcoder on October 21, 2012, 07:47:42 AM
Quote from: Hungry Horace on October 15, 2012, 04:37:25 PM
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.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on October 21, 2012, 12:11:35 PM
Cheers for the update Spellcoder. 8)

The theme for everyone here is patience. ;)
Title: Re: AMOSPro re-development general speculation
Post by: Spellcoder on November 16, 2012, 08:26:14 AM
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 ;).
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on November 16, 2012, 11:45:06 AM
Quote from Spellcoder:
Quote
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:
Quote
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  ;D.

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.   8) 8) 8)
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on November 17, 2012, 03:13:24 AM
Quote
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.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on November 24, 2012, 02:11:48 PM
Quote
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.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on November 25, 2012, 02:32:10 AM
Quote
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  :o.  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 (http://amigate.8m.com/picasso96.html) for some details.  Plenty more on the 'net - just Google away...
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on November 25, 2012, 04:08:50 PM
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
*-----------------------------------------------------------------------
Title: Re: AMOSPro re-development general speculation
Post by: SamuraiCrow on November 25, 2012, 06:14:52 PM
Quote from: MadAngus on November 25, 2012, 04:08:50 PM
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.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on November 26, 2012, 12:09:34 AM
Quote from: SamuraiCrow on November 25, 2012, 06:14:52 PM
Quote from: MadAngus on November 25, 2012, 04:08:50 PM
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!  ;D

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

Quote from: MadAngus on November 25, 2012, 04:08:50 PM
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:
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.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on November 26, 2012, 11:09:17 AM
Quote from: SamuraiCrow on November 25, 2012, 06:14:52 PM
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 :P).

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.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on November 26, 2012, 06:16:57 PM
Quote from: MadAngus on November 26, 2012, 11:09:17 AM
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:
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 ;).

Quote from: MadAngus on November 26, 2012, 11:09:17 AM
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:
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus 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 (http://www.ultimateamiga.co.uk/index.php/topic,9520.msg44389.html#msg44389)). This must remain Old-Sytle with only appropriate features implemented and/or down-streamed from AMOS 3.x.

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.

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.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle 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.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus 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.
Title: Re: AMOSPro re-development general speculation
Post by: Hungry Horace on November 27, 2012, 08:33:08 PM
Quote from: MadAngus on November 27, 2012, 08:51:48 AM
  • 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
Title: Re: AMOSPro re-development general speculation
Post by: SamuraiCrow on November 27, 2012, 08:43:39 PM
Quote from: Hungry Horace on November 27, 2012, 08:33:08 PM
Quote from: MadAngus on November 27, 2012, 08:51:48 AM
  • 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.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus 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 (http://www.ultimateamiga.co.uk/index.php/topic,9520.msg44790.html#msg44790)), 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
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle 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:


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:


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.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus 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 (http://www.ultimateamiga.co.uk/index.php/board,312.0.html)

Topic unlocked.

All discussion should be kept within the AMOS Professional Re-Development -> General Discussion child board for now.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus 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.
Title: Re: AMOSPro re-development general speculation
Post by: SamuraiCrow on November 28, 2012, 01:38:42 AM
Quote from: MadAngus on November 28, 2012, 01:00:15 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.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on November 28, 2012, 07:49:00 AM
Quote from: SamuraiCrow on November 28, 2012, 01:38:42 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:

For AMOSPro.Lib:

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:

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

AMOSPro.Lib:

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.
Title: Re: AMOSPro re-development general speculation
Post by: ghizzo 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!  ;)
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle 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? ...
Title: Re: AMOSPro re-development general speculation
Post by: ghizzo on December 01, 2012, 07:26:53 PM
Quote from: bruceuncle 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 ::).

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 ;)
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on December 01, 2012, 09:49:22 PM
Quote
i'll wait the next update!

It may be a while...  ;)

There's a lot of useful stuff there in addition to just the sources.  Every little bit helps.  I especially like the status reports/bug reports/etc.  They help complete the picture.

Now back to browsing.  Where's my French/English dictionary? ...

It's very tempting to extract the comments and their positions, put them through a translator and then put them back in place.  I've learnt a lot of French lately and I think fully translated sources would be a good first step.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on December 02, 2012, 01:27:20 AM
Tickityboo, excellent news thank you Pietro and Francois. ;D

More documentation and another digital forest to cut down.

ghizzo, do you have a website you want added to the acknowledgments section.
Title: Re: AMOSPro re-development general speculation
Post by: Spellcoder on December 02, 2012, 07:10:08 AM
Quote from: ghizzo 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!  ;)

Thanks for the work on getting the distribution finished and released! :).

Funny to see previous unknown information, like information on research for PCos (a version of AMOS for the pc).

Are your patches for AMOSPro in there too? (faster amos/wb switching, limit bob fix, compiled amos progs memory deallocation race condition fix, printer fix etc)
Title: Re: AMOSPro re-development general speculation
Post by: Hungry Horace on December 02, 2012, 11:52:47 AM
Many many thanks Pietro!

Great news for the AMOS collective still out there!!
Title: Re: AMOSPro re-development general speculation
Post by: BooBoo on December 04, 2012, 10:53:31 AM
Yes thanks guys  :)
I assume the Amos compiler outputs/stores ASM before the final compile could this ASM outputed exported

Of course if anyone is able to update Amos - AGA screen modes would be great 16*16, id be happy to stay with 16,32 colours sprites/bobs

I think the guys at Shadow softare used an AGA extention for JetStrike - it might be worth contacting them
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on December 05, 2012, 02:07:40 AM
Quote from: BooBoo on December 04, 2012, 10:53:31 AM
I think the guys at Shadow softare used an AGA extention for JetStrike - it might be worth contacting them
Cheers for the input.

I recently read something about this. The AGA extention for JetStrike was specific to Jetstrike and for some reason couldn't be used for other things :(. If I find the details of this I'll post them.

Quote
I assume the Amos compiler outputs/stores ASM before the final compile could this ASM outputed exported
Do you mean export the asm instructions.

This sort of thing:
move.l  (T_EcCourant,a5),a4
move.l  (EcWindow,a4),a5
move.w  #0,(WiGraph,a5)

If so bruceuncle may be able to answer that if his current investigations have got that far.
Title: Re: AMOSPro re-development general speculation
Post by: bruceuncle on December 05, 2012, 11:46:16 PM
Quote from: BooBoo on December 04, 2012, 10:53:31 AM
I assume the Amos compiler outputs/stores ASM before the final compile could this ASM outputed exported

I'm afraid it doesn't work like that if it's assembler source output you're after.  Don't know the full details yet.  But, with the sources now public, you'll find each and every AMOS instruction is implemented as a relocatable code chunk.  Plus some more code chunks for initialisations and common tasks.  As long as your code references amos.library through the AMOS includes, you can use the functionality of those chunks for your own purposes in an extension or embedded code and an AMOS Basic program.

The compiler is quite buggy.  So it will get a fair bit of attention in the redevelopment.  We'll all know a lot more then. ;)
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on December 07, 2012, 08:33:34 PM
Although the ClassicAMOS and AMOS 3.x boards are specifically for the actual development, these boards are open to all.

Please post wisely as I do not intend to spend a lot of my time moving posts and topics.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on December 08, 2012, 10:09:05 AM
Sorry folks I've decide to steal back the AMOS Evolution name for the future of Deimos which will now be named Avolution (AMOS Evolution). The board will be renamed to reflect this and will be specifically for development of Avolution.

I'll create a new board for AMOS Pro 3.x when the time comes to update it past the ClassicAmos development stream.

[Edit]
I've changed all the 'AMOS Evolution' references in previous posts in this thread to 'AMOS Pro 3.x' to avoid confusion.
Title: Re: AMOSPro re-development general speculation
Post by: Lonewolf10 on January 05, 2013, 01:00:06 AM
Quote from: rayon on January 04, 2013, 04:51:40 PM
@bruceuncle:
I've seen your AMOS overview and it is a great document to get an understanding of the overall architecture of AMOS.
Also the quality is good, I like it, short simple but understandable!

I agree :)


Quote from: rayon on January 04, 2013, 04:51:40 PM
- Is there a known issue / bug list?

Yes. A few bugs are listed on the www.AmigaCoding.com (http://www.AmigaCoding.com) website.
Title: Re: AMOSPro re-development general speculation
Post by: MadAngus on January 06, 2013, 11:52:24 AM
I've locked this topic, interested parties should now create more specific discussion topics.

If you need me to split posts in this topic into a new thread for specific discussion please inform me.

bruceuncle if you think I should unlock this topic please pm me.

[Edit] I've merged the 'AMOS Pro 2: Known Bugs', 'AMOS Editor workbench window', 'TOME Re-Development', 'AMOS Pro Tutor Project' threads from the ClassicAMOS Development Board to the duplicates in the Feature requests and bug reports.

These can be added to the ClassicAMOS Development Board when the actual development/release cycle begins.