Print

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

[Hungry Horace]

I am reassured to see BruceUncle was last online late this January!
 

I was just wondering... how difficult would it be for someone to add an option to save out a text version of the .amos file on each save? (.amost or something)

This would be great for putting AMOS code on something like GitHub, where we would still be able to see any proposed changes to code

[SamuraiCrow]

AmosPro can output ASCII text already but you can't embed banks in text files like you can with  .amos files.

[Hungry Horace]

yes but to do that, you have to highlight text, store it, and save seperately.

I was suggesting an option to save a text file *adjacnet* to the .amos file (not instead of) which therefore covers off the concern about the stored banks

This is so, when using GitHub or similar services, you would be able to see the code changes in the preview windows etc. Obviously the .amos file would just be shown as a binary file.

[bruceuncle]

I am reassured to see BruceUncle was last online late this January!

Yep, still here!  I've not been posting much lately for two reasons:

• I get too easily side-tracked by anything AMOS or Amiga instead of concentrating on AMOS Pro V2.10 
• 2016 was a baaad year for me.  Initial recovery after my op was pretty good but has slowed down a bit too much for my liking.  And many private bereavements, disasters and mishaps in the family and friends

So I've been quietly "getting on with it" and only posting where I can contribute something useful or if info needs correcting.


Getting back to the original question (saving in ASCII) of course it can be done but it wouldn't really be worth the effort involved (=lots).  Remember that an ASCII save does not automatically open any closed procedures.  But what's wrong with a few keystrokes?:

<Amiga>+<Shift>+<O>	Open all Procedures
<Ctrl>+<A>	Select All
<Ctrl>+<S>	Store Block
<Ctrl>+<Shift>+<A>	Save Block as ASCII

Admittedly you'll have to enter a file name and hit <Esc> to go to Direct mode and <F7> to save any banks...

Onwards

There are a few enhancements which I did feel worthwhile:

Syntax Highlighting
The interface for the necessary Editor Configuration screen is complete.  I've stolen a few bytes out of the Editor Config file (and it's A5 offsets when loaded) to contain the data.  This lead to the need to add a new Menu Item to the Editor Config Menu which, in turn, meant having to decode and understand how the menus work...  Suffice to say we now have sources for the Editor_Menus.Asc and Editor_Menus.Bin files.  And I also know a heck of a lot more about how the Editor Function and Key Tables work, along with their associated Autoload Programs and parameters.  More to do but going really well.  May be a bit too slow for an un-accelerated A500 or A2000 but you can switch it off (and who'd want to actually develop in AMOS on an un-accelerated machine?)

Editor Scrolling
Now that I now how the Function and Key tables work, pretty easy.

The Future
Having had (too much!) time to reflect on how we would eventually move into accelerated  Amigas, AGA chipsets and OS 3.x, I completely changed my mind as to how we should approach this.  Trying to shoehorn all the variations into the existing libraries and code just gets far to complex and cumbersome.  So what I propose is:

• When AMOS Pro starts up, the Loader/Linker loads its libraries.  But first it checks the CPU, OS and Chipset and sets appropriate bits in a "Capabilities" word in the A5 data (plenty of room).  What's loaded then depends on that info.
• Depending on the above, it loads the appropriate Amos.Library and AMOSPro.Lib files for the environment.  I'm thinking of only a couple of versions of each.  An "OCS-or-ECS + 68000 + OS up to 2.1" version - i.e. the current ones plus some extra code for ECS.  And an "AGA + 680x0 + OS 3.x" version - on the basis that if you ain't got OS 3.1 or above, you ain't got AGA and vice versa.  Think names like "Amos.Library", "AMOSPro.Lib" and "AmosAGA.Library", "AMOSProAGA.Lib" or similar.  We could debate whether that would cover some more unusual combinations ("680x0 + ECS" for example) but it will all take time and effort and I'm looking for something practical.  Any thoughts?  But read on...
• We currently have two "*.Lib" file formats that AMOS Pro copes with really well.  There's the original libraries/extensions and the V2.0 ones, identified by an embedded "AP20" tag.  The "AP20" libraries use the V2.0 parameter handling.  I'm adding an "AP21" tag.  This version has an extra word following the tag for authors to use to identify what this library/extension needs to run.  The Loader/Linker then uses its "Capabilities" info to check the libraries as it loads them.  If the library/extension is pre-V2.10, it just loads it (nothing we can do there).  For V2.10 onwards, it can check if the environment meets the requirements for the library/extension and accept or reject it (with a appropriate message to the user).
• When we rewrite the more popular extensions, this obviates the problems created by those written specifically for 680x0 CPUs and AGA chipsets.

Bugs
Just about all sorted (for the "known" bugs anyway).  The glaring exception is the Compiler, which I've put away on a shelf until the rest is completed (don't want the distractions!)  It does however incorporate some of the bug fixes that affect ASCII to numeric conversion as the code and bugs were the result of a simple "copy/paste and change the label names" which just propagated the original bugs.

Info Needed
Does anyone have any better code for detecting CPU and Chipsets than what was originally published in the  How To Code V7 series?

Anyone have any better code for FFP-->ASCII and ASCII-->FFP conversions.  The original is ported C Code and is ugly, inefficient and doesn't give me any indication of overflow or underflow (apart from a high-values in the exponent).  Tempted to replace with the original Motorola code for FFP as it's compact, efficient and does indicate if anything went wrong.  Similarly for Double Precision which has the above problems but on a much larger scale.


That's about it for now.  Any comments welcome as usual.  Must get on with it.

[SamuraiCrow]

There have been some problems detecting the Apollo 68080 and SAGA chipset cores by traditional means....  :-)

The AMCAF extension had a function for checking for the AGA chips called IsAGA.  Perhaps we can do something like it for ECS also on Kickstart 2.  The SuperAGA on the Vampire accelerator will be trickier since it runs on Kickstart 3.1 also.

The chipsets should be checked at runtime is the point I am getting to.  That's how the OS does it.