To be a little more clear, new hardware ancient software. ;)

So yes it does need the restrictions however new software could lift that restrictions.(register setting)

Thomas Clarke wrote:

What I mean by this is, with SuperAGA, we don't need to carry around the same restrictions. If the hardware is new, and the software making use of this enhanced hardware will be new, then the restrictions need not apply, correct?

No. The restrictions apply to any program that want to access the machine through the operating system, and hence through gfx. The problem is not the hardware, and not the user software, but gfx in the middle. No matter how your software works, gfx will not render, draw lines, or move windows around on any chunky machine. You need to patch up gfx for that, no matter what.

For games that access the hardware directly, there is of course no problem.

Good to hear.

So the issue is the OS then. Seeing as AROS already supports true colour modes, the issue is writing an AROS driver that opens up the extra graphics power of the Natami, is that what you mean by 'patching'?

Gfx is not exactly high quality code, too much bound to the hardware, and the design left a bit to desire.

Thomas Clarke wrote:

Seeing as AROS already supports true colour modes, the issue is writing an AROS driver that opens up the extra graphics power of the Natami, is that what you mean by 'patching'?

No. Actually, I know not much about AROS, and have no experience with using it, and how compatible it really is. I believe that patching up gfx with something like P96 might be more realistic.

It might be, but also it might not be. Perhaps it would be sensible to investigate what AROS already offers with regards to true colour modes first, to avoid duplicating work.

According to the CyberGraphX Wikipedia page "AROS implements CyberGraphX V4 compatible API". Here's some documentation about it from the AROS Wikibook:
EXTERNAL LINK 
Surely some of this will be of use for a Natami true colour mode?

A 32 bpp color mode (32 bits per pixel, as RGB) would have been more orthogonal and would have fit right into the typical layout of PC graphics memory. Hopefully, Thomas is still able to revisit this design decision.

In case of AROS this is not a problem because there's no code in it's graphics.library that relies on direct bitmap access (gfx drivers can provide support for that but it is not required so they can deny direct access).

This allows the driver to lie about the real hw color/pixel format and for example it could provide ARGB32 bitmaps which in reality the driver stores as shadow chunky pixel arrays in RAM and then for display real time ditheres to a 8 bit planar screen.

Possibly, but as Georg Steger points out, for AROS itself it does not seem to be an issue, since it hides the actual details about the framebuffer.

    Sub WritePixel(screen as ScreenObject, X as Integer, Y as Integer, Color as Integer)
        Dim Red As Integer = 16711680
        Dim Green As Integer = 65280
        Dim Blue As Integer = 255
    
        WriteRedPixel(screen, X, Y, (Red AND Color)/256^2)
        WriteGreenPixel(screen, X, Y, (Green AND Color)/256)
        WriteBluePixel(screen, X, Y, Blue AND Color)
    End Sub
    

     Sub WritePixel(screen as ScreenObject, X as Integer, Y as Integer, Color as Integer)
         Dim Red As Integer = 16711680
         Dim Green As Integer = 65280
         Dim Blue As Integer = 255
     
         WriteRedPixel(screen, X, Y, (Red AND Color)/256^2)
         WriteGreenPixel(screen, X, Y, (Green AND Color)/256)
         WriteBluePixel(screen, X, Y, Blue AND Color)
     End Sub
     

AROS might, but this includes - as I read it - an additional copy operation, i.e. the AROS code or rather the user program writes a single pixel into an off-screen buffer, and then AROS converts this buffer to the video memory, so a lot of steps are needed to write a single pixel (write into memory, and copy over again to the video memory).

As you know, I don't care about programs that go directly to the hardware. It's the job of the operating system to provide the proper abstraction. Unfortunately, there is no *effective* way of supporting the current Natami organization with the current state of P96. This means a lot of additional work, either by writing conversion functions, or by drilling up existing systems (if we can, for legal reasons).

Greetings from Rapid City,

Thomas

