Re: [hatari-devel] Hatari display in Falcon ST high

[ Thread Index | Date Index | More Archives ]


Eero, I've read all you wrote here, and for me, this is correct.
I'm currently working on the videl, I'll check this point too.

The documentation exists (Mikro and aura docs are really interresting), but not everything
is described.

It seems to me that there are 3 different behaviour for the videl:

- Hi resolution.

Some registers are usefull in certain modes and not in others, some are working the opposite if VGA or RGB.

Some tests like the one Roger is doing are really interresting to understand better the Videl.

 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:

For me, all our code is correct here. There must be something else we haven't yet understood.

Maybe the use of st high resolution on a VGA monitor doesn't behave like the use of ST high resolution on a B/W ST screen ?

Roger, how did you do your tests on the real hardware ?



Le 20/02/2012 21:50, Eero Tamminen a écrit :

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

	- Eero

Mail converted by MHonArc 2.6.19+