you basicly disable vgaonly vgadrawing. not only the 9 bit wide stuff.
Guess the VGA_TEXT_Xlat16_Draw_Line_9
has some endian problem and it might be better to focus on that

Do 16bpp games (svga_s3) have the same problem?

I asked rhoenie to test it:

1<Qbix> rhoenie if you happen to get on a PPC machine one of these days. Could you see if dosbox -machine vgaonly looks alright. In our forum there is report
2          of wrong colours. Feels like an endian issue if it is true
303:43PM <rhoenie> Qbix: oh .. ok.. i can check that today
403:51PM <rhoenie> Please submit a full bug report,
503:51PM <rhoenie> with preprocessed source if appropriate.
603:51PM <rhoenie> See <URL:http://developer.apple.com/bugreporter> for instructions.
703:51PM <rhoenie> make[3]: *** [ems.o] Error 1
803:51PM <rhoenie> *sigh* :-)
903:51PM <rhoenie> compiler crash
1003:52PM <rhoenie> ok.. with -O0 ems.cpp compiles fine
11<Qbix> hmm ems.cpp is not that complicated :)
1203:55PM <rhoenie> ok.. compiled the source from the URL in the topic
1303:55PM <rhoenie> works fine.. even with PowerPC G5 optimazations switched on
1403:55PM <rhoenie> no false colors or such
1503:55PM <rhoenie> (tested three games)
16<Qbix> you used dosbox -machine vgaonly 
17<Qbix> ?
18<Qbix> the screen should be wider in that case
19<Qbix> (in textmode)
2003:57PM <rhoenie> oops
2103:57PM <rhoenie> [mac-admin]:~/Sources/DOSBox/dosbox/src $ ./dosbox_dyn -machien vgaonly
2203:57PM <rhoenie> %-)
23<Qbix> :)
2404:01PM <rhoenie> http://6464.at/~rhoenie/dosbox_g5_vgaonly_1.png
2504:01PM <rhoenie> http://6464.at/~rhoenie/dosbox_g5_vgaonly_2.png
2604:01PM <rhoenie> looks good to me
2704:03PM <rhoenie> ah.. btw..
2804:03PM <rhoenie> lrwxrwxr-x   1 rhoenie  admin      23 May 27  2009 libSDL.dylib -> libSDL-1.2.0.11.2.dylib
2904:03PM <rhoenie> maybe its related to SDL? 

Looks alright to me. Which SDL version do you have installed ?

I have no 16bit games to test in DOSBox. svga_s3 (and the other svga settings) do not have these problems, only the vgaonly setting.

I have SDL 1.2.(13?) I have no problems with other SDL based apps. It works with the changes shown above.

you basicly disable vgaonly vgadrawing. not only the 9 bit wide stuff.
Guess the VGA_TEXT_Xlat16_Draw_Line_9
has some endian problem and it might be better to focus on that

Both VGA_TEXT_Xlat16_Draw_Line_9 and VGA_Draw_Xlat16_Linear_Line

?

In

1//Set entry in 16bit output lookup table
2vga.dac.xlat16[index] = ((blue>>1)&0x1f) | (((green)&0x3f)<<5) | (((red>>1)&0x1f) << 11);

in vga_dac.cpp if at all.

But I think we need to get or set the color bit order with SDL somewhere.
Dominus had reported a similar color endian issue.

it might be related to the SDL version.

But I think we need to get or set the color bit order with SDL somewhere.
Dominus had reported a similar color endian issue.

I'm game for testing anything 😀

If you have a ppc Macintosh it's easy to reproduce. Just set full screen mode, and set vgaonly. You should imediately see the text screen issues. Run any 320 256 color mode game to see the palette issue. I ran Masters of Orion.

FYI: My other issue, for some reason Masters of Orion runs faster on my 1ghz G4 laptop than on my 1.6ghz iMac G5? Noticably faster.

I can confirm this on Intel Mac OS X 10.6.2. with SDL 1.2.14 (and 1.2.x SVN)

in sdlmain.cpp
below this"

1                if (sdl.surface) {
2                        switch (sdl.surface->format->BitsPerPixel) {
3                        case 8:
4                                retFlags = GFX_CAN_8;
5                break;
6                        case 15:
7                                retFlags = GFX_CAN_15;
8                                break;
9                        case 16:
10                                retFlags = GFX_CAN_16;
11                break;
12                        case 32:
13                                retFlags = GFX_CAN_32;
14                break;
15                        }

can you add some logging that prints

1                                        sdl.surface->format->Rmask,
2                                        sdl.surface->format->Gmask,
3                                        sdl.surface->format->Bmask

you can use LOG_MSG() for that. The syntax for that one is identical to printf.

Can you be a bit more elaborate about that? Meaning you need to spell this out for me what to write exactly so it logs to log_msg. As I've probably written before, I can compile things and I can change the files and sometimes get my thinking around it, but when it comes to even the simple programming stuff, I'm lost. Even more so, with stuff like this logging which I have been explained before and forget quicker than it has been taken to explain it to me.

I can't try this right now, but I think he means something like...

1LOG_MSG("Rmask=%x,Gmask=%x,Bmask=%x\n",sdl.surface->format->Rmask, sdl.surface->format->Gmask, sdl.surface->format->Bmask);

?

yeah, I'll post a patch for it tomorrow. might throw in some more variables, but I think they changed the order or format internally in SDL

Thanks star2doc.
I have got this log:

Rmask=7c00,Gmask=3e0,Bmask=1f

Rmask=ff00,Gmask=ff0000,Bmask=ff000000

Dosbox started in fullscreen and the second Rmask is from when I switched back to windowed view, which is also falsely coloured (it's also falsely coloured when you start in windowed mode).
I'm attaching screenshots of both windowed and fullscreen mode.

the set blaster line has some blueish as well

interestingly, the oficial 0.73 release for mac which colors generally works fine for me, does have the blueish prompt in fullscreen/machine=vgaonly. The windowed mode is correctly coloured.

the official release is as far as I know staticly linked against an older version of SDL