Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
69 user(s) are online (52 user(s) are browsing Forums)

Members: 1
Guests: 68

VooDoo, more...

Headlines

 
  Register To Post  

PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
PED81C is a video system for AGA Amigas that provides pseudo-native chunky screens, i.e. screens where each byte in CHIP RAM corresponds to a dot on the display. In short, it offers chunky screens without chunky-to-planar conversion or any CPU/Blitter/Copper sweat.

Download: https://www.retream.com/PED81C

These videos show a few examples:









Notes:
* due to the nature of the system, the videos must be watched in their original size (1920x1080);
* YouTube's video processing has slightly reduced the visual quality (i.e. the result is better on real machines).

Full details straight from the documentation:

--------------------------------------------------------------------------------
CORE IDEA

The core idea is using SHRES pixels 
("pixels" from now onto simulate dots in a
CRT
/LCD-like fashion.

Each dot is made of 4 pixels as follows:

 
ABCD
 ABCD
 ABCD
 ABCD

where

 X
 X
 X
 X

represents a pixel
.

The eye cannot really distinguish the pixels and, insteadperceives them almost
as a single dot whose color is given by the mix of the colors of the pixelsThe
pixels thus constitute the color elements 
("elements" from now onof the dot.
The effect is not perfect though, as the pixels can still more or less be seen.
The sharper the display the bigger the pixelsthe worse the visual mixIn
practice
thoughthe effect works acceptably well on CRTLCD and LED displays
alike
.

The pixels can be assigned any RGB values ("base colors" from now on).
For 
examplethe most obvious choice is:

 
RGBW
 RGBW
 RGBW
 RGBW

Starting from the left
the pixels are used for the redgreenblue and white
elements of dots
The pixels can be assigned any values in these ranges:

 
R$rr0000where $rr in [$00$ff]
 
G: $00gg00where $gg in [$00$ff]
 
B: $0000bbwhere $bb in [$00$ff]
 
W$wwwwwwwhere $ww in [$00$ff]

As 
a consequencethere is an overall brightness loss of at least 50%. For
examplethe white dot (the brighest oneis obtained by assigning the pixels
the maximum values in the ranges 
(i.e$ff0000= $00ff00= $0000ff,
$ffffff), which add up to $ffffff*2the half of the absolute maximum value
of the 4 pixels
i.e$ffffff*4.

Each set of base colors 
("color model" from now onproduces the specific
palette that the dots are perceived in 
("dots palette" from now on). To
understand how to calculate the dots palette
it is first necesssary to look at
how the screens work
.

The rasteri.ethe matrix of the bytes (stored as a linear bufferthat
represent the dots
must reside in CHIP RAMIt is used as bitplane 1 and also
as bitplane 2shifted 4 pixels to the right.
This how a byte %76543210 (where each digit represents at bitin the raster is
displayed
:

 
bitplane 2:     76543210
 bitplane 1
76543210
                 
****

The marked bits are those that produce the dot that corresponds to the byte:

                 
ABCD
                 ABCD
                 ABCD
                 ABCD

                 
^^^^

 
bitplane 2:     76543210
 bitplane 1
76543210

The elements are thus indicated by the bit pairs in the byte
:

 %
73 -> element A
 
%62 -> element B
 
%51 -> element C
 
%40 -> element D

Replacing the digits with letters gives a better representation
:

 %
ABCDabcd

where
:

 
most significant bit for element X
 x 
least significant bit for element X

Each element can have only 4 values corresponding to the bit pairs 
%00, %01,
%
10 and %11. Such values are those stored in COLORxxThereforethe bit pairs
represent the COLORxx indexes
:

 %
00 -> COLOR00
 
%01 -> COLOR01
 
%10 -> COLOR02
 
%11 -> COLOR03

However
there are 4 elementsso it is necessary to distinguish themthis is
achieved by adding two selector bitplanes filled with fixed patterns
:

                 
ABCD
                 ABCD
                 ABCD
                 ABCD

                 
^^^^

 
bitplane 4001100110011
 bitplane 3
010101010101
 bitplane 2
:     ABCDabcd
 bitplane 1
ABCDabcd

Therefore
:

 
bitplane 4 and = %00 -> element A -> COLOR00 thru COLOR03
 bitplane 4 
and = %01 -> element B -> COLOR04 thru COLOR07
 bitplane 4 
and = %10 -> element C -> COLOR08 thru COLOR11
 bitplane 4 
and = %11 -> element D -> COLOR12 thru COLOR15

Given that there are 4 elements 
and that each element can have 4 different
values
the total number of combinations (i.eof dots colorsis 4^256.

In the RGBW color model
COLORxx could be set up as follows (for simplicitythe
low
-order 12 bits are left to the automatic copy performed by AGA):

        
R      |        G      |        B      |        W
 
--------------+---------------+---------------+--------------
 
COLOR00: $000 COLOR04: $000 COLOR08: $000 COLOR12: $000
 COLOR01
: $500 COLOR05: $050 COLOR09: $005 COLOR13: $555
 COLOR02
$a00 COLOR06: $0a0 COLOR10: $00a COLOR14$aaa
 COLOR03
$f00 COLOR07: $0f0 COLOR11: $00f COLOR15$fff

Consequently
the bit pairs in the bytes yield these colors:

     |   %
00   |   %01   |   %10   |   %11
 
----+---------+---------+---------+--------
 %
Aa | $000000 | $550000 $aa0000 $ff0000
 
%Bb | $000000 | $005500 | $00aa00 | $00ff00
 
%Cc | $000000 | $000055 | $0000aa | $0000ff
 
%Dd | $000000 | $555555 $aaaaaa $ffffff

For examplethe byte %RGBWrgbw = %10011010 (%Rr = %11, %Gg = %00, %Bb = %01,
%
Ww = %10represents this dot:

                 
f00a
                 f00a
                 000a
                 000a
                 005a
                 005a

                 
^^^^

 
bitplane 2:     10011010
 bitplane 1
10011010

The dot RGB color is thus
:

 
R: ($ff + $00 + $00 $aa) / = (255 170) / 106.2 = $6a \
 G
: ($00 + $00 + $00 $aa) / =        170  =  42.5 = $2b  > $6a2b40
 B
: ($00 + $00 + $55 $aa) / = ( 85 170) / =  63.7 = $40 /

A critical aspect of PED81C is that each dot is surrounded by spurious bits:

 
bitplane 2:     ABCDabcd
 bitplane 1
ABCDabcd
             
****    ****

Without CPU and/or Blitter interventionthose bits cannot be eliminated but
processing data is precisely what PED81C tries to avoid
so it is necessary to
find a way to deal with the spurious bits
.
This is what happens with two consecutive bytes %ABCDabcd and %EFGHefgh:

                 
ABCD????EFGH
                 ABCD
????EFGH
                 ABCD
????EFGH
                 ABCD
????EFGH

                 
^^^^^^^^^^^^

 
bitplane 2:     ABCDabcdEFGHefgh
 bitplane 1
ABCDabcdEFGHefgh

Between the dots produced by the bytes 
as explained above ("desired dots" from
now on
is a dot that is made of bits coming from both the bytes ("middle dot"
from now on), i.e. %EFGH and %abcdThe simplest solution would be masking the
middle dot out with a no
-DMA vertically repeating jailbar mask spritebut that
would introduce a horrible vertical spacing between the columns of dots 
and
reduce further the brightness of the screen.
A smarter solution would be adding one more selector bitplane to distinguish
between desired dots 
and middle dots (for readabilityfrom now on0 bits are
replaced with 
'·' where needed):

                 
ABCD????ABCD
                 ABCD
????ABCD
                 ABCD
????ABCD
                 ABCD
????ABCD

                 
^^^^^^^^^^^^

 
bitplane 51111····1111····1111
 bitplane 4
··11··11··11··11··11
 bitplane 3
·1·1·1·1·1·1·1·1·1·1
 bitplane 2
:     ABCDabcdEFGHefgh
 bitplane 1
ABCDabcdEFGHefgh

COLOR16 thru COLOR31 could then be set up so that the middle dots are mixes of
the desired dots
keeping in mind that the middle dots have the most and least
significant bits swapped around 
(the least significant bits of the left dot end
up in the most significant bits of the middle dot 
and the most significant bits
of the right dot end up in the least significant bits of the middle dot
). The
simplest settings reflect the settings of the desired dots
but with the RGB
values assigned to the 
%01 and %10 bit pairs swapped around.
For 
examplein the RGBW color model:

        
R      |        G      |        B      |        W
 
--------------+---------------+---------------+--------------
 
COLOR16: $000 COLOR20: $000 COLOR24: $000 COLOR28: $000
 COLOR17
: $500 COLOR21: $0a0 COLOR25: $00a COLOR29: $555
 COLOR18
$a00 COLOR22: $050 COLOR26: $005 COLOR30$aaa
 COLOR19
$f00 COLOR23: $0f0 COLOR27: $00f COLOR31$fff

For exampletwo identical bytes %10001000 ($ff0000would give this result
(which is correct):

                 
RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW

                 f···f···f···
                 f···f···f···
                 ············
                 ············
                 ············
                 ············

                 
^^^^^^^^^^^^

 
bitplane 51111····1111····1111
 bitplane 4
··11··11··11··11··11
 bitplane 3
·1·1·1·1·1·1·1·1·1·1
 bitplane 2
:     1···1···1···1···
 bitplane 1
1···1···1···1···

 left dot
:   $ff0000
 middle dot
$ff0000
 right dot
:  $ff0000

However
, if the bytes were %00001000 ($550000) and %10000000 ($aa0000), the
result would be
:

                 
RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW

                 5···f···a···
                 5···f···a···
                 ············
                 ············
                 ············
                 ············

                 
^^^^^^^^^^^^

 
bitplane 51111····1111····1111
 bitplane 4
··11··11··11··11··11
 bitplane 3
·1·1·1·1·1·1·1·1·1·1
 bitplane 2
:     ····1···1·······
 bitplane 1
····1···1·······

 left dot
:   $550000
 middle dot
$ff0000
 right dot
:  $aa0000

The middle dot would end up being a full red
stronger than the desired dots,
which is not visually correct nor logical, as the middle dots would be more
prominent than the desired dots
A solution could be dimming the RGB values of
middle dots
.
For 
example, if they were halvedthe result would be:

 
left dot:   $550000
 middle dot
: $800000
 right dot
:  $aa0000

The middle dot would be a good average of the desired dots
That works
conceptually
but in practice it causes the middle dots columns to look like
vertical scanlines 
which is not desirable either.

The case of different hues is even more complicated. For example, if the bytes
were 
%10001000 ($ff0000) and %010001000 ($00ff00), the result would be:

                 
RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW

                 f···5a···f··
                 f···5a···f··
                 ············
                 ············
                 ············
                 ············

                 
^^^^^^^^^^^^

 
bitplane 51111····1111····1111
 bitplane 4
··11··11··11··11··11
 bitplane 3
·1·1·1·1·1·1·1·1·1·1
 bitplane 2
:     1···1····1···1··
 bitplane 1
1···1····1···1···

 left dot
:   $ff0000
 middle dot
: $55aa00
 right dot
:  $00ff00

The middle dot would be a kind of average of the actual dots
although not
really good 
(a good average would be $808000).
It is possible to experiment with the COLORxx values to achieve different
results
but the overall scanlines-like effect would still remainMoreoverthe
3rd selector bitplane would steal a lot of CHIP bus slots
An alternative is
required
.

The proposed solution consists in eliminating the 3rd selector bitplane and
assigning the bit pairs %01 and %10 the same RGB values (which basically gives
the most 
and least significant bits the same weight). As a downsidethis
reduces the amount of dots colors
given that each element can have only 3
different values
the total number of colors falls down to 3^81.

For examplein the RGBW color model:

        
R      |        G      |        B      |        W
 
--------------+---------------+---------------+--------------
 
COLOR00: $000 COLOR04: $000 COLOR08: $000 COLOR12: $000
 COLOR01
: $800 COLOR05: $080 | COLOR09: $008 | COLOR13: $888
 COLOR02
: $800 COLOR06: $080 | COLOR10: $008 | COLOR14: $888
 COLOR03
$f00 COLOR07: $0f0 COLOR11: $00f COLOR15$fff

The 
case of two identical bytes %10001000 ($ff0000would still give the same
(correctresult as before:

                 
RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW

                 f···f···f···
                 f···f···f···
                 ············
                 ············
                 ············
                 ············

                 
^^^^^^^^^^^^

 
bitplane 4··11··11··11··11··11
 bitplane 3
·1·1·1·1·1·1·1·1·1·1
 bitplane 2
:     1···1···1···1···
 bitplane 1
1···1···1···1···

 left dot
:   $ff0000
 middle dot
$ff0000
 right dot
:  $ff0000

The 
case of the bytes %00001000 ($880000) and %10000000 ($880000), would give
this result
:

                 
RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW

                 8···f···8···
                 8···f···8···
                 ············
                 ············
                 ············
                 ············

                 
^^^^^^^^^^^^

 
bitplane 4··11··11··11··11··11
 bitplane 3
·1·1·1·1·1·1·1·1·1·1
 bitplane 2
:     ····1···1·······
 bitplane 1
····1···1·······

 left dot
:   $880000
 middle dot
$ff0000
 right dot
:  $880000

Again the middle dot would be brighter than the actual dots
but now this can
be easily solved by simply forbidding the 
%01 bit pair in bytesgiven that it
can always be replaced by the 
%10 bit pairSothe bytes would instead be both
%10000000 ($880000) and the result would be:

                 
RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW

                 8···8···8···
                 8···8···8···
                 ············
                 ············
                 ············
                 ············

                 
^^^^^^^^^^^^

 
bitplane 4··11··11··11··11··11
 bitplane 3
·1·1·1·1·1·1·1·1·1·1
 bitplane 2
:     1·······1·······
 bitplane 1
1·······1·······

 left dot
:   $880000
 middle dot
: $880000
 right dot
:  $880000

Also the 
case of different hues, %10001000 ($ff0000) and %01000100 ($00ff00),
gives a correct result (for complete correctnessin this example the low-order
bits of COLOR02 
and COLOR05 are set to 0):

                 
RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW
                 RGBWRGBWRGBW

                 f···88···f··
                 f···00···f··
                 ············
                 ············
                 ············
                 ············

                 
^^^^^^^^^^^^

 
bitplane 4··11··11··11··11··11
 bitplane 3
·1·1·1·1·1·1·1·1·1·1
 bitplane 2
:     1···1····1···1··
 bitplane 1
1···1····1···1··

 left dot
:   $ff0000
 middle dot
: $808000
 right dot
:  $00ff00


--------------------------------------------------------------------------------
COLOR MODELS

The CORE IDEA section introduces the RGBW color model
but the number of
possible color models is huge 
(2^288). For best resultsit is adviceable to
define the color models that are most suitable to the graphics to be displayed
.

The most obvious general-purpose color models are:
 * 
CMYWCyan Magenta Yellow White
 
GGreyscale
 
KCKey Colors (red yellow green cyan blue magenta white)
 * 
RGBWRed Green Blue White

This table shows the COLORxx settings 
for the general-purpose color models.

                   |    
CMYW   |     G     |     KC    |   RGBW
 ELEMENT 
COLORxx RGB hi/lo RGB hi/lo RGB hi/lo RGB hi/lo
 
--------+---------+-----------+-----------+-----------+----------
       
COLOR00 | $000/$000 | $000/$000 | $000/$000 | $000/$000
         
COLOR01 | $088/$000 | $222/$222 $f00/$f00 | $800/$000
         
COLOR02 | $088/$000 | $222/$222 $f00/$f00 | $800/$000
         
COLOR03 | $0ff/$0ff $fff/$fff $ff0/$ff0 $f00/$f00
 
--------+---------+-----------+-----------+-----------+----------
       
COLOR04 | $000/$000 | $000/$000 | $000/$000 | $000/$000
         
COLOR05 | $808/$000 | $555/$555 | $0f0/$0f0 | $080/$000
         
COLOR06 | $808/$000 | $555/$555 | $0f0/$0f0 | $080/$000
         
COLOR07 $f0f/$f0f $fff/$fff | $0ff/$0ff | $0f0/$0f0
 
--------+---------+-----------+-----------+-----------+----------
       
COLOR08 | $000/$000 | $000/$000 | $000/$000 | $000/$000
         
COLOR09 | $880/$000 $aaa/$aaa | $00f/$00f | $008/$000
         
COLOR10 | $880/$000 $aaa/$aaa | $00f/$00f | $008/$000
         
COLOR11 $ff0/$ff0 $fff/$fff $f0f/$f0f | $00f/$00f
 
--------+---------+-----------+-----------+-----------+----------
       
COLOR12 | $000/$000 | $000/$000 | $000/$000 | $000/$000
         
COLOR13 | $888/$000 | $888/$000 | $888/$000 | $888/$000
         
COLOR14 | $888/$000 | $888/$000 | $888/$000 | $888/$000
         
COLOR15 $fff/$fff $fff/$fff $fff/$fff $fff/$fff

For the G color modelthe arithmetically perfect assignment would be:
 * 
COLOR01COLOR02: $333333
 
COLOR05COLOR06: $666666
 
COLOR09COLOR10: $999999
 
COLOR13COLOR14$cccccc
However
the resulting dots palette would contain only 26 unique colors.

Each color model has strenghts and weaknessesThis table provides an evaluation
of the general
-purpose color models (COLORS number of unique colors in the
resulting dots palette
).

COLOR MODEL BRIGHTNESS SATURATION CONTRAST COLORS NOTES
------------+------------+------------+----------+--------+--------------------
       
CMYW | **         | *          | *        | 73     no redgreenblue
          G 
| ****       |            | ****     | 45     |
         
KC | ***        | **         | **       | 46     noisy middle dots
       RGBW 
| *          | ***        | ***      | 65     |


--------------------------------------------------------------------------------
CALCULATING/GENERATING DOTS PALETTES

Once the color model is defined
the corresponding dots palette can be
calculated by mixing the RGB values assigned to the bit pairs in the bytes from
0 to 255. The bytes which 
include %01 bit pair should be treated as illegal
and thus be assigned one of the RGB values also assigned to a legal byte (the
easiest solution is to 
use the value of byte 0). The calculation of the RGB
value 
($6a2b40corresponding to the byte %10011010 in the RGBW color model,
done in the CORE IDEA sectionmakes for a practical example.

The PED81C archive includes GeneratePalettea handy tool that generates a dots
palette according to the desired color model 
and then saves it to an ILBM file.
It normalizes to $ff the components of the calculated colorsso that the latter
are brighter 
and have a higher dynamic range than the actual dots palette
colors
allowing for better graphics conversionAlsoit assigns the value of
byte 0 to the illegal bytes
.

The command line arguments are:

 
A0/A,A2/A,A3/A,B0/A,B2/A,B3/A,C0/A,C2/A,C3/A,D0/A,D2/A,D3/A,FFIS100/S,FILE/A

 X0
:      24-bit RGB value for the %00 pair of element X
 X2
:      24-bit RGB value for the %10 pair of element X
 X3
:      24-bit RGB value for the %11 pair of element X
 FFIS100
$ff treated internally as $100 (for better rounding)
 
FILE:    output file

 The 24
-bit RGB values must be in hexadecimal format without prefix.

The palettes are suitable for screens which use bitplanes 3 and as selector
bitplanes
.

The PED81C archive also includes:
 * 
the palettes for the general-purpose color modelsstored as ILBM pictures;
 * 
GeneratePalettesa script that generates a few palettes (it can be used also
   
as a reference for GeneratePalette usage).


--------------------------------------------------------------------------------
PRODUCING GRAPHICS

The palettes can be used to draw
/convert graphics.
For 
exampleto display a picture in an RGBW screen:
 
1. draw/remap the picture with the RGBW palette;
 
2. save the picture as raw chunky data;
 
3. copy the raw chunky data to the raster or use it directly as the raster.


--------------------------------------------------------------------------------
SETTING UP AND USING SCREENS

PED81C screens are obtained by opening SHRES screens with these peculiarities
:
 * 
the raster must be used as bitplane 1 and 2;
 * 
bitplane 3 must be filled with %01010101 ($55);
 * 
bitplane 4 must be filled with %00110011 ($33);
 * 
bitplanes 2 and 4 must be shifted horizontally by 4 pixels;
 * 
COLORxx must be set according to the chosen color model;
 * 
the 4 pixels in the leftmost column are made of just the least significant
   bits of the leftmost dots
so it is generally recommendable to hide them by
   moving the left side of the window area by 1 LORES pixel to the right
.

Notes:
 * 
to obtain a screen which is W LORES pixels widethe width of the raster must
   be W
*4 SHRES pixels W/2 bytes (e.g320 LORES pixels -> 1280 SHRES pixels =
   
160 bytes 160 dots);
 * 
to obtain a scrollable screenallocate a raster bigger than the visible area
   
and, in case of horizontal scrollingset BPLxMOD to the amount of non-
   
fetched dots (e.g. for a raster which is 256 dots wide and is displayed in
   a 320 LORES pixels area
BPLxMOD must be 256-320/96);
 * 
HIRES/SHRES resolution scrolling is possiblebut it alters the colors of the
   leftmost dots
;
 * 
given the high CHIP bus load caused by the bitplanes fetchit is best to
   enable the 64
-bit fetch mode (FMODE.BPLx 3).

In generalgiven a raster which is RASTERWIDTH dots wide and RASTERHEIGHT dots
tall
the values to write to the chipset registers in order to create a centered
screen can be calculated 
as follows:
 * 
SCREENWIDTH  RASTERWIDTH 8
 
SCREENHEIGHT RASTERHEIGHT
 
DIWSTRTX     = $81 + (160 SCREENWIDTH 8)
 * 
DIWSTRTY     = $2c + (128 SCREENHEIGHT 2)
 * 
DIWSTRT      = ((DIWSTRTY $ff) << 8) | ((DIWSTRTX 1) & $ff)
 * 
DIWSTOPX     DIWSTRTX SCREENWIDTH 4
 
DIWSTOPY     DIWSTRTY SCREENHEIGHT
 
DIWSTOP      = ((DIWSTOPY $ff) << 8) | (DIWSTOPX $ff)
 * 
DIWHIGH      = ((DIWSTOPX & $100) << 5) | (DIWSTOPY & $700) |
                  ((
DIWSTRTX & $100) >> 3) | (DIWSTRTY >> 8)
 * 
DDFSTRT      = (DIWSTRTX 17) / 2
 
DDFSTOP      DDFSTRT+SCREENWIDTH 8

Example registers settings 
for:
 * 
screen equivalent to a 319x256 LORES screen
 
160 dots wide raster
 
blanked border
 
64-bit sprites and bitplanes fetch mode
 
sprites on top of bitplanes
 
sprites colors assigned to COLOR16 thru COLOR31

 REGISTER 
VALUE ENABLED BITS
 
---------+-------+----------------------------
  
BPLCON0 | $4241 BPU2 COLOR SHRES ECSENA
  BPLCON1 
| $0010 PF2H2
  BPLCON2 
| $0224 KILLEHB PF2P2 PF1P2
  BPLCON3 
| $0020 BRDRBLNK
  BPLCON4 
| $0011 OSPRM5 ESPRM5
  BPL1MOD 
| $0000 |
  
BPL2MOD | $0000 |
  
DDFSTRT | $0038 |
  
DDFSTOP | $00D0 |
  
DIWSTRT | $2C82 |
  
DIWSTOP | $2CC1 |
  
DIWHIGH $A100 |
  
FMODE   | $000F SPRAGEM SPR32 BPLAGEM BPL32

Given a raster which is W dots wide 
and H dots tallthe byte at <XYis
located at 
<raster address> + W*X.


--------------------------------------------------------------------------------
TWEAKS/EXTENSIONS

#1

The selector bitplanes need a lot of RAMTo save RAM drastically it is enough
to store just 1 line 
for each of them and to reset BPLxPTx with the Copper
during the horizontal blanking period of every rasterline
. As a downsidethis
steals some CHIP bus slots 
and complicates Copperlists.

#2

If a selector bitplane is omittedthe elements become 2 couples of identical
elements
; if both the selector bitplanes are omittedall the elements become
equal
Omitting the selector bitplanes saves (a lot ofCHIP bus slots and can
be useful in particular cases
. For examplethe demo THE CURE does not use any
selector bitplanes 
and uses bytes of the kind %HHHHLLLLwhere H High bit,
Low bitthisthanks to jailbar mask sprites produces perfect LORES-looking
4
-color pixels (whichtogether with bitplanes DMA toggling every other
rasterline
produces a dot-matrix display).

#3

If, due to the nature of the graphicsthe visual output looks very "vertical",
it can be improved by applying a crosshatch dither effect by shifting the
rasterlines by 4 pixels on an alternate line basis 
as follows - for example:

 ****************************************
  
########################################
 
++++++++++++++++++++++++++++++++++++++++
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 ...

#4

To lessen the dithering of tweak #3 and improve the color mix, the shifting can
also be inverted on an alternate frame basis - for examplethe rasterlines
could be shown on the next frame 
as follows:

  ****************************************
 
########################################
  
++++++++++++++++++++++++++++++++++++++++
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  ...

This tweak causes flickering visuals (especially on displays with quick
response
), so it is not really recommendable.

#5

Depending on the base colorsto achieve a better visual mixshifting the lines
by 1 pixel on an alternate frame 
(and possibly linebasis could help without
causing too much flicker
Stillnot really recommendable.

#6

Adding a horizontal scanlines effect by swapping the elements palette on an
alternate line basis 
(through BPLCON4makes the visual output resemble that of
a CRT display
.

#7

To reduce the amount of graphics to draw and the memory usagethe raster size
can be halved by repeating each rasterline once 
(which is easily obtained by
means of FMODE
.BSCAN2 and BPLxMOD). This combines well with tweak #6.

#8

If neededthe bitplanes order can be reversedi.ethe selector bitplanes
could be assigned bitplanes 1 
and 2, and the raster bitplanes could be assigned
bitplanes 3 
and 4:

 
bitplane 4:     76543210
 bitplane 3
76543210
 bitplane 2
001100110011
 bitplane 1
010101010101

In this 
case, COLORxx need to be set up differently:

 
bitplane 2 and = %00 -> element A -> COLOR00 COLOR04 COLOR08 COLOR12
 bitplane 2 
and = %01 -> element B -> COLOR01 COLOR05 COLOR09 COLOR13
 bitplane 2 
and = %10 -> element C -> COLOR02 COLOR06 COLOR10 COLOR14
 bitplane 2 
and = %11 -> element D -> COLOR03 COLOR07 COLOR11 COLOR15

Note
GeneratePalette does not support such arrangement.

#9

With a careful setup of COLORxxthe unused 4 bitplanes can be used to overlay
other graphics 
or even up to two more chunky screensoptionally with colorkey
and translucencyThathoweverwould increase noticeably the CHIP bus load.


--------------------------------------------------------------------------------
NOTES

#1

The meaning of PED81C is "Pixel Elements Dots, 81 Colors".

#2

Although due to the middle dots the logical horizontal resolution is half of the
physical one
the averaging provided by the middle dots and SHRES quite fool the
eye
.

#3

Visuallythe best results are obtained with complex/dithered images, as plain
color areas 
and geometrical shapes reveal the pixels and the middle dotsIn
particular
isolated dots look 3x-ish wide.

#4

81 is only the theoretical maximum number of dots colorsThe actual number
depends on the chosen base colors
.

#5

The core idea could be used also to display 24-bit picturesbut the coarseness
of the method wastes completely the subtlety of such high color resolution 
(also
verified experimentally
).

#6

Usage of PED81C is of course welcome and encouragedIt would be nice if credit
were given
. If used in a commercial productionI would appreciate if permission
were asked first 
and if I could receive a little share of the profits.


--------------------------------------------------------------------------------
PERFORMANCE CONSIDERATIONS

PED81C is very CHIP bus intensive
the bitplanes data fetched are twice that of
an equivalent 256 colors LORES screen
. If Lisa had been able to use the BPLxDAT
values of inactive bitplanes 
(like, for exampleDenise does with bitplanes 5
and 6 when 4 bitplanes only and HAM are enabledBPL3DAT and BPL4DAT could have
been loaded with the selector values thus halving the DMA fetches 
but
unfortunately that is not the 
case.
Thereforeone might wonder whether is PED81C is actually advantageousA lot
depends on how graphics are rendered
: for examplea favourable case is when the
CPU can keep on executing cached code after writing to CHIP RAM so that no
/few
cycles are wasted between writes
A general and indirect evaluation can be done
by comparing PED81C to the traditional C2P methods 
as follows.

The measurements, for simplicityare based on the amount of data to render,
convert (if needed) and fetch for output relatively to 1 line.

Reference regular screen:
 * 
320 pixels wide LORES
 
6 bits deep screen (for fairnessbecause PED81C can at most output 81 unique
   colors 
and the actual number of colors, as shown abovemight be even less
   depending on the color model
)

Assumptions:
 * 
1 chunky pixel 1 byte
 
CPU and Blitter operations in CHIP RAM involve 6 bitplanes

In only CHIP RAM is available
the figures are as follows.

CPU-only C2P:
 * 
rendering320 bytes
 
C2P reads320 bytes
 
C2P writes240 bytes
 
bitplanes fetch240 bytes
 
total1120 bytes

CPU
+Blitter C2P1 CPU pass and 1 Blitter pass:
 * 
rendering320 bytes
 
C2P reads by CPU320 bytes
 
C2P writes by CPU240 bytes
 
C2P reads by Blitter240 bytes
 
C2P writes by Blitter240 bytes
 
bitplanes fetch240 bytes
 
total1600 bytes

PED81C
:
 * 
rendering160 bytes
 
bitplanes fetch640 bytes
 
total800 bytes

If FAST RAM is availablethe figures of PED81C do not change (as the raster
always resides in CHIP RAM
), while the figures of the other cases are as
follows.

CPU-only C2P:
 * 
rendering in FAST RAM320 bytes
 
C2P reads from FAST RAM320 bytes
 
C2P writes to CHIP RAM240 bytes
 
bitplanes fetch240 bytes
 
total640 bytes FAST RAM480 bytes CHIP RAM

CPU
+Blitter C2P1 CPU pass and 1 Blitter pass:
 * 
rendering in FAST RAM320 bytes
 
C2P reads by CPU from FAST RAM320 bytes
 
C2P writes by CPU to CHIP RAM240 bytes
 
C2P reads by Blitter from CHIP RAM240 bytes
 
C2P writes by Blitter to CHIP RAM240 bytes
 
bitplanes fetch240 bytes
 
total640 bytes FAST RAM960 bytes CHIP RAM

Overall
PED81C has the edge performance-wiseespecially considering that CPU
and Blitter are not busy with converting dataIt must be pointed outthough,
that PED81C's logical horizontal resolution is halved (hence the 160 bytes per
line) and that the overall visual quality is inferior to that of a regular
screen mode.


--------------------------------------------------------------------------------
BACKGROUND

#1

The idea of using SHRES pixels as elements is by Fabio Bizzetti, who used it for
his Virtual Karting and Virtual Karting II games.
In the late 90s, I was in touch with him and he told me that his idea was to
"fool the RF signal" (or something along these lines). This got me thinking and
I came up with the core idea. Before writing here (in 2022!) I had never
bothered checking what he actually had done, but now I deemed it appropriate to
do it in order to provide a brief description of his method, both as an
acknowledgement of his brilliant idea and to provide more food for thought.
After starting Virtual Karting II in UAE, having a look at the moving graphics,
grabbing a screenshot, checking the values of BPLCON0 and BPLCON1, and checking
the bitplanes memory, I found out that he used bitplanes 1-3 as selector
bitplanes and assigned the pixels these elements (from left to right): red-
orange-yellow-green-cyan-azure-blue-purple (so, there are no middle dots and
dots are really 2x-wide). To mitigate the columns-looking result, he applied the
crosshatch tweak, swapping the scroll offsets on an alternate frame basis.

#2

Between the end of the 90s and 2003 I had created a system (implemented as a
shared library) based on the same core idea, but using 3 selector bitplanes.
PED81C is actually a simplification of that system, born from precisely from the
removal of the middle dots selector bitplane to improve the speed.

The old system was really rich feature-wise, as it provided:
 * 256 colors screens
 * HalfRes screens: screens like PED81C'
s
 
FullRes screensscreens without middle dots this was achieved by means of
   a conversion performed by the CPU
optionally assisted by the Blitter (for
   
the recordthe CPU-only conversion allowed 320x256 screens at about 50 fps
   on an Amiga 1200 equipped with a Blizzard 1230
-IV and 60 ns FAST RAM)
 * 
chequer effectcrosshatch tweak for HalfRes screens
 
double and triple buffering
 
5 embedded color models (RGBWRGBMRGBPRGBPSRGB332)
 * 
color/palette handling functions (color settingcolor remapping24-bit
   fading 
and 24-bit cross-fading)
 * 
Cross Playfield mode256 color screen overlay on top of another screen with
   any degree of opacity between 0 
and 256 (in practicethis produced 16-bit
   graphics
)
 * 
Dual Cross Playfield modelike Cross Playfield modebut with a selectable
   colorkey
 
graphical contexts (clippingdrawing modes)
 * 
pixmap fuctions (blittingzoomingrotzooming)
 * 
graphical primitives
 
font functions
 
ILBM functions

One might wonder why such system is not 
public - the reasons are:
 * 
the core would need to be re-designed;
 * 
the implementation could be better;
 * 
the accessory functions (like the graphical onesshould be in a separate
   library
;
 * 
the documentation would need a major overhaul.

Basicallydo not consider the system suitable for public distributionI
would rather redo it from scratch
... but that is precisely why PED81C was born:
while 
thinking how to improve the systemI realized how to eliminate the 3rd
selector bitplane 
and decided to get rid of the FullRes screensbecause the
point of these systems is obtaining chunky screens without data conversion
(otherwiseit is better to use one of the traditional C2P methodswhich give
better visual results
).

#3

Originally I had planned to use PED81C to make a new gameHoweverI could not
come up with a satisfactory idea
moreoverdue to personal reasonsI had to
stop software development
Given that I could not predict when/if I would able
to produce something with PED81C 
and given that the war in Ukraine put the world
in deep uncertainty
I decided that it was better to release PED81C to avoid
that it went wasted 
and also as a gift to the Amiga community.
I must admit I have been tempted to provide an implementation of PED81C in the
form of a library 
or of a collection of functionsbut since setting up PED81C
screens is easy 
and since general-purpose routines would perform worse than
tailor
-made onesI decided to let programmers implement it in the way that fits
best their projects
.


Edited by saimo on 2022/3/9 18:03:25
Edited by saimo on 2023/6/19 22:33:45
Edited by saimo on 2023/6/21 16:11:05
Edited by saimo on 2023/6/26 20:56:07
Edited by saimo on 2023/11/28 23:01:50
Edited by saimo on 2023/11/28 23:05:45
Edited by saimo on 2023/11/29 12:13:25
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Not too shy to talk
Not too shy to talk


See User information
Clever... is it sort of like subpixel font rendering to achieve the effect?

Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
@NinjaCyborg

I don't know how that works, so I can't answer. The best, most complete and shortest explanation I can give is the one in the CORE IDEA section of the documentation.

Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Just can't stay away
Just can't stay away


See User information
@NinjaCyborg

Quote:
Clever... is it sort of like subpixel font rendering to achieve the effect?
No. Visual results might be similar, but it's something completely different.
For subpixel font rendering you basically just quadruple or sixteenfold the resolution a B/W font is rendered to, then you scale the result down to the original resolution again but using grey scale colours (or matching alpha masks) instead of just B/W for the 2x2 or 4x4 pixels groups which have 1/4, 1/2, 3/4, or in case of sixteenfold rendering additionally 1/16, 2/16 ... 14/16, 15/16, black pixels.

Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Not too shy to talk
Not too shy to talk


See User information
@joerg no that's not sub pixel rendering that's what apple uses for retina display and such. sub pixel rendering anti aliases by splitting each full pixel into separate r g and b pixels and then setting boundary pixels to swatches that will blur the line between the white and the black.

Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Home away from home
Home away from home


See User information
@saimo

this is screaming for a kick arse horizontal shooter !

Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
@328gts

I guess you've been influenced by the video examples, but "native" chunky would be better used for other things (although, I did try to imagine if an interesting horizontal shooter could be done). To be honest, I feared I'd get a flock of Doom-like game requests/proposals :D


@all

Improved/corrected documentation.

Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
Uploaded an archive with updated documentation.
While at it, given that I was asked for a source code example, I whipped up an AMOS Professional program that shows how to set up a PED81C screen and to perform some basic operations on it - hopefully, this will be easy to understand and also open the door to AMOS programmers. The program source is included in the archive.

'-----------------------------------------------------------------------------
'
$VERPED81C example 1.3 (28.11.2023) (c2023 RETREAM
'Legal terms: please refer to the accompanying documentation.
'
www.retream.com/PED81C
'contact@retream.com
'
-----------------------------------------------------------------------------

'-----------------------------------------------------------------------------
'
DESCRIPTION
'This shows how to set up a PED81C screen and to perform some basic operations
'
on it.
'Screen features:
equivalent to a 319x256 LORES screen
' * 160 dots wide raster
single buffer
' * blanked border
64-bit bitplanes fetch mode
' * CMYW color model
'
'NOTES
'
The code is written to be readablenot to be general-purpose/optimal.
'-----------------------------------------------------------------------------

'
-----------------------------------------------------------------------------
'GLOBAL VARIABLES

Global RASTERADDRESS,RASTERWIDTH,RASTERHEIGHT,RASTERSIZE

RASTERWIDTH=160
RASTERHEIGHT=256
RASTERSIZE=RASTERWIDTH*RASTERHEIGHT

'
-----------------------------------------------------------------------------
'MAIN

'
Initialize everything.

_INITIALIZE_AMOS_ENVIRONMENT
_INITIALIZE_SCREEN

'If the initialization succeeded, load a picture into the raster and, in case
'
of successexecute a simple effect on it.

If 
Param
   _LOAD_PICTURE_INTO_RASTER
["picture-160x256.raw"]
   If 
Param
      _TURN_DISPLAY_DMA_ON
[0]
      
_RANDOMIZE_RASTER
      _TURN_DISPLAY_DMA_OFF
   End 
If
End If

'Deinitialize everything.

_DEINITIALIZE_SCREEN
_RESTORE_AMOS_ENVIRONMENT

'
-----------------------------------------------------------------------------
'ROUTINES

Procedure _ALLOCATE_BITPLANE[BANKINDEX,SIZE]
   '
--------------------------------------------------------------------------
   
'DESCRIPTION
   '
Allocates a CHIP RAM buffer to be used as a bitplane.
   
'
   '
INPUT
   
'BANKINDEX = index of bank to use
   '
SIZE      size [bytesof bitplane
   
'
   '
OUTPUT
   
'64-bit-aligned bitplane address (0 = error)
   '
   'WARNINGS
   '
The buffer must be freed with Erase BANKINDEX or Erase All.
   
'--------------------------------------------------------------------------

   Trap Reserve As Chip Data BANKINDEX,SIZE+8
   If Errtrap=0 Then A=(Start(BANKINDEX)+7) and $FFFFFFF8

End Proc[A]
Procedure _DEINITIALIZE_SCREEN
   '
--------------------------------------------------------------------------
   
'DESCRIPTION
   '
Deinitializes the screen.
   
'
   '
WARNINGS
   
'Can be called only if the display is off.
   '
--------------------------------------------------------------------------

   
Erase All
   Doke $DFF1FC
,Rem FMODE

End Proc
Procedure _INITIALIZE_AMOS_ENVIRONMENT
   
'--------------------------------------------------------------------------
   '
DESCRIPTION
   
'Ensures the program cannot be interrupted or brought to back, and turns
   '
off the AMOS video system.
   
'--------------------------------------------------------------------------

   Break Off
   Amos Lock
   Comp Test Off
   Auto View Off
   Update Off
   Copper Off
   _TURN_DISPLAY_DMA_OFF

End Proc
Procedure _INITIALIZE_SCREEN
   '
--------------------------------------------------------------------------
   
'DESCRIPTION
   '
Initializes the screen.
   
'
   '
OUTPUT
   
'-1/0 = OK/error
   '
   'WARNINGS
   '
_DEINITIALIZE_SCREEN[] must be called also in case of failure.
   
'
   '
NOTES
   
'Sets RASTERADDRESS.
   '
--------------------------------------------------------------------------

   
'Allocate the raster.

   _ALLOCATE_BITPLANE[10,RASTERSIZE] : If Param=0 Then Pop Proc[0]
   RASTERADDRESS=Param

   '
Allocate and fill the selector bitplanes.

   
_ALLOCATE_BITPLANE[11,RASTERSIZE] : If Param=0 Then Pop Proc[0]
   
B3A=Param
   Fill B3A To B3A
+RASTERSIZE,$55555555

   _ALLOCATE_BITPLANE
[12,RASTERSIZE] : If Param=0 Then Pop Proc[0]
   
B4A=Param
   Fill B4A To B4A
+RASTERSIZE,$33333333

   
'Set the chipset.

   DIWSTRTX=$81+(160-RASTERWIDTH)
   DIWSTRTY=$2C+(128-RASTERHEIGHT/2)
   DIWSTRT=((DIWSTRTY and $FF)*256) or((DIWSTRTX+1) and $FF)
   DIWSTOPX=DIWSTRTX+RASTERWIDTH*2
   DIWSTOPY=DIWSTRTY+RASTERHEIGHT
   DIWSTOP=((DIWSTOPY and $FF)*256) or(DIWSTOPX and $FF)
   DIWHIGH=((DIWSTOPX and $100)*32) or(DIWSTOPY and $700) or((DIWSTRTX and $100)/8) or(DIWSTRTY/256)
   DDFSTRT=(DIWSTRTX-17)/2
   DDFSTOP=DDFSTRT+RASTERWIDTH-8

   Doke $DFF092,DDFSTRT
   Doke $DFF094,DDFSTOP
   Doke $DFF08E,DIWSTRT
   Doke $DFF090,DIWSTOP
   Doke $DFF1E4,DIWHIGH

   Doke $DFF100,$4241 : Rem BPLCON0
   Doke $DFF102,$10 : Rem BPLCON1
   Doke $DFF104,$224 : Rem BPLCON2
   Doke $DFF108,0 : Rem BPLMOD1
   Doke $DFF10A,0 : Rem BPLMOD2
   Doke $DFF1FC,$3 : Rem FMODE

   '
Set COLORxx.

   
Doke $DFF106,$20 Rem BPLCON3
   Doke $DFF180
,0
   Doke $DFF182
,$88
   Doke $DFF184
,$88
   Doke $DFF186
,$FF
   Doke $DFF188
,0
   Doke $DFF18A
,$808
   Doke $DFF18C
,$808
   Doke $DFF18E
,$F0F
   Doke $DFF190
,0
   Doke $DFF192
,$880
   Doke $DFF194
,$880
   Doke $DFF196
,$FF0
   Doke $DFF198
,0
   Doke $DFF19A
,$888
   Doke $DFF19C
,$888
   Doke $DFF19E
,$FFF
   Doke $DFF106
,$220 Rem BPLCON3
   Doke $DFF180
,0
   Doke $DFF182
,0
   Doke $DFF184
,0
   Doke $DFF188
,0
   Doke $DFF18A
,0
   Doke $DFF18C
,0
   Doke $DFF190
,0
   Doke $DFF192
,0
   Doke $DFF194
,0
   Doke $DFF198
,0
   Doke $DFF19A
,0
   Doke $DFF19C
,0
   Doke $DFF106
,$20 Rem BPLCON3

   
'Build a Copperlist that sets the bitplanes pointers.

   Cop Movel $E0,RASTERADDRESS
   Cop Movel $E4,RASTERADDRESS
   Cop Movel $E8,B3A
   Cop Movel $EC,B4A
   Cop Swap

End Proc[-1]
Procedure _LOAD_PICTURE_INTO_RASTER[FILEPATH$]
   '
--------------------------------------------------------------------------
   
'DESCRIPTION
   '
Loads a raw 8-bit chunky picture into the rasterensuring that its size
   
'is correct.
   '
   'IN
   '
FILEPATHS path of picture file
   
'
   '
OUTPUT
   
'-1/0 = OK/error
   '
--------------------------------------------------------------------------

   
Trap Open In 1,FILEPATH$ : If Errtrap Then Pop Proc[0]
   
L=Lof(1)
   
Close(1)
   If 
L<>RASTERSIZE Then Pop Proc[0]
   
Trap Bload FILEPATH$,RASTERADDRESS

End Proc
[Errtrap=0]
Procedure _RANDOMIZE_RASTER
   
'--------------------------------------------------------------------------
   '
DESCRIPTION
   
'Randomizes the raster by swapping 16 dots per frame, until a mouse button
   '
is pressed.
   
'--------------------------------------------------------------------------

   XM=RASTERWIDTH-1
   YM=RASTERHEIGHT-1
   Repeat
      C=16
      While C
         X0=Rnd(XM)
         Y0=Rnd(YM)
         X1=Rnd(XM)
         Y1=Rnd(YM)
         A0=Y0*RASTERWIDTH+X0+RASTERADDRESS
         A1=Y1*RASTERWIDTH+X1+RASTERADDRESS
         C0=Peek(A0)
         Poke A0,Peek(A1)
         Poke A1,A0
         Dec C
      Wend
      _WAIT_SCREEN_BOTTOM
   Until Mouse Click

End Proc
Procedure _RESTORE_AMOS_ENVIRONMENT
   '
--------------------------------------------------------------------------
   
'DESCRIPTION
   '
Restores the AMOS environment.
   
'--------------------------------------------------------------------------

   Copper On
   Update On
   Auto View On
   Amos Unlock
   Break On
   _TURN_DISPLAY_DMA_ON[$20]

End Proc
Procedure _TURN_DISPLAY_DMA_OFF
   '
--------------------------------------------------------------------------
   
'DESCRIPTION
   '
Disables the bitplanesCopper and sprites DMA.
   
'--------------------------------------------------------------------------

   _WAIT_SCREEN_BOTTOM
   Doke $DFF096,$3A0 : Rem DMACON

End Proc
Procedure _TURN_DISPLAY_DMA_ON[SSPRITESFLAG]
   '
--------------------------------------------------------------------------
   
'DESCRIPTION
   '
Enables the bitplanes and Copper DMA.
   
'
   '
INPUT
   
'SSPRITESFLAG = $20/0 = turn / do not turn sprites on
   '
   'WARNINGS
   '
The chipset must have been set up properly.
   
'--------------------------------------------------------------------------

   _WAIT_SCREEN_BOTTOM
   Doke $DFF096,$8380 or SSPRITESFLAG : Rem DMACON

End Proc
Procedure _WAIT_SCREEN_BOTTOM
   '
--------------------------------------------------------------------------
   
'DESCRIPTION
   '
Waits for the bottom of the screen.
   
'--------------------------------------------------------------------------

   While Deek($DFF004) and $3 : Wend
   Repeat : Until(Leek($DFF004) and $3FF00)>$12C00

End Proc


Edited by saimo on 2023/11/28 23:02:09
Edited by saimo on 2023/11/29 12:13:47
RETREAM - retro dreams for Amiga, Commodore 64 and PC
Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
Really impressive.
Should be a definitive + to Amos Professional as an extension

All we have to decide is what to do with the time that is given to us.
Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
@AmiDARK
Quote:
AmiDARK wrote:Really impressive.

Thanks!

Quote:
Should be a definitive + to Amos Professional as an extension

I wrote the example in AMOS to make it easier to understand by more people, but the system isn't intended for any specific language.
I decided to let programmers implement PED81C in the way that fits best their projects and in their language of choice, given that setting up PED81C screens is easy and given that general-purpose routines would perform worse than tailor-made ones.

RETREAM - retro dreams for Amiga, Commodore 64 and PC
Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
@Saime :
I did never said that it should be "Amos Only" system ;)
But simply that it may be interesting to add support for it using extension format. The support should handle screen setup. User will create his/her own custom methods for required effects.

I must admit that I read doc and didn't understand how it works but I'll do another check and if I find time, I will maybe look to see if I can do something interesting with it using extension format.

EDIT :
From doc I read this :
RGBW
does this mean it is a 32 bit value ? Because after you talk about $ww using $wwwwww ..
I don't understand.
Ew... I think I understand you talk about RGB value for the ColorXX register used for the 4th pixel ? Same for others pixels. Right ?


Edited by AmiDARK on 2023/8/1 20:27:43
Edited by AmiDARK on 2023/8/1 20:29:31
Edited by AmiDARK on 2023/8/1 20:41:10
All we have to decide is what to do with the time that is given to us.
Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
@AmiDARK
Quote:
I must admit that I read doc and didn't understand how it works but I'll do another check and if I find time, I will maybe look to see if I can do something interesting with it using extension format.

EDIT :
From doc I read this :
RGBW
does this mean it is a 32 bit value ? Because after you talk about $ww using $wwwwww ..
I don't understand.
Ew... I think I understand you talk about RGB value for the ColorXX register used for the 4th pixel ? Same for others pixels. Right ?

Key concepts:
* each dot is 8 bit;
* each dot is made of 4 SHRES pixels;
* each SHRES pixel is 2 bit (i.e. it can be assigned 4 different RGB values);
* the RGB values assigned to the SHRES pixels are 24 bit and can be chosen freely.

$wwwwww is a placeholder for any 24 bit value assigned to the W(hite) SHRES pixels in the RGBW mode (e.g. $333333 or $eeeeee).

I hope this helps.

RETREAM - retro dreams for Amiga, Commodore 64 and PC
Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
I have just released a little update, accompanied by the PED81C Voxel Engine (PVE), i.e. a new demo. If you can't be bothered trying it yourself, you can see it in this video - but beware: YouTube's video compression degraded the visual quality (especially the colors saturation and brightness).





Details about PVE straight from the manual:
--------------------------------------------------------------------------------
OVERVIEW

PVE is an experiment to test the graphical quality 
and computational performance
of the PED81C system
It allows to move freely around a typical voxel landscape.


--------------------------------------------------------------------------------
GETTING STARTED

PVE requires
:
 * 
Amiga computer
 
AGA chipset
 
200 kB of CHIP RAM
 
4 MB of FAST RAM
 
PAL SHRES support
 
digital joystick/joypad and mouse
 
2.1 MB of storage space

If the monitor graphics card scan doubler do(esnot support SHRESthe
colors will look off 
or even not show at all.
For 
example:
 * 
MNT's VA2000 graphics card displays only the even columns of pixels, so only
   reds and blues show;
 * Irix Labs' 
ScanPlus AGA displays only the odd columns of pixels (contrary to
   how is was originally marketed
), so only greens and grays show.

To install PVEunpack the LhA archive to any directory of your choice.

To start PVEopen the program directory and double-click the program icon from
Workbench 
or execute the program from shell.


--------------------------------------------------------------------------------
MISCELLANEOUS

The map wraps around at its edges.
The number shown in the top-left corner of the action screen indicates the
  number of frames rendered in the last second
.
Upon returning to AmigaOSPVE prints out:
   * 
the total number of frames rendered;
   * 
the total number of frames shown;
   * 
the average number of frames rendered per second;
   * 
the average time (expressed in framestaken by the rendering of a frame.


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

The graphics are first rendered in a raster in FAST RAM and then copied to a
  triple
-buffered PED81C raster in CHIP RAM.
The screen resolution is 1020x200 SHRES pixelswhich correspond to 255x200
  LORES
-sized dots and to 128x200 logical dots.
Rendering is done by columnsfrom bottom to top and then left to right.
The code applies a depth of 256 steps per columnso it evaluates 256*128 =
  
32768 dots per frame (and then renders only those which are actually visible).
The code is 100assembly.
The code is optimized for 68030.
The program supports only maps of 1024x1024 pixelsbut it can be made to
  support maps of other sizes by simply redefining the width 
and height
  constants 
and reassembling the code.
The height of the camera adapts automatically to that of the point it is at,
  
but it can be made user-controllable and its maximum value can be increased
  almost to the point that the lanscape disappears at the bottom of the screen
.
On an Amiga 1200 equipped with a Blizzard 1230 IV mounting a 50 MHz 68030 and
  
60 ns RAM:
   * 
the program runs at about 20.2 fps;
   * 
the rendering of graphics alone runs at about 22.2 fps;
   * 
the impact of PED81C is of about 22.2-20.2 2 fps in other words,
     
writing the graphics to the PED81C raster requires about 50/22.2-50/20.2 =
     
0.223 frames (when only the bitplanes DMA is active);
   * 
rendering the graphics directly to the PED81C raster degrades the
     performance by about 2 to 3 fps 
(tested only with an older and less
     optimized version
).
On an Amiga 1200 equipped with a PiStorm32the program runs at 50 fps
  
(unsurprisingly).
The map size is 1024x1024 pixels.
The map requires 2 MB of FAST RAM.
The program takes over the system entirely and returns to AmigaOS cleanly.


--------------------------------------------------------------------------------
BACKSTORY

After a hiatus from programming of several months 
(due to a computer-unrelated
project
), I decided to finally create something for PED81C because I had made
nothing with it other than a few little examples
I wanted to test its
graphical quality 
and computational performance, and... I felt like having some
good fun
.
After some inconclusive mental wanderingthe idea of making a voxel engine came
to mind 
for unknown reasons (I had never dabbled with voxel before).
When the engine was mature enough I decided to distribute PVE publicly (which
initially was not planned
).


About the update, I fixed some palette values in a table in the documentation, added the formulas for calculating DIWSTRT, DIWSTOP, DIWHIGH, DDFSTRT and DDFSTOP to the documentation and implemented them in the AMOS Professional source code example. This is the snippet relative to the register settings:
In generalgiven a raster which is RASTERWIDTH dots wide and RASTERHEIGHT dots
tall
the values to write to the chipset registers in order to create a centered
screen can be calculated 
as follows:
 * 
SCREENWIDTH  RASTERWIDTH 8
 
SCREENHEIGHT RASTERHEIGHT
 
DIWSTRTX     = $81 + (160 SCREENWIDTH 8)
 * 
DIWSTRTY     = $2c + (128 SCREENHEIGHT 2)
 * 
DIWSTRT      = ((DIWSTRTY $ff) << 8) | ((DIWSTRTX 1) & $ff)
 * 
DIWSTOPX     DIWSTRTX SCREENWIDTH 4
 
DIWSTOPY     DIWSTRTY SCREENHEIGHT
 
DIWSTOP      = ((DIWSTOPY $ff) << 8) | (DIWSTOPX $ff)
 * 
DIWHIGH      = ((DIWSTOPX & $100) << 5) | (DIWSTOPY & $700) |
                  ((
DIWSTRTX & $100) >> 3) | (DIWSTRTY >> 8)
 * 
DDFSTRT      = (DIWSTRTX 17) / 2
 
DDFSTOP      DDFSTRT+SCREENWIDTH 8

RETREAM - retro dreams for Amiga, Commodore 64 and PC
Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
Just released a new version of PVE. Full changelog below. In short: it's faster and it's got a few little additions.

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.

RETREAM - retro dreams for Amiga, Commodore 64 and PC
Go to top
Re: PED81C - pseudo-native, no C2P chunky screens for AGA
Quite a regular
Quite a regular


See User information
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.

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

--------------------------------------------------------------------------------
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 1200the 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 (2of bitplanes has been
made to check the performance 
as if the Amiga had a native chunky video mode.
Surprisinglythe performance did not improve at allrelatively 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 fpsThe
staggered lines option lowered the fps by about 2. The 2 bitplanes versions
performed better
reaching 80-81 fps or, with the staggered lines on79-80 fps.
Like on the stock Amiga 1200the extended Copperlist that implements the
staggered lines causes a small 
and similar performance dropInsteadthe
halving of the bitplanes DMA load did produce a speed increase
.

The following table sums up the results.

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

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

Notes
:
 * 
when FAST RAM is detectedan 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 asynchronousthe logic runs always at 50 Hz
  
and the rendering never stops (unless it reaches the limit of 50 fpsimposed
  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.


CHANGELOG

March 27, 2024
* Added the Zoomaniac demo.
* [PED81C Voxel Engine] Made a couple of minor changes.
* [PED81C Voxel Engine] Updated documentation.

January 1, 2024
* Rebuilt demos against latest custom framework.
* [PED81C Voxel Engine] Optimized slightly background rendering.
* [PED81C Voxel Engine] Corrected benchmark fps calculation (312 rasterlines were considered instead of 313).
* [PED81C Voxel Engine] Built against latest custom framework.
* [PED81C Voxel Engine] Updated, extended and fixed documentation.

RETREAM - retro dreams for Amiga, Commodore 64 and PC
Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project