Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Beezle]

Hi everyone,

Not sure if this is the appropriate section of the forum, but I just wanted to say, and share a few ideas with you.

Some of you may already know me, but for those who don't Im a long time AMOS user, amiga, and other retro system fan.

I've currently got a few different AMOS based bits and pieces Ive been playing with, but probably the one I most want to get some feedback on is what I've called, "AMOS4Amiga".

It's actually just the package that was previously released under the name of "AMOS4Windows", and "AMOS4AROS", (and a few other OSes), which for those not aware is a preconfigured AMOS Pro environment, with a bunch of extensions pre-installed, along with AMOS3d, TOME, and a bunch of other goodies.

I have however customised it further, replacing and adding a few extensions, adding useful various amos accessories, and created an installer (along with removing all the emulator and amigaos/aros files that are part of the original packages).

In addition to this, I'm also planning on updating the in-software help menus to include various extensions.
Im however a little uncertain about the best layout for this.
Do people think I should have separate, per extension options in the main help menu, or just intergrate the commands from extensions in their appropriate existing sections?

The overall idea is to offer an improved AMOS experience utilizing already existing software, libraries and a little elbow grease

Any feedback, ideas, thoughts or opinions would be appreciated.

[KevG]

Hello Beezle

It sounds as though you've got your hands full. Its been very quiet here lately but I often check these pages for new stuff. Good luck with your project and keep posting your progress here.

I have also been working on something for a while but is a long way off being finished. Its a version
of AMOS basic for Windows. NOT emulated under WinUAE, but a whole new editor where you can design and run AMOS compatible code that will also run on the Amiga. Interpreted only I'm afraid but it has the advantage of having a modern editor with modern tools which allows rapid development. I've wanted to do this for years because the AMOS editor is just pants.

I should probably get back to it. Finding the time is the problem for me.

[bruceuncle]

Hi Beezle,

Great to see another AMOS devotee having a go at improving the beast  .

I don't know how much you've looked around the forum posts, so apologies if this repeats any stuff you've already looked through.  I'm  up to my neck in the AMOS Pro V2.10 release.  Briefly, this fixes most of the reported bugs, except I haven't fully got to grips with the compiler yet.  It also replaces the original Help system.  It grew from my frustration with the few inaccuracies and missing bits in the original manual and help system.  So I started building a system to edit the help in the format of a PDF document (to be called the "AMOS Pro Reference Manual") with contents, alpha and topic indexes, and full cross references.  I databased the original help files as the starting framework.  Then the AMOS Pro sources became available .  Bliss!  So we started work on V2.10, limited to fixing the bugs and fixing the help - enhancements to be started when we're sure the out-of-the-box AMOS works as intended and is documented properly.  One of the bugs involved the 'escape' characters for printing to screen and the graphics character set.  It dawned on me then that I could use the same data for both the AMOS Pro Help System and the AMOS Pro Reference Manual as I could now use coloured text in the help screens.

I use Access 2010 and VBA for most of the work on the help system.  The very flexible and forgiving database engine and VBA used as an object-style environment gets results up and running fairly painlessly.  Lots of refactoring and many regression copies (V42.00 currently  ) make for a very forgiving development environment.  And CodeWright for source editing.  Anyway, it's at the stage where:

• The help works fine
• Many of the bugs are fixed
• There's still a lot of content editing to do on the help files
• I'm building the installer
• I need to build a retokeniser for any existing AMOS progs using the Music extension.  Fixing a couple of bugs in the token table has changed the token values.

On the docs side of things:

