AMOS Pro 2: Known Bugs List

[MadAngus]

Here is a list of known bugs from amigacoding.com. Details can be found on the AmigaCoding bugs page

Please only list and describe your bug here. For discussion a separate thread should be created.

Listed on amigacoding.com

Compiler bugs

• many data statements will crash the AMOS(Pro) compiler
• length of banks are rounded when compiled
• "Not An AMOS Program" error when compiling

Various

• if text from Input command reaches the right side of screen, AMOS will freeze for a while
• 'Track Loop Of', is misspelled
• Track Load will load a music module into Fast RAM if there isn't sufficient Chip RAM causing Track Play to crash the system
• Sam Load will load a sample into Fast RAM if there isn't sufficient Chip RAM
• Using the tab (",") function can cause a number to be printed!
• The Reserve as Work bank command doesn't allocate memory properly causing a crash after only one or two uses.
• Limit Mouse sometimes fails to limit the mouse correctly.

Math bugs

• remainder of mod should be negative if given number is negative
• the Add instruction gives bad results if you use the exponential symbol (^)

Editor bugs

• Editor will change numbers that don't fit in 32 bit
• Editor crashes when running programs with commands after data statements

Helpfile bugs

• Several articles wrongly linked
• Two articles are cut off halfway

Reported Bugs - I'll add any additional bug information I find or is posted in the 'Feature requests and bug reports' Board.'Feature requests and bug reports' board

• Program will not compile (run) if too many ELSE IF's. - Ref
  Discussion Thread
  
  
