Print

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

[bruceuncle]

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]

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

¹ - 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.   
Lots and lots of stability. 
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?

[MadAngus]

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.

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.

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.' 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 , 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.

[MadAngus]

What are your views on where we go after docs?

Let me Start again. I got carried away

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.

[bruceuncle]

I suppose the important bit missing from those stages is the full stop after Stage 4.   

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:

• AMOS, in all its varieties, was aimed squarely at making the process of programming the Amiga's exquisitely unique hardware accessible to just about anyone.
• Thus, it is inextricably bound to the Amiga's hardware model and the 68000 processor family.
• The demise of the Amiga line meant that AMOS never went through the update/upgrade cycles that other languages usually do.  So there's a bit that needs fixing here and there.
• Whilst I could wallow in the nostalgia of it all as is (bugs, extensions and docs as released) I would want to remedy that dilemma.  And knowledge is only valuable if it's spread into the community.
• After all this time, it's a lot easier to take stock, knowing that there is a limit to what can be done (hence the missing full stop).  Some of what may, today, be seen as restrictions (only 320 x 256 in how many colours??!!) were in part responsible for its success.  A standard A500 could only shift 16 million pixels a second and attempting any modern-day graphics with those capabilites would be impossible.  But within those original limits, an Amiga was, and still is, a blindingly fast, innovative machine.  The later models only improved on that situation (faster processors, more memory, AGA chip set, and any others I've left out  ).
• So, my great joy was in discovering that Amiga emulators exist on all sorts of platforms.  And they work!  Down to the finest detail.  I no longer have to regret abandoning my Amiga 2000 all those years ago as I've now got one on my PC.  And my favourite programming language of all time, AMOS, can be used to its full extent.  (Okay, Messysoft's Visual Studio Express and XNA Game Studio are pretty cool.  They're free too.  But aimed at a completely different - some would say boring - machine architecture and programming model.)
• Now move the clock forward to today.  The importance of that full stop is that moving away from the Amiga architecture for a language like AMOS will inevitably end up with something that isn't AMOS. What meaning do some of AMOS's instruction set have in a non-Amiga environment?

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  series is on telly over here in 5 minutes - gotta go)

[MadAngus]

Lots of good points there.

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

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

[Spellcoder]

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)

[MadAngus]

You are my hero,

Big kiss 

yuch!

Excellent work, fingers crossed.

Before someone spends days diving into resourced code...

Bruceuncle don't look, Opps, too late.

[bruceuncle]

Awesome!   
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.

Bruceuncle don't look, Opps, too late.

MadAngus - too late! 

[MadAngus]

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

[Spellcoder]

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

[Spellcoder]

Great news! I've just today received permission from Francois to have Pietro release the sourcecode .

[Hungry Horace]

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!

[MadAngus]

Great work Spellcoder! Look forward to having it hosted here!

I'll second that, excellent.  Spellcoder is

[bruceuncle]

And I'll third it!  (MadAngus's reply came through while I was typing mine  ).

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! 

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

[MadAngus]

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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

I'll leave it there for now, I could go on for another fifty pages on this.