Reverse Engineering The PROM For The SGI O2

The SGI O2 was SGI’s last-ditch attempt at a low-end MIPS-based workstation back in 1996, and correspondingly didn’t use the hottest parts of the time, nor did it offer much of an upgrade path. None of which is a concern to hobbyists who are more than happy to work around any hardware- and software limitations to e.g. install much faster CPUs. While quite a few CPU upgrades were possible with just some BGA chip reworking skills, installing the 900 MHz RM7900 would require some PROM hacking, which [mattst88] recently took a shake at.

The initial work on upgrading SGI O2 systems was done in the early 2000s, with [Joe Page] and [Ian Mapleson] running into the issue that these higher frequency MIPS CPUs required a custom IP32 PROM image, for which they figured that they’d need either SGI’s help or do some tricky reverse-engineering. Since SGI is no longer around, [mattst88] decided to take up the torch.

After downloading a 512 kB binary dump of the last version of the O2’s PROM, he set to work reverse-engineering it, starting by dissembling the file. A big part of understanding MIPS PROM code is understanding how the MIPS architecture works, including its boot process, so much of what followed was a crash-course on the subject.

With that knowledge it was much easier to properly direct the Capstone disassembler and begin the arduous process of making sense of the blob of data and code. The resulting source files now reassemble into bit-identical ROM files, which makes it likely that modifying it to support different CPUs is now possible with just a bit more work.

For those who want to play along, [mattst88] has made his ip32prom-decompiler project available on GitHub.

Thanks to [adistuder] for the tip.


Top image: Silicon Graphics 1600SW LCD display and O2 workstation. (Source: Wikimedia)

California’s Problematic Attempt To Add Age-Verification To Software

Last year California’s Digital Age Assurance Act (AB 1043) was signed into law, requiring among other things that operating system providers implement an API for age verification purposes. With the implementation date of January 1, 2027 slowly encroaching this now has people understandably agitated. So what are the requirements, and what will its impact be, as it affects not only OS developers but also application stores and developers?

The required features for OS developers include an interface at account setup during which the person indicates which of the four age brackets they fit into. This age category then has to be used by application developers and application stores to filter access to the software. Penalties for non-compliance go up to $2,500 per affected child if the cause is neglect and up to $7,500 if the violation was intentional.

As noted in the Tom’s Hardware article, CA governor Newsom issued a statement when signing the unanimously passed bill, saying that he hopes the bill gets amended due to how problematic it would be to implement and unintended effects. Of course, the bigger question is whether this change requires more than adding a few input fields and checkboxes to an OS’ account setup and an API call or two.

Continue reading “California’s Problematic Attempt To Add Age-Verification To Software”

Prevent Your Denon Receiver Turning On From Rogue Nvidia Shield CEC Requests

In theory HDMI’s CEC feature is great, as it gives HDMI devices the ability to do useful things such as turning on multiple HDMI devices with a single remote control. Of course, such a feature will inevitably feature bugs. A case in point is the Nvidia Shield which has often been reported to turn on other HDMI devices that should stay off. After getting ticked off by such issues one time too many, [Matt] decided to implement a network firewall project to prevent his receiver from getting messed with by the Shield.

The project is a Python-based network service that listens for the responsible rogue HDMI-CEC Zone 2 requests and talks with a Denon/Marantz receiver to prevent it from turning on unnecessarily. Of course, when you want these Zone 2 requests to do their thing you need to disable the script.

That said, HDMI-CEC is such a PITA that people keep running into issues like these over and over again, to the point where people are simply disabling the feature altogether. That said, Nvidia did recently release a Shield update that’s claimed to fix CEC issues, so maybe this is one CEC bug down already.

Using A Solid-State Elastocaloric Cooler To Freeze Water

Elastocaloric materials are a class of materials that exhibit a big change in temperature when exposed to mechanical stress. This could potentially make them useful as solid-state replacement for both vapor-compression refrigeration systems and Peltier coolers.

The entire assembled elastocaloric device. (Credit: Guoan Zhou, Nature, 2026)
The entire assembled elastocaloric device. (Credit: Guoan Zhou, Nature, 2026)

So far one issue has been that reaching freezing temperatures was impossible, but a recently demonstrated solution (online PDF via IEEE Spectrum) using NiTi-based shape-memory alloys addressed that issue with a final temperature of -12°C achieved within 15 minutes from room temperature.

In the paper by [Guoan Zhou] et al. the cascade cooler is described, with eight stages of each three tubular, thin-walled NiTi structures. Each of these stages is mechanically loaded by a ceramic head that provides the 900 MPa mechanical stress required to transfer thermal energy via the stages from one side to the other of the device, alternately absorbing or releasing the energy with CaCl2 as the heat-exchange fluid.

