Print

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

[Amiten]

Hi how is goes this amazing project? Any news? Follow with the good works

King of regards

[bruceuncle]

Hi how is goes this amazing project?

Thanks for the interest.  It is going slowly as what we are proposing will take some time.  Especially as anyone involved is likely to be doing stuff in their spare time (which can be a rare commodity these days  ).

I'm documenting the loader, interpreter and compiler.  It's complex!  But we need to understand it fully before we can make any major changes (like adding AGA).

Bug fixes are separate from adding AGA (and there hasn't been much feedback there yet!) but I would like to see a bug-free AMOS Pro (minus AGA) released as soon as we can manage it.

AMOS Pro already recognises AGA hardware even though it isn't implemented yet.  It does this to ensure any AGA registers are set correctly to prevent non-AGA software suddenly turning on hi-res sprites.  I haven't found any other references yet but it's early days.  The original AMOS team were certainly well aware of what they were doing.

Another example is the problem of modifying code (relocations, etc.) on a system with a 68020 or higher.  These have an instruction cache which must be flushed after changes are made to avoid the wrong instructions being picked up from the cache instead of memory.  So they flush the cache through an operating system call.

They were well aware of where the Amiga hardware was heading back then.

Will keep everyone posted on progress but expect a few "quiet weeks" while we actually do some work rather than posting  .

As encouragement, I've attached a PDF of the loader/interpreter docs up to the start of where the AMOS libraries (extensions) are loaded.  I'm currently in the middle of the next section.  The diagrams are just about ready (along with multiple sketches of what's happening) just got to put it in Visio (wash my mouth out!).  That section looks like the heart of where any context switching code for loading would need to go.

Please regard this attachment as very-much-work-in-progress (although constructive suggestions always welcome).

It all takes time     

[Lonewolf10]

You've done a great job on that documentation, bruceuncle

[bruceuncle]

You've done a great job on that documentation, bruceuncle

Thanks mate.  All encouragement helps 

The next bit's the fun bit.  What it does loading and relocating a library is very interesting to say the least!  I'll keep feeding it out on the forum as I work through it.

I still haven't decoded what all those 4 byte codes for each token are for (in +Toktab_Verif.Bin).  When the context is that a program is running, they're swapped for another (code-generated?) table for "rapid tokenisation", then swapped back when testing or editing is the context.  I haven't pulled all the tokenise, test and run code apart yet but it will be in there somewhere.  I can't see the original AMOS team hard-coding them all, so how did they derive them?  More importantly, what do we use for any new instructions?  Is there any benefit in applying the technique to other V2.0 libraries and extensions? 

It's hard not to go wandering off chasing through the sources instead of sticking to "start at the beginning and work through to the end". 

I'm only intending to document Loader/Interpreter and Compiler to this level of detail in case anyone wondered if I'd found a job for life!  amiga.library may get the same treatment if necessary for AGA conversion.  I think we all need to understand how this core of the AMOS system really works before we try carving new stuff into it.  We're going to need new and modified AMOS Basic instructions for an AGA version and they should go into amiga.library and AMOSPro.Lib to prevent fragmenting the system under AGA.

More next week.

[bruceuncle]

Just the next instalment of the AMOSPro analysis.  I'm currently in the middle of the code relocation and token table parameters bits.  That resolves the Rxxx macro-generated and "GetP" tokens in a library's code.  This attachment goes to the point where everything is loaded and the Routine Address Tables created.

Please treat this as still in the very-much-work-in-progress state 

But there should be enough in the document to see how context switching can be easily accomplished:

• There are three spare bits in the LB_Flags byte in each library.  So plenty of room for AGA and ECS flags.  I don't know enough about the hardware yet to know whether we would need to treat AGA and ECS switches differently.  So would we need a flag for each?
  
• Any extra Routines required for AGA (and/or ECS) would be added to AMOSPro.Lib.  These will be resolved to a Routine Number and a Routine Address when the library is loaded.  Unfortunately, a context switch cannot directly swap these Routine Addresses in the Routine Addresses Table as each Routine's code would have to be relocated all over again if we did.
  
• We can, however, add a Switcher Table.  In the source for amos.library this would be hard-coded and just contain Routine Numbers for each entry:
  
  • Original OCS_Routine_Number
    
  • Related AGA_ECS_Routine_Number
    
• If it's ok to use AGA or ECS (hardware check) the loaded libraries would be scanned to see if their AGA/ECS flags are set.  These just indicate compatibility, not that the library contains AGA/ECS code.  If all the libraries check out (software check) then AGA or ECS functionality needs to be available.  This must be done before relocation so it would slot in after the Library_Patch() routine in the existing source.
  
• If the previous steps indicate that context switching may be required, a global flag would be set to indicate this and the Switcher Table would be built.  This would only apply to AMOSPro.Lib as long as we do AGA/ECS in that library only.  Each entry to contain:
  
  • OCS_Routine_Number
    
  • AGA_ECS_Routine_Number
    
  • Code for a jmp OCS_Routine_Address instruction (the one in the Routine Addresses Table before this Switcher Table is built)
    
  • Code for a jmp AGA_ECS_Routine_Address instruction (the one in the Routine Addresses Table before this Switcher Table is built)
    
  • A blank entry to hold code for a jmp Address instruction.  This is the Switcher Instruction.
    
  Each entry is initialised with Routine Addresses from the Routine Addresses Table.  The blank Switcher Instruction entry is initialised to be identical to the OCS jmp OCS_Routine_Address one.  The original entry in the Routine Addresses Table would now be replaced with the address of the Switcher Instruction.
  A global flag would be used to indicate the current state of the switcher.  Initially it would be cleared to indicate OCS.  So the initial effect is that nothing is changed.  Except that now the original instruction's Routine Address points to a jump to the OCS Routine.
  
• Library relocation can now be done exactly as it already is in the existing source.
• When a switch is required (i.e. when a Set Aga or Set Ecs instruction is encountered)  the Switcher Table is iterated, simply moving the jmp AGA_ECS_Routine_Address instruction into the Switcher Instruction for each entry.  The global AGA/ECS flag is set to indicate the Switcher Table's state.  This must be followed by a jsr Sys_ClearCache to clear the processor's instruction cache for 68020s and above.
  
• The reverse is done at the start of any Test or Run for a program.  The Switcher Table is iterated, moving the jmp OCS_Routine_Address instruction into the Switcher Instruction for each entry.  The global OCS flag is cleared to indicate the Switcher Table's state.  Again, this must be followed by a jsr Sys_ClearCache
  

Assumptions

• Appropriate AGA/ECS structures have been added to extend the AMOS Basic data area (positive offsets from A5) or as new structures pointed to from that area.  Note that the amiga.library data area (negative offsets from A5) cannot be extended as you'd overwrite the buffers area in existing software!
  
• amiga.library is used as the software-to-hardware interface for AGA/ECS.  In other words, it provides the low-level hardware routines necessary, just like it does now for OCS.
• AMOSPro.Lib is used to provide the AMOS Basic instructions.  It uses amiga.library to do the donkey work.
• The majority of AGA/ECS functionality switching can be done without using a Switcher Table approach.  There's no point in doing it for each and every graphics instruction when all that may be required is a simple check on a parameter.  For example, checking a Colour Number parameter already involves looking at the current number of bit planes.  So adding a check for a global AGA/ECS flag would have little performance hit.  In other words, the existing AMOS Basic instruction routine would just be modified.
• Where a separate routine is required for an AMOS Basic Instruction, it would be added to the library and be prefixed Aga.  As an example, if we need to replace the existing Screen Open instruction with a new routine:
• The existing Instruction Number label is L_InScreenOpen.
• The AGA/ECS Instruction Number label should be L_InAgaScreenOpen.
• The AGA/ECS Instruction's parameters definition MUST match the original's.
• The L_InAgaScreenOpen Instruction Number is NEVER called directly.  Only through the Switcher Table.  In other word, there will be no matching Aga Screen Open token in the Token Table.
• If different parameters are required for an existing OCS Instruction, insert a "token continuation" after it in the Token Table using the "!" and "-2" notations.  In the Screen Open example (unrealistic I think, but this is just a "f'r'instance") this would then use a Routine Number label of L_InAgaScreenOpen1.  That routine (and all AGA routines) should check the global AGA/ECS flag and throw an error is it's not set!

I think that about covers it.  If it's a bit daunting for those out there working on the low-level AGA/ECS stuff, don't worry.  I intend to take care of all this housekeeping and integration work.  I'll publish a diagram of how it would all work when I've finished the current doc    That would probably be easier to follow 
(Which is why I'm writing these docs.  It helps reinforce my own understanding and I need to know all this stuff inside out before we start carving new functionality into AMOS.  And, of course, so the community gets the knowledge too.  ) 

[SamuraiCrow]

Sorry, I just noticed the last post had an unanswered question in it.

There are three spare bits in the LB_Flags byte in each library.  So plenty of room for AGA and ECS flags.  I don't know enough about the hardware yet to know whether we would need to treat AGA and ECS switches differently.  So would we need a flag for each?

I think a 3-bit enumeration would be a more practical endeavor.  That way future softcores on FPGA machines would be able to have their chipset features supported as well.  (This may be solved by a future AmosPro for AROS 68k.)

[bruceuncle]

Sorry, I just noticed the last post had an unanswered question in it.

There are three spare bits in the LB_Flags byte in each library.  So plenty of room for AGA and ECS flags.  I don't know enough about the hardware yet to know whether we would need to treat AGA and ECS switches differently.  So would we need a flag for each?

I think a 3-bit enumeration would be a more practical endeavor.  That way future softcores on FPGA machines would be able to have their chipset features supported as well.  (This may be solved by a future AmosPro for AROS 68k.)

Good point.  That would give much more scope for future enhancements.

Bear in mind that it will be some time before I get to actually working on an AGA version.  The current bug fixing, Help Files and Ref Manual will take a while yet to complete.  So I've got AMOS AGA "sorted out" in my own mind as "do-able".  That allows me to "shelve" the problems for the time being and lets me concentrate on the current tasks.  The fine details I'll worry about when we get to actually designing it (any volunteers?  ).

[OlafS3]

I got the permission to include "Game Master System" in "Aros Vision"

I have just tested "The Game Extension" in AMOS that is based on "Game Master System". It supports AGA including Sprites and Bobs

To test it I wrote this short program that loads a IFF picture and waits till left mouse button pressed:

G Init Gms
G screen open 0,320,256,256,lowres
G Load IFF "clown.pic",0
G Wait Lmb
G reset

Opens AGA screen with 256 colors

Screenshot below