VOGONS


First post, by Amdahl

User metadata
Rank Newbie
Rank
Newbie

Hello,

I have compiled Dosbox 0.70, 0.71, and now 0.72 on Solaris 9 SPARC.

I have a compiled executable by disabling opengl, but in all three versions the keyboard is mapped very strangely. I have figured out how to type EXIT and press enter.

I am pretty sure the problem is in Dosbox, since the SDL test apps register the correct keys.

Since 0.72 noted corrections in keymapping, I thought I should mention the problem here, since perhaps someone knows exactly where to look. Could it be a dosbox.rc problem?

In case anyone wants to know, I have tried compiling with various GCC, Sun C, and even a Sun GCC. All seem to exhibit the same problem if they complete compilation.(I can't recall if all actually managed to compile; I think some may not.) I am typically compiling with Sun C/SunStudio11.

Thanks!

Reply 1 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

usescancodes=false, or hack out that code in sdlmain.cpp

Reply 2 of 9, by Amdahl

User metadata
Rank Newbie
Rank
Newbie

Hello,

Finally was able to do this. The keyboard now works.

When compiled with Sun C, MOUNT has no effect. The drive letter mapped will not exist after MOUNT is run.

When compiled with Sun's edition of GCC for Solaris 9, the MOUNT command has effect, and you can switch to the new drive. But the contents of the drive will be empty, no matter what was mounted.

Any ideas what is causing this? Clearly something to do with compiler, such as structure sizes or alignment?
---- UPDATE
Compiled with a generic GCC 3.3.2. Was able to mount and access non-NFS directories. I tried running a Sierra game, and got a Bus error. Turned off MIDI, same thing.

Reply 3 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Think there was a similar report on the sourceforge page, but that guy never
reported back if he fixed it/could get more information about it.

You could try placing a bunch of logging commands into the respective files
to see if the drives are created during mounting (see dos_programs.cpp,
there's the MOUNT command implemented). Logging is something like
LOG_MSG("This is d: %x",d);
And/or go through the code with a debugger.

Reply 4 of 9, by Amdahl

User metadata
Rank Newbie
Rank
Newbie

I recompiled with --enable-debug, but that crashed very early, on scrollok() in debug_gui.cpp.. I had to comment out resizeterm due to undefined in debug_gui.cpp. Don't know why that wouldn't compile.
No good on the debug version.

Instead, I just added -gdwarf-2 (-g not supported by Sun dbx debugger) to compiler flags.

After running SIERRA, I got my core dump and loaded into dbx.

invalid address alignment
Current function is VGA_UnchinaedVGA_Handler::writeHandler
399 pixels.d=((Bit32u*)vga.mem.linear)[addr];
in vga_memory.cpp

420 writeHandler()
...
InitPageHandler::writew line 182 mem_writew()

DoString line 86 SaveMw()

CPU_Core_Normal_Run line 636 DoString(R_STOSW);break;

selected regs:
pc 0x0024e0d8:writeHandler+0x40 ld [%o5+%g1], %g1
npc 0x0024e0dc:writeHandler+0x44 st %g1, [%fp-28]
%fp = ?
%g1 = 0x01679587
%o5 = 0x0

dump of local vars:
this = 0x187c67c
data = 0
addr = 0
pixels=UNION
val = '\0'

print pixels:
pixels = {
d=4276384262U
b= 32-bits of junk??
}

print &vga = 0x1668078

The configure script shows unaligned memory access is no. But it would appear that the vga.mem.linear buffer is not aligned, even though vga is? The flags to g++ appear to be:
-gdwarf-2 -MT -MD -MP -MF ".deps/vga.Tpo" -c

Perhaps you have a suggestion on a compiler switch to try, or a pragma to add to the vga.h? I also wonder, if perhaps the source of all the 'problems' across compilers are different alignment decisions, and perhaps greater annotation will be needed in the source code or just one flag will do?

Reply 5 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Is the processor picky about alignment of 32bit memory accesses? If so,
there are some issues with the unchained handlers. Best thing you could
try is specifying some compile flag to align all structures to 4 byte boundaries
or even more. Might or might not fix this very issue.

Reply 6 of 9, by Amdahl

User metadata
Rank Newbie
Rank
Newbie

Yes, I'm pretty sure gcc can align on 4 byte or even 16 or 32 byte boundaries. Will it cause any problems with the emulation of IO registers and so on?

In any case, I'll give it a try at 4-byte, since I think that is all SPARC requires.

Reply 7 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Will it cause any problems with the emulation of IO registers and so on?

Wouldn't know why it should.
The only thing you can test by changing the alignment is whether the
vga.mem.linear should be dword aligned or not. If it still doesn't work,
some of the handlers have a problem...

Reply 8 of 9, by Amdahl

User metadata
Rank Newbie
Rank
Newbie

Unfortunately, gcc doesn't appear to have any alignment flag for structs. I tried -falign-labels.

Sun C has -dalign, which I tried, but I was hit by the mount failure problem again.

So, does anyone know how to align structs on gcc with either pragmas or compiler directives? Or compiler switches?

Or any ideas what might be going wrong with mount, and then I could switch back to Sun C?

Reply 9 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I've aligned the vga memory, try a cvs checkout.

About the sun compiler (which might be interesting to get working,
yet could be a lot of work): start at dos_programs.cpp, class MOUNT,
checking especially code that's #ifdef'd (the else parts usually being
for gcc).