]Here is a mystery I hope someone can help me solve. I've been building DOSBox for years under both OSX/macOS and Windows (using both Visual Studio and MinGW), using a modified version of the source that owes a lot to helpful people on this forum. Recently I've tried using the same source code for both my OS X builds and Windows builds, and I came across this problem.
When I build under Windows, the startup screen shows the correct ANSI.SYS colors. When I built under OS X in the past (using older versions of my code), I also got the correct ANSI.SYS colors. But when I try to build my current code under OS X (macOS Sierra, actually), I get the wrong colors shown in the attached screen shot.
I can't see anything wrong with the code in shell.cpp, so it seems that something is going wrong somewhere else, perhaps in configure.ac, though I can't imagine what it might be. Here's the relevant shell.cpp code:
1 MSG_Add("SHELL_STARTUP_BEGIN", 2 "\033[44;1m\xC9\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD" 3 "\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD" 4 "\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xCD\xBB\n" 5 "\xBA \033[32mWelcome to DOSBoxWP\033[37m - " __DATE__ " \xBA\n" 6 "\xBA \xBA\n" 7#if defined (MACOSX) 8 "\xBA To toggle to and from fullscreen, use \033[31mCmd-Enter\033[37m. \xBA\n" 9 "\xBA To redraw the screen if the colors change, use \033[31mCmd-F3\033[37m. \xBA\n" 10 "\xBA To adjust the emulated CPU speed, use \033[31mCmd-F11/F12\033[37m. \xBA\n" 11 "\xBA See the About box on the main menu for other keyboard commands. \xBA\n" 12#else 13 "\xBA For supported shell commands type: \033[33mHELP\033[37m \xBA\n" 14 "\xBA To toggle between windowed and full-screen modes, use \033[31mAlt-Enter\033[37m. \xBA\n" 15 "\xBA To adjust the emulated CPU speed, use \033[31mCtrl-Alt-F11/F12\033[37m. \xBA\n" 16 "\xBA For other keys, see Keyboard help... on the system menu. \xBA\n" 17#endif
Can anyone guess what's going wrong here? I'll be very grateful for any help.
PS I use a version of my OneStopDOSBoxOSX script (all ideas by Dominus, not me) to build my code:
It certainly resembles the issue seen before with hi-color modes on Macs: NBA Live 97 on Mac
Your situation seems worse, however, with text modes affected (I doubt it's specific to ANSI colors). In any case, it's presumed to be an endianness issue. As I mentioned in the linked thread, a reversal of ARGB could account for the scrambled colors, so perhaps you can investigate the cause based on that.
Stock SVN, built in macOS Sierra with my build script (where all the intelligent bits are by Dominus, not me), doesn't have this color problem. I don't need to make any changes in the straight SVN code; I don't need to apply the patch in that post. It just works.
So: there must be something else in my modified code that's ultimately causing the ARGB problem here, and I still haven't figured out what it might be. I'll go back and check through all my changes until I figure out what did it, and will report back. Meanwhile, thank you for that exact memory of what is going wrong.
1// emendelson uncomments 2// combined 8/9-dot wide text mode 8bpp line drawing function 3static Bit8u* VGA_TEXT_Draw_Line(Bitu vidstart, Bitu line) { 4 // keep it aligned: 5 Bit8u* draw = ((Bit8u*)TempLine) + 16 - vga.draw.panning; 6 const Bit8u* vidmem = VGA_Text_Memwrap(vidstart); // pointer to chars+attribs 7 Bitu blocks = vga.draw.blocks; 8 if (vga.draw.panning) blocks++; // if the text is panned part of an 9 // additional character becomes visible 10 while (blocks--) { // for each character in the line 11 Bitu chr = *vidmem++; 12 Bitu attr = *vidmem++; 13 // the font pattern 14 Bitu font = vga.draw.font_tables[(attr >> 3)&1][(chr<<5)+line]; 15 16 Bitu background = attr >> 4; 17 // if blinking is enabled bit7 is not mapped to attributes 18 if (vga.draw.blinking) background &= ~0x8; 19 // choose foreground color if blinking not set for this cell or blink on 20 Bitu foreground = (vga.draw.blink || (!(attr&0x80)))? 21 (attr&0xf):background; 22 // underline: all foreground [freevga: 0x77, previous 0x7] 23 if (GCC_UNLIKELY(((attr&0x77) == 0x01) && 24 (vga.crtc.underline_location&0x1f)==line)) 25 background = foreground; 26 if (vga.draw.char9dot) { 27 font <<=1; // 9 pixels 28 // extend to the 9th pixel if needed 29 if ((font&0x2) && (vga.attr.mode_control&0x04) && 30 (chr>=0xc0) && (chr<=0xdf)) font |= 1; 31 for (Bitu n = 0; n < 9; n++) { 32 *draw++ = (font&0x100)? foreground:background; 33 font <<= 1; 34 } 35 } else { 36 for (Bitu n = 0; n < 8; n++) { 37 *draw++ = (font&0x80)? foreground:background; 38 font <<= 1; 39 } 40 } 41 } 42 // draw the text mode cursor if needed 43 if ((vga.draw.cursor.count&0x8) && (line >= vga.draw.cursor.sline) && 44 (line <= vga.draw.cursor.eline) && vga.draw.cursor.enabled) { 45 // the adress of the attribute that makes up the cell the cursor is in 46 Bits attr_addr = (vga.draw.cursor.address-vidstart) >> 1; 47 if (attr_addr >= 0 && attr_addr < (Bits)vga.draw.blocks) { 48 Bitu index = attr_addr * (vga.draw.char9dot? 9:8); 49 draw = (Bit8u*)(&TempLine[index]) + 16 - vga.draw.panning; 50 51 Bitu foreground = vga.tandy.draw_base[vga.draw.cursor.address+1] & 0xf; 52 for (Bitu i = 0; i < 8; i++) { 53 *draw++ = foreground; 54 } 55 } 56 } 57 return TempLine+16; 58} 59// end emendelson uncomments
If I uncomment the commented-out block, and comment out the uncommented block, then I get the right colors, but not char9.
Is there an easy fix that would give back the colors while keeping char9? As you can see, I'm deeply indebted to you for help with this years ago, and I hope I'm not asking too much by coming back for more.
PS: The colors are correct in Win32; they're wrong only in OS X/macOS. And you're right - this has nothing to do with ANSI.SYS colors; I've changed the title of the thread to reflect this.
There were other things than 9-dot characters you wanted, like 512 characters. I forget the reason(s) for using the 16-bpp drawing instead of 8-bpp, but that would appear to be a crucial point in the color issue. However, what I don't understand is why it's only an issue *now*, all these years later...
There were other things than 9-dot characters you wanted, like 512 characters. I forget the reason(s) for using the 16-bpp drawing instead of 8-bpp, but that would appear to be a crucial point in the color issue. However, what I don't understand is why it's only an issue *now*, all these years later...
Wait - after writing the rest of this message I seem to have fixed the problem, though I'm not at all sure how. I'll post details when I figure it out.
Meanwhile, to answer your question:
I should have been more clear: It's only an issue now because I decided to re-create my whole project from scratch, starting from current SVN instead of the ancient code that I was using when you provided patches for 512-characters, underline in mode mono, and char9. Since that time, SVN made changes that supported 512-characters, underline in mode mono, and much else, so I thought it would make life easier if I worked with current code. It was getting
The only thing missing from SVN was char9, and I was able to get that working (in Win32) but making the changes spelled out in my earlier message with the three blocks of code. So yesterday, I tried to see if my new code would work in OS X - and found the problem with the colors.
Well, I need to apologize (yet again) for wasting your time. The problem was that I had commented out too many lines. Instead of the third code block in my message above, I should have used this:
The problem was ignorance on my part, and the result was that you wasted time tracking down an old bug. Apologies again for that, and again a thousand thanks for all the help you've given over the years.
The machine=vgaonly setting uses 16-bpp drawing to support line-wise palette changes, so it would seem to be susceptible to the issue. Can you confirm that with a vanilla SVN build on your Mac system?
The machine=vgaonly setting uses 16-bpp drawing to support line-wise palette changes, so it would seem to be susceptible to the issue. Can you confirm that with a vanilla SVN build on your Mac system?
Yes, as you thought, the issue occurs with pure SVN. The screen shot has the details:
The attachment Screen Shot 2017-06-05 at 7.46.10 PM.png is no longer available
I'm not sure this is relevant, but the issue seems to occur only if machine=vgaonly is set in the .conf file. If it is set in the .conf file, then a change in the setting from the command line has no effect; if it is NOT set in the .conf file, then a change to machine=vgaonly does not cause the issue to occur.
PPS: As you see from the screen shot, I use config -get cpu in my tests. This is to make sure that I don't have the problem where dynamic crashes in an OS X build.
Last edited by emendelson on 2017-06-06, 12:54. Edited 1 time in total.
Thanks for checking. It makes sense that vgaonly is affected, but I don't recall that being noted about the issue before.
When changing the machine= setting at the prompt, it won't go into effect until DOSBox is restarted. In SVN you can write the changed setting and restart from the prompt with: config -writeconf -r