E-Maculation

I reviewed how BII set color depth in SDL. It doesn't use preference file color depth at all.

eg, win/[height]/[width]/[color depth bit]

This weekend I added new prefs displaycolordepth in my experimental branch https://github.com/rickyzhang82/macemu/tree/video-debug

Now I can play Lemmings in 256 color. Since this is hack, I don't think I will send a pull request.

To use this, add
cat ~/.basilisk_ii_prefs
displaycolordepth 8
...

Compile BII with macemu/BasiliskII/src/Unix/build.sh in my experimental branch

I took it back. I sent my pull request. It works like a charm in SDL.

It was merged to upstream macemu repo.

To specific customized color depth, you need to build BII with SDL 1.2

Add the parameter below to your pref file manually. I know nothing about gtk gui. So we have to add this manually.

displaycolordepth [bit of color depth]

If 0, use default color depth, which is maximum setting in your host.

If 8, then it is 2^8 = 256 color.

Hmm... any chance we can get Win/OSX builds with this compiled in? I don't have my GCC toolchain set up anymore and BII won't compile under LLVM

I've found that BII has serious performance issues above thousands of colors when you set large screen dimensions. Haven't tracked down the issue yet, but being able to manually set the color depth would fix the problem

I am a little puzzled by this discussion. Color depth (at least in BasiliskII for OSX) can be set in Monitors control panel in MacOS. With later System/MacOS versions (from 7.5.x?) the choice is even remembered between subsequent BasiliskII launches.

I can compile BII under El Captain with llvm from XCode. You need to disable JIT and not using slirp.

But you do need SDL 1.2. You can get it from macport.

For System 7.0 and 7.1, setting the display depth in Monitors in BII only persists while the emulator is running. You can reboot, etc. while switching to thousands of colors, and it persists. But once I quit the emulator and start it back up, I'm back to millions of colors, as you've noted.

The problem is that it takes a full 10 seconds for each screen redraw when under millions of colors, so it's almost impossible to open Monitors and change the depth -- takes longer than most of the stuff I'd be doing in the guest OS once that happened. This slowness starts the minute the ROM loads, so it takes a LONG time before I get to the Monitors CP, even before attempting to get my mouse onto it to launch it.

It's odd, because I have no mouse issues at all under SheepShaver, and I never used to have any under BII. But on modern hardware at large screen sizes... it's completely unusable. None of the other Mac emulators have this issue; even the slow ones have better mouse response at thousands of colors; at millions, well, I'd be better to create my own flipbook of images (it would take me less time to draw to the screen myself).

Ricky's changes seem to at least alleviate the problem, because I can get it to boot in thousands of colors, changing boot times from 10 minutes to 10 seconds. But there's somethingn else going on here too, since most of the underlying code is shared with SheepShaver, which has no issues.

Ricky, good to know about the ability to compile; my host is probably fast enough to disable JIT; I guess I'll have to forego slirp for tun/tap. Maybe what we really need to do is what was discussed ages ago on here: migrate BII from SDL 1.2 to 2.0... that would probably fix most of the issues.

I'm using 7.6. I don't see Monitor control panel with color depth change in my guest OS.

In terms of drawing performance, I don't see any issues you mentioned under Fedora 24 host, El Captain host and Tiger host either. Even I use full screen in 1920 x 1080 or 1024 x 768, it boot less than 5 seconds in millions color.

But all 3 tests is done from latest compilation in github with recent dependency library either from Fedora 24 or macport. My Linux host is i7 2600k , El Captain is iMac i5 (not sure CPU) and Tiger is the laste PPC version of iBook G4.

I'd love to change JIT and port TCG from QEMU. Binding a particular compiler doesn't seem a good approach. But I haven't started to read JIT part. The technical manual documentation is not details enough. If you know some of them, we can discuss it online.

rickyzhang wrote:I'm using 7.6. I don't see Monitor control panel with color depth change in my guest OS.

The control panel may look different or may have a different name (Monitors & Sound), but it is always there. If it does not appear with the control panels, see in the Extensions Manager if happens to be disabled.

