Welcome, Guest. Please login or register.

Author Topic: AmigaOS and the Console Development - Part 1  (Read 13542 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline olsen

Re: AmigaOS and the Console Development - Part 1
« on: October 01, 2015, 11:10:37 AM »
Quote from: matthey;796682
AmigaOS 4.x can be used on a CSPPC with AGA graphics so maybe it is not completely useless.

Wait -- the operating system allocates chip memory bitmaps in a particular manner. The bitplanes are interleaved, which means that a single line of the bitmap is stored consecutively in memory. See the Leo Schwab article on page 10 for an explanation of how interleaving works: https://archive.org/details/AmigaWorld_Tech_Journal_Volume_2_Number_1_1992-02_IDG_Communications_US

This is an optimization to allow for blitter operations to move bigger chunks of data in a single operation, rather than breaking them up into several separate operations. For example, if the bitmap is non-interleaved, the blitter is reinitialized and restarted for each single bit plane. In interneaved form the blitter is initialized and started only once. As a side-effect, the update minimizes flickering. The update can also use more bandwidth (one big chunk vs. up to 8 smaller chunks).

Now, what exactly will SetWriteMask() do in this situation? It has the effect of making display updates more costly if an interleaved bitmap is used (which is the standard case). Instead of moving one consecutive chunk of bitmap data, the blitter operations have to be broken up into individual planes again. Available bandwidth is used less effectively. This can be noticeably slower.
 

Offline olsen

Re: AmigaOS and the Console Development - Part 1
« Reply #1 on: October 02, 2015, 09:36:41 AM »
Quote from: matthey;796714
Good explanation. So the SetWriteMask() is only an optimization for non-interleaved planar bitmaps? It now sounds like SetWriteMask() should be removed in all cases this "optimization" is used for AmigaOS 3+.


It's not that terrible, really. The blitter works exactly like it always did regardless of whether you restart it several times over for each individual plane, or let it rip for a single consecutive chunk of memory which comprises all planes. Noticeable gains are only possible on an AGA machine (higher bandwidth). On an ECS machine the effects will be less pronounced. In Super72 mode at four colours, ECS already has so much trouble at hand that it cannot always detect if the blitter is still running :-(

Where the write mask makes a big difference, however, is with RTG screens. Instead of jush pushing chunky pixels around, CyberGraphX/Picasso96/etc. now have to treat the screen as if it were a real planar bitmap, so that only the relevant data is affected when text is rendered or scrolled. This requires significant extra effort.

Ironically, the "optimization" of restricting rendering operations to a single plane now cause exactly the opposite of the intended goal.