Print

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

[KickstartA1000]

Just picked up my old Amiga 1200 and loaded up AMOS Pro to try out some old codes I wrote eons ago..
One thing I noticed about AMOS extensions is that you find very Little support for ECS chipset;
for example, if you want to create bitmaps larger than 1008pixels X 1024pixels you have to rely on assembler and go poking into hardware registers directly.
Are there any extension modules that have commands that bypass the old 'Screen Open'-command and let you take advantage of the ECS blitter possibilities?

Thanks!

[SamuraiCrow]

If you bypass the Amos Open Screen command you may also have to bypass all the other graphics commands.  I know the Game extension does this and thus adds AGA support.  Also, there are some Intuition.library enabler extensions that try to make the Amos display system-friendly so it will take advantage of the Kickstart 2+ functionality on your ECS system, thus patching your Amos program back to the OS.

[KickstartA1000]

Thank you SamuraiCrow for your answer.
I will checkout the Game extension then. I'm having an idea for an alternative 3d algorithm or '3d-pipeline'.

[bruceuncle]

I had a lot of time to think about AMOS and ECS/AGA support whilst I was in hospital.  I also had the printed AMOS Pro sources for a bit of light reading  .  Anyway, the main problem is backward compatibility.  We've been through a few ideas on the forum but haven't settled on anything yet.  The main problem is the existing screen structure, which only allows 6 bitplanes.

My latest thinking is:

Add two new instructions to AMOSPro.Lib.  These would be Set Ecs and Set Aga.  No parameters and would have to appear at the start of any program along with any similar instructions (eg. Set Buffer or Set Double Precision).

Add two more functions to allow the programmer to check the environment.  These would be Ecs and Aga (similar to the existing Ntsc).

Define the screen structures for ECS (if necessary) and AGA (for 8 bitplanes).  Then modify all the existing instructions that are affected to use the new structures if the programmer has specified ECS or AGA.  And change their parameter rules (eg. allow 256 for the number of colours when defining a screen).

There are three modules that need attention for this: the internal amos.library (core graphics functionality), AMOSPro.Lib (the instructions) and AMOSPro (the tokenise and verify bits).  Adding the new instructions to the end of AMOSPro.Lib's token table is straightforward.

It's quite an extensive and tricky mod, but looks feasible.  Luckily, most instructions that might need more than their current number of parameters are already handled as special cases.  Eg. Fade specifies no parameters in its library spec.  The checking is done during tokenising and verifying.  (How on earth do you specify 256 colours in a fade anyway?!  Probably modify it to accept an integer array maybe?)

This is far from trivial to do but has the advantage that the language mainly remains familiar and there's only four new instructions to learn.  I'm assuming also that, for AGA, the programmer will only be interested in 256 colours, larger bitmaps and so on.  And not some of the fancier screen modes (like SuperHires and chunky graphics).

This is still at the 'thought bubble' stage as I've got my hands more than full at the moment and my 'sitting time' is still rather limited.  Any comments anyone?

[SamuraiCrow]

Instead of just adding bitplanes to the internal workings of AmosPro, let's use bitmap structures.  That way we are not just kicking things down the road.  Bitmap structures have the bitplane pointers at the end so they can grow or shrink as needed.  It also makes using chunky modes possible in the future because they are patched by the OS.

That said, we could use fewer new commands by setting the minimum Kickstart version and just using that.  The default Kickstart version for current versions of AmosPro is 34 which corresponds to Kickstart 1.3.  ECS requires release 37 or better (Kickstart 2.x) and AGA requires Kickstart 3.0, which is 39.  This will require changes to the startup code to make sure the libraries can open with the correct kickstart version number.

[bruceuncle]

Instead of just adding bitplanes to the internal workings of AmosPro, let's use bitmap structures.  That way we are not just kicking things down the road.  Bitmap structures have the bitplane pointers at the end so they can grow or shrink as needed.  It also makes using chunky modes possible in the future because they are patched by the OS.

