@saimo

I'm sure I'm not the only one but I would like to take the time to say keep up the GREAT WORK! I'm ALWAYS impressed how by much you can push the limits of our little computer!

Last edited by AmigaSource on 19-Sep-2025 at 01:09 PM.

_________________
Please visit AmigaSource.com!!! Since 2001... Your BEST source for Amiga information. Again... *** Always Under Construction *** (Over 3000+ Amiga links for your viewing pleasure! -- Please help spread the word!)

@saimo

what you do is stupid
you try to get everything from AGA
AGA was too slow too outdated before going into production
even Atari had 16 bit chunky pixel color in 1992
you should learn to accept critics
leave AGA buy graphics card

if you really have to use classic use OCS with 68000 7 Mhz 0.5 MB CHIP 0.5 MB SLOW

@ppcamiga1

STFU and find some new material.

Quote:

even Atari had 16 bit chunky pixel color in 1992

And where is it now? That's right, in the same place as the A1200. Chunky pixels didn't save it. Nor the Archimedes. Nor the RiscPC. Nor the Mac Quadra.

Now go and port MUI to Unix or whatever and don't come back until you've done it.

_________________
Doing stupid things for fun...

@AmigaSource

Quote:

I'm sure I'm not the only one but I would like to take the time to say keep up the GREAT WORK!

As long as real life permits, I will.
And, by the way, a new demo is about to come...

Quote:

I'm ALWAYS impressed how by much you can push the limits of our little computer!

Thanks for the support!

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

thanx for your work

@Karlos

stop trolling start working on mui

@ppcamiga1

Do it yourself you lazy lump.

_________________
Doing stupid things for fun...

@ppcamiga1

Oh friend ppcamiga1,
oh miserable retard,

let me understand your logic:

working on squeezing new potential from AGA is wrong,
because AGA is the past and has no place in the present where any graphic card will do a better job.

HOWEVER people should work on Mui,
a GUI toolkit the functionality of which is well below Windows 3.1.

Oh friend ppcamiga1,
oh miserable retard.


/m!

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@ppcamiga1

I hope he does, and figure out a way so that everyone can use it, but you! :P

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@MEGA_RJ_MICAL

Quote:

HOWEVER people should work on Mui, a GUI toolkit the functionality of which is well below Windows 3.1.

MorphOS looks quite better than Windows 3.1, just saying... ;)

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@MEGA_RJ_MICAL

micro mical stop trolling take your pills

@pixie

stop trolling start working on zune

@ppcamiga1

Quote:

ppcamiga1 wrote: @MEGA_RJ_MICAL micro mical stop trolling take your pills

Pot. Kettle. Black.

_________________
Doing stupid things for fun...

@Karlos

stop trolling start working on zune

@ppcamiga1

DO IT YOURSELF.

_________________
Doing stupid things for fun...

Alright, time for a new demo. Also this one shows the AGA chipset combining 3 full screen 8-bit layers (or playfields, if you prefer) using various 8-bit alpha values.
It isn't available for download yet as I have to finish to write some more technical details.

https://www.youtube.com/watch?v=Wh34biwfc0w

LAYERS

Common:
* 320x256 dots
* PTDQ system
* RGBWa color model

Background:
* maximum 256 colors
* horizontal scrolling

Middleground:
* maximum 256 colors
* colors use 8-bit alpha values for the fade-in and cross-fading effects
* vertical scrolling

Foreground:
* maximum 81 non-transparent colors
* triple buffer

NOTES

* All the layers reside in CHIP RAM.
* If the foreground did not use 100% transparent dots, its maximum number of colors would have been 256.
* The horizontal scrolling requires the background layer to be at least twice as wide as the screen plus 32 dots (i.e. 16 bytes). Making the layer additional D dots wider (where D is dividable by 64) would waste D/4 bytes per line of CHIP RAM.
* The background layer can be made to scroll also vertically without problems.
* The Thalion logo is scaled in real time on a chunky raster which gets written to the foreground layer by means of the PTDQ C2P conversion routine PTDQ_DoC2P_R().
* The 24-bit palettes for the fade-in and cross-fading effects are pre-calculated at startup; the effects are obtained by writing each frame a whole palette to the COLORxx registers with the CPU during the vertical blanking.
* The music is a tracker module played by means of P6112.
* On a stock Amiga 1200, the demo runs at 50 fps.
* YouTube's encoding degraded the quality.

Last edited by saimo on 30-Sep-2025 at 04:10 PM.
Last edited by saimo on 21-Sep-2025 at 09:39 PM.
Last edited by saimo on 21-Sep-2025 at 09:10 PM.
Last edited by saimo on 21-Sep-2025 at 09:08 PM.
Last edited by saimo on 21-Sep-2025 at 09:07 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

I can only imagine how this must look on CRT! Bravo!!

_________________
Doing stupid things for fun...

@Karlos

Quote:

I can only imagine how this must look on CRT! Bravo!!

Yeah, me too! Thanks.