• I need to tweak the AMOS Pro Reference Manual format from A5 to A4.  That will mean less pagination to do on the finished article.  The database exports an RTF format which is then imported into Word.  It then has to have page breaks set the hard way (for well over 1,000 pages!).  Also need to finish tweaking the RTF writer to not pick up anything specific to AMOS help (menus, etc.).
• I've nearly got a working paper on the AMOS File Format which explains both the format, the tokens used, and how the tokens are generated in the Tokenise, Detokenise and Verify stages for a program.  Waiting for me to chase up the exact details for the extra info and offset words used with program structure tokens in the final Verify stage (Do ... Loop, If ... Else ... End If, etc.).
• A 90% complete AMAL quick reference.  Same format as the DBL quick reference I published quite a while back.  I'm not considering finishing this until after AMOS 2.10.
• Nothing to do with AMOS    .  I use Resource V6.06 a lot on the Amiga.  The manual's pretty good but the help system is clunky to use and has a couple of display glitches right where some of the most useful info is located.  As all the real info is in the help system (not in any docs anywhere) it's been frustrating knowing there's a lot of powerful stuff there but no info on how to use it.  So I Re-sourced Resource's libraries to get the data out into my database and, you guessed it, I'll be publishing it as a manual shortly.

The thread  here has an alpha release of V2.10 (copy and rename files, so read the ReadMe) that also demos the proposed help file display format.  It uses colours for the equivalents of the Bold and Italics used in the manual.  Again, read the ReadMe to find them - the remainder of the help file is unchanged.  This post in that topic has the zip file attached to it to save you searching for the correct download.  SamuraiCrow checked it out on AROS and it all works fine.

In addition to this, I'm also planning on updating the in-software help menus to include various extensions.
Im however a little uncertain about the best layout for this.
Do people think I should have separate, per extension options in the main help menu, or just intergrate the commands from extensions in their appropriate existing sections?

AMOS Pro currently caters for this in a very clunky fashion - it looks for LatestNews_nnn.xxx files and uses them if they're present.  So there's only limited expansion.  To provide help for the compiler, it uses a completely separate help system and a modified AMOSPro_Help.AMOS program (two different versions with the same name!).

My "thought bubble" has been along these lines:

• The content of the original help files covers the extensions that come out-of-the-box.  It just needs the compiler help adding to it and the Compiler Shell modded to use that instead of the current "custom" jobbie.
• AMOS Pro knows what extension slots are occupied as it has to load them and relocate them during startup - they're in the config file.  So it's pretty simple to find the names of any extensions that have been added.
• If we use a naming convention for the *.map and *.txt files for the help for each extension so they match the extension's file name, we can grab the data to build a menu screen for the core help system when AMOS Pro starts.  Eg.  AMOSPro_CRAFT.Lib would have matching AMOSPro_CRAFT.map and AMOSPro_CRAFT.txt files for its help.
• We'd also need a combined map table for the context help to work from.  Eg.  Slot Number plus the existing Name Key, File Offset.
• So the user can either:
  
• Hit help with the cursor over a keyword.  The help prog searches the combined map table, grabs the associated Slot Number when it finds the Name Key match, gets the appropriate file name from the data saved at startup and uses the File Offset to grab the display text.
• Start from the Help Main Menu, which will always have the core help available, plus the names of any Extensions loaded.
• The core extensions (AMOS Pro, Music, I/O, 3D, Compact and Compiler) would just use a combined Slot Number of, say, zero as we know what they are.

Let me know if you need any help with help file formats and the help program itself.

I have however customised it further, replacing and adding a few extensions, adding useful various amos accessories, and created an installer (along with removing all the emulator and amigaos/aros files that are part of the original packages).

Make sure you realise the implications of changing a token table in an existing extension.  I'll get that working paper finished a.s.a.p. so you can see what I'm talking about.  I'm probably preaching to the converted  ...

I'll stop blathering on and get back to work.  The last couple of years have left me little time to work on this stuff as so many unexpected 'family crises' have cropped up.  But that's all over now (I hope!) so 2015 should be a good year for AMOS fans. 

[SamuraiCrow]

Since this thread is listed on the news on the front page, I thought I'd better give it a more descriptive title than "Hi Folks".  By the way, welcome to the forum, Beezle!