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.

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.

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

Code:

screen win/800/600

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

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.

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.

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.

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.