@all

I have uploaded the demo now. You can get it from https://retream.itch.io/ptdq.
The delay was due to the fact that I wanted to add the following section to the documentation.

PERFORMANCE

The following calculations evaluate the performance on Amiga without FAST RAM.

Given that the screen is 1280 SHRES pixels wide, 256 lines tall and 8 bitplanes
deep, the amount of bytes fetched each frame by the bitplanes DMA is
1280/8*256*8 = 327680. However, thanks to the AGA 64-bit data fetch, the number
of reads per frame are 327680/8 = 40960.

The pulse effect applied to the Thalion logo redraws every frame an area of
64x46 dots, which amount to 64*46 = 2944 bytes (as each dots corresponds to a
byte).
Given that the scaling reads and writes the dots by byte (from many tests, it
turned out to be the fastest solution on a stock Amiga 1200), it needs 2944*2 =
5888 memory accesses. Such accesses are performed one after another, without
other instructions causing delays. However, the CPU is never granted access to
the CHIP bus twice in a row, so the accesses actually take 5888*2 = 11776 color
clocks.
After the scaling, the data needs to be read, C2P-converted and then written to
the foreground bitplanes, for a total of 2944*2 = 5888 bytes. To convert 32
bytes, PTDQ_DoC2P_R() performs 9 memory accesses in parallel with other
operations and 7 accesses right after another access, thus needing 9+7*2 = 23
color clocks. Therefore, ignoring for simplicity a marginal overhead, it needs
(5888/32)*23 = 4232 color clocks.
In all, the pulse effects needs 11776+4232 = 16008 color clocks.

When a fade-in or cross-fading effect takes place, the CPU also writes 24-bit
values to all the COLORxx registers. So it needs to
 * read 256*4 = 1024 bytes from CHIP RAM,
 * write 256*4 = 1024 bytes to COLORxx and
 * perform 8*2 = 16 writes to BPLCON3.
Both reads and writes are made by longword (thus setting 2 COLORxx registers at
a time), however the writes internally execute as two word writes, for a total
of 3 accesses per 2 COLORxx registers. Given that all these accesses are
consecutive, they take 3*2 = 6 color clocks. The fact that the high and the low
low order bits of the colors have to be written separately means that for each
color 2 accesses are needed, thus cancelling the avantage of processing the
colors by longword. As a result 256*6 = 1536 color clocks are needed.
The writes to BPLCON3 are spaced a little bit by means of a few instructions,
so, for simplicity, it can be assumed that each of them needs 1 color clock.
In all, a fade-in or cross-fading effect needs 1536+16 = 1552 color clocks.

When the staggered lines option is on, the Copper alters BPLCON1 once per line
by means of a WAIT and a MOVE instruction, which need 4 memory accesses, for a
total of 256*4 = 1024 additional accesses. Moreover, due to the horizontal
scrolling, the CPU needs to update the values of the MOVE instructions in the
Copperlist, performing 256 consecutive writes which require 256*2 = 512 color
clocks.
In all, the staggered lines need 1024+512 = 1536 color clocks.
(Note: using a Copper loop to have just two MOVE instructions that can be
quickly modified by the CPU does not provide any speed benefit as each jump,
executed by a MOVE to COPJMP2, would require 2 more reads, thus cancelling the
gain on the CPU side.)

The demo also plays music, which requires some color clocks for the audio data
DMA. Due to how music playback works, there is no simple way to calculate its
load on the CHIP bus. However, it is possible to calculate the load in a very
heavy case (and certainly worse than the actual one) by assuming that all the 4
channels play continuously at almost the maximum frequency allowed, i.e., for
simplicity, 28500 Hz. That means that 28500*4 = 114000 bytes need to be read per
second, i.e. about 114000/50 = 2280 bytes per frame. Given that the data is
fetched by words, those amount to 2280/2 = 1140 memory accesses per frame.
(Note: if the quality were half of the one considered - which is closer to
reality - the accesses would be 1140/2 = 570, but such value would not make much
difference anyway.)

Putting all the figures together, the total number of color clocks needed is
40960+16008+1552+1140 = 59660 if the staggered lines are off and 59660+1536 =
61196 if the staggered lines are on. Considering that a PAL Amiga has 313*227 =
71051 color clocks per (long) frame, those figures represent respectively
100*59660/71051 = 83.8% and 100*61196/71051 = 86.1% of the color clocks
available in a frame.

It might seem that there is some room to perform other operations, but the above
calculations do not take into account the reads performed by the CPU to fetch
the instructions (which do occur often as the 68020 has only a tiny instruction
cache of 256 bytes); moreover, the CPU is not just reading and writing data, but
also performing other operations (which only partially overlap with writes).
Therefore, unfortunately, there is not really much more that can be done in a
frame time.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@Karlos

stop trolling start working on zune

@saimo

buy graphics card. no matter what you do with AGA it will be always worth nothing.
simply because AGA was too slow and too outdated even before a1200 go into production.