Just for reference, which version of DOSBox are you using?

I am using the latest CVS Win 32 binary, but it is a long-standing problem, visible even before 0.63. In Ultima 1, that problem will go away but the colors in the Castle title screen picture are wrong (they should be the same as the EGA colors.)

I think the Tandy graphics and sound detection need some work... I've attempted to run the "Jumpman" disassembly project on Dosbox, and it only runs CGA as opposed to the PCjr/Tandy mode.

Likewise, "The Slugger" by MasterTronic at RetroGrade Station is a game I remember playing in Tandy color on my old tandy 1000. I also remember more sound... The Slugger freezes in Tandy mode on DosBox...

Pirates - Found on Retrograde station as well, has major tandy artifacting - Water is black, not blue. EGA works well...

Finger: You are using machine=tandy right? Just wanted to be sure.

Trebor has complained about this before:
Thexder colors incorrect since version 0.62

Hmm... I remember trying Thexder in Tandy mode using a CVS DOSBox a month or two ago and having it work fine. I'll try again and see if I remember correctly.

The game works fine, but the colours are off. This is visible on the logo screen already. The "Thexder" logo is a sickly green colour.

The corruption mentioned by GH is visible on the screen before the title that asks whether to use the joystick. Looks like a typical case of video memory not being cleared when switching to graphics mode.

Indeed. I can make out the DOSBox intro message as a corruption artifact on the joystick screenshot.

I found the cause for the palette bug. Thexder sets up the palette using a BIOS call: Int 0x10, AX=0x1002.

DOSBox (in int10_pal.cpp, function "INT10_SetAllPaletteRegisters"), handles this by writing to its internal port VGAREG_ACTL_ADDRESS/WRITE_DATA (port 0x3C0). Since DOSBox 0.61, however, the handler for this port was disabled if the machine-type is anything other than MCH_VGA (function "VGA_SetupAttr" in vga_attr.cpp). This causes the requested palette changes to be ignored.

Quick and dirty fix: Disabling the check for the machine type allows the palette change to go through and fixes Thexder and possibly other games as well.

The proper fix for this, though, should not be to change the working of an internal port for this. Best way is propably to reimplement the INT10 functions not to work the ports, but set the palette directly through VGA_ATTR_SetPalette.

HunterZ wrote:

Finger: You are using machine=tandy right? Just wanted to be sure.

Correct. Otherwise these games force EGA mode. Just thought I'd point out more games in the thread, in case they were related errors...

I changed VGA_SetupAttr() in vga_attr.cpp to work for MCH_VGA || MCH_TANDY, and now the in-game colors are correct but the joystick screen is still corrupted:

Yes, the screen not getting cleared is unrelated to the palette problem.

In the function "FinishSetMode" in int10_modes.cpp, the video memory is cleared through a switch/case block. This doesn't have a case for M_TANDY16, though. I think this should be a case falling through to the M_CGA4 and M_CGA2 cases. So, simply add "case M_TANDY16:" immediately after the line "case M_CGA2".

did you guys check it against the cvs or the 0.63 source ?
as i recall some work was done on that set_pallet.

Qbix: Latest CVS. I'm obsessed with using the latest everything 😀

Qbix: I used the 0.63 codebase for debugging. Checked the game with 0.61, 0.63 and CVS.

The glitches are due to text mode memory overlapping with video memory;
I think the mode switch on the tandy does both Clear & Change mode
(where-as on VGA, there is a distinction between Change Mode and Clear&ChangeMode, eg AX=13, int 10h.)

Could be modeX tweaks sneaking back in, or could also be some "text" floating in the video buffer .. I will try do a bounds check this weekend;
find out which buffer is overlapping.

Notice my post a few posts above: the FinishSetMode function, which clears the screen, does not have a provision for M_TANDY16. It is told to clear the screen, but doesn't know how.

I don't think it's necessarily a text-vs-graphics mode thing, but rather a general need to clear on mode-switch thing. You can see from the screenshots in this thread that both text-to-graphics and graphics-to-graphics (or is it text-to-text and text-to-graphics?) switching results in corruption.

Attached is a patch to fix these problems. I've rerouted the INT10 calls to the appropriate ports for Tandy.

Something weird I came across: In DOSBox, the Tandy Video Gate Array ports are 0x3DA=address, 0x3DE=data. This is confirmed by my disassembly of the Tandy ROM. On the IBM PCjr, however, of which the Tandy 1000 was supposed to be a clone, 0x3DA serves as a flipflop address/data port and 0x3DE is not mentioned anywhere (in the IBM PCjr Technical Reference). Rather a surprising difference.