Ultimate Amiga

Network Boards => AMOS Professional Re-Development => AMOS Factory => Feature requests and bug reports => Topic started by: Lonewolf10 on January 19, 2013, 09:35:59 PM

Title: AMOS Pro 2: New feature suggestions List
Post by: Lonewolf10 on January 19, 2013, 09:35:59 PM
Hi,

Just starting this thread as I can't seem to find one that would be appropriate for the following suggestions. Feel free to add your suggestions or feedback.

*** NB:  AGA, TOME and bugs are discussed in other threads ***


 - The ability to view a list of all labels within a program via editor menu
 - The ability to view a list of all Procedures in a program via editor menu
Title: Re: AMOS Pro 2: New feature suggestions
Post by: MadAngus on January 22, 2013, 12:09:31 AM
Quote from: Lonewolf10 on January 19, 2013, 09:35:59 PM
Hi,

Just starting this thread as I can't seem to find one that would be appropriate for the following suggestions. Feel free to add your suggestions or feedback.

The Feature requests and bug reports board (This board) is for just that ;).

As there isn't a list of features thread we can use this thread as a place to list them, but no discussion.

Please create a new separate discussion thread for each feature.

Title: Re: AMOS Pro 2: New feature suggestions
Post by: Umpal on March 28, 2016, 02:22:07 PM
I don't know how about you guys but I miss a lot Syntax Highlighting feature in AMOS Editor.
This is how it could look (don't mind colors, it's just an example and the palette could be adjustable):

