Print

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

[bruceuncle]

I started this thread as a place for people to post any comments on the AMOS Pro V2.0 sources.  So if you're having a look at them, please post any findings here.

It will be a little while before we get to the stage when the main task will be to review the sources formally.  But, of course, I would expect people to be doing that on an ad-hoc basis already

To start the ball rolling:

amos.library - Source Problems

I've been looking through the AMOS Pro V2.0 sources now available.

In writing the Reference Manual, the new sources are invaluable for checking out assumptions.  Checking the allocation of memory banks lead me to look a bit closer at the +w.s source for amos.library.  It's obvious that there are some chunks of source missing (unresolved bra jumps in the system jump table beginning at the SyIn: label - line 9,928).   Check out the ChipMM and FastMM entries (offsets 55 and 56 on lines 9,983 and 9,984.  The later replacement entries for these functions are there ok.  These are a set of jumps near the end of the table, all starting with a 'W' prefix at line 10,014 onwards (and match up with the actual machine code in amos.library).

As amos.library is probably the first module we want to assemble for comparison with the V2.0 release file, this is a bit of a problem.   

However, with the rest of the source now available, it's easy to Resource  amos.library complete with the AMOS includes labels.   The AMOS team used their own Amiga library equates (+equ.s) for what you'd normally find in the Amiga Includes files.  These sometimes have different names!  And there are a few more to give a finer granularity for the hardware address offsets.

So, I've already taken on the task of:

• Form a set of AMOS symbols files for Resource to use.
• Resource the V2.0 release version of amos.library using the +w.s source as the guide for internal symbols.
• Whilst doing the above, translate the comments!  I downloaded a handy French/English dictionary which, with vague memories of 'schoolboy french', makes that easy.

That will deliver us a source that has english comments and matches both the release version and the equates files.

As I'm still up to my neck with the Reference Manual, this is just one of those repetetive tasks I'm using to fill in the times when the docs are driving me to a padded cell.  So it will take a while.

If anyone's interested in AMOS symbols files for Resource, just let me know and I'll make that more of a priority rather than as-needed.  When I've got them complete, I'll post them in this thread anyway.  It will take a while as the Reference Manual completion is still the highest priority.  But "all work and no play ..."

amos.library - Patches and Other Versions

Does anyone know the history of the amos.library file with 'VER: Amos.library 2.30 (02-12-98)' at offset $58?   It's obviously not an in-place hack as it's a complete reassembly of the library.  So it has the hallmarks of an 'official' patch by someone with access to the sources.  Any info would be useful.

Any other versions of amos.library out there?

[Spellcoder]

Pietro did some patches to amos.library and a few other files between I think 1998 and 2001.
Some things he did (date added for fixed for which I know when he released a patch):

• (?) fix for printer commands?
• (27 aug 1998) speed of flipping between AMOS and Workbench twice as fast and more OS-friendly
  and 'The interlace problem with AmigaOS 3.1 is fixed'
  
• (11 sep 1998) 'Limit Bob' command fixed (was an error in the check whether the given coordinates where correct)
  
• (13 may 2000) fix for compiled AMOS programs (in Header_CLI.Lib and Header_BackStart.Lib) where memory is deallocated before amos.library is finished cleaning up
  

I didn't get a response yet from Pietro whether his fixes are in the AMOSPro sourcecode distribution. So I assume they aren't in there?

[bruceuncle]

Pietro did some patches to amos.library and a few other files between I think 1998 and 2001.

Thanks for the info Spellcoder.   This V2.30 file seems to be one of those.

Unfortunately (for me!) I can't do a binary compare to check the differences as all the relocated branches show up as changes.   So I'll have to Resource that version of amos.library, as well as the V2.00 release version, to get at what was changed.

Anyone know of any later versions?  The latest I have is this one we're talking about - 'VER: Amos.library 2.30 (02-12-98)'.  I obviously don't want to take the time to Resource it if there's any later version.  Any 'fixes' already done will save us a lot of time later.

[bruceuncle]

If anyone's interested in AMOS symbols files for Resource, just let me know and I'll make that more of a priority rather than as-needed.  When I've got them complete, I'll post them in this thread anyway.  It will take a while as the Reference Manual completion is still the highest priority.

I needed to do this sooner rather than later as using Resource on +w.s (the source for amiga.library) needs the Bob data structure straight away.

So here they are.

To use them, just add them in as Resource User Symbol files.  I'm using V6.06 which has a simple GUI that makes this a simple task.  For earlier versions I think this was a menu function instead.  V6.06 is certainly way ahead of the Resource version I remember from my 'real' Amiga days.

