Ultimate Amiga
Network Boards => AMOS Professional Re-Development => AMOS Factory => ClassicAMOS Development => Topic started by: bruceuncle on January 27, 2014, 04:35:13 AM
-
This release is a work-in-progress for a V2.10 release of AMOS Pro that is aimed at fixing the existing bugs. You'll need to unzip the attached file and follow the readme.txt instructions to install it.
It includes the latest (today!) bug list as a PDF which should help explain what's going on and where I'm up to. So I won't repeat it all here ;) .
I've got two main objectives at this stage:
- Progressively fix the existing bugs on the list (and any new ones I find)
- Improve the AMOS Help system so that I can generate it from the AMOS Documentation database. (Which I regard as the biggest AMOS Pro bug - "If the Help don't work, people won't use it.") It will then match the AMOS Reference Manual generated in RTF format from the same database.
So if my priorities seem a little strange, that's why.
As usual, all this takes time so I'll continue to release alpha and beta versions as I get the spare time to do them. Until it's all fixed! :)
If you don't like the new Help File format, you can leave the rest of the release in place and just replace the AMOSPro_Help.map and AMOSPro_Help.txt files from your backups (you did backup didn't you? ::) ). The new AMOSPro_Help.AMOS program and the binaries are fully backwards compatible with the old files.
The important result I need from this release is for people to install it and check out the sections of the Help File in the new format (definitely read the readme.txt instructions !!!). So please let me know if you think the colours, content and layout work okay ;) .
-
It works here.
One comment of something to watch for when renaming libraries: AmigaDOS is case-insensitive but Exec.library's OpenLibrary command might not be. Be sure to rename AMOS.Library appropriately, not amos.library. (If it works though, post here so I will update my knowledge. I'm just going on the word of another programmer and haven't tried it out myself.)
Edit:
Confirmed as a bug in OpenLibrary Autodocs. See here (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0222.html).
-
Thanx a lot
I have included AMOS Pro in AROS Vision and look forward to include new versions (expecially when AGA support is added). Thanx a lot for your work.
I will test 2.10 this weekend
-
It works here.
One comment of something to watch for when renaming libraries: AmigaDOS is case-insensitive but Exec.library's OpenLibrary command might not be. Be sure to rename AMOS.Library appropriately, not amos.library. (If it works though, post here so I will update my knowledge. I'm just going on the word of another programmer and haven't tried it out myself.)
Edit:
Confirmed as a bug in OpenLibrary Autodocs. See here (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0222.html).
Ah, but amos.library is not an AmigaDOS library (so maybe it shouldn't be in LIBS: in the first place :) ). It's a custom collection of three sets of library routines. So AMOSPro uses LoadSeg() to get it into memory. It expects to find it in one of three locations, which it tries in this sequence:
- APSystem/amos.library
- libs/amos.library
- libs:amos.library
These names are what are used in the +B.s source and are what you'll see in the resulting AMOSPro binary (i.e. all lower-case).
Once in memory, it has a jump and data list in the first six longwords. To cut a long story a bit shorter, the "startup" jump expects to find A5 pointing to an initialised AMOS data area. It uses that to initialise the following vectors in the first three negative longword offsets from A5:
- SyVect - offset -4, points to the "system" jump table
- EcVect - offset -8, points to the "screens" jump table
- WiVect - offset -12, points to the "windows" jump table
The macros SyCall, EcCall, WiCall and their variants are used, together with the instruction number equates in +Equ.s, to call the functions.
AMOSPro only uses _LVOOpenLibrary() for:
- dos.library
- intuition.library
- mathffp.library
- graphics.library
- icon.library
which all appear in the sources, as in the above list, in lower-case.
-
I've split off my off-topic reply into a separate thread (http://www.ultimateamiga.co.uk/index.php/topic,9703.msg45952).
-
quick random question about the help file update.... is it possible for entries documenting Extension commands to be added?
Obviously, the help description would then need to state if a command is 'AMOS Command' or 'Extension Command: AMCAF' etc, and could even be used to verify if commands are AMOS original or AMOS Pro specific.
Just a thought!
-
quick random question about the help file update.... is it possible for entries documenting Extension commands to be added?
Obviously, the help description would then need to state if a command is 'AMOS Command' or 'Extension Command: AMCAF' etc, and could even be used to verify if commands are AMOS original or AMOS Pro specific.
Just a thought!
A good thought! Obviously, initially, I'll just be doing the AMOS Pro instruction set (over 1,000 to document!). But the Help System in AMOS is flexible enough to cope with extra help files.
I'd prefer it to be 'seamless' to the user. AMOS Pro 'knows' what extensions are present when it starts up (it has to load them and initialise them). So if we use a naming convention and 'known' location for any associated help files, they can be integrated at load time. There will be problems with that concept in merging the map and text files but I prefer to look on that aspect as just another challenge ;) . Maybe they can still be separate files for each extension and AMOS just iterates the map files to find a match for context help (might be a bit slow though). Otherwise, 'gluing' them into the Help system is no problem as that's how the "Latest News" files get picked up now.
-
What I'd really like though, is some feedback on the new help topic format ;) . It takes up more space but I think it will be worthwhile (especially as it's already in that format in the Help Database). So read the readme.txt file about where the converted topics are and have a look, and think about what you like and what you don't like.
Then let me know. 8)
The alternative is to add a briefer version just for the Help files. But I don't like that option as I never like storing the same data in more than one place. And I'd have to rewrite each topic for the shortened version. Heck, that thought alone makes me think I've already made up my own mind! ;D . But I would appreciate some feedback.
-
Attached is a release that fixes a bug in Hypertext in the last release:
If the new escape sequence ( "{{" ) was used to allow printing of Hypertext syntax instead of it being interpreted as a Hyperlink, the rest of the line disappeared when the text was scrolled.
There's also an updated bugs list doc. It explains why too many Data statements or lengthy If ... End If structures can stuff up AMOS. Read it! It's something important in AMOS that needs to be understood. ;)
I've included all the other files from the previous release. So, if you've already installed that, you only need to copy one file. Read the readme.txt file for details.
-
Excellent! One more bug bites the dust!
-
I've just read the bugslist PDF. Great job bruceuncle :)
I will install the new version of AMOS at the weekend ;)
-
Quick progress report:
- I've changed the docs DB schema to now handle both the Ref Manual and AMOS Help File data. There's just a few cases where I can't use the material for both purposes and some duplication of effort is required. Three target document types: Ref-Manual-only, AMOS-Help-only and Both (the vast majority thank goodness!)
- The data now comprises: the original Ref Manual stuff so far, the AMOS Help File contents in full (for the menus) and stuff I've formatted into the new schema.
- Both the DB and the Help Editor now handle AMOS Help Menus (they'll just be ignored for the Ref Manual extract, or a separate AMOS-Help-only record used where necessary). The menu links have been validated, which corrects those few incorrect pointers in the original. I've also incorporated the Latest News and Compiler Help files - messy but I can now sort that out with all the benefits of a rigid database schema to ensure it stays sorted!
- I now need to re-program the extractions as I've changed the formatting markups. I'm using a strict sub-range of HTML (the one an Access RTF Textbox understands, so I get my WYSIWYG). Both the original extractor programs are OO (as far as VBA allows anyway) so it won't be too much hassle.
- I've done no more on AMOS bugs as I wanted the above sorted (and make damned sure it was achievable) before I continued on in that direction. And to get a more substantial chunk of Help File out there from the already written Ref Manual stuff. I need to continue with that too (writing the Ref Manual material I mean - but for both targets now).
Food for thought... The current AMOS Help system looks for keyword matches in its *.map files. But the AMOS Editor tokenises and detokenises each line in its window as the user moves around in it. So it knows what AMOS Token(s) is(are) under the cursor or selected text. This includes the Extension Number as part of the tokenisation. I would suspect that a far more accurate and flexible AMOS Help system could be designed to use AMOS Token lookup instead. More compact, far quicker (the *.map files would then only contain tokens which would be sorted for quick binary searching) and, as Hungry Horace suggested, able to cope with any loaded extensions that had compatible Help Files. Just a thought...
-
Food for thought... The current AMOS Help system looks for keyword matches in its *.map files. But the AMOS Editor tokenises and detokenises each line in its window as the user moves around in it. So it knows what AMOS Token(s) is(are) under the cursor or selected text. This includes the Extension Number as part of the tokenisation. I would suspect that a far more accurate and flexible AMOS Help system could be designed to use AMOS Token lookup instead. More compact, far quicker (the *.map files would then only contain tokens which would be sorted for quick binary searching) and, as Hungry Horace suggested, able to cope with any loaded extensions that had compatible Help Files. Just a thought...
It's a good thought but you'd be the only one that understands the tokenizer well enough at this point to accomplish it. How long do you think that would take out of other programming time? In other words, do you think it would take time away from other bugs that still need fixing?
I think it was your idea in the first place to resist the temptation to add many features until the bugs are fixed.
-
In other words, do you think it would take time away from other bugs that still need fixing?
I think it was your idea in the first place to resist the temptation to add many features until the bugs are fixed.
That's why that "thought bubble" isn't in the bullet point list. It belongs in V3.x along with OCS/ECS/AGA capabilities. And we have all speculated on what we want when we get around to working on that version ;) .
To make it clear, V2.10 is purely a bug-fix version.
A few of the reported bugs refer to the AMOS Help system - missing and incorrect links, topics cut off in the middle, etc. Plus, quite a few of the AMOS Help topics are blatantly incorrect! To me, that is a much of a problem as something that just doesn't work. If the Help is wrong, the user loses confidence. So part of my bug-fix process is to get a better quality and quantity of help available to the user. As I'd already got a swag of new documentation available in the AMOS Reference Manual project, that content is being incorporated into the bug-fixed help system. I've taken a little time out from the AMOS source files to ensure that I can generate both AMOS Help files and the Reference Manual from the same database. Otherwise, I'd be rewriting all the stuff I'd already got in the database :( . The same will eventually apply to a possible HTML version of the Reference Manual.
The database contents are by no means complete. That's another on-going project and will take some time yet before everything is in the new format and accurate. It's also why I kept bleating about some feedback on the new Help File format. It's a major change to the look-and-feel of the help files.
As the database contents grow (something I get back to every now and then) I can then just issue Help File updates at the push of a button. The programming for that is now nearly complete.
It also gives me a break from wading through the sources checking the implications of bug fixes and ensuring the integrity of the code. Which can be a real pain at times. The latest fix (I'm in the middle of it) is a good example. It's the one about long (out-of-range) numbers being accepted by the editor, but truncated or otherwise mashed around. There's no error message for that and no mechanism to handle the message. I'm re-using some of the existing code routines but have to double-check for any unexpected repercussions from the changes. At that point in the code, I'm up to my neck in stack frames that are maintained over many hundreds of lines of code. I think I can see the way to do it... ;)
For that bug, there's also the problem of how to release the fixes. The editor configuration file needs to be changed without upsetting the user's personal settings. So I'll have to build an updater! And so it goes on.
I released that alpha version to give people a chance to okay or veto the help file formats and to see that something is happening. And, as the changes were minor, I could get away with a simple "just backup and replace these files". All future fixes will need a formal updater package for release as many more files will be affected and configuration files will need to be changed in-situ. So it may be a little while before the next batch of fixes appears. At which stage I should be able to raise the level to a beta release.
So don't worry too much. I'm still on track and fully committed 8) (or should that be committable? ;D )
-
@bruceuncle
I've verified that the bug was fixed and the new format looks good. After I installed it and posted on AmigaCoding.de about it, Olaf put the bug-fixed AmosPro in the AROS Vision 2.3 release. I guess alpha code has moved to beta but bug-fixes are really good to get feedback on. I haven't seen any harmful repercussions of the existing bug fixes but haven't done much with AmosPro either.
I'm glad you're keeping the new coding priorities straight. I've put FS-UAE on my Mac and it seems to work quite a bit better than EUAE especially with regard to capturing the mouse input and only releasing it when I hit the middle mouse button/wheel. This makes working with AmosPro so much easier.
-
Oh dear, I've just seen the "120 days old" warning. Sorry, I hadn't realised it was that long. And I did take a short side excursion to Resource Bloodwych (just for a break from the AMOS Docs). Anyway, apologies again for leaving it so long. (A few problems with family and friends seem to have taken up a fair bit of time too ;) ).
Here's what I've been doing in the AMOS V2.1x arena:
It's taking a while to get this next release together as I've the installer to complete and had to do a load of work to finally get a "clean" formatted AMOS Help File out of the existing Docs database. It was originally designed for a printed output (PDF with built-in XRef links - and still is!). I had to build a side-by-side WYSIWYG AMOS Help editor into the original which took one heck of a lot longer to get right than I anticipated. But it works! There's a few piccies of the editor attached so's you can see what I mean. As I just press a button and all 1,000+ Help topics and menus pop out of the database automatically, it's essential that I can preview the AMOS output as I go, and correct if necessary. Some topics also need separate versions for the printed and Help File outputs. AMOS Help Menus being the obvious one - they're in the contents, index and cross-references in the PDF version but need to be menus in the AMOS Help version.
So be patient. There's a lot happening at my end but I've been a bit slack in keeping everyone up to date/
-
Thanks for the update!
-
You have been busy bruceuncle. Thank you for the pictures and the update :)
-
Thanks
-
Thanks guys. I was starting to feel a bit lonely :'( .
I'm just about to start pulling the AMOS Compiler apart to see what the problems are. I've been putting that off until I knew more about how the libraries are loaded and used, how tokenising works, how the interpreter works, and so on. (Still a bit vague on variables but they're starting to make sense.) I think I know enough now to tackle the 'love child' in the AMOS Pro world - the Compiler ;D .
So if anyone out there has any info on the AMOS Pro Compiler that fits this list:
- Bugs not already in the list
- Any known 'fixes'
- Any modified versions that differ from the original V2.0. (Binaries are fine if any exist. I picked up a couple of bug fixes for the Interpreter from modified amos.library and AMOSPro.Lib binaries.)
then please let me know. No point in re-inventing the wheel ;) .
Also please appreciate that pulling the compiler apart and trying to debug it is going to take some time.
However, on the brighter side of AMOS Pro redevelopment, it shouldn't be too long before I can get an installable beta out (with the Compiler 'as is'). Looks like about 8 floppies worth but may be more as I want it to include the entire set of sources and support files necessary to build AMOS Pro from scratch. (Adapting to other development directories will just mean you have to change some paths in the +amos_includes file). I also need to get the bug list up to date (I've been a bit slack updating it to reflect what I've been fixing :-[ ). Not to mention completing the CSI AMOS docs on how the Loader and Interpreter work. (Damn! I was hoping everyone had forgotten that. Or that the original had sent them all to sleep ;D .)
-
I don't recall any major updates to the compiler v2.0, but will check my files and get back to you :)
-
I don't recall any major updates to the compiler v2.0, but will check my files and get back to you :)
Thanks Lonewolf10. I haven't come across any mods myself but I thought it worth asking anyway.
-
Thanks Lonewolf10. I haven't come across any mods myself but I thought it worth asking anyway.
I didn't find any mods myself after searching my collection, however I did find these which you may find useful:
Compiler 1 sources (2View/AMOSCompiler.zip)
multitasking patch (AMOS_Tools/AMOS_Patch.zip)
AMOS Optimizer (2View/aot100.lha)
AMOS Pro Compiler Intuition Interface 1.01 (by Fabrizio Bazzo, 1996), including sources (2View/APCII.lha)
Let me know if you have them already or not.
You can ignore the archive names in the brackets, they are just there as a reminder of the archives location should you decide you would like something. Some (or all) of them may have been downloaded from Aminet.
-
Thanks Lonewolf10. I haven't come across any mods myself but I thought it worth asking anyway.
I didn't find any mods myself after searching my collection, however I did find these which you may find useful:
Compiler 1 sources (2View/AMOSCompiler.zip)
multitasking patch (AMOS_Tools/AMOS_Patch.zip)
AMOS Optimizer (2View/aot100.lha)
AMOS Pro Compiler Intuition Interface 1.01 (by Fabrizio Bazzo, 1996), including sources (2View/APCII.lha)
Let me know if you have them already or not.
Thanks Lonewolf10 :) . I don't have any of those. So where can I download them? (The "2View/" and "AMOS_Tools/" have me mystified, or am I missing something I should know ??? ?)
Any sources related to AMOS or AMOS Pro are useful. I paw over sources like an ancient mariner over lost treasure maps ;) . Sometimes they're useful, sometimes not. Sometimes there's even comments :o . But they're always interesting.
-
So where can I download them?
Found them straight away using Google ::) .
Thanks again for pointing me in their direction.
-
Thanks Lonewolf10 :) . I don't have any of those. So where can I download them? (The "2View/" and "AMOS_Tools/" have me mystified, or am I missing something I should know ??? ?)
Sorry, I wasn't entirely clear in my previous post. "2View/" and "AMOS_Tools/" are directories on my laptop's harddrive ;D
Found them straight away using Google ::) .
Thanks again for pointing me in their direction.
No problem :)
-
Hello friends,
What about Amos AGA? Still development?
Hope yes !
All the best
Amiten
-
First come bug fixes, then new features.
-
Yeah. I'm still up to my neck in the bug fix phase. (A couple in the AMOS accessory programs Sample_Bank_Maker and Resource_Bank_Maker have cropped up now but already fixed! I expect there may be more... The Help sample programs also have more than a few comments that are misaligned with line number references and a few other mistakes - not critical but confusing! It just all takes a lot of time to put right.) And I've still got a list of minor bugs that I haven't even looked at in any great detail yet. Some of them appear to just be 'the way AMOS expects you to use the commands' rather than outright bugs. The original manual doesn't make some things very clear as to how the instructions should be 'fitted together'. So way down the track that manual's got to be rewritten too. For the time being, I'm pouring that knowledge into the help database. As I should still be able to pull an AMOS Reference Manual out of that, maybe that might be enough.
But, as SamuraiCrow points out, bug fixes first then AGA. I've collected a mass of material on AGA but can't afford to get too involved until this current task is over. If anyone else wants to have a dabble please do. Any input and/or source is very welcome. It will be a mammoth task in itself as I haven't settled on an architecture yet but, in any case, some major surgery will be required!
I haven't got very far into the compiler and can't yet see any obvious causes for the crash and memory bugs. It will take me a while as a lot of family life (unfortunately tragedies mostly :'( ) has kept me away from spending as much time as I would like on AMOS. But I do check the forum daily from my smartphone, so chat away guys ;) .
I have managed to strip out the HD installer and mostly adapted it to checking and installing AMOS V2.10 from a set of floppies. Note that this is a HD install only! Whilst it may just be possible to run AMOS Pro V2.10 from floppies (as the original install disks do) the size of the help file blows that away from the start. And running AMOS Pro from floppies is a time-consuming way to develop stuff. One advantage is that there's then no need for the kludges to get it all to fit. (E.g. those dummy accessory programs that refer you to a different location. They can now all reside in the Accessories directory.)
So a set of floppies to install to a hard drive is what I'm building.
I've always been a lousy communicator so don't hesitate to give me a nudge if I haven't posted for a while and you want to know where I'm up to. :)
-
Nice ! I hope you find the time to complete Amos Aga it'll be a dream for me, between I dont know if I can help in any task because dont know really how you made this miracle. All the best
Amiten
-
So a set of floppies to install to a hard drive is what I'm building.
What's wrong with an ISO image for CD-ROM? I suppose it would be mostly empty. How many disks are you up to so far?
-
Nice ! I hope you find the time to complete Amos Aga it'll be a dream for me, between I dont know if I can help in any task because dont know really how you made this miracle.
Have you installed the Games Master System users' archive (http://aminet.net/package/dev/misc/gms_user) and GMS developers' archive (http://aminet.net/package/dev/misc/gms_dev) so you can try out the Games Extension (http://www.ultimateamiga.co.uk/index.php?action=tpmod;dl=item364)? You'll have to use the GMS environment's features using custom commands that resemble the original AmosPro versions, but it supports AGA quite well. If you run into trouble, post back here and I can see if the GMS manual has any solutions for you.
-
So a set of floppies to install to a hard drive is what I'm building.
What's wrong with an ISO image for CD-ROM? I suppose it would be mostly empty. How many disks are you up to so far?
I stuck with floppies as being the easiest way to install for anyone who doesn't already have AMOS Pro installed. Just boot the first floppy. If AMOS V2.00 is already installed, the install program can run quite happily with those libraries so the user can just run the install program straight off the floppy having already booted from their hard drive. It looks like around eight floppies. Apart from the bootable disk, which has just enough support for the AMOS install program itself, they no longer represent a floppy-only AMOS Pro though.
So I suppose a CD version could do the same. It would mean modifying the install program and I'm already up to my neck getting everything together for a floppy install. I don't have any Amiga hardware experience except my A2000 many years ago. Can the CD32 boot from a floppy? If it can't, then I'd have to do a CD version, but later... A *.lha version would also be possible, but would create problems with cleaning up the hard drive if anything failed during the install.
Just for fun, I've attached a cut-down of the install program I'm working on with only the modified intro anim for everyone's amusement (hopefully ::) ). The original was using 16 colour bobs on a 32 colour background giving an unwanted masking effect (you probably never noticed!). The original explosions animation seems to have started out as a series of bobs from tiny to massive. It was then changed to screen flipping as more memory efficient, but someone forgot to remove the bobs from the bank... A set of bobs was also splatted directly into the sprite bank from a data bank for reasons unknown. So I couldn't resist cleaning it up and modifying it a bit to emphasise the 'AMOS Pro cleaned up' nature of the release. (Well, I love actually programming in AMOS so forgive the distractions.) I also substituted Say for the voice to incorporate the release version. The idea being to continue this animation for future release versions. The version number is yet to go on the screen and into the dialogues.
This is a very quick and dirty chop out of the testbed program in which I'm developing the installation, so excuse the messy. I haven't tidied anything up yet. It also has the banks embedded rather than loading them at run time as you'd have to modify the code otherwise. This is probably about as 'messy work in progress' as it gets ;D .
-
CDTV and CD32 don't boot from floppy by default since it was an optional add-on for those models to have floppy drives at all. They typically would boot from the CD-ROM. Normally one wouldn't program with those models in their stock configuration anyway because neither of them came standard with a hard-drive either. They were upgradable to computers using expansion decks like the Paravision SX-1 and SX-32.
-
... Normally one wouldn't program with those models in their stock configuration anyway because neither of them came standard with a hard-drive either. ...
Thanks SamuraiCrow. From my limited practical knowledge of the machines, I don't see anyone developing in AMOS Pro on much less than an A1200 upwards. I'll go on with a floppy install then, mainly for the nostalgia and partly as a universal currency.
-
This is a very quick and dirty chop out of the testbed program in which I'm developing the installation, so excuse the messy. I haven't tidied anything up yet. It also has the banks embedded rather than loading them at run time as you'd have to modify the code otherwise. This is probably about as 'messy work in progress' as it gets ;D .
Yeah... not sure if my current AMOS configuration is at fault but...
- Sam Stop causes a syntax error (twice!) at lines 670 and 725
- Once they are commented out it runs, but then crashes! (8000 0004 error)
The animation itself is pretty cool and did make me smile. The explosion is fine, then the other stuff is good. After that thing stops being lowered it crashes...
-
Yeah... not sure if my current AMOS configuration is at fault but...
- Sam Stop causes a syntax error (twice!) at lines 670 and 725
- Once they are commented out it runs, but then crashes! (8000 0004 error)
The animation itself is pretty cool and did make me smile. The explosion is fine, then the other stuff is good. After that thing stops being lowered it crashes...
Thanks for the feedback (I think :D ) Lonewolf10.
That's a bit worrying as I thought there was only one version of AMOSPro_Music.Lib out there. Looks like you may have another!
The AMOS program I posted is stored tokenised (as they all are). So it's essential that the tokens don't change in an AMOS installation. Each token is just a 16-bit number, which is the number of bytes from the start of a token table to the start of that token's details. So the Sam Stop instruction in the source +Music.s:
dc.w L_InSamStop0,L_Nul
dc.b "!sam sto","p"+$80,"I",-2
dc.w L_InSamStop1,L_Nul
dc.b $80,"I0",-1
would have a token representing the number of bytes to the start of that code fragment above (=$246).
A set of tokens for a library looks like this (from +Equ.s, the tokens at the start of AMOSPro.Lib):
_TkVar equ $00000006
_TkLab equ $0000000C
_TkPro equ $00000012
_TkLGo equ $00000018
_TkBin equ $0000001E
_TkCh1 equ $00000026
_TkCh2 equ $0000002E
Not to be confused with the Instruction Numbers used when you're calling a library's code from your own asm code. I.e. they're not just 1, 2, 3, ...
Any change to a library's token table that changes the length of an entry will mean that an existing (i.e. already tokenised) AMOS program using that library won't find some of the tokens.
For example, just one of the bugs in the +Music.s token table is this one (there are others):
dc.w L_InSamLoopOff0,L_Nul
dc.b "sam loop of","f"+$80,"I",-2
dc.w L_InSamLoopOff1,L_Nul
dc.b $80,"I0",-1
It's missing the exclamation mark "!" at the start to indicate it's got multiple parameter formats. Inserting the missing "!" and reassembling would work okay for all tokens up to that point, but any following tokens would be one byte out. Any existing program (i.e. any saved before the change) using those tokens would fail at the Test stage when it was run. Note that any new programs typed in and saved would be fine as they would be tokenised with the new token values. The same goes for any existing programs saved in ASCII - AMOS tokenises them fresh as it loads them.
Which is a nightmare for AMOSPro_Music.Lib's bugs as fixing them does affect its token table. The solution I've been working on is an AMOS program that will examine the files in a directory picking up any *.AMOS ones. It then hunts through the tokens looking for calls to extension libraries (token $004E) that use AMOSPro_Music.Lib (extension 1). Having found one, I can then substitute new for old (see, I knew all that work on tokens wasn't wasted ;) ). I can find them okay, but I haven't decided how best (= fastest) to do the substitution check yet to prevent trying to retokenise a file twice (in theory, shouldn't matter as long as I check each possible token value (= slowest)). Life wasn't meant to be easy...
Anyway, that's a possible cause, as the verification code throws Syntax Error for most things it doesn't understand when checking.
The guru 8000 0004 is a CPU trap for the illegal instruction. The AMOS team used it extensively for debugging. The +Lib.s source has one that someone left behind by mistake after a debugging session. It was only in the source though, not the binary. There are some others in the source in some bug traps, so I'll check those out and also check for the instruction in the V2.00 binaries.
In the sources distribution, the file +Debug.s also has:
Debug set 2
which puts a load of these traps into the binaries if the sources are just assembled 'as is'.
In the meantime, could I ask you to post your copies of:
- AMOSPro:AMOSPro
- AMOSPro:AMOSPro_Interpreter_Config
- AMOSPro:APSystem/AMOSPro.Lib
- AMOSPro:APSystem/AMOSPro_Music.Lib
so I can do a compare of the binaries against the AMOS Pro V2.00 versions?
If your AMOSPro_Interpreter_Config isn't in the directory above, the one in S: will be the one AMOS's using.
-
@bruceuncle
re: tokenization errors
How hard would it be to create a "forwarder" for obsolete tokens? That way you could start a fresh token at the end of the list with the same name as the old token and just have an AmosPro routine in the loader update to the new token entry.
-
@bruceuncle
re: tokenization errors
How hard would it be to create a "forwarder" for obsolete tokens? That way you could start a fresh token at the end of the list with the same name as the old token and just have an AmosPro routine in the loader update to the new token entry.
Thanks SamuraiCrow. Just to put this into perspective:
- This token problem only arises for the core AMOS libraries.
- Any other extensions are SEP (Someone Else's Problem).
- The only core library affected is AMOSPRO_Music.Lib.
Unfortunately, one of the errors in AMOSPro_Music.Lib's token table is the one I quoted - the missing "!". As this is effectively an "invisible" character, a substitute instruction cannot simply be tacked onto the end of the token table and "forwarded" from the original.
AMOS uses the token table in two ways:
- The text part of the entry is used in Tokenising each line of a program when the user hits the [Enter] key, or when an ASCII program file is loaded.
- The Token Number is used in Verifying a program (the Test before Run phase) and in converting the tokens back into something readable for the screen (it just jumps straight to the token entry using the Token Number offset and pulls out the text).
(Before any pedantic peoples post, I'm over simplifying here to keep the explanations short(ish)).
So "!sam loop off" and "sam loop off" both look the same to the Tokeniser.
I'd rather go with a one-off retokeniser program, as that fixes the problem once only. AMOS Pro already does some Instruction Number substitution for old libraries when it loads them. I really don't want to add to that if I can avoid it as there's a big difference between Instruction Number substitution (easy) and Token Number substitution (harder).
There was a retokeniser program with the AMOS Pro release (in the Tutorial directory) used to fix single-to-double-precision problem differences between V2.00 and earlier versions. That could "cheat" as the tokens are identical - the token routines for maths instructions are swapped so single- and double- precision look identical. All that retokeniser had to do was convert each line into text (detokenise) and back again (tokenise). The theory behind that simple statement is a bit more complex than that! So I won't go into it here (I've forgotten the details anyway - it was a while ago that I "understood" it ::) .) My point being that this process of a bit of retokenising for a new version of AMOS Pro is already in "the culture".
I've got so many balls in the air at the moment that the retokeniser is only a minor concern. The Tokenise, Detokenise and Verify code is a hard-coded wilderness in the original code. It makes extensive use of the AMOSPro.Lib tokens being known and unchangeable. I don't fancy adding more to that! I've had to do it to cope with a couple of bugs in the Editor (numeric overflow and incorrect numeric conversion). It took me ages to work out how to exit from the middle of that code to handle the error messages. I gave up on a logical solution and cache the stack pointer at the start instead. So I can jump out of it anywhere, restore the original stack pointer, and handle the error messages. The original code makes extensive use of the stack for temporary storage and tracking where it is at any given point is a real headache :o .
-
UGH! I see what you mean!
-
Yeah... not sure if my current AMOS configuration is at fault but...
- Sam Stop causes a syntax error (twice!) at lines 670 and 725
- Once they are commented out it runs, but then crashes! (8000 0004 error)
The animation itself is pretty cool and did make me smile. The explosion is fine, then the other stuff is good. After that thing stops being lowered it crashes...
Thanks for the feedback (I think :D ) Lonewolf10.
That's a bit worrying as I thought there was only one version of AMOSPro_Music.Lib out there. Looks like you may have another!
I'm completely confused now.
First I checked to see if I was using the Enhanced Music Extension (EME) and no I wasn't, then I pressed F2 - no errors! So I decided to run it and it worked without crashing.
I was working on other things the first occasion I ran it, but a reset (or crash) would fix memory issues (e.g. cake slices, as I believe it was described as somewhere) right? It crashed on me several times before I posted about my issue, but now it is working flawlessly straight from starting WinUAE and I haven't changed any configuration files or anything.
Would you still like me to post the requested files?
-
I'm completely confused now.
First I checked to see if I was using the Enhanced Music Extension (EME) and no I wasn't, then I pressed F2 - no errors! So I decided to run it and it worked without crashing.
I was working on other things the first occasion I ran it, but a reset (or crash) would fix memory issues (e.g. cake slices, as I believe it was described as somewhere) right? It crashed on me several times before I posted about my issue, but now it is working flawlessly straight from starting WinUAE and I haven't changed any configuration files or anything.
Would you still like me to post the requested files?
Thanks Lonewolf10. Don't worry about posting those libraries. My only concern was that there may have been an AMOSPro_Music.Lib out there different to the one originally distributed. From all my waffle on token tables, you probably gathered that my retokeniser has to match against one, and only one, version of the token table. So I can breathe a sigh of relief on that score at least :)
As to why the problems arose in the first place, I'm far from an expert in WINUAE. However, I have crashed it twice, and on the second occasion my desktop gadgets disappeared. Which should be just about impossible in Windows 7! So maybe WINUAE got corrupted or the loaded config file got corrupted. Or maybe even that session of Windows was flaky (happens sometimes). I'd put it down to "just one of those things". Happy to hear it's working fine now. Thanks again for your feedback.
All the AMOS Pro V2.10 assembler and AMOS Basic sources, and all binaries that will allow it, have a version number embedded. So we can quickly check which version we're talking about in the future. (And hopefully pave the way for installed version checking and backup for the Installer program.)
-
Thanks Lonewolf10. Don't worry about posting those libraries. My only concern was that there may have been an AMOSPro_Music.Lib out there different to the one originally distributed. From all my waffle on token tables, you probably gathered that my retokeniser has to match against one, and only one, version of the token table. So I can breathe a sigh of relief on that score at least :)
Yeah, I totally understand :)
As to why the problems arose in the first place, I'm far from an expert in WINUAE. However, I have crashed it twice, and on the second occasion my desktop gadgets disappeared. Which should be just about impossible in Windows 7! So maybe WINUAE got corrupted or the loaded config file got corrupted. Or maybe even that session of Windows was flaky (happens sometimes). I'd put it down to "just one of those things". Happy to hear it's working fine now. Thanks again for your feedback.
Yeah, it seems something was off that day. I have crashed the WinUAE debugger several times before ;D
-
This release is a work-in-progress for a V2.10 release of AMOS Pro (...)
I know it's an old topic but no doubts still very important. Uncle Brcue, are you able to make another fix? I just found a critical bug:
I have a text file with different numbers. Some of them are negative. In my program I do:
1. Read the string, e.g. "-22.0176"
2. Pass that number to a variable# using Val() instruction
3. Display it on the screen
Under AMOS editor it works correctly displaying -22.0176 but after I compile it and run it changes the negative to positive 22.0176!
Try this both in Editor and compiled:
Screen Open 0,320,256,16,Lowres : Flash Off : Curs Off
LINE$="-22.0176"
N#=Val(LINE$)
Print "N#="+Str$(N#)
Print
Wait Key
-
Sounds like a compiler bug, not a problem with AmosPro itself.
-
Sounds like a compiler bug, not a problem with AmosPro itself.
You're right. Any chance of fixing it? I figured out some workaround but to be honest it requires a lot of work in my couple of thousand lines of code and after all it'd be code over code - something that should work without such a contrive.
By the way. I need someone to enlighten me. Is there an exe AMOSPro v 2.10 or just those fixed libraries available in download section that require only swap with original 2.0? I already did that but was wondering if there is a fixed main exe file.
I didn't say that but: Great work guys, whoever is/was involved in fixes. I hope the work is continued. Thanks from my part.
-
Yep, it's a bug in the compiler. It's related to a bug in the ValRout() function in the AMOS core library. That function evaluates a numeric string and returns an integer, single or double. It returns a zero and a fail flag if anything goes wrong (overflow or 'bad' number) or if the string is not a number.
The function is used for two tasks:
1: By the tokeniser in the editor to convert what's been typed in into a number token.
2: By the AMOS Basic Val() function.
The ValRout() function has minor bugs in a branch to the wrong label and inconsistent return values. Unfortunately, the function and parts of it were copied and pasted (complete with bug!) to other parts of the sources, including the compiler. Tracking down what calls the function was not straightforward as at least one reference is via a JSR(An).
Anyway, the function also takes a param in a data register (typing on my phone, so sorry about lack of specifics) which indicates whether to include the sign or not. Reason being that the tokeniser will already have parsed and created a token for any sign, so all it wants is the digits. Whereas the Val() function will need the full signed result.
So it looks like you've found a new bug where the compiler isn't setting the 'sign required' param.
V2.10 is still being worked on. I had a major, major back operation last year which I'm still recovering from. So it's been a bit slow going...
-
Bruceuncle thanks a lot for you reply. It's very complex and explains to the root why the compiler has driven me crazy. I'm glad I didn't lost my mind :D
I'm sorry to hear about your back issue. I can say I totally understand what it means as I'm experimenting similar thing (but I'm still looking for a non surgical solution). I wish you very fast and efficient recovery. And of course I hope for a fix for Val() bug.
Cheers,
Peter
PS Have you seen my feature suggestion (http://www.ultimateamiga.co.uk/index.php/topic,9620.0.html)? I understand it's not easy to apply but it'd be fantastic to have such thing in AMOS Editor :)
-
V2.10 is still being worked on. I had a major, major back operation last year which I'm still recovering from. So it's been a bit slow going...
Hello Bruceuncle,
I would wish you a very fast recovery too
thanks for your great work, hope to see an update in the future :)
Juri
-
This 2.10 sounds exciting. Anyone heard from bruceuncle in a while?
-
We haven't heard from bruceuncle in months.
-
I hope he is all well and fine, considering his last posts.
In the facebook group for AMOS F. Lionet has posted about wished fixes in AMOS, and this would be a perfect timing for bruceuncle join the discussion there, considering his hard work with AMOS 2.10
-
I hope he is all well and fine, considering his last posts.
In the facebook group for AMOS F. Lionet has posted about wished fixes in AMOS, and this would be a perfect timing for bruceuncle join the discussion there, considering his hard work with AMOS 2.10
SYNCHRO [n] or [n TO n]
would be handy for only running amal channels when required :)
-
what a pity that this dear AMOS PRO is no longer updated (I'm talking about the real version, not AOZ)
-
Is AMOS 2.10 still relevant?
-
Is AMOS 2.10 still relevant?
Sorry, there appears to be no one visiting any more.
I have plans to reinvent site and start to get it back to its millions of views
.
-
yes, this site seems to be dead... it's a shame.
-
yes, this site seems to be dead... it's a shame.
Blame Facebook. I believe they all use that instead. I hate Facebook.
-
yes, it's a shame, a website is much more practical than facebook.