I have nothing against RGB packed chunky formats, but I will buy Natami EXACTLY because of this unique mode :-). Ideally, if driver/GFX subsystem could support merged channels in framebuffer (e.g. of the three framebuffer byteplanes any two or all three could be in fact the same framebuffer memory area; or partially overlapping areas (for channel pairs)), as in Amiga normal bitplanes.

I know, corner case of this merging (monochromatic display) can be done also in LUT mode, but on bitplanes it is still more cumbersome... And those channels themselves are very interesting project, a different way to go -- this is what I expect from this project :-).

And, isn't that some (many) image manipulation algorithms operate exactly on separate color channels? And they can be easier streamed and paralleled this way?

I would even encourage Thomas (H.) to push this channel support further, e.g. with possibility of configurable reduction of resolution (e.g. packed byteplane with 2/4 pixels per byte) and bit depth of a given channel (e.g. packed byteplane with 2/4/8 bits per pixel) -- I guess it's mainly matter of RAMDAC control?

Thus, what I'm saying is that the benefits are minimal, but the costs are large - as in: quite some software has to be rewritten to make use of it. (Would you spend your time in drilling up P96 or Cgfx, provided we *would* get licenses to extend it?)

Przemyslaw Szeremiota wrote:

I know, corner case of this merging (monochromatic display) can be done also in LUT mode, but on bitplanes it is still more cumbersome... And those channels themselves are very interesting project, a different way to go -- this is what I expect from this project :-).

Please note: This is not about LUT vs. direct color modes, but rather how a direct/true-color mode is implemented. And of course you can merge channels in a true-color display - though it requires more CPU cycles. But since there is rarely an application that requires such operations, I don't see why it matters.

Przemyslaw Szeremiota wrote:

And, isn't that some (many) image manipulation algorithms operate exactly on separate color channels? And they can be easier streamed and paralleled this way?

Not really. For example, ICC profiles do define separate LUTs on R, G and B indeed, but the channels need to go into a common matrix transformation/common lookup as well, so you need all three channels simulatenously anyhow as inputs for a single operation. There is no benefit of the three planes you could take advantage of, and there is no parallelity in the Natami either. In fact, it is a bit easier with 32bpp because a single longword catches or writes a single pixel.

Przemyslaw Szeremiota wrote:

I would even encourage Thomas (H.) to push this channel support further, e.g. with possibility of configurable reduction of resolution (e.g. packed byteplane with 2/4 pixels per byte) and bit depth of a given channel (e.g. packed byteplane with 2/4/8 bits per pixel) -- I guess it's mainly matter of RAMDAC control?

I don't know. I don't quite see the benefit, a reduced resolution in one of the R or G or B channels doesn't make much sense. It would make some sense for a YCbCr type of frame buffer since video is typically subsampled, but then again you are completely on your own because P96 nor Cgfx supports anything but RGB. Thus, there is *some* benefit in a YCbCr planar mode, but none I see for planar RGB.

Greetings,
Thomas

24  16M    24  6  (chunky-planar mix mode)
8    256    8  2  (chunky mode)
16  65536  16  2  (chunky mode)
32  16M    32  2  (chunky mode)

So on this roadmap there are both: real chunky modes and
the discussed mixed-mode proposal.
 

The second thing is as I get it we need conversion methods between planar and chunky. I think it would make sense to do that in hardware.

Ceti remember that part of the RAM is unavailable to programs because of the use of a RAM disk.
second I think i am one of the few here that see a good reason to update the sprite engine above using BOBs(off-topic)

the hybrid mode makes it easier to use planar ciruitry/mechanics get used by chunky to some extend.
This would eliviate stress on the memory since less bandwidth is required.(more for other things)
If this is well implemented it could mean you can disassociate one color plane and swap it with a different one.(neat effect if used properly)

The advantage planar had was it's LUT, if this feature is available for the hybrid mode one could use it for a color intensity map.
But this would be a less usfull feature IMHO i think some of the artist here can tell us otherwise.

and if we do need a package formot i still prefer 16bit RGB 565 format over 32bit RGBAX 88871.