Print

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

[bruceuncle]

I'm starting this topic as a place to put the work-in-progress for the analysis of AMOS Pro V2.0.

It continues from some previous posts in the AMOS Pro and AGA topic.  This is a more suitable place for them.

I've attached the latest PDF of where I'm up to.  Note that this is very-much-work-in-progress and posted to whet your appetites.  The analysis is a lot further ahead than the documentation.  One is a lot of reading, research and note-taking.  The other is a slog through Visio to get it on paper  .

No one seems to have noticed that I'd slipped into calling amos.library amiga.library in the last PDF (must have been a Freudian slip).  So I wonder if anyone's reading any of this stuff?!!  Please let me know  .

[SamuraiCrow]

As far as knowing what Amiga.library was, I was kind of confused but I thought I would figure it out later.

[Lonewolf10]

No one seems to have noticed that I'd slipped into calling amos.library amiga.library in the last PDF (must have been a Freudian slip).  So I wonder if anyone's reading any of this stuff?!!  Please let me know  .

I have been reading it and did make a mental note of a few things that needed amending from your previous PDF - however, I forgot to post it on here. There were just a few things that needed moving about, or a few typo's. Admittedly the "amiga.library" thing was not one of them

I did spend some time last night pulling apart the Resource Screen Open sources, but it's getting very confusing with labels starting with L_, Dia, Sys_, PRT_ or a combination. I don't know off hand which are macro's (ok, I remember L_ is from your documentation, but I have no clue what the others are).

Here's something I snipped from +music.s last night, which I'm sure will be useful so will post it here:

Code: [Select]

; The beginning of each routine is defined with macros. NB: in the following text
; a space in inserted in the macro name, so that it is not detected by
; "Library_Digest".
;
; Lib_ Def Function_Name_No_Parameter
; or
; Lib_ Par Function_Name_With_Parameter
;
; Those two macro have the same function:
; - Create an entry in the library offset table, so that AMOSPro locates
; the function,
; - Are detected by Library_Digest: it then creates a label in the "_Label.s"
; file (see above) of the following form, by appending a "L_" to the name:
; L_Function_Name_... This label must be used in the extension to reference
; the routine.
;
; Differences between Lib_ Def and Lib_ Par
; - Lib_ Def must be used for internal routines (ie, not instructions or
; functions)
; - Lib_ Par must be used for instructions or functions: it reserved a space
; before the routine if used by the interpreter, to call the parameter
; calculation routines. Well this is internal, you don't have to care
; about it, just use "Lib_ Par" for routines referenced in the token
; table...


I haven't looked closely at the internal functions sources (the ones also listed in the file +music.s), but here are my notes from a few years back when I was playing around writing my own extension:

