Daily Archives: 2023-11-26

How Apple’s developers reflashed Mac ROMs in the ’90s

Source: OSNews

Article note: What a cool find.

After I wrote about the possibility of programmable Mac ROM SIMMs in Quadras a couple of months ago, I suspected that there had been a way for developers at Apple in the 68k Mac era to reflash the ROM in their Macs during development, just like BIOS updates on PCs. The reason I believed this is because the ROM SIMM socket in the Quadras brought out pins for 12V (VPP) and write enable (/WE). I had verified that the write enable pin was going into the memory controller chip in several Mac models, so I was pretty confident that in-system programming was possible.

As luck would have it, multiple people pointed out to me that an Apple internal utility used for ROM flashing had been uploaded to the Macintosh Garden. It was recovered from a prototype PowerBook 520 purchased in 2020. Of course, I had to download this utility and figure out how it works.

I honestly cannot believe it’s taken this long for such a tool to become available one way or the other. Classic Macs are incredibly popular in the retro community, and being able to reflash the ROMs like this is incredibly useful. It took some work and disassembly, but Doug Brown got it working.

Posted in News | Leave a comment

PCSX2 Disables Wayland Support

Source: Hacker News

Article note: "Your established usecase is wrooong! Supporting it would be inconsistent with purely-theoretical future UI modes!" again from the Wayland camp. These days I basically hope we get a PipeWire to Wayland's Pulseaudio. PA was "the ultimate solution" and always horrible even though it lingered for years, but it paved the technical and social way for a good (and compatible) successor, and showed where the problem points would be so the successor actually _did_ solve the whole problem space and more. The Wayland folks have made some terrible-looking choices, largely related to getting burnt on supporting haphazard extensions forever on X... why is why the "do everything in extensions that we'll spend a decade arguing about before giving in and supporting what was initially asked for, just restricted enough to be awkward for every program that uses it forever" design was probably a bad decision. Also around the lack of a reference compositor library (but that's probably the same thing eg. xlib). Also around things like punting on input plumbing (yes, slipping into the kernel input layer with keyd virtual devices mostly works for hotkeys and remaps, but that's hacky. No, there still isn't an elegant way to pipe text to a specified window. Yes, those should be the same feature, and should be standard across compositors with one protocol.). It's possible there's going to either be an "un-blessed" rogue extension suite that allows a bunch of "unapproved" behavior but every useful compositor has to implement because so much desirable software assumes its presence, or a shim/protocol filter/interceptor thing that sits behind/between/around the compositor to do the critical stuff that has been deemed 'wrong.'
Comments
Posted in News | Leave a comment