adespoton wrote:The problem is that it takes a full 10 seconds for each screen redraw when under millions of colors, so it's almost impossible to open Monitors and change the depth -- takes longer than most of the stuff I'd be doing in the guest OS once that happened. This slowness starts the minute the ROM loads, so it takes a LONG time before I get to the Monitors CP, even before attempting to get my mouse onto it to launch it.

Is this in OSX? If so, which BasiliskII build do you use? I do not experience that delay or slow redraw in BasiliskII running System 7.0.1. Even with millions of colors it seems fairly responsive.

Due to the better documentation, I've actually been considering putting time into improving the m68k module in qemu to boot 68k Macs and do away with BII altogether in my collection. In the meantime, Mini vMac II has got to the point where it is superior to BII in almost every way (no shared folder, but can live-swap images that can be mounted on the host, and no Ethernet, but has Localtalk).

I'm using the 2014 build on here; the issue doesn't show itself when I'm in 800x600 mode, but starts to appear when I get up to 1080, and at 1200, it's unusable. Oddly, at 1680x1050, the problem is gone, and the mouse is just a bit laggy. Maybe it has to do with odd screen ratios.

That said, try the same resolutions in Mini vMac, and notice the difference; it's night and day, even on the "fast" BII resolutions.

I see, I never tried System 7 with screen sizes larger than 1024/768.

IMHO, it is way more work to emulate m68k Mac in QEMU. This port work is missing in current QEMU:

• port mac rom

• port mac emulated hardware: scsi, timer, serial, video, ethernet and etc

It is a daunting task to port features from BII to QEMU. But the upside is that you get patch and update from QEMU community.

Updating BII is relatively less work. What BII is not quite working now:

• a portable JIT without object file hack and compiler constraint

• a portable and easy-to-use emulated network.

For JIT, I'm still researching. I believe the current JIT in BII is port from QEMU old emulation method (I may be wrong about this). TBH, most modern machines are fast enough that I can't tell the difference w/wo JIT. It is not necessary to enable JIT. But to me it is a fun project to figure it out how JIT works in BII.

In terms of portable emulated network, BII has provided way and way too many networking options without proper documentation. Some like tun/tap are difficult to set it up and some like slirp are broken in 64bit. I tried my best to patch and fix sheep_net module for latest Linux and document it. It works more stable and better than it used to be. However, sheep_net is bound to Linux. Personally, I prefer Linux as development platform. So I haven't gone that far to find a better solution for networking.

I believe the current JIT in BII is port from QEMU old emulation method

That is correct, but as you know Qemu moved to TCG. The assembly used in the 32 bit Basilisk jit version is not 64 bit compatible.

Best,
Cat_7

I will work on ditching old JIT in BII.

But it is better to have someone who is interested in and share experiences. It is difficult to find a right place. BII dev mailing list is quite and I heard no response from macemu github either.

Hey rickyzhang, thank you for this!

Prince of Persia is another game that requires an 8-bit display (pop-up) and with your modification the game runs like a charm.
In the past I had to either modify X itself to run in 8-bit mode or I had to use VNC to get an 8-bit display.

Again, nice work, thanks.

rickyzhang wrote:I will work on ditching old JIT in BII.

But it is better to have someone who is interested in and share experiences. It is difficult to find a right place. BII dev mailing list is quite and I heard no response from macemu github either.

Not sure how much time I'll have to spend on moving BII to TCG, but I'll be around to bounce ideas off of.

Something I'd like to see is the opposite: embed the BII hardware profile into qemu, so we get a 68k Mac emulator in it, and working sound and network support across 68k and PPC.... one can dream.

Adding the shared folder idea across all platforms would be nice too.

I agree that merging BII to QEMU is better in long term if some one in QEMU team keeps it up with their changes. But as I said, it will requires more work to merge it in this direction in short term.

Currently, there are several things broken in BII under modern Mac. Besides JIT, there are 32bit slirp and incompatible Cocoa Pref UI. I put JIT in high priority just because of my personal interest and also I have work around for networking and UI. But in reality JIT is not that important any more. All my boxes are fast enough to emulate it even without JIT.

It really takes time for me to figure out how JIT work in BII. I move BII source code into my personal LXR website ( a cross reference websites like this: http://lxr.free-electrons.com/source/). I can read the source code on my iPad safari whenever I have free time. I believe as time move on I may lose interest. It is highly probable I will do nothing.