Code: [Select]

  Special Commands
  ================

  AMOS loads the whole extension, but the compiler works differently.
  The compiler picks each routine in the library and copy's it into the
  program, INDIVIDUALLY. This means that you MUST NEVER perform a JMP, a
  BSR or get an address from one library routine to another, as the distance
  between them may change!!! Use the special macros instead...

  Importants points to follow:

      - You cannot directly call other library routines from one routine
        by doing a BSR, but I have defined special macros (in S_CEQU file)
        to allow you to easily do so. Here is the list of available macros:

        Rbsr    L_Routine       does a simple BSR to the routine
        Rbra    L_Routine       as a normal BRA
        Rbeq    L_Routine       as a normal BEQ
        Rbne    L_Routine       ...
        Rbcc    L_Routine
        Rbcs    L_Routine
        Rblt    L_Routine
        Rbge    L_Routine
        Rbls    L_Routine
        Rbhi    L_Routine
        Rble    L_Routine
        Rbpl    L_Routine
        Rbmi    L_Routine

  I remind you that you can only use this to call an library routine
  from ANOTHER routine. You cannot do a call WITHIN a routine, or call
  the number of the routine your caling from...
  The compiler (and AMOSPro extension loading part) will manage to find
  the good addresses in your program from the offset table.

  You can also call some main AMOS.Lib routines, to do so, use the
  following macros:

        Rjsr    L_Routine
        Rjmp    L_Routine
 
 
  As you do not have access any more to the small table with jumps to the
  routines within AMOS, here is the concordance of the routines (the numbers
  are just refecrences to the old AMOS 1.23 calling table, and is not of
  any use in AMOS1.3):


        Rjmp    L_Error            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~
        Jump to normal AMOS error routine.
        IN:     d0.l=AMOS error message number (e.g. 159="Break Detected")
        OUT:


        Rjmp    L_ErrorExt            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~
        Jump to custom defined message, stored at the end of the extension.
        IN:     d0.l=Custom defined message number
                d1.l=0  (Can be trapped)
                d2.l=Extension number  (Can be any number!!!)
                d3.l=0  (Important - display error msg on?)
                a0.l=Address of first error message in extension
        OUT:


        Rjsr    L_Tests            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~
        Perform one AMOSPro updating procedure, update screens, sprites,
        bobs etc. You should use it for wait loops.
        IN:
        OUT:


        Rjsr    L_WaitRout            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~
        Used by the AMOS Play command. Function unknown (Francois didn't say!)
        Wait for end of sound data, signalled by 0 time in last Play command?
        Failing to signal end with 0 time (eg. Play 20,0) will result in an
        endless loop that can only be interrupted with Control+C.


        Rjsr    L_GetEc            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~
        Get screen base address

        In:     D0.l= number, Out: A0=address   ("|Music.s", AP 1.0?)
        In:     D1.l= number, Out: A0=address   (ADB using AP2.x)


        Rjsr    L_Demande            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~
        Ask for string space (must be EVEN).
        IN:     D3.l=Length   (AP 1.0?)
        OUT:    A0=Points to free space
                A1=Points to free space

        Put your string in the space provided (starting at the address in a1) in
        AMOS format (eg. first 2 bytes=string length, and the rest is the string),
        add the length of the string to a1 and EVEN the address to the highest
        multiple of two. Move the value of a1 into HiChaine(a5) location.
        Example:

        string="Example"
        length=7                       length requested=10
        a1    =380422                  a1 for HiChaine =380432

        It is possible to use a0, since L_Demande returns same address in a0 & a1!
        If you get the HiChaine value wrong AMOS will either return an "out of string
        space" error, it will crash at the next string-based command, or AMOS code
        in the editor may have random characters appear after an a$="string" command!
        For more HiChaine help see the JVP extension or ADB Extension24 source code.


        Rjsr    L_RamChip            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~
        Ask for PUBLIC|CLEAR|CHIP ram.
        IN:     D0.l=size
        OUT:    D0.l=address of start of memory
                Z set if not successful


        Rjsr    L_RamChip2            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~
        Ask for PUBLIC|CHIP ram.
        IN:     D0.l=size
        OUT:    D0.l=address of start of memory
                Z set if not successful


        Rjsr    L_RamFast            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~
        Ask for PUBLIC|CLEAR ram.
        IN:     D0.l=size
        OUT:    D0.l=address of start of memory
                Z set if not successful


        Rjsr    L_RamFast2            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~
        Ask for PUBLIC ram.
        IN:     D0.l=size
        OUT:    D0.l=address of start of memory
                Z set if not successful


        Rjsr    L_RamFree            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~
        Returns free memory
IN:
OUT: d0.l=amount of free memory


        Rjsr    L_Bnk.OrAdr            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~
        Find whether a number is a address or a memory bank number
        IN:     D0.l= number
        OUT:    D0/A0=start address of bank


        Rjsr    L_Bnk.GetAdr            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~~
        Find the start of a memory bank.
        IN:     D0.l=   Bank number
        OUT:    A0=     Bank address
                D0.w=   Bank flags
                Z set if bank not defined.


        Rjsr    L_Bnk.GetBobs            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
        Returns the address of the bob's bank
        IN:
        OUT:    Z       Set if not defined
                A0=     address of bank


        Rjsr    L_Bnk.GetIcons            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        Returns the address of the icons bank
        IN:
        OUT:    Z       Set if not defined
                A0=     address of bank


        Rjsr    L_Bnk.Reserve            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
        Reserve a memory bank.
        IN:     D0.l    Number
                D1      Flags
                D2      Length
                A0      Address of name of the bank (name is 8 bytes long)
        OUT:    Z       Set if not successful
                A0      Address of bank
        FLAGS:
                Bnk_BitData             Data bank
                Bnk_BitChip             Chip bank
                Example:        Bset    #Bnk_BitData|Bnk_BitChip,d1
>>>>    NOTE:   you should call L_Bnk.Change after reserving/erasing a bank.
>>>>
>>>> L_Bnk.Change not defined by Francois!!!


        Rjsr    L_Bnk.Eff            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~
        Erase one memory bank.
        IN:     D0.l    Number
        OUT:


        Rjsr    L_Bnk.EffA0            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~
        Erase a bank from its address.
        IN:     A0      Start(bank)
OUT:


        Rjsr    L_Bnk.EffTemp            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
        Erase all temporary banks
        IN:
        OUT:


        Rjsr    L_Bnk.EffAll            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~~
        Erase all banks
        IN:
        OUT:


        Rjsr    L_Bnk.Change  (L_BkChange?? L_Bnk.Change not defined in "|LEqu.s")
                                AMOS doesn't like L_BkChange???
  ~~~~~~~~~~~~~~~~~~~~~~~~~~
        Inform the extension, the bob handler that something has changed
        in the banks. You should use this function after every bank
        reserve / erase.
        IN:
        OUT:


        Rjsr    L_Dsk.PathIt            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~~
        Add the current AMOS path to a file name.
        IN:     (Name1(a5)) contains the name, finished by zero
        OUT:    (Name1(a5)) contains the name with new path, finished by zero
        Example:
                move.l  Name1(a5),a0
                move.l  #"Kiki",(a0)+
                clr.b   (a0)
                RJsr    L_Dsk.PathIt


        Rjsr    L_Dsk.FileSelector            ** Tested **
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        Call the file selector.
        IN:     12(a3)  Path+filter
                8(a3)   Default name
                4(a3)   Title 1
                0(a3)   Title 2
                All strings must be in AMOS string format:
                        dc.w    Length
                        dc.b    "String"
        OUT:    D0.w    Length of the result. 0 if no selection
                A0      Address of first character of the result string
                        String finished with a 0

  L_Bnk.ResBob ;found in "|LEqu.s" from AP1.0   - ResBob - Amos 2.x doesn't like (ADL)
  L_Bnk.ResIcon - ADL (Rjsr)
  L_Bnk.InsBob - ADL (Rjsr)
  L_Bnk.DelBob - ADL (Rjsr)
  L_Bnk.Load - ADL (Rjsr)
  L_Bnk.SaveA0 - ADL (Rjsr)
  L_Bnk.SaveAll - ADL (Rjsr)
  L_Lst.ChipNew - ADL (Rjsr)
  L_Lst.New - ADL (Rjsr)
  L_Lst.Del - ADL (Rjsr)
  L_Lst.DelAll - ADL (Rjsr)
  L_Dev.Open - AP 2.x accepts!!  Does it work?
  L_Dev.Close -
  L_Dev.GetIO
  L_Dev.AbortIO
  L_Dev.DoIO
  L_Dev.SendIO
  L_Dev.CheckIO
  L_Dev.Error

Now to go back and pull my hair out over Resource Screen Open!! (I will discuss this further in the Limit Mouse thread)

[bruceuncle]

Thanks Lonewolf10 

I did spend some time last night pulling apart the Resource Screen Open sources, but it's getting very confusing with labels starting with L_, Dia, Sys_, PRT_ or a combination.

Have a look at the system, screen and window library call macros in +Equ.s.  That's where the common macros are. 

They make it a bit of a pain following the code as you'll see something like:

     EcCall   SPal

but you won't find SPal as a routine anywhere.  Similar to the L_xxx labels, SPal is just an instruction number (in +Equ.s) indexing into a jump table in +W.s.  So the routine there is really called EcSPal.  Which is very tedious as you have to track each one down to find out what's happening.

The Dia, Sys_ prefixes are also in +Equ.s.  PRT_ is another routine label prefix I think.  Look for L_PRT_ in +Lib.s.

Have you got a text editor that can do searches across multiple files?  That's pretty well essential for tracking stuff down.  Let me know if you haven't and I'll see what I can dig up.

I haven't looked closely at the internal functions sources (the ones also listed in the file +music.s), but here are my notes from a few years back when I was playing around writing my own extension:

Many thanks mate.  That's still all relevant to V2.0 libraries.  The major change was to handle the instruction and function numbers a bit differently (that's about where the analysis doc's up to).  I'll get the next steps detailed in Visio as soon as I can.  But in summary, it does a lot more work with those parameters.  It inserts a call to parameter handling routines that replace the GetP longword generated by a Lib_Par macro.  So it speeds up the interpreter's access to parameters for an AMOS Basic instruction or function.  Presumably it does a better job in the compiler but I haven't got that far yet.  And I still haven't a clue what +Toktab_Verif.Bin represents!

[Lonewolf10]

Have a look at the system, screen and window library call macros in +Equ.s.  That's where the common macros are. 

They make it a bit of a pain following the code as you'll see something like:

     EcCall   SPal

but you won't find SPal as a routine anywhere.  Similar to the L_xxx labels, SPal is just an instruction number (in +Equ.s) indexing into a jump table in +W.s.  So the routine there is really called EcSPal.  Which is very tedious as you have to track each one down to find out what's happening.

The Dia, Sys_ prefixes are also in +Equ.s.  PRT_ is another routine label prefix I think.  Look for L_PRT_ in +Lib.s.

Thanks

Have you got a text editor that can do searches across multiple files?  That's pretty well essential for tracking stuff down.  Let me know if you haven't and I'll see what I can dig up.

At the moment I just use the text viewer in WinRAR to search through the files using the search function.

I haven't looked closely at the internal functions sources (the ones also listed in the file +music.s), but here are my notes from a few years back when I was playing around writing my own extension:

Many thanks mate.  That's still all relevant to V2.0 libraries.  The major change was to handle the instruction and function numbers a bit differently (that's about where the analysis doc's up to).  I'll get the next steps detailed in Visio as soon as I can.  But in summary, it does a lot more work with those parameters.  It inserts a call to parameter handling routines that replace the GetP longword generated by a Lib_Par macro.  So it speeds up the interpreter's access to parameters for an AMOS Basic instruction or function.  Presumably it does a better job in the compiler but I haven't got that far yet.

Thanks for the info.

And I still haven't a clue what +Toktab_Verif.Bin represents!

I have been thinking about that and if you compare it to the start of the Amiga ROM (probably easiest using the WinUAE debugger if you have WinUAE), it looks rather similar. Whilst I don't think it contains assembler code, it does appear to contain some sort of jump table and perhaps a few other things too. I haven't looked too closely into this at the moment.


Regarding your latest PDF posted above, could you move the "Make_Labels.AMOS" bubble on page 19 to the left so it doesn't cover up what I presume is LEqu.s?

It's good to see the instruction token tables documented properly
I'm going to have to check my notes, because I have a feeling you are missing something out.

[bruceuncle]

Regarding your latest PDF posted above, could you move the "Make_Labels.AMOS" bubble on page 19 to the left so it doesn't cover up what I presume is LEqu.s?

Thanks: Done 

The way I put this stuff together is to "brain dump" the text.  Then put the pretty pictures together (I'd never used Visio before but it's so easy.  Just like using Lego  ).  Then finally get the layouts looking right.

The last doc is a bit cut off in the middle.  So I'll try and get it documented through to the end of library loads a.s.a.p.  It will make a lot more sense then.

I think the code is a hack from the original AMOSPro executable sources as it adds 1 to an Instruction Routine Number but doesn't for a Function Routine Number.  Which is what the original jump tables did.  The jumps and tokens were embedded in the AMOSPro executable and seem to be laid out as Function jump offset / Instruction jump offset / Token // Function jump offset / Instruction jump offset / Token // etc.  Hence the add 1 to an Instruction's Routine Number. 

Then it puts it all right for the V2.0 library format (the plus 1 is "corrected") when it goes through the tokens inserting the Parameter Fetch Routines.  So the end effect is just the same as for a pre-V2.0 library.  The big difference is that there will only be one jump offset word for a token when it's complete.  The other word is taken up by that set of parameter flags.  So for Reserved Variables (Instruction + Function) the routine addresses must follow each other in the Addresses Table.  The offset will only point to one address in the table.  The other address is always assumed to be the next one.  That's why the hangover from the original AMOS Pro where it adds 1 to an Instruction's address number. 

If you look at the way the +LEqu.s lists the Routine Numbers, you'll see that the ones used for AMOS Basic Instructions are laid out with the function always following the instruction for Reserved Variables.  And, luckily for us they stuck to the strong naming convention of L_Inxxx and L_Fnxxx for Instructions and Functions respectively. Eg.:

L_FnHunt:      set   574
L_InAReg:      set   575     ; Areg() Instruction
L_FnAReg:      set   576     ; Areg() Function
L_InDReg:      set   577     ; Dreg() Instruction
L_FnDReg:      set   578     ; Dreg() Function
L_IReg:        set   579

But at the stage the docs are up to, that's not shown yet.  Apologies if that's just making it more confusing.  The next instalment should clear it all up.

Back to the grindstone.... 

[bruceuncle]

And I still haven't a clue what +Toktab_Verif.Bin represents!

I have been thinking about that and if you compare it to the start of the Amiga ROM (probably easiest using the WinUAE debugger if you have WinUAE), it looks rather similar. Whilst I don't think it contains assembler code, it does appear to contain some sort of jump table and perhaps a few other things too. I haven't looked too closely into this at the moment.

The stuff in it is derived from those //$01$19$05$00 comments against each token in +Lib.s.  The Make_Toktable.AMOS program in the Dot_AMOS directory in the sources distro generates it.  So I assume each couple of words is related to a token.  Really strange is that these values are swapped for the routine offsets when a program is run, then the original offsets are swapped back for editing and testing.  It's a worry as the code's very obscure so far.  And if we go adding new tokens to +Lib.s, they won't work unless we know how to generate their two-word codes.  And I can't believe Francois and the team laboriously typed them in by hand!  The compiler doesn't appear to reference them at all but don't quote me on that.  I'm steadfastly resisting the temptation to go there until all this other stuff is completed 

[bruceuncle]

This is the next instalment of the work-in-progress for the analysis of AMOS Pro V2.0.

It continues with what the Loader does and how it works.  It's now to the point where the Libraries have been relocated (phew!) so I thought that an appropriate milestone for another publication.  Please, please bear in mind that this is an unfinished chunk of work.  So expect typos and other minor stuff-ups.  There's also no Contents pages yet as they will only be added when the whole thing is completed.  This is being done in Visio so anyone with experience in that app will know why  .

If all goes well, I will be unavailable for a couple of weeks towards the end of this month.  We'll be moving house.  I'll let everyone know when as it may take some time to get back on the 'net.  We're moving to the country where things happen a bit slooower than in the big city lights  .  I'll still be able to view the site on my smartphone.  But typing replies on that is a bit like "washing your feet with your socks on".  Now where have I heard that expression before... ?

[SamuraiCrow]

@bruceuncle

Congrats on moving house!  My wife-to-be has packed a bunch of her stuff and brought it over to my apartment in preparation for the big day when she becomes my wife!

[bruceuncle]

@bruceuncle

Congrats on moving house!  My wife-to-be has packed a bunch of her stuff and brought it over to my apartment in preparation for the big day when she becomes my wife!

Thanks mate.  Sorry to be a while replying - we're slowly going bonkers waiting to see if this all works out.  The new house is just what we want and where we want but, as usual, it depends on the buyers of our house, etc. (the domino effect  ).  We should know next Monday or Tuesday.  The suspense is killing us!

This got posted in a reply to a new AMOS user, but is far more appropriate here:

"Time to ask for some more feedback.  The original V2.0 release on six disks had to leave a lot out to get it to fit on just those six disks.  They also become assigns that are essential to the AMOS code.  But it did mean that AMOS Pro could be used without a HDD.  Once on a HDD, that's no problem - I'm aiming at a HDD install that will probably take up seven or more disks to get the 'missing' bits in.  But that would no longer run as a bootable AMOS Pro for non-HDD systems.  An alternative is to stick with the original six disk format and add one or two extras disks for HDD users.  Yet another is to release an LHA for HDD install only.  It would be nice to do all the above but time is precious and limited.  And this has been going on a long time with no tangible deliverables yet.  So what does the AMOS community want for something 'real soon now'?"