Author Topic: whats the deal with OS9 and BW/16color modes?  (Read 139 times)

Offline goodoldmacs

  • Newcomer
  • *
  • Posts: 9
  • New Member
whats the deal with OS9 and BW/16color modes?
« on: May 18, 2024, 11:03:14 AM »
i have read conflicting information like you can enable the modes if you use particular monitors or if you replace the monitors extension with some specific older version, etc etc

it seems like one of those things though where the only reason programs wont run in higher color modes is just because the program itself is set to stop running?  like even if the system were in 256 or higher, the program would still run fine...if it wasn't closing itself down?

in all the years of mac tweaking is there no trick to either 1) get those modes available in OS9 or 2) trick the program into running anyway?

Offline joevt

  • Enthusiast Member
  • ***
  • Posts: 89
  • New Member
Re: whats the deal with OS9 and BW/16color modes?
« Reply #1 on: May 19, 2024, 06:05:29 AM »
It has nothing to do with the display and everything to do with the hardware and driver.

SheepShaver's emulated graphics device supports all color depths and resolutions in Mac OS 9.0.4.

A program shouldn't depend on a color depth unless it's using its own drawing routines.

A game that's made for the original black and white Macs, on top of requiring a black and white mode, may also require a specific resolution (512x342) and even a specific framebuffer address.

I suppose you could make an emulated framebuffer in a newer Mac and copy that buffer to the real framebuffer at 60fps (or less if that takes too much processing power). Changing the framebuffer address is probably not possible (unless you can do something tricky with virtual memory?) - it may be easier to patch the program.

Offline goodoldmacs

  • Newcomer
  • *
  • Posts: 9
  • New Member
Re: whats the deal with OS9 and BW/16color modes?
« Reply #2 on: Today at 11:13:02 AM »
 maybe i should have been more specific:

there are a fair number of games made for OS7 that won't work in OS9 on a standard GeForce MX 20, because when you try to run them they say in an error, "please set to 16 colors mode and try again"...but in the monitors panel, there's no option.

so that was the problem i was trying to understand if there is some solution.

anyway your explanation makes sense, it's just...ok so a program requires black and white mode, a specific resolution, and a framebuffer address....why is that impossible to work around after 20+ years of OS9/OS10?

also there are some programs that run in 16 colors, lower resolution, yet you can use these on OS9.  they just run in a typical finder window in the middle of the screen.

i'm sure some programs do have advanced frame codes but isn't it also possible that some are just simply programmed to get the user to switch to 16 color mode not because it is technically required but just because...no real reason?  except maybe it caused the game to run better at the time it was released?
  like for example, classic 16 color sim city has this lock, but there is nothing so advanced or particular about its graphics.

so yes the point i was making is surely someone must have figured a workaround?  either an extension that adds a framebuffer emulation like you say, or maybe a method using resedit to simply remove the check?  after all, if it simply didnt have the check run at the beginning, then tried to run the game anyway, what's the worst that could happen?  a crash and restart?  at least then there would be a chance to play it.

Offline robespierre

  • Veteran Member
  • ****
  • Posts: 132
  • malfrat des logiciels
Re: whats the deal with OS9 and BW/16color modes?
« Reply #3 on: Today at 02:14:23 PM »
Graphics APIs are complicated and there are operations that are not fully generic for efficiency reasons.

Let's say there is a program that displays graphics using QuickDraw. It sets the pen color using the 16-color QuickDraw API, then calls QuickDraw commands to display text and circles and lines etc on the screen. This program will work fine when the monitor is set to 16 colors, 256 colors, thousands, or millions. Actually, it will even work fine in black and white, although some of the graphics may be harder to read.

Now suppose that a second program, just like the first, is designed with 16-color graphics in mind. But besides what the first program does, it does something more. It calls the QuickDraw function to grab the screen as a display buffer and then writes data to that array directly (not through the pen/pattern API). Now this program really only will work if the display is in 16-color mode and the screen array is in the packed 4 bit/pixel format it expects. In any other display depth or format, the assumptions it makes will be violated. If it checks for this situation it will exit with an error like "Please set your display to 16 colors and try again", but if it does not check, it will corrupt the display with garbage. Whether or not an error message is displayed, it cannot work because its assumptions have been violated.