PED81C - pseudo-native, no C2P chunky screens for AGA

[hooverphonique]

Originally Posted by saimo

Thank you!
Table updated.

You're welcome.. Looking at the table, it seems your engine has an affinity for 030

Originally Posted by saimo

Did you try it to run it normally? Could you move around without problems?

Yes - I could only move forward and left, but that's probably due to the manky old joystick I was able to dig up
It showed 17 FPS on screen by the way.

[klx300r]

@ hooverphonique

[klx300r]

Originally Posted by hooverphonique

You're welcome.. Looking at the table, it seems your engine has an affinity for 030

well the 030's are running at 50 Mhz and you're 040 is running at 33

[hooverphonique]

Originally Posted by klx300r

well the 030's are running at 50 Mhz and you're 040 is running at 33

Yes, but an 040 is a great deal faster per clock than an 030

[Karlos]

Originally Posted by hooverphonique

Yes, but an 040 is a great deal faster per clock than an 030

Surely your chip ram write bandwidth is an important fact here.

[klx300r]

Originally Posted by hooverphonique

Yes, but an 040 is a great deal faster per clock than an 030

this is true and why my comment was made tongue n cheek

[saimo]

Originally Posted by hooverphonique

You're welcome.. Looking at the table, it seems your engine has an affinity for 030

Written on that CPU indeed, but I'd write the very same code also for 68040.

Yes - I could only move forward and left, but that's probably due to the manky old joystick I was able to dig up
It showed 17 FPS on screen by the way.

That matches nicely you benchmark figures

[saimo]

Originally Posted by Karlos

Surely your chip ram write bandwidth is an important fact here.

Agreed. And, as far as I know, also the access to the FAST RAM on the motherboard is rather sluggish.

[saimo]

Given that now PVE has been tested on a wide range of machines, I have just released it officially. The changelog below summarizes what we discussed here. Many thanks to everybody!

https://retream.itch.io/ped81c

v1.1 (22.12.2023)
* Reworked screen buffering, so that the raster data is more efficiently written to CHIP RAM when bitplanes DMA is inactive.
* Improved 68030 caches handling.
* Added 68040 and 68060 caches handling.
* Added MMU handling to avoid that the MMU affects the speed negatively.
* Optimized rendering core by making it write the dots sequentially.
* Made a little 68060-specific code optimization.
* Ensured 68060 susperscalar dispatch is enabled.
* Added live-toggable staggered lines video filter, which helps see better colors on devices that do not support SHRES and reduces the jailbars effect on devices that support SHRES (to enable/disable: [F1]).
* Made fps indicator live-togglable (to enable/disable: [F2]).
* Made quitting from the voxel screen return to the splash screen.
* Replaced mouse controls with keyboard controls.
* Added benchmark function.
* Added command line switches to control the CPU caches.
* Fixed bug that caused a longword to be written to a random location when the fps indicator was on.
* Fixed an innocuous initialization bug.
* Made cleanup code more robust.
* Updated, extended and fixed documentation.

[Photon]

Rasterization on top of rasterization - while AGA can do chunky just fine considering the platform: CPU and chipset. (PPC is a different platform and fantasy CPU/same CPU with emu increase framerate, and will be appreciated by fans of those platforms.)

I appreciate another take. You are competing with Demoscene fame finding a more efficient way since 1994/1995 (even if many are not demonstrating realtime usage).

I will put a comment on your videos to supply HW specs in description. It is relevant if you want to compete with software tech on a specific platform. (Otherwise not.) Cheers

[saimo]

Originally Posted by Photon

Rasterization on top of rasterization

Could you elaborate on this, please? Graphics are rasterized only once.

- while AGA can do chunky just fine considering the platform: CPU and chipset.

I'm afraid you lost me again
Chunky on AGA always demands some compromises, so I wouldn't say "just fine".

I appreciate another take.

Glad to hear that.

You are competing with Demoscene fame finding a more efficient way since 1994/1995 (even if many are not demonstrating realtime usage).

I will put a comment on your videos to supply HW specs in description. It is relevant if you want to compete with software tech on a specific platform. (Otherwise not.) Cheers

Nope, I'm not competing - just having fun and proving an alternative method of dealing with chunky graphics. Anyway, I replied.

[saimo]

Just released a new version of PVE which is a trifle faster (about 0.07 fps) on my 68030.

v1.2 (01.01.2024)
* Optimized slightly background rendering.
* Corrected benchmark fps calculation (312 rasterlines were considered instead of 313).
* Built against latest custom framework.
* Updated, extended and fixed documentation.

