Hi,
On maanantai 20 helmikuu 2012, Roger Burrows wrote:
When running in Falcon mode (68030+Falcon selected in System), Hatari
uses the STe palette registers as the source for colour[1] in ST high.
It should use the Falcon palette registers, like a real Falcon does.
This happens in Hatari 1.6.0 running under Windows.
I have a test program that allows you to modify selected registers of
either the STe or Falcon palette. The test program runs in TTP mode,
and modifying register 1 should immediately change the text colour from
the default black.
When run on a real Falcon or Aranym, modifying Falcon palette register 1
changes the colour; modifying STe palette register 1 has no effect. When
run on Hatari 1.6.0, the reverse is true.
All these tests are done with TOS v4?
According to "--trace videl" there are several shift register writes
even on TOS v4 boot. What are the STE and Falcon shift register values
at this point?
Aranym would seem to force use of STE palette when
either in ST-low or in ST 4 or 2 color mode:
--------------------
#define HW getHWoffset()
...
bool VIDEL::useStPalette(void)
{
bool useStPal = false;
int st_shift = handleReadW(HW + 0x60);
if (st_shift == 0) {
// bpp == 4
int hreg = handleReadW(HW + 0x82); // Too lame!
// Better way how to make out ST LOW mode wanted
if (hreg == 0x10 || hreg == 0x17 || hreg == 0x3e) {
useStPal = true;
}
} else if (st_shift == 0x100) {
// bpp == 2
useStPal = true;
} else {
// bpp == 1 // if (st_shift == 0x200)
useStPal = true;
}
return useStPal;
}
...
void VIDEL::refreshPalette(void)
{
SDL_Color palette[256];
int i, c, numColors = useStPalette() ? 16 : 256;
if (numColors == 16) {
/* STe palette registers, 4 bits/component */
--------------------
Hatari seems to be using STE palette if ST shifter mode register
is written after spshift register write, regardless of what are
the register values / selected number of bitplanes:
--------------------
void VIDEL_ST_ShiftModeWriteByte(void)
{
Uint16 line_width, video_mode;
Uint8 st_shiftMode;
st_shiftMode = IoMem_ReadByte(0xff8260);
LOG_TRACE(TRACE_VIDEL, "Videl : $ffff8260 ST Shift Mode (STSHIFT)
write: 0x%x\n", st_shiftMode);
/* Activate STE palette */
videl.bUseSTShifter = true;
...
void VIDEL_FALC_ShiftModeWriteWord(void)
{
Uint16 falc_shiftMode = IoMem_ReadWord(0xff8266);
LOG_TRACE(TRACE_VIDEL, "Videl : $ffff8266 Falcon Shift Mode
(SPSHIFT) write: 0x%02x\n", falc_shiftMode);
videl.bUseSTShifter = false;
}
...
static void VIDEL_updateColors(void)
{
//Dprintf(("ColorUpdate in progress\n"));
int i, r, g, b, colors = 1<< bpp;
#define F_COLORS(i) handleRead(VIDEL_COLOR_REGS_BEGIN + (i))
#define STE_COLORS(i) handleRead(0xff8240 + (i))
if (!videl.bUseSTShifter) {
for (i = 0; i< colors; i++) {
int offset = i<< 2;
r = F_COLORS(offset)& 0xfc;
...
} else {
for (i = 0; i< colors; i++) {
int offset = i<< 1;
r = STE_COLORS(offset)& 0x0f;
--------------------
The bitdepth checking looks like this:
--------------------
static int VIDEL_getScreenBpp(void)
{
int f_shift = handleReadW(HW + 0x66);
int st_shift = handleRead(HW + 0x60);
/* to get bpp, we must examine f_shift and st_shift.
* f_shift is valid if any of bits no. 10, 8 or 4
* is set. Priority in f_shift is: 10 ">" 8">" 4, i.e.
* if bit 10 set then bit 8 and bit 4 don't care...
* If all these bits are 0 and ST shifter is written
* after Falcon one, get display depth from st_shift
* (as for ST and STE)
*/
int bits_per_pixel;
if (f_shift& 0x400) /* Falcon: 2 colors */
bits_per_pixel = 1;
else if (f_shift& 0x100) /* Falcon: hicolor */
bits_per_pixel = 16;
else if (f_shift& 0x010) /* Falcon: 8 bitplanes */
bits_per_pixel = 8;
else if (!videl.bUseSTShifter) /* Falcon: 4 bitplanes */
bits_per_pixel = 4;
else if (st_shift == 0)
bits_per_pixel = 4;
else if (st_shift == 0x01)
bits_per_pixel = 2;
else /* if (st_shift == 0x02) */
bits_per_pixel = 1;
--------------------
Only difference to Aranym seems to be videl.bUseSTShifter
check which is missing on Aranym. I think this is the reason
why Hatari bUseSTShifter was added (not so much for ST palette
stuff), and more correct than the Aranym bitdepth check.
Aranym palette check is probably the more right one though. :-)
Is there any documentation on what exactly would be the right
behavior?
- Eero