The context for the proposal is to provide basic ECS/AGA support for a core AMOS Pro package.  As it's currently planar graphics through and through, the idea is to extend support for the larger bitmaps, EHB and up to 256 colours in the core AMOS modules.  This would be all planar based.

For chunky graphics and any other desirable AGA support, I would suggest that it gets delegated to an extension.  Although, I would prefer the core functionality to still reside in amos.library in the same manner as it does for planar graphics.  It just gives a tidier architecture and all the user has to do is specify the extension.  It's also a better fit with the version checking as all the loader has to do is check the 'handshake' when it loads amos.library.  I've already introduced a 2.10 check for that and an AP21 check for extenson libraries.  Avoid any concept of introducing yet another 'internal library' to cope with it.  (I would be prepared to change my mind on that if the addition bloats amos.library too much.  )

The advantages:

• The AMOS programmer has a familiar environment and uses the same set of instructions for some of the ECS/AGA benefits.
• As far as I can see (which is not too far without a lot more work on it  ) the impact on existing instructions can be accommodated within the current AMOSPro.Lib token table.
• Should any problems arise with extra parameters, a token table entry can be set to No Flags and parameter handling delegated to the instruction's code.
• There would only be a handful of extra instructions needed to be added to the AMOSPro.Lib token table:  Set Ecs, Set Aga, Ecs and Aga are the only ones that come to mind.
• The AMOS programmer gets an immediate boost to capabilities in a familiar planar environment.
• No problems with backward compatibility.

The disadvantages:

• It might get a bit messy if too many existing instructions need new parameter templates.  We can't do anything to the AMOSPo.Lib token table that would shift token values - all existing code would break big time!  From a fairly shallow look, AMOS Pro already delegates parameter checking for some of the instructions (eg. Fade, Palette) so no messing with parameter templates in the token table is needed.
• Further AGA support (i.e. chunky, superhires or hires sprites?) gets delegated to an extension library.  This would need to avoid the trap of using an identical prefix for all its instructions. (Which slows verification lookups as the instruction index for the library would have only one letter of the alphabet in its dictionary.  Eg. use names like Screen Chunky Open rather than prefixing every instruction with the same word, as in Chunky Screen Open .)
• Yet another extension!
• Would inevitably delay AGA chunky, etc introduction as this in itself is a pretty mammoth task.

That said, we could use fewer new commands by setting the minimum Kickstart version and just using that.  The default Kickstart version for current versions of AmosPro is 34 which corresponds to Kickstart 1.3.  ECS requires release 37 or better (Kickstart 2.x) and AGA requires Kickstart 3.0, which is 39.  This will require changes to the startup code to make sure the libraries can open with the correct kickstart version number.

Agreed.  Similar checks are already needed anyway as AGA capabilities need both the hardware and WB 3.x (and kickstart 39?).

The result for the programmer would be an appropriate error message if they tried something like Set Aga in a inappropriate environment.

I spent a lot of time in hospital reviewing the architecture for AMOS Pro.  Although the code modules are very tightly coupled, if they are viewed as one composite package rather than individual modules, there is in fact a lot of flexibility and foresight built in (thanks François).  There is a lot of free space in most of the structures if you look closely  .  So we have a lot of  scope to enhance it without breaking it or getting too carried away trying to skirt around architectural problems.

Please note that there is a lot of assumption and speculation in the above.  More work is required before such a plan could be actioned.  And, at the moment, I'm out of the mix until AMOS Pro 2.10 hits the deck (not too long now  ).

Thanks for the feedback SamuraiCrow, much appreciated.  My knowledge of the Amiga and its programming is still accumulating and I have no experience getting my hand dirty in some of the innards.  So, if we decide to go ahead with something like the above, I will need a lot of support from people with more experience than myself to pull it off.

Suggest we move this to an AMOS 3.x thread for further discussion?

[SamuraiCrow]

Agreed.  I will post later.