Looks like a nice endian issue 😀

Actually looks nice, shoulda get that for little endian as well 😀

Let's call it the teardrop issue 😉

pretty cool

WOW it's like im playing a tandy THROUGH A WARPED GLASS WINDOW!

OT but you should try the Apple II versions.

These blow the PC and Tandy Music out of the water. Let me know if you want more details!

I'd be curious to know if the Apple II versions were better. I had an apple //c back in the day, and I recall the sounds being identical to the PC speaker (single channel). The IIgs versions often had better sounds, but I thought they were just using the four channel sound built in to the AGI scripts. The Tandy has the same sound hardware as the PCjr, and although I never compared directly I think the 4-channel sound I get from the Tandy emulation, e.g. Gold Rush, is similar to the sound I got on the IIgs version. Let me know if they were actually different.

Back to the point, if it is an endian issue it would be straightforward to fix, since presumably the same code already exists in the svga_s3 emulation (which reproduces the graphics correctly). On the other hand, I would have thought much more serious problems would have arisen if the chipset emulation was off in this way.

it would be straightforward to fix

Feel free to post a patch.

Sure, I'll take a look. I haven't poked around in the source before, but presumably there is a source file that handles the s3 hardware emulation, one that handles the tandy emulation, and a couple of macros/defines that determine how to handle addressing when there's a difference in the architecture (e.g. x86 on POWERPC). The endian conversion might actually be handled in the SDL, but I imagine there's probably something in the DOSBox code, too. I may be grossly oversimplifying, but it seems that this would be the minimum requirement for a program like DOSBox. I'm thinking that someone already had to solve this problem for the s3 emulation, and my plan would be to compare and see where the code was left out for the tandy video.

If any of that sounds correct, you could help me out by directing me to the code where s3/tandy emulation is handled (and the relevant define statements). Also, is there anything special to running DOSBox with a debugger? I prefer gdb/ddd, but there will be a learning curve either way, so I can learn another debugger if it's better.

Thanks in advance for any help. I can't guarantee I'll be able to make any headway, but I can at least try to contribute.

Try compiling dosbox, then enable debug symbols so you can use gdb with it.

Another thing you can easily use is LOG_MSG() (like printf) that will output strings
into the console window, so you can track what code is called.

First check what happens in VGA_SetupHandlers() (vga_memory.cpp which also
contains much of the graphics memory related functionality).

vga_draw.cpp contains the routines that transfer data from emulated memory to
the graphics surface so that's most likely where the bug lies (put some LOG_MSGs
there to check wich function is used for the game).

Feel free to post here about progress or questions.

nfitzkee wrote:

I'd be curious to know if the Apple II versions were better.

SQ1: http://www.youtube.com/watch?v=XdUfOohO8mU&feature=related

Even features digitized voice right at the start!

KQ1: http://www.youtube.com/watch?v=puof3EErVYw

The Amiga versions are also quite good for these older Sierra Games.

With machine=tandy the AGI games use the 4BPP line drawing, which looks to be working with bytes.

Have output options other than surface been tried? There is endian stuff in sdlmain.cpp, which might be a good place to investigate if the issue is limited to certain output types.

I just acquired an old iBook and the first thing I used it for was DOSBOX for OS X. Have the same "flipped" scrambling in Tandy modes. Glad I found this thread before posting. After 8 months, is there any news? This old iBook is a little slow for VGA games, but CGA and Tandy era generally run okay. The scrambling is consistent in several different games, and has not crashed anything yet.

no news. nobody debugged it as we don't have such a machine.

I could possibly come up with another old iBook like this. But I'm in central USA, and I think the Dosbox crew is in Europe? Shipping might be an issue. Send me a private message if you consider it worth doing.

does the problem happen on new portable Macintoshes too? if not i guess it is better to wait for them to die than fix something that will die soon anyway 😉

Is the GetHostWritePt mechanism endian safe for byte arrays?

I can test stuff if you need me to, I have both a PPC and Intel Mac around for testing stuff (I might need to look for the tandy KQ1, though),

Thanks for the offer, I accept 😀

Attached a patch with logging of the video memory vs output values. They are logged to the console.
Go to the screen that is depicted above and post one line.

On x86 the line looks like this:
vram 00,0f,f0,00, output 00,00,00,0f,0f,00,00,00