Print

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

[bruceuncle]

I'm currently analysing and documenting the AMOS Pro loader - AMOSPro (relevant sources +B.s, +Verif.s, +InternalJumps.s and +LibOffsets.s).  This is fascinating stuff and has thrown up some possibilities we maybe hadn't considered before.

At the same time, james666 has been looking into AGA for AMOS.  And run into the usual problems associated with the AMOS Pro screen and associated data structures being incompatible with AGA structures.  We've been corresponding on this subject for a while and discussing possible solutions.

If you haven't had a look at how AMOSPro starts everything up, this is a quick high-level overview:

The loader is in two code hunks.  One is permanent (the interpreter and some internal library functions) and one is discarded after use (the loader and linker).

The loader/linker hunk takes care of:

• Loading and initialising amos.library plus a few of the essential Amiga libraries.
  
• Allocating and initialising the AMOS data structures (base address pointed to by a5 with both positive and negative offsets).
• Iterates through the AMOS Extensions listed in the editor config file.  It pays particular attention to AMOSPro.Lib (for obvious reasons).  But I haven't yet figured out what the heck it's doing with those codes in the source that generate Toktab_Verif.Bin.  It all takes time...
  
• It calls Library_Patch, which adds the library functions to AMOSPro.Lib's list of functions.  This is needed as that library is split between the library itself (+Lib.s and +ILib.s) and the loader (the permanent hunk of +B.s).  So those functions are added here.  They're the ones defined using the Lib_Int macro.
  
• Each loaded library is then subjected to a relocation pass which looks for those AFLINE instructions (as tokens).  Each is decoded and, as all the necessary libraries are in memory at that stage, the appropriate instruction and absolute address are inserted as replacements for the original AFLINE instructions and the one or two words following them.
  
• The relocation action taken depends on whether the library is AMOS Pro V2.0 or an earlier one.  This is identified by the AP20 token in the 'new' libraries.
  
• The earlier libraries are just relocated as above.  In addition, a table is used to re-map and replace any 'old' system instruction numbers with 'new' ones.
• The V2.0 libraries also have each instruction's parameters examined (if any) and the appropriate parameter jump addresses are inserted into the functions.  These jumps replace those GetP markers in a V2.0 library put there by the Lib_Par macro.
  
• I haven't looked at the compiler yet (I'm leaving it until last) but comments in +equ.s suggest it does a similar load and link.  But against discrete code chunks for each instruction and using relative addressing instead of absolute.
  

From the above, you can see that AMOS Pro is already doing re-mapping depending on context.  The interpreter also does similar re-mapping when it encounters instructions like Double Precision.

From the work that james666 has done, we know that the existing AMOS screen, window and associated data structures can't cope with the extra data storage required for AGA.  At least, not without a very messy solution and the inevitable slow down as new storage areas are re-mapped "on the fly".

So, to get around the problem of retaining compatibility with previous AMOS programs and extensions, there would appear to be two courses we can take:

• Give up on compatibility and rewrite an AGA-only version of AMOS.
• Explore the possibilities presented by re-mapping screen structures "on demand'.

We don't like the idea of option 1 as I think the appeal would be very limited.