I generated the symbol file sources using VBA on the Wintel side, and assembled them with a batch file on the Amiga side.  Slowly getting used to AmigaDOS again .  There was no point individually documenting each source, so I've included the UserSymbols.doc file from Resource, which explains all.  Also be sure to view the ReadMe.doc file which explains what each one contains.

Resource can only use unique symbol values in any one symbol file.  Otherwise it wouldn't know which symbol to use for duplicate values.  So the plethora of miscellaneous AMOS equates can't be handled this way.  Just create them on the fly as needed.  Resource will include them as equates as the start of any *.asm file it produces.  So they're easy to check for accuracy.

For the same reason, I've had to make a choice where the AMOS team created duplicate symbol values in the data structures (for 'clarity' in the sources?!).  E.g. WiTitH and WiSAuto in the AMOS window data structure.  You may not always agree with those choices .  If appropriate, just create any necessary ones on the fly as above.

As it seems we 'll have to use Resource a fair bit in this project, if anyone needs any help using it just send me a PM and I'll try to demystify it for you.  I've got quite a bit of experience with it now  .

[bruceuncle]

This is a continuation of an off topic discussion from here:
http://www.ultimateamiga.co.uk/index.php/topic,9641.msg45324.html#msg45324

@james666 regarding bug fixing and AGA enhancements:

I started at the beginning with the sources: the loader (+b.s and +verif.s).  I'm trying to build up an overall picture of the architecture before I get stuck in to bug fixes and enhancements.  Which doesn't mean that I don't get very distracted at times! 

From there, it's amos.library and the extension libraries (which includes AMOSPro.Lib which is treated (mostly!) as just another extension).  Then the editor (+edit.s) and monitor (+monitor.s).  The AMOS Libraries are fairly well understood already as they were exposed through +music.s early in AMOS Pro's life.  It's the rest that needs exploring and documenting now.  The compiler comes last as if the rest don't work right, the compiler stands no chance!

AGA

There was a lot of discussion early on about AGA enhancements.  This post and the thread it's in will give you some idea if you haven't already read them:

http://www.ultimateamiga.co.uk/index.php/topic,9520.msg44818.html#msg44818

One idea that only just occurred to me as I read your post is have two amos.library implementations and switch between them when tokenising.  Or one amos.library with two branch tables and switch between those.  This is me very much 'shooting from the hip' so take these comments as such.

This would increase the memory requirements as all libraries are loaded and jumps relocated at startup.  But is anyone seriously running AMOS Pro on 1/2 or 1 meg systems?

The tokenisation already does something similar to switch libraries between single- and double-precision math libraries depending on what it finds.

Tokenisation

If you haven't already looked at tokenisation, it works like this.  These are a few generalisations as there's a bit of tight-coupling here and there.  But it's only intended as an overview of the process:

• When a line is entered in the editor's text buffer, it is immediately tokenised and placed in the program buffer when the user moves the cursor off that line.  It's also immediately detokenised back to the editor's text buffer to format the line (case and spacing).  This tokenisation places blank relocation offset words in the program buffer as it would be too intensive and time-wasting to resolve all offsets in the program each time a line is changed.
• Hence the next phase when the user Tests or Runs the program.  The same tokenisation is performed but with syntax checking added and offset words resolved.  This is the point at which it can detect syntax errors.
• Some tokens are 'special' in that they need to be known outside of any extensions that may be loaded.  These are mostly program structure tokens like If ... Then ... Else and loops, labels, procedure and function calls.  Basically anything that will require calculating offsets for tokens that are followed by offset words.  (Incidentally, that word length for an offset is why huge If ... Else If ... End If and loop structures will eventually bomb out when the offset overflows.)  So it's tightly coupled with AMOSPro.Lib.  Not too bad as nothing would work without that 'extension'!
• Tokenisation is at least a two stage process (may be more, I haven't finished exploring yet).  It will throw up the errors that apply to syntax mistakes.
• Next, the interpreter takes over when the program is Run.  If it's been changed since the last Test, it will retokenise (to be sure, to be sure) and then start interpreting based on the tokens and offsets.  A call to an extension instruction's token has a simple offset into the loaded libraries tables.  The extension's code is expected to take care of parameter values checking (correct parameter syntax checking will have already been done in the Test part which also uses the loaded libraries table).
• For extensions, if the loader discovers an old-format extension, it remaps some of the core functionality via a table so that the old-format still works okay in Pro V2.0.

I'll be drawing the pretty pictures and documenting the AMOS Pro architecture so we'll all know what the overall picture is.  But it will take time!

Quo Vadis?

Back to the sources.  Our original concept was to reproduce the AMOS Pro executables byte-for-byte from the sources.  This was to make sure that we had the correct versions to match the commercial release.  So we would normally be a bit concerned about size mismatches.  However, as I found out myself, these discrepancies appear to be caused by long offsets for bcc branches.  But we should prove that before we get too carried away.  There must be a parameter in Genam that we need to set to get it to optimise bcc instructions that have no offset length specified (eg. bsr instead of bsr.b, bsr.w or bsr.l).  It would be tedious to have to specify these explicitly just to achieve a byte-for-byte match.

The same applies to all the *.AMOS programs used in the system.  We must match the commercial release so we have a fixed starting point for changes.

As long as any bug-fixes are commented as such it shouldn't matter too much in the long run as they'll all be incorporated into a (hopefully) bug-fixed release.  I want to avoid using the word 'official' release!     But we need to avoid having umpteen versions of AMOS Pro out there, each fixing specific bits and pieces.

The release should be a hard-drive-only install that will run unattended and with the registration fixed to an acknowledgment to Francois and the team instead maybe?

[james666]

That's great information on tokenisation Bruce.  I've never looked at it in detail.  All I knew is that new commands in my extensions magically worked!  Incidentally, was the new 2.0 extension format known before the AmosPro source code was released?  I hadn't seen the "20/07/93" version 2.0 of music.s before.  (Damn, I can't believe 20 years have gone.)

