Print

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

[bruceuncle]

I'd blathered on about a Context Switcher for integrating AGA (and/or ECS) functionality into AMOS Pro in another topic previously.  The objective being to maintain compatibility with existing AMOS programs and extensions whilst still allowing full AGA capabilities.

On going back and reading that, it's probably not the best of descriptions  .  So I took a bit of time out from CSI AMOS to do a quick document on it.  It's attached as a PDF.

I hope this make the technique easier to understand (feel free to throw the brickbats if necessary    ).

Note that we cannot proceed with this technique until we understand what those codes in +Toktab_Verif.Bin mean and how they're derived.  We will need to add some new tokens into AMOSPro.Lib and can't do that until we understand +Toktab_Verif.Bin.

[SamuraiCrow]

Quick question:  Looking ahead to an AROS 68k version of AmosPro, is there a way we can make a switcher table for different versions of switchers?  For example, can we leave things open for a future AmosPro to use a CyberGrpahX 3 compatible graphics driver as AROS supports?  If so, I'd like to be able to set a switcher for any graphics capability level someday.  Having looked at your document, perhaps setting additional data in the switcher's positive offsets will make it plausible.

[bruceuncle]

Quick question:  Looking ahead to an AROS 68k version of AmosPro, is there a way we can make a switcher table for different versions of switchers?  For example, can we leave things open for a future AmosPro to use a CyberGrpahX 3 compatible graphics driver as AROS supports?  If so, I'd like to be able to set a switcher for any graphics capability level someday.  Having looked at your document, perhaps setting additional data in the switcher's positive offsets will make it plausible.

Yep.  You can carry the concept as far as you like because Francois left that LB_Append longword free in a library's data zone.  Plug in a pointer to any switcher structures you'd feel necessary.  Plus there's the LB_Free byte to pop any flags into.  I've got a fair idea of what's free in the existing AMOS data structures from having databased the sources and using a powerful multi-document searcher and text editor to chase them up and validate the assumptions.

It can easily be multiple-way switching  if you needed it.  Just expand each element in the switcher table to include three, four or more options.  Each just has to have a Code Routine and Instruction Number to handle it, plus the code and Instruction Number Table in the loader's discarded hunk so you can construct AMOSPro.Lib's switcher table.

That free longword means you can point to any structure you like for more complex structures if you needed them. 

When I actually get to the coding phase for a switcher and AGA/ECS (a fair way off yet - my priority with coding is to get bug fixes in and an easy HD install release a.s.a.p.) I'll be leaving linked list pointers free for future expansion.  Eg.  the LB_Append longword will point to the switcher table which will also include another longword free for any expansion (not shown in the Context Switcher Design PDF doc).  I strongly suggest we apply that criterion to any other new structures also (eg. the AGA and ECS screen structures we'll need) and please use linked lists.  The code for handling linked lists is already there in AMOS Pro (in +B.s starting line 1187, with Instruction Numbers in +Lequ.s starting line 94 - PDF attached).  Or use Exec's linked list handling.  But as a personal foible, I kinda like the idea of keeping it 'all AMOS'  .

BUT, for anything you set up using Context Switching, the major work is in integrating the switched instructions back to the AMOS Basic language.  The switching structure work required for AGA/ECS functions is minor compared to all those AMOS Basic graphics instructions that would need to be modified to match the capabilities.  Not just the obvious AMOS Basic ones.  There's AMAL, Menu and Interface subprograms to be modified as well.  A lot of work!  However, I'm retired now and this will be my pet project for the next few months years.

One step at a time.  First I want to understand the inner (less attractive?  ) core first.  The way AMOS actually runs a program is fascinating.  I'll keep analysing (and publishing) until I have enough to start classifying the AMOS Basic language in terms of requirements for AGA/ECS.  There's nothing to stop other graphics modes being done the same way.  I assume you mean things like Picasso96 and the CyberGrpahX 3 thingy you mentioned?  I don't know anything about them as they came after my 'real' Amiga experiences back in the late 80s and early 90s.  Still catching up with what's been going on since then  .

[bruceuncle]

That original document on an AGA Context Switcher is now out of date.  I should have mentioned this earlier but I'd wanted to get another instalment of CSI AMOS out first.

With there being two possible start addresses for a library's code routine, the switcher table needs to be a bit more complex.  One entry point address for Relocated Code to use (all those Rbxx macros) and another for the Parameters Routine entry point (the one the Interpreter will use).  I'm not going to describe all this again here, just download the latest CSI AMOS document here.

In addition, the +/- 32k branch limit imposed by those relocated Rbxx macros mean that the Switcher Table itself can't be located at any arbitrary location as any affected (switchable) routine in AMOSPro.Lib will have to reference addresses in the table.  So it will have to be located inside AMOSPro.Lib itself.  Similar to the embedded +Toktab_Verif.Bin table.  Or, if AMOSPro.Lib grows too fat, it might have to be located in the middle somewhere  .

No real problem, just a bit different to that earlier document and somewhat expected as there was a lot of puzzling stuff in the sources.  That's why I'm doing CSI AMOS.  We definitely need to understand AMOS Pro in full before we go hacking into it.   

I'll post a revised Design Document for it as soon as I get the time.