The truth about 256 colour screen modes on the Archimedes
Xavier
I'm speaking here about the pre RISC PC series, with the 1st VIDC, so
yes that's the good old Archimedes series and the A30x0 series.
I'm a bit surprised to find different explanations about the 8 bit per
pixel 256 colour screen modes on these machines. (mode 13 and mode 15
for example).
On the one hand, I read the palette can be redefined in groups of 16,
and on the other hand that you can define 64 colours freely chosen
from 4096, and automatically 3 tints appear for each of these freely
chosen 64 colours.
What is the truth ?
Isn't it uncorrect to refer to the palette of these 256 colour screen
modes on these machines as 'fixed' if you can alter it, even if it
gives you a headache as it's impossible to get exactly what you want ?
Additionaly, I'd like to know if there is an application, or a piece
of code somewhere, to help one pick up the colours to define one's own
palette.
Thanks for your help.
Xavier
I see !InterGif (http://utter.chaos.org.uk/~pdh/software/intergif.htm)
as a solution with its 'Find best' option (see
http://utter.chaos.org.uk/~pdh/software/intergif/desktop.htm) to
generate the most accurate 256 colour palette, from a given sprite.
It also appears an app called !PalMaker, available on APDL CD1, does
the job too.
What do you think ?
I'd still like to understand technically what's or not limited in the
256 colour screens modes.
Thanks.
Martin Wuerthner
ups.com>
Xavier <xlt...@gmail.com> wrote:
> On 23 août, 08:58, Xavier <xlta...@gmail.com> wrote:
>> Hello.
>>
>> I'm speaking here about the pre RISC PC series, with the 1st VIDC, so
>> yes that's the good old Archimedes series and the A30x0 series.
>> [...]
>
> I see !InterGif (http://utter.chaos.org.uk/~pdh/software/intergif.htm)
> as a solution with its 'Find best' option (see
> http://utter.chaos.org.uk/~pdh/software/intergif/desktop.htm) to
> generate the most accurate 256 colour palette, from a given sprite.
InterGIF[1] knows nothing about VIDC1 palette limitations. It simply
generates a full palette of the requested size with arbitrary colours.
Such a palette is not suitable for VIDC1 machines. Some extra hardware
(e.g., ColourCard) or a later machine (RiscPC upwards) would be needed
to use it.
In a desktop environment it is not very common to change the screen
palette anyway. The OS (more accurately, the ColourTrans module)
performs the job of mapping arbitrary colour information to the
currently chosen screen palette.
On modern machines there is not much use for modes with palettes
anyway. Most Iyonix computers probably run in a 16 million colour mode
all the time.
[1] Just as an aside, InterGIF 6.17b (the most recent version) is at
http://www.mw-software.com/software/freeware.html
--
Martin
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------
Theo Markettos
> I'm a bit surprised to find different explanations about the 8 bit per
> pixel 256 colour screen modes on these machines. (mode 13 and mode 15
> for example).
> On the one hand, I read the palette can be redefined in groups of 16,
> and on the other hand that you can define 64 colours freely chosen
> from 4096, and automatically 3 tints appear for each of these freely
> chosen 64 colours.
According to the VIDC datasheet:
There are 16 12-bit palette registers. That means in a 16 colour mode you
can define each colour to be whatever you want out of the 4096.
In a 256 colour mode, only 8 bits of each palette register are used. There
are 3 red bits, 2 green bits and 3 blue bits. The full 12-bit colour comes
from a mix of bits from the palette register and the logical colour (ie the
pixel value in RAM):
Blue Green Red
L7 D10 D9 D8 L6 L5 D5 D4 L4 D2 D1 D0
Ln = logical colour bit
Dn = palette colour bit
All modes have an additional 'supremacy' bit, which (I think) says whether
the pixel is transparent or not when doing genlock.
Reading between the lines, I think that means that when you pick a logical
colour L[7:0] you get control over the following 'x' bits in the palette
field:
bbbb gggg rrrr
.xxx ..xx .xxx
The rest are predefined by the logical colour. So any given colour will
already have a most of its colour defined because the most significant bits
are already chosen.
> Isn't it uncorrect to refer to the palette of these 256 colour screen
> modes on these machines as 'fixed' if you can alter it, even if it
> gives you a headache as it's impossible to get exactly what you want ?
Given the above, you can only make small changes to the palette. And it
definitely does give you a headache!
> Additionaly, I'd like to know if there is an application, or a piece
> of code somewhere, to help one pick up the colours to define one's own
> palette.
As Martin says, ColourTrans is the way forward here.
Theo
druck
> Xavier<xlt...@gmail.com> wrote:
>> Isn't it uncorrect to refer to the palette of these 256 colour screen
>> modes on these machines as 'fixed' if you can alter it, even if it
>> gives you a headache as it's impossible to get exactly what you want ?
>
> Given the above, you can only make small changes to the palette. And it
> definitely does give you a headache!
I don't think anyone managed to do anything useful with the limited
programmability of the palette in classic 256 colour modes.
The standard arrangement extended the pure 6bit RGB colour cube as best
as it was possible to do with an extra 2 luminance bits. It lent itself
quite well to fast colour matching and dithering when displaying higher
colour depth material.
---druck
Steffen Huber
> I don't think anyone managed to do anything useful with the limited
> programmability of the palette in classic 256 colour modes.
I seem to remember an application called PaintCan by Denis Bogatz (sp?)
which provided basically all 4096 colours for painting and then
optimized the palette to give the best representation.
Steffen
--
Steffen Huber - http://www.huber-net.de/
hubersn Software - http://www.hubersn-software.com/
Theo Markettos
> I seem to remember an application called PaintCan by Denis Bogatz (sp?)
> which provided basically all 4096 colours for painting and then
> optimized the palette to give the best representation.
There was also a demo called 32768 or something, which claimed to display
that number of colours on the screen. I don't know whether that was true or
not - the hardware is limited to 4096 as the DACs are only 4 bits per
channel, but they may have done things like changing the palette every frame
to do time-dithering.
Theo
John Greenwood
In article <9bkceb...@mid.individual.net>,
Steffen Huber <sp...@huber-net.de> wrote:
> I seem to remember an application called PaintCan by Denis Bogatz (sp?)
> which provided basically all 4096 colours for painting and then
> optimized the palette to give the best representation.
I found at:
http://www.mirrorservice.org/sites/ftp.uni-stuttgart.de/pub/systems/acorn/riscos/graphics/tools/
.... but it did not run on my SA-RPC
John
Xavier
greenwood.co.uk> wrote:
> In article <9bkcebFad...@mid.individual.net>,
> Steffen Huber <s...@huber-net.de> wrote:
>
> > I seem to remember an application called PaintCan by Denis Bogatz (sp?)
> > which provided basically all 4096 colours for painting and then
> > optimized the palette to give the best representation.
>
> I found at:
>
>
> .... but it did not run on my SA-RPC
>
> John
Thank you !
Will have a look at it these days.
Theo Markettos
> There was also a demo called 32768 or something, which claimed to display
> that number of colours on the screen. I don't know whether that was true or
> not - the hardware is limited to 4096 as the DACs are only 4 bits per
> channel, but they may have done things like changing the palette every frame
> to do time-dithering.
Thinking about this a little more, I bet that's what they did. You've got a
colour X, a colour X+1 and you want to make X+0.5. So you display X for 50%
of the time and X+1 for 50% of the time. That doubles the number of
colours. But you can do this for each of R, G, B independently, which is a
factor of 8. 8x4096=32768 colours. But of course you can't choose them
arbitrarily due to the hardware.
Theo
druck
Both those used colour cycling in 16 colour modes, not 256.
---druck
chris...@bigfoot.com
> Hello.
>
> I'm speaking here about the pre RISC PC series, with the 1st VIDC, so
> yes that's the good old Archimedes series and the A30x0 series.
>
> I'm a bit surprised to find different explanations about the 8 bit per
> pixel 256 colour screen modes on these machines. (mode 13 and mode 15
> for example).
> On the one hand, I read the palette can be redefined in groups of 16,
> and on the other hand that you can define 64 colours freely chosen
> from 4096, and automatically 3 tints appear for each of these freely
> chosen 64 colours.
>
> What is the truth ?
Presumably 'groups of 16' because each of the 16 palette entries
affects 16 of the 256 colours representable in the frame buffer.
You cannot define 64 colours freely chosen from 4096 because that
would require 4 times as many palette entries than actually exist
(i.e. 6 bits instead of 4 bits of each pixel controlled by the
palette). For the tints to 'automatically appear', the palette would
need to control the most significant 2 bits of each colour component
(2 to the power of 2*3 = 64) instead of the least significant 3 bits
of blue/red and the least significant 2 bits of green. This would
arguably be more useful, but it would require VIDC to provide 64
palette entries, which it does not.
The tint bits are read from the palette but they are also shared
between all three colour components. Therefore there is almost no
point changing the two least-significant bits of each palette entry
(except perhaps to do extremely crude fade in/out with only four
levels of brightness). All you are left with is the ability to
influence the second-most significant bits of blue and red, which is
not very useful.
> Isn't it uncorrect to refer to the palette of these 256 colour screen
> modes on these machines as 'fixed' if you can alter it, even if it
> gives you a headache as it's impossible to get exactly what you want ?
You might find the following link helps you to understand, although it
doesn't let you simulate reprogramming the palette because that would
make the 'GCOL' bit ordering (which interleaves bits read from the
palette with those read from the frame buffer) meaningless:
http://starfighter.acornarcade.com/convert/
> Additionaly, I'd like to know if there is an application, or a piece
> of code somewhere, to help one pick up the colours to define one's own
> palette.
There probably aren't any alternative palettes which make sense, which
is why people don't bother.
Chris
xlt...@gmail.com
http://www.stardot.org.uk/forums/viewtopic.php?f=29&t=3613
http://www.stardot.org.uk/forums/viewtopic.php?f=29&t=5212
Hope this helps.
Zarchos.