(http://s5.postimg.org/4rp0byu7n/AMOS_Syntax_highlighting.jpg) (http://postimg.org/image/4rp0byu7n/)

And compared side by side:

(http://s5.postimg.org/7n23ity7n/AMOS_Syntax_highlighting_compare.jpg) (http://postimg.org/image/7n23ity7n/)
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: bruceuncle on March 28, 2016, 04:18:59 PM
I'm using my phone so I'll reply in full tomorrow. I worked on this while I was in hospital and in physio, and it's very possible.  Downside is that it slows the editor display down by a factor of three!  The editor cunningly arranges matters so it only has to write text to one biplane, which is why the editor is quick.  So slow Amigas would probably choke a bit on an eight colour display using all three biplanes.

Looks good.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: SamuraiCrow on March 28, 2016, 04:29:45 PM
Using the Copper list to scroll each line of text would work well for 3 bitplanes.  All that is needed is a y-unlimited tile scrolling algorithm like in the Amos remake of Horace Goes Skiing.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: Umpal on March 28, 2016, 06:54:20 PM
Quote from: bruceuncle on March 28, 2016, 04:18:59 PM
I worked on this while I was in hospital and in physio, and it's very possible.

You, sir, just made my day  ;D

Quote
Downside is that it slows the editor display down by a factor of three!

Fine by me! We can safely assume that nobody's using a non expanded Amiga for coding nowadays ;)
I will ask all my family to vote for such feature if it helps ;D

Quote from: SamuraiCrow on March 28, 2016, 04:29:45 PM
Using the Copper list to scroll each line of text would work well for 3 bitplanes.  All that is needed is a y-unlimited tile scrolling algorithm like in the Amos remake of Horace Goes Skiing.

Sounds fantastic but if it requires a whole new routine for the editor then I guess it's too complicated and time consumer. I've read some posts and I see you're involved in fixing the sources too so I keep my thumbs up for éxito in this matter. Will see what Uncle says tomorrow as it seems he already have something in his pot (http://www.freesmileys.org/smileys/smiley-forum/stirthepot.gif) (http://www.freesmileys.org/smileys.php)
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: Umpal on March 28, 2016, 10:16:14 PM
I would embrace another upgrade to actual AMOS Pro 2.xx: Instruction Select Case.

(http://s5.postimg.org/3kkpulzsj/AMOS_Select_Case.jpg) (http://postimg.org/image/3kkpulzsj/)

This would eliminate a looot of If conditions. Is it difficult to implement? I mean for you guys. What do you think about it?
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: SamuraiCrow on March 28, 2016, 10:47:24 PM
I think the new features should mainly go into the version 3 branch.  2.1 has been declared as a bug-fix release.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: Umpal on March 29, 2016, 01:24:22 AM
You are right, I agree. Fixes first! But for the other hand... If something could be quite easy to introduce and really useful then I would give it a go before because, let's be honest, version 3 is not going to happen very soon. Correct me, but introducing one by one feature is much easier than making a whole bunch of instructions that need a lot of internal and then beta testing, and then fixing and then... Of course all is possible but we, especially you guys doing this wonderful stuff, are limited by time. Just my cent. I wish you the best on this project with all my heart.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: bruceuncle on March 29, 2016, 02:38:55 AM
Quote from: bruceuncle on March 28, 2016, 04:18:59 PM
I'm using my phone so I'll reply in full tomorrow. I worked on this while I was in hospital and in physio, and it's very possible.
The text you see on the editor's screen gets there from a buffer.  The buffer uses fixed length text lines, each 256 bytes long.  So the code can find any cursor position by multiplying the Y coord by 256 (shift eight bits to the left).  By increasing each line to 512 bytes, the second 256 bytes can hold the colour of each character.  Simply offset 256 bytes from a character (eg. 256(An)) to get a character's colour.

The colour bytes can be written into the buffer during the Detokenise process.  This takes a line of AMOS Basic Tokens and converts them back to text for display on the screen.  When it processes each token, the token's type is obviously known and the appropriate colour byte(s) can be derived.  The available types are:

Keywords     AMOS Basic instructions, punctuation, math and logic symbols.
Names     The names the programmer has given to Variables, Labels and Procedures.  It is not possible to split these up and use a different colour for each as Detokenise() doesn't 'know' the context until the program is Verified (the Test and Run process).
Numeric Literals   Any integer, single, double, hexadecimal and binary numbers in the code.
Text Literals     Any text enclosed in single or double quotes.
Comments     Any text following a Rem or '.

A colour also needs to be defined for the inverted display of selected text (blocks).

When time comes to print to the screen, the function just needs to check if chroma-coding is switched on and use modified routines to do the work.  This involves inserting appropriate 'escape' sequences into the text each time the colour bytes change value.  So the output has to be buffered (using the general purpose Buffer(A5)) then printed as a text string.  This is much faster than doing it character by character to the screen.  There are a few places where single characters are output to the screen (eg. as you type stuff in) which would default to the Keywords colour.  The chroma-coding would occur as you move off the current line, in the same way that AMOS 'corrects' text case and spacing now when you move off a line.

I did a mockup of what it could look like a while back (program attached) that looks like this:

(http://s19.postimg.org/ahor94uvn/Sample_Chroma_Coding.jpg) (http://postimage.org/)

The stuff at the top of screen was just to see what standard palette colours look like.  Modify the AMOS code to try different colours.

In addition, the text case for Keywords and Names is already implemented in AMOS Pro.  The settings are in the editor config file (DtkMaj1 and DtkMaj2) but not currently editable.  So they're fixed as mixed-case for Keywords and upper-case for Names.  The options are mixed-case, upper-case or lower-case.  So you could have Keywords in upper-case and Names in lower-case if they were made editable (see 'prrof of concept' below).

There's also seven longwords of free space available for 'future use' (thanks François!) so storing the chroma-coding settings is no problem - one byte each:

Ed_Chroma_Keyword
Ed_Chroma_Name
Ed_Chroma_Number
Ed_Chroma_String
Ed_Chroma_Remark
Ed_Chroma_BlockColour
Ed_Chroma_Flag


The flag is used to switch chroma-coding on and off as not everyone likes to use it.

I did a 'proof of concept' for the DBL code needed to write a dialogue to edit all this (file also attached - excuse the messy, this was just to see if it was feasible - it is  ;) ).  It looks like this:

(http://s19.postimg.org/iyo9k1zkj/Options_Dialogue.jpg) (http://postimage.org/)

And with a dropdown for the colour selection:

(http://s19.postimg.org/41fsj1mc3/Options_Dialogue_plus_Colour_Dropdown.jpg) (http://postimage.org/)

The layout and design leave a lot to be desired, but this was just to prove it's possible.  It's one thing to work out how to implement chroma-coding and another thing altogether to enable the user to set it up!  I would move the dropdown buttons to the right of each colour and drop the dialogue down there rather than over the colours as in the above.  Also, there's no labels for the text case three-state buttons (I just wanted to see if three-state was possible).  I envisaged a sample window on the right to display what the result looks like - would have to be a machine code program to get the necessary speed.  Anyway, these are just musings.

I've attached the AMOS progs that produced the above screens.  You'll also need the attached AMOSPro_Default_Resource.Abk file to replace the original in the APSystem directory of your AMOS installation.  It contains the images for the multi-state buttons and some revised DBL code for the file selector.

The Select Case you speculate on is just not feasible without major code changes.  It's a structural instruction (like Do ... Loop and If ... Then ... End If) that needs offsets inserted during Test and Run and would require major changes to the Verify() code.  Any changes that affect program structure are almost impossible  :( . 

Now, back to the bugs as this is all enhancement and not fixes!  And now I'm recovering and more active, I want to get stuff out there instead of just talking about it. ;D
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: Umpal on March 29, 2016, 04:53:44 AM
I'm speechless! It's something I didn't expect or at least not so fast. I know it's not done yet but from my post this morning to what you say and present is just amazing. I played with your code like a kid back in 1982 with River Raid. Let me express it this way:

(http://arabuusimiehet.com/break/amiga/img/3000/3829.PNG)

Quote from: bruceuncle on March 29, 2016, 02:38:55 AM
The available types are:

Keywords     AMOS Basic instructions, punctuation, math and logic symbols.
Names     The names the programmer has given to Variables, Labels and Procedures.  It is not possible to split these up and use a different colour for each as Detokenise() doesn't 'know' the context until the program is Verified (the Test and Run process).
Numeric Literals   Any integer, single, double, hexadecimal and binary numbers in the code.
Text Literals     Any text enclosed in single or double quotes.
Comments     Any text following a Rem or '.

I went too far with the numbers of colors on my mockup but of course I was aware of certain limitation. Even if it's five as listed above, I and many others will be super happy (I couldn't resist and I posted info about it on Polish forum ppa.pl - naturally my joy has been shared  ;D).

Quote
The stuff at the top of screen was just to see what standard palette colours look like.  Modify the AMOS code to try different colours.

Yes, I did that and I spent on it more time than on any other game recently  ;D

Quote
In addition, the text case for Keywords and Names is already implemented in AMOS Pro.
There's also seven longwords of free space available for 'future use' (thanks François!)

I join in those thanks!

Quote
And with a dropdown for the colour selection:

Wouldn't it be more user friendly and nicer for the eye if instead of dropdown list you added a line of colour boxes in a row? It would give the user a complete view of all colors and selection made. Just an idea, I'll accept whatever it be, even if I had to hex-edit all the values  ;D

I'm very positive and can't wait to see the result!

Quote
The Select Case you speculate on is just not feasible without major code changes.  It's a structural instruction (like Do ... Loop and If ... Then ... End If) that needs offsets inserted during Test and Run and would require major changes to the Verify() code.  Any changes that affect program structure are almost impossible  :( . 

No worries. I'm not surprised. Deep inside I knew it won't be easy so let it be, if accepted, as a v 3.0 feature.

Quote
Now, back to the bugs as this is all enhancement and not fixes!  And now I'm recovering and more active, I want to get stuff out there instead of just talking about it. ;D

(http://www.desismileys.com/smileys/desismileys_4547.gif) (http://www.desismileys.com/) Sticking here for any update.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: PerspexSphinx on April 11, 2016, 08:37:51 PM
Colour syntax highlighting in Amos really would be most useful and helpful. Your demo is a tantalizing glimpse, please make this an implemented feature.

Great stuff!
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: PerspexSphinx on April 11, 2016, 08:48:35 PM
Oops, didn't mean too post twice... I'm just excited I guess.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: SamuraiCrow on April 12, 2016, 06:18:48 AM
Quote from: PerspexSphinx on April 11, 2016, 08:48:35 PM
Oops, didn't mean too post twice... I'm just excited I guess.
I fixed it.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: Umpal on April 12, 2016, 09:53:55 PM
@bruceuncle, any update regarding the Syntax Highlighting? Not pressing, just curious.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: Hungry Horace on February 28, 2017, 12:08:07 PM
I am reassured to see BruceUncle was last online late this January!
 

I was just wondering... how difficult would it be for someone to add an option to save out a text version of the .amos file on each save? (.amost or something)

This would be great for putting AMOS code on something like GitHub, where we would still be able to see any proposed changes to code :)
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: SamuraiCrow on February 28, 2017, 01:59:28 PM
AmosPro can output ASCII text already but you can't embed banks in text files like you can with  .amos files.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: Hungry Horace on February 28, 2017, 08:18:56 PM
yes but to do that, you have to highlight text, store it, and save seperately.

I was suggesting an option to save a text file *adjacnet* to the .amos file (not instead of) which therefore covers off the concern about the stored banks :)

This is so, when using GitHub or similar services, you would be able to see the code changes in the preview windows etc. Obviously the .amos file would just be shown as a binary file.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: bruceuncle on April 03, 2017, 01:49:11 AM
Quote from: Hungry Horace on February 28, 2017, 12:08:07 PM
I am reassured to see BruceUncle was last online late this January!

Yep, still here!  I've not been posting much lately for two reasons:
So I've been quietly "getting on with it" and only posting where I can contribute something useful or if info needs correcting.


Getting back to the original question (saving in ASCII) of course it can be done but it wouldn't really be worth the effort involved (=lots).  Remember that an ASCII save does not automatically open any closed procedures.  But what's wrong with a few keystrokes?:

<Amiga>+<Shift>+<O>         Open all Procedures
<Ctrl>+<A>Select All
<Ctrl>+<S>Store Block
<Ctrl>+<Shift>+<A>Save Block as ASCII

Admittedly you'll have to enter a file name and hit <Esc> to go to Direct mode and <F7> to save any banks...

Onwards

There are a few enhancements which I did feel worthwhile:

Syntax Highlighting
The interface for the necessary Editor Configuration screen is complete.  I've stolen a few bytes out of the Editor Config file (and it's A5 offsets when loaded) to contain the data.  This lead to the need to add a new Menu Item to the Editor Config Menu which, in turn, meant having to decode and understand how the menus work...  Suffice to say we now have sources for the Editor_Menus.Asc and Editor_Menus.Bin files.  And I also know a heck of a lot more about how the Editor Function and Key Tables work, along with their associated Autoload Programs and parameters.  More to do but going really well.  May be a bit too slow for an un-accelerated A500 or A2000 but you can switch it off (and who'd want to actually develop in AMOS on an un-accelerated machine?)

Editor Scrolling
Now that I now how the Function and Key tables work, pretty easy.

The Future
Having had (too much!) time to reflect on how we would eventually move into accelerated  Amigas, AGA chipsets and OS 3.x, I completely changed my mind as to how we should approach this.  Trying to shoehorn all the variations into the existing libraries and code just gets far to complex and cumbersome.  So what I propose is:


Bugs
Just about all sorted (for the "known" bugs anyway).  The glaring exception is the Compiler, which I've put away on a shelf until the rest is completed (don't want the distractions!)  It does however incorporate some of the bug fixes that affect ASCII to numeric conversion as the code and bugs were the result of a simple "copy/paste and change the label names" which just propagated the original bugs.

Info Needed
Does anyone have any better code for detecting CPU and Chipsets than what was originally published in the  How To Code V7 (http://plantmonster.net/koodailut/amiga/template/amigaexamples/Manuals/HowToCode7.pdf) series?

Anyone have any better code for FFP-->ASCII and ASCII-->FFP conversions.  The original is ported C Code and is ugly, inefficient and doesn't give me any indication of overflow or underflow (apart from a high-values in the exponent).  Tempted to replace with the original Motorola code for FFP (https://github.com/cloudkitsch/n68k/tree/master/programs) as it's compact, efficient and does indicate if anything went wrong.  Similarly for Double Precision which has the above problems but on a much larger scale.


That's about it for now.  Any comments welcome as usual.  Must get on with it.
Title: Re: AMOS Pro 2: New feature suggestions List
Post by: SamuraiCrow on April 03, 2017, 03:48:52 AM
There have been some problems detecting the Apollo 68080 and SAGA chipset cores by traditional means....  :-)

The AMCAF extension had a function for checking for the AGA chips called IsAGA.  Perhaps we can do something like it for ECS also on Kickstart 2.  The SuperAGA on the Vampire accelerator will be trickier since it runs on Kickstart 3.1 also.

The chipsets should be checked at runtime is the point I am getting to.  That's how the OS does it.