I think it would be best to have just one tokenisation procedure for the core amospro.lib commands and one amos.library that intelligently handles any AGA requests - similar to the standard Amiga graphics.library.  In theory the low-level coding shouldn't be too hard.  The AGA hardware isn't really that different - just 2 extra bitplane pointers and a couple more control registers.  The main difficulty is that the existing screenbase structure (6 physical bitplanes, 6 logical bitplanes, 6 current bitplanes) is probably hardcoded in a lot of places.

I'm pretty sure we can put together a working, re-assembled version of the existing AmosPro 2.0 in short order.  As discussed on the other thread, the sources seem fine.  I've already got byte-exact versions of AmosPro and the editor, and tweaking the Devpac options will probably give 1:1 copies of amos.library and amospro.lib too.  I'll work through the other components over the next few days.  I would suggest that we write a standard workbench installer script that produces a complete Amos 2.0 environment in one step.  This would be a big improvement in itself because users would no longer have to run the buggy AmosPro 1.x installer and then install the compiler in a separate step. 

It's inevitable that there will eventually be multiple homebrew Amos distributions, just like with Linux.  That's the beauty of open source - anyone can make changes and it's up to the users to decide which they prefer.  To avoid confusion we therefore need to have a consistent branding for the Amos Factory version, including suitable notes in the startup screen and help files.

[bruceuncle]

From the Source Code Versioning System and Repo thread:

It's also worth setting up an alternative Devpac environment using the Genam executable from the sources distro.  Just slot it in as a replacement.  It will glide over the illegal bit manipulation instructions without reporting an error.  I know that sounds blasphemous, but bear in mind that we need to be able to reproduce amos.library exactly as the original to be sure we haven't got a modified version.  We know that bug exists so can address it later when we've proved we've actually got unmodified sources.

And it does cause a problem at least in one point in the code when it's used against the hardware registers - see +w.s at line 277.  Exactly which bit in DMACONR did they intend to issue a read to?  BZERO or SPREN?

For similar bit operations on label offsets from a5, it's self-correcting.  Which is probably why they didn't notice it.  But the hardware registers are different as I understand that they should always be referenced using word-sized data.  Can anyone confirm that as I'm still a novice as far as Amiga hardware's concerned?

I think I got this notion because the hardware registers can only be accessed on word boundaries.  So trying to use a bit operation on a byte address that's not word-aligned would never work as the address's lowest bit is masked out by the system.

Should we convert the 'culprits' to:

	move.w	Offset(An),Dn
	btst	#Mask,Dn

(substitute for Offset, Mask, An and Dn according to context) rather than subtract 8 each occurrence?  It would be in keeping with best practice and assemble without any mutterings at the expense of a few bytes and a few extra CPU cycles.

[bruceuncle]

Incidentally, was the new 2.0 extension format known before the AmosPro source code was released?  I hadn't seen the "20/07/93" version 2.0 of music.s before.  (Damn, I can't believe 20 years have gone.)