Option 2 would use techniques already present in the loader and interpreter.  (And presumably also in the compiler.  But note that I haven't analysed that yet.)

So how would it work?

I've been thinking it over from the programmer's point of view.  I.e. the real AMOS User.  They're used to context switching in their existing instruction sets.  So giving the choice of AGA or non-AGA with something like a Set Aga command at the start of a program would come as no real surprise.  We're already used to Set Buffer, Set Accessory, etc.

From the programmer's perspective:

Advantages

• Existing software and extensions would still work (non-AGA) without any changes.  This includes any system calls and/or direct access to the AMOS data structures.  They would remain as they are.
• The existing AMOS Pro included libraries can be easily converted as we have the sources.  Only +B.s, +ILib.s and +Lib.s would require any major surgery anyway.
  
• Authors of any new extensions can make the choice between AGA and non-AGA simply by choosing the appropriate "compatibility token" - we would suggest using the existing AP20 for non-AGA compatible and AP21 for AGA compatible.  If they choose AGA, then the new AMOS AGA data structures would be automatically re-mapped for them.  As this is done by the loader, there's no impact on performance.  The AGA structures just sit there until the interpreter sees a Set Aga instruction.  Then it just switches the structures and remaps any related calls.  Note that this is done at program Test time, so again, there's no performance impact when a program is actually running.
  
• Most existing 3rd-party extensions could convert to AGA compatible as long as they don't use any graphics (to be defined!).  The conversion could easily be achieved even if the sources are not available (simply change the AP20 token to AP21 with a hex editor, or insert it for an earlier library).
  
• Whatever the programmer's choice, hardware AGA availability is the governing factor.  If the loader does not detect an AGA chipset, the Set Aga instruction throws an error at Test time.
  

Disadvantages

• Some significant existing third-party software would need re-writing if it wanted to take advantage of AGA.  Eg. TOME.
• More complex environment for the hard-core programmers, extension writers and assembler fans.  But at least the structures and code would be available and documented.
• Some memory size bloat.  But as we all seem to agree, that's not really an issue these days.

We (james666 and I) are very much in favour of this approach for the post-bug-fixing phase of development.

What does the forum think?

[Hungry Horace]

Sounds like a sensible solution... Personally, I think TOME needs a re-write anyway (hello... 8x8 tiles??) and/or a number of the better functions of extensions should be "borrowed" an included in AMOS directly anyway...

I can envisage how even using a SET AGA command and suitable AGA CHECK , a program could be witten to work on both AGA and EcS, and commands such as LOAD IFF could be shared bit simply point to a different file depeding on some program initialisation

[bruceuncle]

Sounds like a sensible solution...

Thanks Hungry Horace  .  The more I think it through, and the further I get into the analysis, the more I like the idea myself.  AMOS already does similar so the 'outline' of what would be needed is already there.  And two separate AMOS data structures (the AMOS original and the AGA extra) means no change for existing programs and extensions no matter how they used the data or system functions.
 

Personally, I think TOME needs a re-write anyway (hello... 8x8 tiles??) and/or a number of the better functions of extensions should be "borrowed" an included in AMOS directly anyway...

Erm, well, if the original authors agree there's a lot to 'borrow' into the new AMOS.

If the authors don't agree, well we can always just rewrite their concepts from scratch.  I've done some cursory exploration of some of the more useful extension functions and there's nothing particularly 'commercial in confidence' about them.  Some of them seem to have come from what people did using the AMOS 'Machine Code' instruction set anyway in AMOS 1.3 programs.

I can envisage how even using a SET AGA command and suitable AGA CHECK , a program could be witten to work on both AGA and EcS, and commands such as LOAD IFF could be shared bit simply point to a different file depeding on some program initialisation

I don't want to clutter the concept with too much detail at this stage.  Just a "Do we agree this is the way to go?" question.

However, you can take it for granted that there would be instructions supporting AGA beyond simply making the existing graphics instructions work.  You mentioned one yourself  :  an Aga function working similarly to the existing Ntsc one.  It would just check both hardware and loaded library compatibility.  We would also need stuff to do things like set sprite resolution and anything else that may only make sense in an AGA environment.

So, for example, you could code something like:

If Aga
   Set Aga
   Sprite Lowres
   Screen Open 1,320,256,256,Lowres
   Dim G_PAL(255)
Else
   Screen Open 1,320,256,32,Lowres
   Dim G_PAL(31)
End If

And I really want to see that cute AGA animation in the sources (/Dot_AMOS/AA_Logo.AMOS) pop up when AMOS starts in an AGA environment... 


Back to the here and now.  The main work at the moment is understanding what we've got and the bug fix phase.  But that won't stop any AGA work going on at the same time.  (And a special thanks to james666 for his input.)  I'd just rather we nailed down how it's going to be integrated now, rather than tearing our hair out later.

I'll be publishing analysis as it proceeds.  In my usual fashion "real soon now".    (It takes time, it takes time...)

[SamuraiCrow]

Re:TOME extension additions
I agree with Hungry Horace.  The TOME command structure is more useful than the TOME extension itself is.  TOME uses blitter-scrolling and a row of Icon Paste equivalents to do its tile-maps.  This causes a spike in blitter activity which can lead to delays.

After having read the documentation to ScrollingTrick and the included C sources, I think that we need a way to make a seamless wraparound from the bottom of screen memory to the top using a custom Copper-list.  Normally this is done by a Cop Wait instruction at the end of the last row of screen memory followed by COP MOVEL for each bitplane pointer at the top of the Screen RAM.

Also, we need to look into interleaved bitplanes since ECS or AGA have much wider strides for bitplane widths.  This allows all of the bitplanes to be allocated in one big chunk of Chip RAM starting with row 0 of bitplane 0, followed by row 0 of bitplane 1, up until row 0 of bitplane n where n is the number of bitplanes in use.  It is only at this point that row 1 starts for bitplane 0, followed by row 1 bitplane 1 and so on.  The advantage of this is substantially faster Icon Paste instructions since they can be accomplished with a single tall blit rather than one for each bitplane.  This reduces the number of blitter interrupts and/or blitter waits necessary.  It comes with Kickstart 3+ but can be implemented in Amos without the need for Graphics.library 3+.

Also, will there be a Set Ecs command to widen the screen allocation capabilities?

[bruceuncle]

Also, we need to look into interleaved bitplanes since ECS or AGA have much wider strides for bitplane widths.  This allows all of the bitplanes to be allocated in one big chunk of Chip RAM starting with row 0 of bitplane 0, followed by row 0 of bitplane 1, up until row 0 of bitplane n where n is the number of bitplanes in use.  It is only at this point that row 1 starts for bitplane 0, followed by row 1 bitplane 1 and so on.  The advantage of this is substantially faster Icon Paste instructions since they can be accomplished with a single tall blit rather than one for each bitplane.  This reduces the number of blitter interrupts and/or blitter waits necessary.  It comes with Kickstart 3+ but can be implemented in Amos without the need for Graphics.library 3+.

Thanks for the info.  I'd read about this but hadn't realised the implications.  Makes me wish I wasn't bogged down so much with understanding and documenting the AMOS framework.  I think I'll have to put some 'play time' aside and have a look.

Also, will there be a Set Ecs command to widen the screen allocation capabilities?

Don't quite understand why you'd need one.  Doesn't AMOS Pro assume that as the default anyway?  Or do you mean those screen resolutions that make my eyes hurt?  Keep in mind that I'm an Amiga hardware novice so I need some of these things explaining.   


At this stage I'm not so much interested in all AGA details (but they're all noted) as in ensuring that we get a stable and extensible framework for AMOS.  Without that, we'd be getting into a very messy state.  The existing AMOS framework isn't all that bad and is reasonably well structured.  It's too tightly coupled for my liking but I can live with that.

