Print

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

[SamuraiCrow]

Do we want to be able to implement Kickstart version specific features in AmosPro?

For example, interleaved bitplane support was added to Kickstart 3 but would work on ECS as well.  Using it limits the horizontal scrolling to 1024 pixels due to the way the modulo registers are used but it speeds up opaque blitting like Icon Paste by combining all bitplanes into one tall blit.

This would throw a monkey wrench in the idea that we could just use a Set ECS command at the beginning and require Kickstart 2 or better for that.  ECS systems can run Kickstart 3.1, for example, and get the benefit of the features of it.  Another feature would be memory pools in the allocation.

Finally, Aros 68k supports some features that are not present in Workbench 2 or 3 such as integrated graphics card support and TLSF memory allocation.  How do we deal with that?

[bruceuncle]

Do we want to be able to implement Kickstart version specific features in AmosPro?

For example, interleaved bitplane support was added to Kickstart 3 but would work on ECS as well.  Using it limits the horizontal scrolling to 1024 pixels due to the way the modulo registers are used but it speeds up opaque blitting like Icon Paste by combining all bitplanes into one tall blit.

This would throw a monkey wrench in the idea that we could just use a Set ECS command at the beginning and require Kickstart 2 or better for that.  ECS systems can run Kickstart 3.1, for example, and get the benefit of the features of it.  Another feature would be memory pools in the allocation.

Hmm.  Maybe better going with something like:

Set Env Kickstart,Chipset

Where Kickstart is the version number, 37, 39, etc and Chipset is an identifier specifying OCS, ECS, AGA.

So that the programmer specifies the environment (effectively, the software version and machine) and gets a polite decline error if it's not available.  If it is okay, then internal flags in AMOS Pro are set and enhanced capabilities are made available.  I don't know enough about Amiga environments to know whether such a check can be progressive.  Ie. Is the machine's kickstart the same or higher than the one the programmer has specified?  And can the same progressive checking be applied to chipsets?

Also, would a chipset identifier alone be sufficient?  Would we need to include eg. size of chip RAM?

Bear in mind that my main objectives (initially) for AMOS Pro are understanding the architecture and probing the ways it can be enhanced.  My knowledge of Amiga chipsets and how they can be exploited is limited to the posts I read here.  It is very much something I want to understand fully, but priorities don't allow me that luxury just yet (available time, available time, available time!).  So any furthering of my grasp of what's possible is much appreciated. 

Finally, Aros 68k supports some features that are not present in Workbench 2 or 3 such as integrated graphics card support and TLSF memory allocation.  How do we deal with that?

I think there is a limit to what we can expect to be able to practically implement in AMOS Pro.  The sort of enhancement progression I see at the moment is:

1: AMOS Pro with OCS and WB1.3/2.1 support stable and documented (that's what's happening now).  Obviously, that's limited to planar graphics.
2: AMOS Pro with additional ECS and AGA support for planar graphics.
3: AMOS Pro with a 'best of' AMOSPro_Extras.Lib exploiting the 'best of the rest' from existing extension libraries.
4: AMOS Pro with a chunky graphics AMOSPro_Chunky.Lib supporting whatever is possible in that realm.

I don't see it going any further than that.  And the above is still a major exercise 

[SamuraiCrow]

Fair enough.  Usually the way the OS does it is to version check the Kickstart ROM version at startup and flag an error message if you open an illegal screen mode when you open a screen.