[deluxe1260]

Just tried PVE(1.2) on my Amiga

Amiga1200
Blizzard1260@50 rev.1
setpatch, w/o SS

Here are the results:
rb 31.872
rb cc 31.330
rb cs 30.039
rb cc cs 30.032

[saimo]

@deluxe1260


Cool, thanks!
I have added a line with your figures to the table in the manual. After I gather some more updated data, I'll release it.

[saimo]

It was ages that I intended to dig up some 20+ years old code and use it to play with PED81C a little more. Finally I got around to do it and came up with a new test program called Zoomaniac.
Details in the video and in the manual excerpt below. Download available at https://retream.itch.io/ped81c.

[ Show youtube player ]

--------------------------------------------------------------------------------
OVERVIEW

Zoomaniac has been written to evaluate the performance on a stock Amiga 1200 of
a general-purpose texture scaling routine that writes directly to a PED81C
raster.


--------------------------------------------------------------------------------
PERFORMANCE

The following results are relative to the full screen effect that zooms the
cosmonaut in and out.

On a stock Amiga 1200, the execution speed is between 25 and 26 fps. If the
staggered lines are turned on, the performance drops by about 1 fps (which was
unexpected, since all that such option adds is a Copper WAIT and a Copper MOVE
for each rasterline).
Given that the DMA load caused by PED81C is "double" (see its documentation for
the details), a version that uses only half the number (2) of bitplanes has been
made to check the performance as if the Amiga had a native chunky video mode.
Surprisingly, the performance did not improve at all: relatively to the CHIP bus
access, the scaling code must interleave so nicely with the bitplane data
fetches that having more bus cycles available does not make any/much difference.

An Amiga 1200 equipped with a 68030 clocked at 50 MHz and 60 ns FAST RAM easily
performs at steady 50 fps. To find out the maximum performance, new tests were
made with special versions of the program that had the video synchronization
code disabled.
The speed when running the program normally was between 77 and 78 fps. The
staggered lines option lowered the fps by about 2. The 2 bitplanes versions
performed better, reaching 80-81 fps or, with the staggered lines on, 79-80 fps.
Like on the stock Amiga 1200, the extended Copperlist that implements the
staggered lines causes a small and similar performance drop. Instead, the
halving of the bitplanes DMA load did produce a speed increase.

The following table sums up the results.

S = stock Amiga 1200
E = Amiga 1200 68030 @50 MHz / 60 ns FAST RAM (Blizzard 1230 IV)
2 = 2 bitplanes on
4 = 4 bitplanes on
L = staggered lines on

  |     4 |     L4 |     2 |    L2
--+-------+--------+-------+-------
S | 25-65 |  24-25 | 25-26 | 24-25
E | 77-78 |  75-76 | 80-81 | 79-80

Notes:
 * when FAST RAM is detected, an alternative and more suitable scaling routine
   is used (although writes still happen to CHIP RAM);
 * on (some?) machines equipped with FAST RAM an even faster strategy would be
   rendering to FAST RAM and then simply copying at the maximum speed the
   rendered frame to the CHIP RAM raster.


--------------------------------------------------------------------------------
TECHNICAL NOTES

* The scaling routine fits any rectangle from a texture into a rectangle of any
  size and ratio of another texture with nearest-neighbor matching.
* Logic and rendering are totally asynchronous: the logic runs always at 50 Hz
  and the rendering never stops (unless it reaches the limit of 50 fps, imposed
  by the display refresh rate), thus exploiting the machine's full potential.
* The screen buffering employs three buffers in CHIP RAM.
* The screen resolution is 1020x256 SHRES pixels, which correspond to 255x256
  LORES-sized physical dots and to 128x256 logical dots.
* The code is 100% assembly.
* The program takes over the system entirely and returns to AmigaOS cleanly.

[klx300r]

@ saimo


thanks again

[pixie]

Great job saimo, as always!

[tomcat666]

Very nice...

Pistorm32 2.2Ghz :

[ Show youtube player ]

As with the landscape demo, very nice. On actual CRT looks much better than the video (even though the video is not that bad either, this is captured via a cheap chinese RGB->HDMI converter to 1080p then via an a bit less cheap but still cheap HDMI->USB grabber )

[alexh]

@saimo Amazing work.


@Tom-Cat What's it like with the "no-limit" option?

[tomcat666]

Originally Posted by alexh

@saimo Amazing work.


@Tom-Cat What's it like with the "no-limit" option?

what is the option exactly ? since I get the same 50 fps with

zoomaniac -no-limit
zoomaniac -nolimit
zoomaniac no-limit