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

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.

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.

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?

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.

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.

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...

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?

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).