Ultimate Amiga
Network Boards => AMOS Factory => Extensions Forum => Topic started by: DaleH on March 14, 2014, 03:16:29 AM
-
Hi all. First post here on the Factory since around '99! I'm amazed my account was still here, actually.
Anyways, I'm getting back into using AMOS Pro (v2 Update) on FS-UAE (Mac OS X version on Mavericks) with my old favourite Gui Extension v1.75.
For a little background, with this extension, you make a GUI interface in GadtoolsBox and then use a gui conversion utility from within AMOS Pro to create a memory bank and load it into into memory. You then use the Gui Compiler Shell to create the WB executable.
Nice, simple, used to work every time. Until now. The GadtoolsBox interface import works fine, as always, and I get my .abk file nicely created and loaded up, but when I try to load the Gui Compiler Shell I get this error message:
Error in previous program: Syntax Error
By the way I get the same error with all other versions of the extension, so I went back to my "last known good position" with v1.75.
So my obvious question is what the heck is causing this pesky error message? Anyone had this kind of issue before and if so how did you solve it?
I should add that I am using proven code that has compiled without issues in the past. It's as clean as I can make it.
Thanks in advance.
Dale
-
I have never used the Gui or GadToolsBox, sadly, so I have never seen that error message before.
Hopefully someone else can help you...
-
Hi, I don't know this extensions but can give some info on the error message:
Error in previous program: Syntax Error
This is in two parts:
Error in previous program: means there's an error in a "hidden" program, presumably an accessory.
Syntax Error means that it's the error picked up in the "hidden" program. It can be from a number of causes. (As I bug-fix and rewrite AMOS Pro, it's my intention to make some error messages a bit less obscure!).
- Running out of memory.
- A Token error.
The first is unlikely but always worth checking.
The second is caused by the way AMOS Pro runs its programs. ALL AMOS programs are saved in tokenised format. When AMOS "tests" a program before running it, it is doing two things:
- Validating the AMOS Tokens. This is essential as it needs to know that a Token from an Extension is available. That is, that the Extension is both loaded and is in the correct slot.
- Any branches within the program have to be resolved into offsets. This is so that the interpreter can jump to the correct place in the program. This applies to all "structural" instructions like If ... End If, Do .. Loop, etc.
The first of these is what usually caused the completely uninformative Syntax Error message.
The Token for an Extension (that is, all loaded AMOS Libraries) comprises its Extension slot number and the Token for the instruction within that Extension. So, if it's in the wrong slot, you'll get this error. Again, unlikely but always check every possible cause! Far more likely is that the Token itself is no longer valid. This happens if the Extension's Token Table has changed, causing some instructions to no longer reside at the same offset from the start of the Token Table.
A Token is simply the offset from the start of the Token Table to the entry for the instruction involved. If there's any change in size or position for a Token Table entry, any following Tokens will be invalid for any program written and saved using a previous version.
As I mentioned, I don't know anything about this Extension, but a quick scan of the docs refers to "saving programs in ASCII format". When such a program is then merged, it is re-tokenised. So no invalid Tokens are generated. The reason this works is that the tokenisation process searches the Token Table looking for a match to the ASCII representation of the instruction. This is obviously very time consuming, so it's only used when the program is tokenised. When the program is then "run", it expects to be able to use the Token as a simple offset so it knows where to jump to find the code for an instruction. As any invalid Token would produce the wrong offset and could cause a jump into never-never-land, the "test" process is there to check that all Tokens are valid.
Which is a long-winded way of saying you should check:
- You have enough memory.
- All needed Extensions (I notice AMCAF in the distro) are loaded and in the correct slots.
- All Extensions are the correct version as an incorrect one can cause that invalid Token problem. I don't know if AMCAF changed its Token Table over different versions but, if you already had it installed, it may be worth trying the one in the distro just in case.
- Loading each AMOS program in turn and "testing' it should throw up which one has the problem. You'll get a Syntax Error for an incorrect Token and will be able to see where it occurs. That may give a clue to which Extension is a wrong version.
Hope the above helps. I'm always long-winded in describing these things as it's important to understand why they happen. And Token errors are common in Extensions between versions. Always save each program in ASCII. That way you can swap versions without any problems. (Unless the Extension's changes mean an instruction's name has been changed! Extension authors take note.)
Oh, and I almost forgot, "Welcome back" ;) 8)
If you haven't looked around the AMOS forum lately, watch out for AMOS Pro V2.10 which is what I and some others are working on. Find it here (http://www.ultimateamiga.co.uk/index.php/topic,9701.msg45943.html#msg45943).
-
Thanks, bruceuncle, that gives me quite a bit to go on now. And thanks for the welcome back, though I have since seen that I did post in 2010 yet have no memory of it. Old age, I guess!
Dale
-
Time to report back on my problem, which now seems to have been an extension compatibility issue.
I decided to take everything back to square one with a freshly installed 3.1 system hd file. I then installed the Gui extension 1.62 and tested it. It worked fine. Just to get back into it, I quickly bashed together a few simple programs and compiled them without any problems. I've now added Ldos (my previous "big project" was a file conversion utility that used it) and compiled the old file without any errors.
The problem seems to be resolved. The really nice thing about using something like FS-UAE is that it's very easy to save backup copies of the entire hard drive file as you progress through trouble shooting. Makes it much easier to get back to a previous position without installing it all over and over.
I have copies of the versions 1.7, 1.75, 2, and 2.1 of the Gui extension, so I'll slowly begin going up the ladder to see if the issue returns and where it occurs. I recall that it was v 1.75 that I used for a long time back in the day.
So thanks again for the feedback bruceuncle. I'm sure I'll be around.
Dale
-
Very happy to see you finally got it working again. :)
A couple of things I should have pointed out when I suggested saving *.AMOS files in *.ASC format:
- Remember to also list and save any embedded banks!
- Check for machine code procedures. These will look like a 'folded' procedure but you won't be able to unfold them. They're AMOS Procedures that just contain 68000 machine code. If you come across any, and want to know what they do, just post me the *.AMOS file and I can extract it and turn it back into assembler source code. I've got AMOS code that can pull apart the tokenised format, so embedded machine code is pretty easy to extract. And I became an expert Resource user from trying to understand AMOS before the sources were released.
The really nice thing about using something like FS-UAE is that it's very easy to save backup copies of the entire hard drive file as you progress through trouble shooting.
Too true. I use WINUAE and Amiga Forever (Cloanto) on a PC. It means I can create and destroy any Amiga model and OS, and test out the AMOS Pro fixes as we finish each one. The only hassle is that the Amiga files are each so small and numerous that the time to copy a 120Mb 'directory' drive is painfully slow on a machine that can usually manage around 150Mb/second. Worth the wait though ... ;D
-
Too true. I use WINUAE and Amiga Forever (Cloanto) on a PC. It means I can create and destroy any Amiga model and OS, and test out the AMOS Pro fixes as we finish each one. The only hassle is that the Amiga files are each so small and numerous that the time to copy a 120Mb 'directory' drive is painfully slow on a machine that can usually manage around 150Mb/second. Worth the wait though ... ;D
I totally agree and FS-UAE gives me something Commodore/Amiga never could... an Amiga laptop! I finally have a reason to haul out my old Macbook 1,1. It can run OS X 10.6, which is just enough for the emulation software. I'm a happy Amiga-Guy! ;D
-
Ok, so just a quick update.
Upon trying to use newer versions of the extension, I returned to the cycle of errors much like before. So I systematically began loading the support programs (programmed in AMOSPro) into the editor for a look at where the problems were and taking note of the various version numbers.
The first snag I needed to correct was to have the correct extension libs and to run the needed patches. Somehow, my compiler and libs and patches were not "playing nice" at all.
Secondly, I (re)discovered that later versions of the GUI converter and compiler do indeed use AMCAF commands, though I did not see it in the docs. Not really surprising as AMCAF came as part of the distribution.
I am now running v2.0 of the extension which is working very well now. If I feel brave I'll have a look at 2.1, the Phoenix version later.
Dale
-
Congratulations 8)
Keep us posted on progress. When we've got a clean, bug-free AMOS Pro completed, we'll need to turn our attention to the wealth of extensions out there. The idea being to get them all compatible (upgraded to the AP201 format) clearly versioned and documented so a programmer can guarantee that they all work in 'perfect harmony'. :)
So all info on anything AMOS is always welcome.
1 - The AP20 reference is to the token "AP20" that is embedded in library and extension files from AMOS Pro V2.00 onwards. It lets AMOS know that it can use some faster V2.x routine formats. Earlier extensions formats (= all of them!) are supported but would benefit from the upgrade.