Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #652 > unrolled thread

The truth about 256 colour screen modes on the Archimedes

Back to article view | Back to comp.sys.acorn.programmer

Contents

  The truth about 256 colour screen modes on the Archimedes Xavier <xltardy@gmail.com> - 2011-08-22 23:58 -0700
    Re: The truth about 256 colour screen modes on the Archimedes Xavier <xltardy@gmail.com> - 2011-08-23 01:09 -0700
      Re: The truth about 256 colour screen modes on the Archimedes Martin Wuerthner <spamtrap@mw-software.com> - 2011-08-23 12:08 +0200
    Re: The truth about 256 colour screen modes on the Archimedes Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-08-23 15:58 +0100
      Re: The truth about 256 colour screen modes on the Archimedes druck <news@druck.org.uk> - 2011-08-23 23:04 +0100
        Re: The truth about 256 colour screen modes on the Archimedes Steffen Huber <spam@huber-net.de> - 2011-08-24 15:25 +0200
          Re: The truth about 256 colour screen modes on the Archimedes Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-08-24 15:54 +0100
            Re: The truth about 256 colour screen modes on the Archimedes Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-08-30 17:28 +0100
              Re: The truth about 256 colour screen modes on the Archimedes druck <news@druck.org.uk> - 2011-08-31 18:24 +0100
          Re: The truth about 256 colour screen modes on the Archimedes John Greenwood <newsgroups.86z@john-greenwood.co.uk> - 2011-08-26 09:17 +0100
            Re: The truth about 256 colour screen modes on the Archimedes Xavier <xltardy@gmail.com> - 2011-08-26 11:17 -0700
    Re: The truth about 256 colour screen modes on the Archimedes chrisbazley@bigfoot.com - 2011-09-03 02:03 -0700
      Re: The truth about 256 colour screen modes on the Archimedes xltardy@gmail.com - 2013-12-29 12:03 -0800

#652 — The truth about 256 colour screen modes on the Archimedes

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 ?
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.

[toc] | [next] | [standalone]

#653

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'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.

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.

[toc] | [prev] | [next] | [standalone]

#654

In message <6a280e48-7eb9-46d8-bdb7-ef2085f7627b@n12g2000yqh.googlegro 
ups.com>
          Xavier <xltardy@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
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#656

Xavier <xltardy@gmail.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#659

On 23/08/2011 15:58, Theo Markettos wrote:
> Xavier<xltardy@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

[toc] | [prev] | [next] | [standalone]

#662

druck wrote:
> 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/

[toc] | [prev] | [next] | [standalone]

#663

Steffen Huber <spam@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.

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

[toc] | [prev] | [next] | [standalone]

#678

Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#679

On 30/08/2011 17:28, Theo Markettos wrote:
> Theo Markettos<theom+news@chiark.greenend.org.uk>  wrote:
>> 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.

Both those used colour cycling in 16 colour modes, not 256.

---druck

[toc] | [prev] | [next] | [standalone]

#667

In article <9bkcebFadnU1@mid.individual.net>,
   Steffen Huber <spam@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

[toc] | [prev] | [next] | [standalone]

#670

On Aug 26, 10:17 am, John Greenwood <newsgroups....@john-
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:
>
>        http://www.mirrorservice.org/sites/ftp.uni-stuttgart.de/pub/systems/a...
>
> .... but it did not run on my SA-RPC
>
> John

Thank you !
Will have a look at it these days.

[toc] | [prev] | [next] | [standalone]

#684

On Aug 23, 7:58 am, 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'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

[toc] | [prev] | [next] | [standalone]

#3089

Just in case sbdy reads this thread after a search on the keyword 'palette' then I advise this curious truth seeker to read these 2 threads on the stardot forums :
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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web