NiTi alloys are known as about the ideal type of SMA for this elastocaloric purpose, so how much further this technology can be pushed remains to be seen. For stationary refrigeration applications it might just be the ticket, but we’ll have to see as the technology is developed further.

Trying A Vibe-Coded Operating System

If you were to read the README of the Vib-OS project on GitHub, you’d see it advertised as a Unix-like OS that was written from scratch, runs on ARM64 and x86_64, and comes with a full GUI, networking and even full Doom game support. Unfortunately, what you are seeing there isn’t the beginnings of a new promising OS that might go toe to toe with the likes of Linux or Haiku, but rather a vibe-coded confabulation. Trying to actually use the OS as [tirimid] recently did sends you down a vibe-coded rabbit hole of broken code, more bugs than you can shake a bug zapper at, and most of the promised features being completely absent.

[tirimid] is one of those people who have a bit of a problem, in that they like to try out new OSes, just to see what they’re like. The fun starts with simply making the thing run at all in any virtual machine environment, as apparently the author uses MacOS and there it probably ‘runs fine’.

After this the graphical desktop does in fact load, some applications also open, but it’s not possible to create new folders in the ‘file explorer’, the function keys simply switch between wallpapers, there’s no networking or Doom support despite the promises made, there’s no Python or Nano support at all, and so on.

Clearly it’s still got the hallmarks of a functioning OS, and it’s sort of nice that you don’t need to know what you’re doing to create a sort-of-OS, but it will not appease those who feel that vibe-coding is killing Open Source software.

Continue reading “Trying A Vibe-Coded Operating System”

Creating An Ultra-Stable Lunar Clock With A Cryogenic Silicon Cavity Laser

Phase-coherent lasers are crucial for many precision tasks, including timekeeping. Here on Earth the most stable optical oscillators are used in e.g. atomic clocks and many ultra-precise scientific measurements, such as gravitational wave detection. Since these optical oscillators use cryogenic silicon cavities, it’s completely logical to take this principle and build a cryogenic silicon cavity laser on the Moon.

In the pre-print article by [Jun Ye] et al., the researchers go through the design parameters and construction details of such a device in one of the permanently shadowed regions (PSRs) of the Moon, as well as the applications for it. This would include the establishment of a very precise lunar clock, optical interferometry and various other scientific and telecommunication applications.

Although these PSRs are briefly called ‘cold’ in the paper’s abstract, this is fortunately quickly corrected, as the right term is ‘well-insulated’. These PSRs on the lunar surface never get to warm up due to the lack of an atmosphere to radiate thermal energy, and the Sun’s warm rays never pierce their darkness either. Thus, with some radiators to shed what little thermal energy the system generates and the typical three layers of thermal shielding it should stay very much cryogenic.

Add to this the natural vacuum on the lunar surface, with PSRs even escaping the solar wind’s particulates, and maintaining a cryogenic, ultra-high vacuum inside the silicon cavity should be a snap, with less noise than on Earth. Whether we’ll see this deployed to the Moon any time soon remains to be seen, but with various manned missions and even Moon colony plans in the charts, this could be just one of the many technologies to be deployed on the lunar surface over the next few decades.

Inside SKALA: How Chornobyl’s Reactor Was Actually Controlled

Entering SKALA codes during RBMK operation. (Credit: Pripyat-Film studio)
Entering SKALA codes during RBMK operation. (Credit: Pripyat-Film studio)

Running a nuclear power plant isn’t an easy task, even with the level of automation available to a 1980s Soviet RBMK reactor. In their continuing efforts to build a full-sized, functional replica of an RBMK control room as at the Chornobyl Nuclear Power Plant – retired in the early 2000s – the [Chornobyl Family] channel has now moved on to the SKALA system.

Previously we saw how they replicated the visually very striking control panel for the reactor core, with its many buttons and status lights. SKALA is essentially the industrial control system, with multiple V-3M processor racks (‘frames’), each with 20k 24-bit words of RAM. Although less powerful than a PDP-11, its task was to gather all the sensor information and process them in real-time, which was done in dedicated racks.

Output from SKALA’s DREG program were also the last messages from the doomed #4 reactor. Unfortunately an industrial control system can only do so much if its operators have opted to disable every single safety feature. By the time the accident unfolded, the hardware was unable to even keep up with the rapid changes, and not all sensor information could even be recorded on the high-speed drum printer or RTA-80 teletypes, leaving gaps in our knowledge of the accident.

Continue reading “Inside SKALA: How Chornobyl’s Reactor Was Actually Controlled”