About BasiliskII, a 68k Mac emulator for Windows, MacOSX, and Linux that can run System 7.x through MacOS 8.1.
Thu May 05, 2016 8:31 pm
First time posting (hello!) and had a question regarding how to fix a black screen when colors are set to 256. Switched to 256 before with no problems, but for some reason it doesn't seem to like it now. Can't see anything but the system is still running. Trying, unsuccessfully, to switch back in the darkness.
Running latest version of Basilisk II on a 2.6 GHz Intel Core i7 Macbook Pro with OS X 10.8.5
Any help? Similar issues? Or even a way to set the colors back so that I can see again? Thank you!
Thu May 05, 2016 9:16 pm
I presume you mean 256 colors within your guest OS (which verion?) and not OS X, which won't go that low?
You can set the colors back by changing the bit depth in your BII prefs and rebooting. You *may* have to also delete the xpram file.
Thu May 05, 2016 10:58 pm
Yeah trying to set colors back from 256 to millions in the guest OS, which is the latest System 7.
No luck with changing display settings to "screen win/1440/900/1" in the prefs file. I tried "16", "18", and "32" and no luck with those bits per pixel either.
I don't know if this is significant, but I can see the startup screen. It's only once extensions are loaded that I'm in darkness. Is there a way to boot without extensions in Basilisk?
Fri May 06, 2016 12:09 am
By "latest system 7" do you mean 7.6.1, or 7.5.3?
To boot without extensions in BII, you need to hold down the shift key at just the right moment. It's probably worth installing Conflict Catcher or Extensions Manager as well, so you can attempt to disable the appropriate extension that way, if the problem is an extension.
Fri May 06, 2016 12:23 am
I believe 7.5.5. The rom isn't very helpful in guessing, as it's named quadra650.rom
Can't seem to time holding SHIFT down properly. Or, if I am, booting without extensions isn't making a difference.
Deleting the xpram didn't do anything either..
Fri May 06, 2016 9:13 am
Setting the colors to 256 in Monitors control panel in MacOS in BasiliskII should work fine. I don't know if initial color depth can be set in the prefs file for BasiliskII for OSX, I never tried that. I don't know what happened in your case.
For startup with extensions off, the shift key needs to be pressed (and then held) in the split second between BasiliskII window opens and extensions start loading. Next to impossible to hit the right moment.
- Which BasiliskII build do you use?
- What happens if you set the line in prefs file to a standard value like
- Did you try to use the GUI application to configure the settings?
If you have a backup of the HD image file that you use in BasiliskII from before the problem started, then replacing the current file with a copy of the backup will be the easiest solution.
Fri May 06, 2016 8:46 pm
Mr. Ronald R! You are the lucky winner. It turns out setting my screen settings from "screen win/1440/900" to "screen win/800/600" was the (sort of) solution.
For some reason, I can set the window size all the way up to 1439/899 but when I go back to 1440/900 it goes black again. What's up with that?
Also, if it's so hard to boot without extensions, maybe that's an issue that should be addressed in later versions. I use the latest build of Basilisk II, 3/1/2014.
Fri May 06, 2016 10:18 pm
Ah; I should have twigged to that. Certain ROMs have max resolution settings. I was dealing with this just last week when attempting to set some ROM window dimensions to 1280x720.
Sat May 07, 2016 4:46 am
I've had it running at 1440/800 resolution for a few weeks until recently when I had this problem. I've been playing a game that runs at 256 colors, so whenever it starts up it'd say "Switch from millions to 256 colors?". Occasionally, when I clicked 'OK' to switch from millions to 256 at the game startup the screen would go black and then crash after a few seconds.
Eventually I figured, "Hey, I'll just go to my Monitors control panel and change it to 256 colors so I don't have to bother changing it every time." When I clicked 256, the screen went black and stayed black without crashing. I realized the system was running fine, but now it was all black.
Anyway, glad it works now.
Sun May 08, 2016 8:42 pm
Possibly it has something to do with how the ROM allocates memory for video RAM; could be a related bug in BII, or just that the original hardware couldn't handle that.
Thu Jun 02, 2016 11:36 pm
adespoton wrote:Possibly it has something to do with how the ROM allocates memory for video RAM; could be a related bug in BII, or just that the original hardware couldn't handle that.
The ROMs supported by Basilisk II always expect the allocation to be in hardware (VRAM). (Only the earliest ROMs allocated this memory in RAM, considering the already high hardware costs at the time.) I'm not sure if any of the 32-bit ROMs had any leftover code to manually allocate the buffer. If there is, this could explain whole black screen problem: bypassing B2's allocation, drawing to a redundant buffer not seen by the emulator.
Basilisk II/SheepShaver bypass the ROM to allocate the video memory itself, and really all in one large block: RAM, ROM, VRAM. The emulator may face a few unhandled problems when attempting to resize the buffer; it easily crashes on my Windows system during restart. So if, say, the native ROM code tries to refresh the video base to the expected hardware VRAM, the emulator would be reading from high addresses that don't exist; B2 will crash if illegal reads aren't handled. (Build 142 traps illegal reads, and would run slower— one solid “blank” color, presumably white in 256 colors or lower.)
The technical limits for video are much higher than 1440x900, so that's not really an issue (besides ROM video drivers supposedly throwing a fit, trying to match the resolutions or whatever). For Millions (32bpp), the maximum width is 4,095 due to QuickDraw's use of the row size number to store two flag bits, effectively clipping the maximum size of a row to 16383 bytes.
High resolutions in earlier days were expected to be done in page/portrait format— larger vertical resolutions, useful for page editing/printing jobs. Some of the other limits, such as Handle size (8MB total) only apply to offscreen buffering not onscreen buffering.
The ROM video drivers of course never expected the high resolutions supported by the iMac. Very few video cards for 68K releases even supported Millions of colors. The Performa 636's (the one I have) video card with 1MB of VRAM would never leave 640x480 no matter the monitor connected, and never supported Millions.
Thu Jun 02, 2016 11:51 pm
That about sums it up
Back in the day, I hardware modified my Color Classic to run 640x480 in Thousands of colors by replacing the VRAM and rerouting a trace on the board. I think the Classic may have been the last hardware that allocated video RAM in main RAM storage; after that, the ROMs were just referencing the VRAM address. For the purposes of BII, this is the way it would be done.
Interesting to compare this to the drawing in Mini vMac, where Paul was able to patch the Quickdraw routines easily since all the supported ROMs just allocated a section of RAM, and so that could be easily patched to a larger allocated block elsewhere.
However, the BII black screen seems to be specifically a Windows issue; I haven't seen it show up on other platforms, other than from a corrupt PRAM file. So that might narrow down the code to examine to isolate and potentially fix the issue.
Fri Jun 03, 2016 8:01 am
Is the black screen issue back? It was fixed here:viewtopic.php?f=6&t=6128&p=44856#p44856
Tue Jun 14, 2016 7:45 am
Yes, dougg3 made it clear that the ordering of addressing is critical (RAM before ROM). His submission fixed the black-screen-on-startup issue with Windows builds.
This video problem is different. I know of nothing that would cause the emulator to change screen mode (resolution/depth) during startup sequence. I could be wrong. But the resolution and depth settings are specific to this.
As far as I see it, this problem more likely has to do with how Mac OS 10.x deals with indexed mode graphics (256 colors or lower). The native video accelerator(s) may have trouble with the settings.
Looking at the source code (video_macosx.mm - Dec 21, 2014), I see that the emulator doesn't expect widths higher than 1280. Also, CGBytesPerRow() comes up with a rowsize because “Under 10.1, CGDisplayAvailableModes() does not provide bytes per row.” I'm not sure if the limitations in this area actually promote the problem in this topic, but I'd probably limit the width to as low as 1024 (a power of two) to avoid video failure for 256 colors or lower.
Tue Jun 14, 2016 5:12 pm
That lines up with what I remember; also, software that requires 256 colours or less is probably expecting a screen resolution of, at most, 1024x768 (more likely 640x480 max).
Tue Aug 16, 2016 4:34 pm
I have pull request for that in github https://github.com/cebix/macemu/pull/92
If you use SDL, It works for any resolution in 8bit color depth under Mac and Linux.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.