256 Colors on Linux

[bfinoradin]

I am compiling Mini vMac for (x)Ubuntu 14.04.2 LTS, which is running in vmware.

Whenever I introduce the -depth flag in the options (with the goal of 256 colors / "-depth 4") it compiles fine, but the display is all garbled... see image:



What am I missing?

[adespoton]

I am compiling Mini vMac for (x)Ubuntu 14.04.2 LTS, which is running in vmware.

Whenever I introduce the -depth flag in the options (with the goal of 256 colors / "-depth 4") it compiles fine, but the display is all garbled... see image:



What am I missing?

The first thing you're missing is making the image publicly viewable on dropbox

Once we see what you mean by "all garbled" I might have further suggestions. Meanwhile,

What guest OS are you attempting to run? What ROM image are you using? Are you doing a MacII compile?

[bfinoradin]

Fixed image.

Here are my options:
-t lx64
-m II
-hres 640
-vres 480
-depth 4
-fullscreen 1
-magnify 1
-sound 1
-drives 16
-emm 0
-ta 2
-mem 8M

Guest OS is System 7.0.1

Using Mac II ROM

[adespoton]

Hmm... that doesn't appear to line up with your screenshot. For some reason it's running in windowed mode.

You might want to try via http://www.gryphel.com/c/var/index.html

Or, download a variation like http://www.gryphel.com/d/var/latest/c/m ... 86.bin.tgz and see if that works.

[edit] Hmm; the screen size doesn't really line up with a Mac IIcx either; 800x600 would make more sense.

[bfinoradin]

Hmm... that doesn't appear to line up with your screenshot. For some reason it's running in windowed mode.

Yes, I exited fullscreen to take the screenshot. Fullscreen option alone only sets the mode it starts in – it's still a toggle.

[edit] Hmm; the screen size doesn't really line up with a Mac IIcx either; 800x600 would make more sense.

But unrelated to the issue at hand, no?

[adespoton]

Hmm... that doesn't appear to line up with your screenshot. For some reason it's running in windowed mode.

Yes, I exited fullscreen to take the screenshot. Fullscreen option alone only sets the mode it starts in – it's still a toggle.

[edit] Hmm; the screen size doesn't really line up with a Mac IIcx either; 800x600 would make more sense.

But unrelated to the issue at hand, no?

Ah; that explains the fullscreen bit.

The screen resolution is purely looking at potential problem points; as I think gryphel was able to separate screen depth/resolution from the actual ROM display handling, it's probably not the issue, but it's always worth testing. In situations like this, I usually do a few builds only adjusting one variable each time to isolate where the actual issue is.

[bfinoradin]

I tried out "Variation mnvm3677-3.3.3" which is a 64 bit linux build, with a depth of 5, and it runs fine but when I change to "millions" it crashes…

[bfinoradin]

Oh, and to be clear I've tried compiling with no options other than target, mac II, and depth. Same result.

[adespoton]

Can you display 256 colors natively on your Linux build? If yes, this seems like a bug and needs to be filed with gryphel.

[gryphel]

I haven't been able to recreate this problem. I downloaded 14.04.2 LTS for x64, installed it in VMware Fusion 6.0.3, ran "Software Updater", and installed VMware tools. Then I tried mnvm3677-3.3.3 and made a fresh install of Mac System 7.0.1 with default options, and it worked normally. I also compiled a version of Mini vMac in 14.04 with the options you listed, and it also worked normally.

What version of VMware are you using (and for what host operating system)? That could be one possible difference.

Have you tried using your same Mac System 7.0.1 image in Mini vMac compiled for a different target, either outside VMware, or in a different VM?

When you say "it crashes", when using mnvm3677-3.3.3, do you mean that Mini vMac crashes, or that the emulated Macintosh crashes (but Mini vMac is still working, i.e the Mini vMac window is still there, and the Mini vMac control mode still works)?

For the version you compiled, you say the display is garbled. Is Mini vMac otherwise working normally, such as does Control-Q-Y quit the emulator? Does the Mini vMac control mode display normally, or is it garbled too?

If you launch Mini vMac from the command line, is any debug text written out to the terminal?

[bfinoradin]

What version of VMware are you using (and for what host operating system)? That could be one possible difference.

I'm not sure actually – I'll enquire with our IT dept and find out. I should mention that I'm remotely accessing the Xubuntu host in a web browser through Guacamole.

Have you tried using your same Mac System 7.0.1 image in Mini vMac compiled for a different target, either outside VMware, or in a different VM?

Yep – it works totally fine in a Mac OS X build and I can get 256 colors no problem.

I also tried a fresh 7.1 install in the Linux host and it has the exact some problems.

When you say "it crashes", when using mnvm3677-3.3.3, do you mean that Mini vMac crashes, or that the emulated Macintosh crashes (but Mini vMac is still working, i.e the Mini vMac window is still there, and the Mini vMac control mode still works)?

I mean that Mini vMac crashes - the process terminates.

For the version you compiled, you say the display is garbled. Is Mini vMac otherwise working normally, such as does Control-Q-Y quit the emulator? Does the Mini vMac control mode display normally, or is it garbled too?

The controls work, but the vMac control mode display is also part of the garbled graphics.

If you launch Mini vMac from the command line, is any debug text written out to the terminal?

No - but maybe I'm doing it wrong. Does it accept flags for verbose output or something?

[gryphel]

I should mention that I'm remotely accessing the Xubuntu host in a web browser through Guacamole.

Oh. That is an unusual configuration. I'm more surprised it works in black and white than that it doesn't work in color.

I mean that Mini vMac crashes - the process terminates.

My guess is that Mini vMac is crashing because the default behavior of xlib is to terminate the application on error, and Mini vMac doesn't override that default.

One possible thing you could try is to compile Mini vMac with SDL (using "-api sdl" in the build system). If that works, it would be some evidence of a bug in the X11 port of Mini vMac, which doesn't show up in more normal circumstances, instead of a bug in Guacamole, Xubuntu, or VMware, etc.

[bfinoradin]

Trying SDL option – but I am confused as to where this goes… in the options list along with -t, -m, -depth, and so on, or is it a flag for gcc at compile time? I keep getting errors on both ends…

[gryphel]

Trying SDL option – but I am confused as to where this goes… in the options list along with -t, -m, -depth, and so on, or is it a flag for gcc at compile time?

It is an option for the build sytem, like -t, -m, -depth, and so on.

I keep getting errors on both ends…

You will need to install SDL 1.2 development stuff. (Not the more recent and incompatible SDL 2.) How to do that could depend. Google turns up some things:

http://stackoverflow.com/questions/1432 ... 2-04-1-lts
http://www.upubuntu.com/2012/01/how-to- ... imple.html
http://askubuntu.com/questions/344512/w ... -in-ubuntu

[bfinoradin]

The good news: it turns out I was building from 3.2 not 3.3 I can compile with SDL using 3.3.3 SRC, and now get full color!

The bad news: there are two bugs that have shown up…

1) although I am building with "-emm 0" it seems to not be disabling the "accurate" mouse emulation. Mouse gets weird in fullscreen.
2) A piece of software that was working previously now crashes with an error every time I try to open it…

[bfinoradin]

Also, the colors seem to be a bit off…



Versus how they should be…

[adespoton]

That last bit is likely an SDL issue; I'm not sure what the fix would be though. Possibly something has its endianness backwards?