• Length of Code Line too short... - Ref
  
  
• Global does not allow string literals and wildcards.  So Global "G*" gives a Syntax Error as soon as it sees the double-quotes (single-quotes doesn't work either).  The same applies to Shared.
  
  


• Def Fn and the corresponding = Fn only function at either the global-level-only or procedure-level-only.  You can't declare one globally and use it in a Procedure (which should be fixed).  And you can't declare one in a Procedure and use it globally (which probably shouldn't be fixed - whadda you think?).  Which makes it a bit useless.
  
  


• For ... To ... Next ... Step always performs one iteration of the loop no matter what is specified for the starting, ending and step values.  E.g. For X=X1 To X2 : <do something> : Next X will perform one loop even if X1 is greater than X2.
  Discussion Thread[/glow]
  
  


• Left$(), Mid$() and Right$() all accept 'illegal' values for their position and length parameters as long as they are not negative.  However, the results are what you would expect (as if the parameters had been trimmed to suit the string being operated on).  E.g. S$=Mid$("abcd",2,97) leaves S$ containing "bcd".  More unusual behaviour than a bug.
  
  


• Embedded menu command "LOcate ..." will corrupt the menu item's 'selected' display if it's used to position the cursor backwards in the string (to overprint).
  
  


• In AMAL, the mouse key 2 instruction (K2) return the opposite of mouse key 1 (K1).  I.e.  K1 returns True if the left mouse button is pressed and False if not.  K2 returns False if the right mouse button is pressed and True if not.
  
  


• If you use End Proc[] to return a value from a Procedure, the final ] can be left out and gives no errors either in testing or running.  So, as it doesn't actually stop things working, it's more unusual behaviour again.  Though it should be fixed!
  
  


• In programming the Interface DBL Editor, the program won't compile (naturally!) and chucks a guru.  I used a lot of Else If statements in checking keyboard input, so I changed all those to single-shot If ... End If instead and the result's the same.  I had a lot of Data statements, so I chucked them into a memory bank instead.  Same result.  So, along with most people who've tried to use it, I can see the compiler has a lot of problems to be sorted.  Note that there's only an error when trying to compile.  The interpreted code work fine. 
  
  


• AMOS's dual playfield bug
  AMOS has an annoying bug that makes it impossible to scroll the background screen horizontally in dual playfield mode with more than 16 pixel precision.
  Ref post
  Workaround - provided in ref post.
  
  
• Using the file-selector typing " / " <return>  to go back a directory, will change the path to include the current path *plus* a // drop-back for a folder.
  ref post
  
  

Possible bugs: that may be worth investigating.

Items reviewed and eliminated as not being a bug will be crossed out.

• xec.library
  Once I have compiled my program onto a self booting disk the following message is displayed in an AmigaDos window after loading before the program begins;
  Ref post
  
  



• Graphics cards
  The only hardware that i find AMOS doesnt like is graphics cards, and i'm told you can get around that by using the Intuition extension and opening your AMOS screens in that.
  Ref post
  
  


• Partition sizes over 2GB
  Another problem is that the AMOS hard drive installer doesn't like partition sizes over 2GB.  Anything over this size returns a negative value when checking for sufficient space to install, thus causing the installer to fail.  An install to a < 2GB partition and then a COPY ALL to the larger partition worked for me.
  Ref post
  

[Hungry Horace]

New Bug:

Length of Code Line too short...

Try a manual FADE command, with 32 colours....

e.g.

FADE 1,$000,$000,$111,$111 .... $FFF,$FFF

you'll find that it wont allow it!

I have had to use horrible code where each value is loaded into variables A, B ,C etc in order to work-around this before.

[bruceuncle]

Thanks for the feedback people.  I'm keeping all these in the reference database.

A few more I've come across in writing the ref manual.  Some of these are more in the 'unusual behaviour' category rather show-stopping bugs:

• Global does not allow string literals and wildcards.  So Global "G*" gives a Syntax Error as soon as it sees the double-quotes (single-quotes doesn't work either).  The same applies to Shared.


• Def Fn and the corresponding = Fn only function at either the global-level-only or procedure-level-only.  You can't declare one globally and use it in a Procedure (which should be fixed).  And you can't declare one in a Procedure and use it globally (which probably shouldn't be fixed - whadda you think?).  Which makes it a bit useless.


• For ... To ... Next ... Step always performs one iteration of the loop no matter what is specified for the starting, ending and step values.  E.g. For X=X1 To X2 : <do something> : Next X will perform one loop even if X1 is greater than X2.


• Left$(), Mid$() and Right$() all accept 'illegal' values for their position and length parameters as long as they are not negative.  However, the results are what you would expect (as if the parameters had been trimmed to suit the string being operated on).  E.g. S$=Mid$("abcd",2,97) leaves S$ containing "bcd".  More unusual behaviour than a bug.


• Embedded menu command "LOcate ..." will corrupt the menu item's 'selected' display if it's used to position the cursor backwards in the string (to overprint).


• In AMAL, the mouse key 2 instruction (K2) return the opposite of mouse key 1 (K1).  I.e.  K1 returns True if the left mouse button is pressed and False if not.  K2 returns False if the right mouse button is pressed and True if not.


• If you use End Proc[] to return a value from a Procedure, the final ] can be left out and gives no errors either in testing or running.  So, as it doesn't actually stop things working, it's more unusual behaviour again.  Though it should be fixed!


• In programming the Interface DBL Editor, the program won't compile (naturally!) and chucks a guru.  I used a lot of Else If statements in checking keyboard input, so I changed all those to single-shot If ... End If instead and the result's the same.  I had a lot of Data statements, so I chucked them into a memory bank instead.  Same result.  So, along with most people who've tried to use it, I can see the compiler has a lot of problems to be sorted.  Note that there's only an error when trying to compile.  The interpreted code work fine. 

Keep 'em coming.  This is all good stuff.  The more we can squash in the first bug-fix sessions the better.  And we can't swat 'em unless we know about 'em. 

New Bug:

Length of Code Line too short...

Try a manual FADE command, with 32 colours....

e.g.

FADE 1,$000,$000,$111,$111 .... $FFF,$FFF

you'll find that it wont allow it!

I have had to use horrible code where each value is loaded into variables A, B ,C etc in order to work-around this before.

Yeah, so it does.  31 colours is ok, 32 gives a syntax error.  Fade is one of those instructions that doesn't have a parameter profile in the token table (just a solitary "I").  So presumably the parameter checking's in the code.

It's not a limit on line length as the max length of an AMOS line is 251 characters and this is nowhere near that.  Thanks for the post as that's one I'd missed whilst doing the docs.

[Hungry Horace]

another bug:

when using the file-selector typing " / " <return>  to go back a directory, will change the path to include the current path *plus* a // drop-back for a folder.


for example... i am in folder:

HD2:Projects/Horace/

i type "/" <return> to go back a folder, and i am in:

HD2:Projects/Horace//

and then go into a folder "bloodwych" and i am in...

HD2:Projects/Horace//Bloodwych/

... what i *should* have arrived at was:

HD2:Projects/Bloodwych

it's quite annoying when you are browsing through different folders for AMOS files!!

[MadAngus]

Folks Please only list and describe your bug here. For discussion a separate thread should be created, otherwise it is going to be a nightmare to keep track of who's talking about what.

[Edit]
I've split off the ENDIF and For...To...Next...Step always discussion to separate threads. I've also added links to the discussions in first post bug list.

[Lonewolf10]

I have (re)found an error with the Unpack command in AMOS Pro 2:

Unpack _BANK [To _SCREEN]

generates the error "Not a packed bitmap" (both in Editor mode and when program is ran - I haven't checked compiled version) even though banks ARE valid packed bitmaps (using Pack _SCREEN To _BANK).

The error is because the target screen (if any are open) doesn't match height of unpacked image from _BANK! Once the target screen equals the unpacked height (in the editor or when program is ran) it unpacks without errors.

[bruceuncle]

Menu$(n,n,...)=Normal$, Selected$, Inactive$, Background$

Normal$ works.
Selected$ works.
Inactive$ is always ignored and has no effect on an inactive menu item.
Background$ does weird stuff that I can't make any sense of yet!  I think it's maybe just meant to contain embedded commands.  But the cursor appears to be set to the end of the menu item and one line down.  The resulting displayed text is then not cleared from the screen.

[bruceuncle]

Every TimeInterval Proc Procname
Every On
Every Off
Wait TimeInterval

If you use the interrupt system to call a procedure, turning it off using Every Off stops the Wait instruction working.  The program will wait indefiinitely - i.e. it looks like it's locked up.  It hasn't crashed, it's just that the TimeInterval will never get counted down.

I haven't looked at the way AMOS handles these interrupts yet.  So this may be something that can be solved (i.e. a bug) or may just be something to be aware of (i.e. unusual behaviour).

[bruceuncle]

Attached is the master list of AMOS Pro Bugs that I'm using to track and maintain version control over fixes, AMOS_Bugs_20130517.zip.  As at 17/05/2013.

There's a version in each of these formats:

• *.xlsx
• *.xls
• *.ods
• *.csv

The details of the bugs are in *.pdf files which are all thread posts either from here or AmigaCoding.
 
Put the *.pdf files in the same folder as your preferred workbook app.  Then open the workbook from the file requester within your workbook app.  The links to the *.pdf files will then work from within the workbook.  Don't start the workbook by double-clicking or by selecting from the recent files list.  The links rely on the current directory function!  If you can only use the *csv format, you've got no chance, but the text might be useful  .

Let's say we use the end of May as a cutoff for any bugs not on this list and not reported before then.  That gives us a release point and deliverables objective.  Any posted after the end of May will go into the next (speculated) release.  As will any in this batch that haven't been fixed or may require a major architecture change to fix.

When this release (speculated as V2.01) will be ready is up to how much can be achieved over (say) the next six months. 

Don't forget, bug fixing is one thing.  Being able to release to an unattended hard disk install is another thing altogether!  I'll be working on pulling all the necessary source components together to enable that to happen.  A simple start in that direction is the attached Assembler List.txt.  This is a one-file view of what the individual assembler scripts look like with all debugging removed.  It does not include any of the peripheral sources, just the assembler.

When I've managed to assemble all the required executables, byte-for-byte, from the sources, I'll post the essential sources and includes (including (sic) the missing powerpacker ones).  Together with the suggested directory structure and assigns for us all to be "singing fro the same songbook" (how I hate that expression!!!  ).

Those last few paragraphs don't really belong in this topic.  So watch for a new Classic AMOS Pro V2.01 topic, which is where I'll post the stuff mentioned above (and probably a copy of this post  ).

[SamuraiCrow]

Thanks, but LibreOffice 3.5 doesn't like the spaces in the filenames.  Or at least the hyperlinks don't work.

[Lonewolf10]

Firefox 3 (version 3.6.22) downloaded both fine, though "Assembler List.txt" saved as "Assembler". I just renamed the file and it opened fine in Notepad.

(That's why I always use underscore instead of spaces when saving files - that way I know that if I ever stick them on the internet somewhere there won't be problems)

Edit: After opening the Excel file, I realised SamuraiCrow might actually be talking about the links in the workbook! 
Great job getting it all together, bruceuncle

[bruceuncle]

Thanks, but LibreOffice 3.5 doesn't like the spaces in the filenames.  Or at least the hyperlinks don't work.

Aaargh!  Oh for some common standards!

Sorry about the hyperlinks guys.  They may only work in Messysoft Orifice 2003 onwards as the cell formula has to know the current directory to find the target files.  That way the files are relocatable as long as they're always in the same directory as the spreadheet file, and the spreadsheet file is opened from within the spreadsheet app you're using:

=HYPERLINK(INFO("DIRECTORY")&"FileName","DisplayText")

So a typical cell looks like this:
=HYPERLINK(INFO("DIRECTORY")&"www.amigacoding.com - AMOS_Bug_Bank_length.pdf","AmigaCoding - AMOS_Bug_Bank_length.pdf")

I don't know if the spreadsheet app you're using has any similar function, but with a different syntax, for returning the current directory?  If it has, have you got search and replace for cell formulae?  Assuming it can handle hyperlinks anyway.  It's a lot more useful as a list when you can just click on the link and up pops the file.

[bruceuncle]

(That's why I always use underscore instead of spaces when saving files - that way I know that if I ever stick them on the internet somewhere there won't be problems)

Thanks for the tip.     I can still remember the days when we were paranoid about spaces in path names.   

PS
I've also got keyboard dyslexia from constantly swapping from Amiga shortcut keys ("Bless 'em, bless 'em.") to PC shortcut keys!   

[SamuraiCrow]

Thanks, but LibreOffice 3.5 doesn't like the spaces in the filenames.  Or at least the hyperlinks don't work.

Aaargh!  Oh for some common standards!

Sorry about the hyperlinks guys.  They may only work in Messysoft Orifice 2003 onwards as the cell formula has to know the current directory to find the target files.  That way the files are relocatable as long as they're always in the same directory as the spreadheet file, and the spreadsheet file is opened from within the spreadsheet app you're using:

=HYPERLINK(INFO("DIRECTORY")&"FileName","DisplayText")

So a typical cell looks like this:
=HYPERLINK(INFO("DIRECTORY")&"www.amigacoding.com - AMOS_Bug_Bank_length.pdf","AmigaCoding - AMOS_Bug_Bank_length.pdf")

I don't know if the spreadsheet app you're using has any similar function, but with a different syntax, for returning the current directory?  If it has, have you got search and replace for cell formulae?  Assuming it can handle hyperlinks anyway.  It's a lot more useful as a list when you can just click on the link and up pops the file.

That command WOULD WORK if only there weren't minus signs and spaces in the filenames.

Oh, and LibreOffice is the best way to open an OpenDocument file format because OpenOffice.org has bit-rotted.

[Hungry Horace]

Thanks for the tip.     I can still remember the days when we were paranoid about spaces in path names.   

my boss still wonders why i so often name files without spaces.....