Ultimate Amiga
Network Boards => AMOS Professional Re-Development => AMOS Factory => Feature requests and bug reports => Topic started by: MadAngus on December 05, 2012, 05:52:46 PM
-
Here is a list of known bugs from amigacoding.com. Details can be found on the AmigaCoding bugs page (http://www.amigacoding.com/index.php/AMOS:Bugs)
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' (http://www.ultimateamiga.co.uk/index.php/board,314.0.html) board
- Program will not compile (run) if too many ELSE IF's. - Ref (http://www.ultimateamiga.co.uk/index.php/topic,9597.msg44902.html#msg44902)
Discussion Thread (http://www.ultimateamiga.co.uk/index.php/topic,9621.0.html)
- Length of Code Line too short... - Ref (http://www.ultimateamiga.co.uk/index.php/topic,9597.msg44909.html#msg44909)
- 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] (http://www.ultimateamiga.co.uk/index.php/topic,9622.0.html)
- 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 (http://www.ultimateamiga.co.uk/index.php/topic,9352.msg42737.html#msg42737)
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 (http://www.ultimateamiga.co.uk/index.php/topic,9596.msg45069.html#msg45069)
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 (http://www.ultimateamiga.co.uk/index.php/topic,9029.msg40661.html#msg40661)
- 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 (http://www.ultimateamiga.co.uk/index.php/topic,9277.msg42182.html#msg42182)
- 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 (http://www.ultimateamiga.co.uk/index.php/topic,9277.msg42192.html#msg42192)
-
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.
-
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.
-
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!!
-
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.
-
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.
-
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.
-
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).
-
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:
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!!! :P ).
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 ::) ).
-
Thanks, but LibreOffice 3.5 doesn't like the spaces in the filenames. Or at least the hyperlinks don't work.
-
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 :)
-
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'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. 8) I can still remember the days when we were paranoid about spaces in path names. ;D
PS
I've also got keyboard dyslexia from constantly swapping from Amiga shortcut keys ("Bless 'em, bless 'em.") to PC shortcut keys! ;)
-
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.
-
Thanks for the tip. 8) I can still remember the days when we were paranoid about spaces in path names. ;D
my boss still wonders why i so often name files without spaces..... :)
-
Okay, okay ;D
See if the attached version works.
WARNING! Contains absolutely no spaces, periods nor hyphens but may contain traces of paranoia. :)
-
AFter wrestling with LibreOffice and updating to the latest version 4.0.3, I can safely say it still doesn't work. The INFO() function doesn't support the "DIRECTORY" argument. I took out the INFO() function and tried it without it. It still wouldn't load. I tried using relative paths with a file:// in front of it. Still nothing. I think it's hopeless. :(
-
It shouldn't be hopeless. I know some people at work use workbooks filled with links to files, so I know it *should* work. However, I have never implemented anything like that in my workbooks (yet).
-
I'm beginning to suspect the HYPERLINK() function isn't intended for use with local files in any form. I haven't tried an absolute path yet because that would be a very hollow victory.
-
Hmmm... I got it to work in Excel by clicking on the insert hyperlink icon and typing in the filename (with NO filepath). For example, I typed in "amigaguide.guide" and it opened the file contained in the same directory as the workbook without any problems (full path is "C:\Documents and Settings\User\Desktop\amigaguide.guide").
I'm using an old version of Excel, on Windows 2K SP4.
Edit: Just got it to work with the HYPERLINK() function too, just using filename (no filepath).
Edit2: Further playing shows that Excel supports the INFO function and DIRECTORY function... but it points to the "My Documents" folder, which is not where any of the files are stored. (The full path to the files is "C:Documents and Settings\User\My Documents\Amiga-HD\HD1-DEV_KIT\AMOS_Bugs\").
-
To all. Excel Hyperlinks are tricky because they usually embed the complete path to the target file in the =HYPERLINK() function. Which is useless if you want to move the files around or distribute them. That problem can be solved using a bit of VBA to get the workbook's full path, extracting the directory path and either updating the link cells or making a function for the cell instead. I didn't want to do that 'cos it would only work for Excel users (and not everyone uses Excel).
The method I used gets the "current directory" [ =INFO("DIRECTORY") ] in the cell formula instead. As I pointed out, this will only work if you open the workbook from within Excel using File Open. Each time you open a workbook, the "current directory" will change! So, if you then go back to the hyperlinked workbook, the "current directory" function will get the wrong one. If you double-click the workbook in Windows Explorer, you'll get whatever default directory Excel's set up to use. Which is usually My Documents. The same thing happens if you select from a Recent Files list too.
As the =INFO("DIRECTORY") function only seems to be available in Excel, it seems it was a bit pointless anyway ;D
Recommend you relink in the spreadsheet to the files manually. Tedious, but the info's a lot easier to digest with the links working.
Notes on the Bugs List
This list may well contain bugs that were AMOS Pro V1.x specific and are fixed in V2.0. I haven't checked as I just wanted to nail down a deliverables criterion. If you know of any of these that have been fixed in V2.0, please let me know and I'll remove them.
I set a cut-off date of end of May (2013! :) ) just so I can partition up the workload. This batch will all be versioned internally as V2.01x.xxx. Anything reported after that date will just go into the next batch (which will be versioned as V2.02x.xxx internally). And so on. I'd be very surprised if there are not some obscure bugs involving obscure instructions that haven't surfaced yet.
For example, one I just came across in the last couple of weeks is that there's an error in the AMOS Equates file. If I hadn't been testing the Ask Editor and Call Editor instructions for the docs, I doubt it would ever have surfaced! (And just noticed it's in my list but not in the spreadsheet! Mea culpa! Mea maxima culpa! :o )
The objective is to get a V2.01 release out in the next six months. We won't get everything fixed by then, but should have something worthwhile releasing.
Note also that the version numbers I'm using internally (in the database that holds all this stuff) is in the format 2.xxx.xxx. This is to give a finer granularity for controlling the fixes for us. But releases I would expect to only use the V2.xx format unless there's any good reason not to. So the user will see V2.01, V2.02, etc.
-
The bank allocation bug (1.15) may solve multiple other bugs if solved first. Cases in point: the loading of samples into Fast RAM.
-
A quick question (sic) on a Print bug. The bug is:
If you use:
Print ,,
Print "a",,"b"
You get:
-2147483648 -2147483648
a -2147483648 b
This is caused by a bug in the Verification (syntax check) code. AMOS Basic expects a Print statement to follow the format:
Print <expression><separator><expression><separator>...
and is supposed to choke if it gets something like:
Print <expression><separator><separator><expression>
or:
Print <separator><expression>
If you try the same thing with the other Print separator, the semicolon, you'll see what I mean.
With Verification letting that usage of the comma through instead of chucking it out, the Interpreter evaluates it instead of treating as a separator. The comma (Token _TkVir, number $5C) uses L_FnNull if it's picked up as an expression. So it's evaluated to #EntNul which is $80000000 or -2147483648 in decimal, which is what you're seeing.
Bear in mind that AMOS Basic was built for speed. And although its syntax is similar to other Basic dialects, it is different. It expects you to use Tab$ to do the job if you want a tab at the beginning of a line or if you need multiple tabs in the middle of a line.
So my question is "Do we want to correct the Verification bug to reject it as a Syntax error (simple and fast) or do we want to fix it in the Interpreter (much more complex, slightly slower and 'not really AMOS')?"
(Forgive my bias :) )
-
I would have expected it to be a zero length string, rater than a VBA style Tab$....
Surely that would be faster also? Ie. ignore separators until you reach a valid string to print
-
I would have expected it to be a zero length string, rater than a VBA style Tab$....
Surely that would be faster also? Ie. ignore separators until you reach a valid string to print
I just knew this would open a can of worms ;) Thanks for the feedback.
It's not that simple Hungry Horace. The Print statement can contain all sorts of functions and expressions as well as quoted strings. The Interpreter code that handles this is quite complex.
The way AMOS works is by using a very intensive Verification phase (the Test button) before it runs a program through the Interpreter. That way, any syntax errors are detected before the Interpreter crashes the system. (Yeah, I know. Good theory that doesn't always work in practice. But it's a good architecture for an Interpreter.) The Interpreter then just has to run through the tokenised code picking up the tokens and acting on them. Just like most other p-code style interpreters.
The problem with this little bug is as I stated in the original post: The Interpreter expects a chain of <expression><separator><expression><separator>... for a Print. To change that expectation is a lot more work than correcting the Verification code, which is where the bug is. AMOS Basic syntax is pretty unique in that it's similar to the syntax used in other Basics, but it is different. For example, using Tab$ to allow the programmer to do the equivalent of Print ,,"Hello World". In AMOS Basic it would be Print Tab$;Tab$;"Hello World". Tab$ takes no parameters (unlike, say, a VBA Tab$(Size)). You're expected to preset the tab length using Set Tab Size. It may be more cumbersome but it's the way AMOS Basic syntax works.
I think I'll just stick to plan A and correct the Verification to chuck it out as a syntax error, which is what it does for a semicolon used in the same way. At least then it's consistent behaviour and still AMOS Basic :) .
-
/me checks the PEG parser generator code Sidewinder and I wrote for Mattathias.
For Mattathias BASIC we just made the "Printval" rule optional within the repeated field of "PrintSeparator" rules so that the parser wouldn't choke. For the comma separator, converting it to a Tab$; would work well too.
You can view the WIP PEG parser generator file here (http://sourceforge.net/p/mattathias/code/37/tree/frontends/amos.peg).
-
/me checks the PEG parser generator code Sidewinder and I wrote for Mattathias.
For Mattathias BASIC we just made the "Printval" rule optional within the repeated field of "PrintSeparator" rules so that the parser wouldn't choke. For the comma separator, converting it to a Tab$; would work well too.
You can view the WIP PEG parser generator file here (http://sourceforge.net/p/mattathias/code/37/tree/frontends/amos.peg).
Many thanks SamuraiCrow.
To provide some context, what I'm aiming for is still to follow the original plan for "Classic AMOS" which is to fix the bugs, document and release a HDD install. Then look at enhancements (AGA, extra instructions, etc). I don't at this stage want to change its syntax rules.
Having said that, I very much like the idea of automatically converting a misplaced comma (as far as AMOS is concerned ;)) into a Tab$ token during Verification. That fits nicely with the universal Basic shorthand of a ? for a Print.
Thanks again mate. 8)
-
- 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 (http://www.ultimateamiga.co.uk/index.php/topic,9596.msg45069.html#msg45069)
I would be incredibly grateful if this bug could be fixed.... i often surf around my Projects/ folders and watching the path get longer and longer and longer as i scoot back a folder is quite troublesome!!! [/list]
-
- 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 (http://www.ultimateamiga.co.uk/index.php/topic,9596.msg45069.html#msg45069)
I would be incredibly grateful if this bug could be fixed.... i often surf around my Projects/ folders and watching the path get longer and longer and longer as i scoot back a folder is quite troublesome!!! [/list]
Aaargh! Do you want I should move this up the priority list? I thought the nags had quietened down since MadAngus disappeared into the wild blue yonder. I'm tackling all the bugs on the list (and thankfully some are cases of RTFM rather than a bug). This is taking some time and I need the occasional diversion every now and again...
Since I discovered the real power in Resource now I've pulled the docs out of its help files, I'm currently putting the macros together to disassemble AMOS Pro Extensions to produce sources usable with +amos_includes.s. Luckily, I'd already done a lot of the hard stuff a couple of years ago (Good grief! Is it really that long?) when I put all the Resource symbol libraries together for AMOS Pro. Found bugs in a couple (chopped off some of the symbols for +LEqu.s at the full-stop :-[ ) but the results look great so far. As soon as I've finished that (and published a revised Help doc - the last one had the same errors as the help file that it came from - nothing like hands-on to really find out the truth) I'll be back on AMOS Pro V2.10.
-
Obviously I would never think of making any demands on your schedule :)
Pulling apart the extensions could be really key, and to have some natively included and included in the in built help file would be amazing!
I am just saying, if it goes high up the list when you *do* resume by fixing, I'd be very happy! Hopefully it's not too difficult to fix either....
-
Obviously I would never think of making any demands on your schedule :)
Just take any disparaging comments as "tongue in cheek" ;D
Having seen how much easier it is to move around file selectors in some other apps, I can appreciate what you're asking for. The AMOS Pro file selector is common to both the language itself and anything else that cares to use it. So it would work across the board (I can't really see anyone writing an alternative as it involves a lot of the dreaded DBL code ;D - maybe I would, always the masochist).
I'd also like to get both it and the editor to respond to a mouse wheel! AMOS gives me keycodes for a mouse wheel but fitting them in is a little tricky, especially in the editor. I'm hoping to try and sneak that one under the nose of the "no enhancements" rule for V2.10 (like the chromacoding for the Help display ;) ).
-
Having seen how much easier it is to move around file selectors in some other apps, I can appreciate what you're asking for. The AMOS Pro file selector is common to both the language itself and anything else that cares to use it. So it would work across the board (I can't really see anyone writing an alternative as it involves a lot of the dreaded DBL code ;D - maybe I would, always the masochist).
Hehe, I wrote my own file selector in AMOS which I have used ever since I wrote it. It isn't terrible fast (especially with directories containing 100+ files) and is obviously quite memory hungry, but it works. I have plans to give it and overhaul sometime as there are a few enhancements that would be it even better...
If anyone would like to see the code, just let me know.
-
I may have stumbled on another bug today (I'm trying to write a program to convert data into an IFF image, that I can later convert into PNG image for even better compression 8)) in AMOS Pro 2.00:
_DATA=130
IF _DATA and $40=64 then Print "1"; Else Print "0";
Always results in "1" being printed on the screen. Is this a bug or am I doing something silly???
_DATA=130
_DAT64=_DATA and $40
If _DAT64=64 then Print "1"; Else Print "0";
Works fine, but is uglier...
-
I may have stumbled on another bug today (I'm trying to write a program to convert data into an IFF image, that I can later convert into PNG image for even better compression 8)) in AMOS Pro 2.00:
_DATA=130
IF _DATA and $40=64 then Print "1"; Else Print "0";
Always results in "1" being printed on the screen. Is this a bug or am I doing something silly???
_DATA=130
_DAT64=_DATA and $40
If _DAT64=64 then Print "1"; Else Print "0";
Works fine, but is uglier...
No, not a bug. You've just fallen foul to the rules of "operator precedence".
What's happening is that the $40=64 is evaluated before the and. So it evaluates as if written _DATA and ($40=64). The equality operator (=) takes precedence over the logical operator (and). To fix it, just write it as (_DATA and $40)=64. And no, it's not silly ;) . I've fallen for similar errors myself many times. Different languages sometimes use slightly different operator precedence rules. So, these days , I get so paranoid about operator precedence in complex expressions that I tend to go too far with the brackets!
-
Bah!
I don't use brackets that often and didn't even think about it.
Thanks for the help, and glad it's not a bug :)
(PS. the program is almost finished, just need to add the ability to load in external files :))
-
Hello mates,
i'm new here so please be gentle. ;)
I recently started coding with AmosPro/Compiler (again) and came across a really hard to trace bug. It appears to be some kind of memory trash or something. Even the compiled executable has it.
I try to describe what is happening.
Sometimes, when entering a procedure, a local variable used for loops is pre-set with a random(?) number, so the inside of the ForNext-loop will fail, as described in the buglist above (it is always executed once).
I tried to make sure the variable is not GLOBAL or SHARED and even set it to =0. But then the Error is happening somwhere else, another variable (even GLOBAL ones) are set to e.g. =0.
Sometimes it results in "illegal ...." something something, sometimes it is a different error, like calling screen open with 0 as width, obviously.
I attached a picture of a Monitor screenshot.
Is this memory corruption, IF it is that, a known bug?
-
Hello mates,
i'm new here so please be gentle. ;)
I recently started coding with AmosPro/Compiler (again) and came across a really hard to trace bug. It appears to be some kind of memory trash or something. Even the compiled executable has it.
I try to describe what is happening.
Sometimes, when entering a procedure, a local variable used for loops is pre-set with a random(?) number, so the inside of the ForNext-loop will fail, as described in the buglist above (it is always executed once).
I tried to make sure the variable is not GLOBAL or SHARED and even set it to =0. But then the Error is happening somwhere else, another variable (even GLOBAL ones) are set to e.g. =0.
Sometimes it results in "illegal ...." something something, sometimes it is a different error, like calling screen open with 0 as width, obviously.
I attached a picture of a Monitor screenshot.
Is this memory corruption, IF it is that, a known bug?
It looks like your variable is getting overwritten by another task or the blitter. Local variables are stored on the parameter stack. Are you using any unknown codes or do you have any unusual extension installed that might not be fully debugged?
-
I don't know.
i have
AmosPro Music Extension v2.00,
AmosPro Picture Compactor v2.00,
AmosPro Requester v2.00,
AmosPro Compiler extension v2.00,
AmosPro IO Devices Extension v2.00,
TOME v4.24Plus,
AmosPro AMCAF extension v1.50Beta4 11-jan-98,
Amos Pro Club Extension v2.9Plus
installed. No idea, what all these are doing. :o
-
I just checked again and there was a short moment, where i got a "out of buffer" something displayed in red at the top. ???
I have Set Buffer 200 in the Code. That is 200kB, isn't it enough?
-
I just checked again and there was a short moment, where i got a "out of buffer" something displayed in red at the top. ???
I have Set Buffer 200 in the Code. That is 200kB, isn't it enough?
I'm pretty sure that's 200 bytes. Try 65536 for 64k buffer.
-
Help says 'Set Buffer kilobytes' 1024 bytes?
-
Help says 'Set Buffer kilobytes' 1024 bytes?
Ok, the scanned manual also says kBytes. Is the Set Buffer command the first in your program? http://www.ultimateamiga.co.uk/HostedProjects/AMOSFactory/AMOSProManual/5/504.html
-
I just checked again and there was a short moment, where i got a "out of buffer" something displayed in red at the top. ???
I have Set Buffer 200 in the Code. That is 200kB, isn't it enough?
I think 200 is a very large number for Set Buffer, but it makes sense if you use big arrays.
The strange result from the monitor session could perhaps be explained by the monitor itself being somewhat unstable (at least that's what I experience from time to time). I would try inserting some print statements where the errors occur and run the program normally to see what happens.
-
The problem is at runtime i use screens but i would like to print to the cli console. how can i do this?
-
Writing to the CLI console requires an extension. Otherwise you could open a console window of your own using file handling commands.
-
I've tried and put Set Buffer 210 in. So this would be 10k more. The compiled program still exits with an illegal call, probably because one variable is trashed or zero.
Is there a way to re-set all internal structures etc. of AMOS at runtime? Could it be a stack issue? I do not use any fancy recursion stuff. Or, another idea, is there a limit on the number of arguments for a procedure?
-
I think i found it. I made a booboo!
I was just searching through all arguments i use in procedures and it seems i had used one or two beeing declared GLOBAL despite not needed to be really GLOBALs, SHARED in some Procs would have been enough.
So, i keep on testing. Sorry to bother you with a non-bug. ::)
-
@DiskJuggler
I'm glad you found the culprit.
-
Thank you.
Is the "STR$() adds a Space" already tackled? It seems to be common as i stumble upon workarounds on this all the time.
-
Thank you.
Is the "STR$() adds a Space" already tackled? It seems to be common as i stumble upon workarounds on this all the time.
It's the sign character. That's why there is a space. Negative numbers have no space because it's occupied by the minus.
-
* Recently I found an error in Amos, I do not know if it is documented.
Using DirFirst and DirNext with file that have 2 times point, like for example File.00001.IFF, a search of * .IFF fails, because it searches from left to right.
In FSel$ too
On the other hand, in AmigaDos the same DirFirst command does it correctly.
-
Replied on the BitBucket bug report.
-
Thank you.
Is the "STR$() adds a Space" already tackled? It seems to be common as i stumble upon workarounds on this all the time.
yes i just discover this bug ! damn !