By using context switching for AGA (which fits neatly into that existing framework) we get flexibility.  The only cost is ensuring that the AMOS AGA data structures are extensible.  I.e. "Woe betide he who uses fixed arrays for any new stuff.", "Don't mess with the data structures or we'll cut your hands off!", "Linked Lists are my best friend.", etc., etc.     If we can get that right, it means any future development can easily extend within the new AGA context or, if absolutely necessary for some special purpose, create a new one.  That would be a big step to take as you'd also have to add some suitable switching and functionality to what would already be available within amos.library.

To make that concrete with an example, assume that most of the current clamour in AGA wish lists seems to be for 8 bitplanes and 256 colours at current resolutions.  And assume that is what we implement for AGA support.  Then suppose you want to add in AGA productivity resolutions.  You'd already have most of what you need just by using the AGA context switch.  If you needed more, the AMOS AGA memory structures can be extended to accommodate what you need.  If that solution meets your needs, no problem.  If it doesn't, canvass the community for support for a new context.  Add a new library token, something like AP22 or whatever, and create your own.  Backward compatibility would still be assured.

Unless, of course you're aiming to include all AGA functionality in one hit.  In which case, the above example is irrelevant.  I'd be happy either way, it's just a case of who wants to take on the tasks involved?

But all this depends on a stable community-owned base version.  So that's why I'm up to my neck in the framework instead of doing interesting and exciting stuff.   