I haven't checked the two against each other.  You can identify a V2.0-format library by "AP20" embedded at offset $32 from the start of a library file.  Pre-V2.0 libraries don't have it.  (The same for all those Extensions written before the 2.0 source release!)  Interestingly, AMOSPro_3d.Lib isn't V2.0, all the other 'core' libraries are.

The only important difference from the interpreter and compiler's viewpoint seems to be that some of the core functions have to be re-mapped for a pre-V2.0 library that calls amos.library.  There's a table in +b.s that handles the re-mapping at line 2,667 labelled Ext_Convert.  The comment just mentions "AMOSPro 1.0 >>> AMOSPro 2.0".

I haven't been into the detail yet of this yet, so anyone interested should have a look themselves as there's some assumptions in that previous paragraph! 

[gibs]

Hello,
Is there a trick to compile with the James fixed Amos Library (without having a crash at launch) ?
Thanks

[bruceuncle]

Hello,
Is there a trick to compile with the James fixed Amos Library (without having a crash at launch) ?
Thanks

james666 kindly agreed to his bug fix being included in the AMOS Pro V2.1x project.  That's the one where we're gradually fixing bugs and upgrading the documentation.  You can get the modified binaries and sources in this zip.

If you want to play around with the source files, you need to do a bit of editing for the includes files.  I'd recommend replacing the original includes with a set from DevPac for V2.1 or later.  Do include the ones in the zip file mentioned above.  The original sources were mostly fine and will give a byte-for-byte binary when you assemble them.  However, the ones for AMOSPro.Lib (+Lib.s and +ILib.s) contain an illegal instruction (left over from a debugging session and forgot to remove it?).  So be careful to do binary comparisons before you rely on a source.  Many of the files in the sources distribution are not required.  They're just left over from development.  So I found it a much cleaner environment to make my own development directory and just copy in the essential files.

I would also recommend reading this thread in full for some of the traps and pitfalls involved.  There's also a map of the files used here.

PS.  Does anyone know where the original sources can be downloaded these days?  My original link was to the PlanetAmiga site which has no trace of them now.  If they're not out there and generally available, should we put them in the Downloads section on this site?

[gibs]

Hello. I can compile.

On A500, from the editor it works.
From The workbench, it doesn't.

On A1200 the program works from the Editor & Workbench.



I have installed the new Amos.library + AmosPro.lib I found in your pack 2.10 alpha.

[gibs]

On A500, When I launch the compiled program from the WB, it report a "Software Failure":

Amos
Program Failed (error #80000003).
Wait for disk activity to Finish.

[bruceuncle]

Sorry gibs, I completely misunderstood the question  .  I thought you were asking about assembling the sources.

I'm afraid I can't be much help on the compiler yet.  We know there's something radically wrong somewhere in the guts of it.  But I'm not looking at it until the Interpreter bugs and docs are fixed.  It's apparently not unusual for the compiled programs to misbehave or refuse to compile.  I can see some optimisation being done in the compiler source so maybe that's at fault.  In theory, the compiler is just stitching together code blocks that the interpreter uses.  So it should all work.  There are so many problems cropping up from it that I may have to 'get distracted' from what I'm trying to do with the rest of AMOS and have a look.  Another chunk of rainforest due to hit the dust then as I deliberately hadn't printed out that source so I wouldn't be tempted...  So much for good intentions 

[gibs]

Ok ok take tour time. You guys are doing a fantastic job and I really appreciate. So I'm on my own this time. I will try to find why it fails on A500 and not on 1200 but I think it's since I switched the library and lib.

[gibs]

I have investigated a bit:
So my binary crash on A500 and not on A1200 (weird).

To try to understand what make it crash, in the code I put :
Print "After Setbuffer"
Wait Key
Print "After Blah blah"
Wait Key

Well, I don't even see the text after the 1st line of Code (after Set Buffer).
Of course I removed Set buffer, but it also doesn't work.
While it works on A1200.

Then I tried to Disable AGA , Then Cpu Cache, to make it crash on A1200 but it doesn't.

Back on the A500 : I tried in emulation to put 2MB of Chip Ram : Same result (crash).
And of course on my real A500+ (1MB of Chip and 8MB of Fast) it also crash.


EDIT: After hours of research, I found that it has nothing to do with the compiler or the new library, that's the good new It was my Banks. I have removed them before compiling and I don't have the crash anymore... Funny because there was no problem with the A1200 config.
You can erase those messages, as they are useless in this thread.