[SamuraiCrow]

Don't quite understand why you'd need one.  Doesn't AMOS Pro assume that as the default anyway?  Or do you mean those screen resolutions that make my eyes hurt?  Keep in mind that I'm an Amiga hardware novice so I need some of these things explaining.

OCS and Kickstart 1.3 allow a maximum scrolling width of 1024x1024 pixels.  With Kickstart 2 and ECS that was lifted to 32768x32768.  If we had an ECS enhanced mode that would also be included in AGA, that is the only significant difference I'd need.  It's used for making faster-scrolling tile-maps and bitplane interleave.

[Amiten]

I have to read all of this thread from beginig to end to know exacly what its cooking here but only the idea of AGA posibilities in Amos for me its simply Amazing!!!!

A dream for me, say many thanks to the people are involve in this projects and my best whises can make reality.

King of regards
Amiten

[Lonewolf10]

I agree with Amiten. You guys are making great progress 

[BooBoo]

Looks good - I think you should drop TOME it was ok for its time but doesnt offer anything intresting all the scrolling routines can probably written alot quicker using regular amos commands

[BooBoo]

If you included wraparound etc there comes a point where what is left for the progarmer to do this routines should be writen by the author of the game or app etc not dumbed down into amos commands - if you go to far this is no longer Amos

[Hungry Horace]

Looks good - I think you should drop TOME it was ok for its time but doesnt offer anything intresting all the scrolling routines can probably written alot quicker using regular amos commands

I'm not sure that's true!! I've seen very impressive scrolling using TOME on YouTube (and tried a little of it myself) and it was certainly far better results than I have ever managed!!

I am not sure i agree about "dumbing down" by adding more commands / functions.... programming in AMOS should be about easily realising a vision - with the minimum of amount of "complex" coding needed - it's things like TOME that make this possible IMHO. If you chose to go the "long route" , that's obviously ok (and may have benefits) but can be detrimental to productivity.

[BooBoo]

as far as I know TOME uses screen copying?
with wraparound you can use hardare scrolling the speed you can program you could probably write 8way wraparound in a day in Amos.

[Amiten]

I honestly satisfied to be able to use all resolutions and colors offered AGA mode,

  besides all the functions that you have as originally Amos even AGA bobs and sprites a. for me this would be  amazing That.

okay, I'd be moving Tiles AGA fantastic, but for me I do not see indispensable if is to difucult to inplement.

what for me if it would be very important is that all the result of using the new capabilities of the Amos AGA,  the compiler compile it without problem, whether it would be a great pity and almost for me would be meaningless without being able to use AGA compiling the result.

Good look with the Work I hope one day not so Far Can use AGA in Amos definitely.

King Of Regards
Amiten

[Lonewolf10]

as far as I know TOME uses screen copying?
with wraparound you can use hardare scrolling the speed you can program you could probably write 8way wraparound in a day in Amos.

I haven't looked into the TOME sourcecode, but if it did it the fastest (and logical) way it would use BOTH methods. The fastest way to create large scrollable levels (think Super Mario World, Sonic The Hedgehog, Turrican etc.) is to use hardware scrolling then paste the next set of level tiles just offscreen.
I tried doing it purely in AMOS a few years back and couldn't get it working properly (or fast enough).

I agree with Horace. AMOS is all about making it easier for the programmer, and adding new commands to give them access to previously unavailable functions is always going to be welcome.
Yes, you could code the equivalent routine in AMOS, but dedicated commands will always be faster (as long as they are written by competent 68000 ASM programmers).

[BooBoo]

AGA would be great for AMOS to allow the basic building blocks and obvious predecessor of AMOS, AMOS AGA and TOME is ok but anything beyond this should stay with extentions and be warp amos or something.

This is in no way a criticism of anyones work its just with time exploring intresting routines written in amos this has realy made me enjoy using amos and if the course of amos is to then simplify it doesnt seem great.