Mainboard with the two 128 kB EPROMs containing the special MacIntosh Plus ROM image. (Credit: Pierre Dandumont)

The Lost 256 KB Japanese ROM For The Macintosh Plus Has Been Found

May 17, 2025 by Maya Posch 15 Comments

The Apple Macintosh Plus was one of the most long-lived Apple computers and saw three revisions of its 128 kB-sized ROMs during its life time, at least officially. There’s a fourth ROM, sized 256 kB, that merges the Western ROMs with Japanese fonts. This would save a user of a Western MacIntosh Plus precious start-up time & RAM when starting software using these fonts. Unfortunately, this particular ROM existed mostly as a kind of myth, until [Pierre Dandumont] uncovered one (machine-translated, French original).

The two 128 kB EPROMs containing the special MacIntosh Plus ROM image. (Credit: Pierre Dandumont)

Since this particular ROM was rumored to exist somewhere in the Japanese market, [Pierre] went hunting for Japanese Macintosh Plus mainboards, hoping to find a board with this ROM. After finally getting lucky, the next task was to dump the two 128 kB EPROMs. An interesting sidenote here is that the MacIntosh Plus’ two ROM sockets use the typical programming voltage pin (Vpp) as an extra address line, enabling 256 kB of capacity across the two sockets.

This detail probably is why this special ROM wasn’t verified before, as people tried to dump them without using that extra address line, i.e. as a typical 27C512 64 kB EPROM instead of this proprietary pinout, which would have resulted in the same 64 kB dump as from a standard ROM. Thanks to [Doc TB]’s help and his UCA device it was possible to dump the whole image, with the images available for download.

Using this ROM image was the next interesting part, as [Pierre] initially didn’t have a system to test it with, and emulators assume the 128 kB ROM format. Fortunately these are all problems that can be solved, allowing the ROM images to be validated on real hardware as well as a modified MAME build. We were informed by [Pierre] that MAME releases will soon be getting support for this ROM as well.

Voyager 1’s Primary Thrusters Revived Before DSN Command Pause

May 15, 2025 by Maya Posch 43 Comments

As with all aging bodies, clogged tubes form an increasing issue. So too with the 47-year old Voyager 1 spacecraft and its hydrazine thrusters. Over the decades silicon dioxide from an aging rubber diaphragm in the fuel tank has been depositing on the inside of fuel tubes. By switching between primary, backup and trajectory thrusters the Voyager team has been managing this issue and kept the spacecraft oriented towards Earth. Now this team has performed another amazing feat by reviving the primary thrusters that had been deemed a loss since a heater failure back in 2004.

Unlike the backup thrusters, the trajectory thrusters do not provide roll control, so reviving the primary thrusters would buy the mission a precious Plan B if the backup thrusters were to fail. Back in 2004 engineers had determined that the heater failure was likely unfixable, but over twenty years later the team was willing to give it another shot. Analyzing the original failure data indicated that a glitch in the heater control circuit was likely to blame, so they might actually still work fine.

To test this theory, the team remotely jiggled the heater controls, enabled the primary thrusters and waited for the spacecraft’s star tracker to drift off course so that the thrusters would be engaged by the onboard computer. Making this extra exciting was scheduled maintenance on the Deep Space Network coming up in a matter of weeks, which would have made troubleshooting impossible for months.

To their relief the changes appears to have worked, with the heaters clearly working again, as are the primary thrusters. With this fix in place, it seems that Voyager 1 will be with us for a while longer, even as we face the inevitable end to the amazing Voyager program.

Exposed inner copper on multilayer PCB. (Credit: mikeselectricstuff, YouTube)

LACED: Peeling Back PCB Layers With Chemical Etching And A Laser

May 15, 2025 by Maya Posch 8 Comments

Once a printed circuit board (PCB) has been assembled it’s rather hard to look inside of it, which can be problematic when you have e.g. a multilayer PCB of an (old) system that you really would like to dissect to take a look at the copper layers and other details that may be hidden inside, such as Easter eggs on inner layers. [Lorentio Brodeso]’s ‘LACED’ project offers one such method, using both chemical etching and a 5 Watt diode engraving laser to remove the soldermask, copper and FR4 fiberglass layers.

This project uses sodium hydroxide (NaOH) to dissolve the solder mask, followed by hydrogen chloride (HCl) and hydrogen peroxide (H₂O₂) to dissolve the copper in each layer. The engraving laser is used for the removing of the FR4 material. Despite the ‘LACED’ acronym standing for Laser-Controlled Etching and Delayering, the chemical method(s) and laser steps are performed independently from each other.

This makes it in a way a variation on the more traditional CNC-based method, as demonstrated by [mikeselectricstuff] (as shown in the top image) back in 2016, alongside the detailed setup video of how a multi-layer PCB was peeled back with enough resolution to make out each successive copper and fiberglass layer.

Continue reading “LACED: Peeling Back PCB Layers With Chemical Etching And A Laser” →

Turning A Chromebox Into A Proper Power-Efficient PC

May 14, 2025 by Maya Posch 20 Comments

Google’s ChromeOS and associated hardware get a lot of praise for being easy to manage and for providing affordable hardware for school and other educational settings. It’s also undeniable that their locked-down nature forms a major obstacle and provides limited reusability.

That is unless you don’t mind doing a bit of hacking. The Intel Core i3-8130U based Acer CXI3 Chromebox that the [Hardware Haven] YouTube channel got their mittens on is a perfect example.

The Acer CXI3 in all its 8th-gen Intel Core i3 glory. (Credit: Hardware Haven, YouTube)

This is a nice mini PC, with modular SODIMM RAM, an NVMe storage M.2 slot as well as a slot for the WiFi card (or SATA adapter). After resetting the Chromebox to its default configuration and wiping the previous user, it ran at just a few watts idle at the desktop. As this is just a standard x86_64 PC, the only thing holding it back from booting non-ChromeOS software is the BIOS, which is where [MrChromebox]‘s exceedingly useful replacement BIOSes for supported systems come into play, with easy to follow instructions.

Reflashing the Acer CXI3 unit was as easy as removing the write-protect screw from the mainboard, running the Firmware Utility Script from a VT2 terminal (Ctrl+Alt+F2 on boot and chronos as login) and flashing either the RW_LEGACY or UEFI ROM depending on what is supported and desired. This particular Chromebox got the full UEFI treatment, and after upgrading the NVMe SSD, Debian-based Proxmox installed without a hitch. Interestingly, idle power dropped from 2.6 watts under ChromeOS to 1.6 watts under Proxmox.

If you have a Chromebox that’s supported by [MrChromebox], it’s worth taking a poke at, with some solutions allowing you to even dualboot ChromeOS and another OS if that’s your thing.

Continue reading “Turning A Chromebox Into A Proper Power-Efficient PC” →

A Single-Pixel Camera Without Moving Parts Using Compressed Sensing

May 12, 2025 by Maya Posch 18 Comments

One of the reconstructed images, using all 4,096 matrix patterns as input, next to the original object. (Credit: okooptics, Jon Bumstead)

There’s a strange allure to single-pixel cameras due to the simultaneous simplicity and yet fascinating features that they can offer, such as no set resolution limit. That said, the typical implementations that use some kind of scanning (MEMS) mirror or similar approach suffer from various issues even when you’re photographing a perfectly stationary and static scene due to their complex mechanical nature. Yet there’s a way around this, involving a LED matrix and a single photoresistor, as covered by [Jon Bumstead] in an article with accompanying video.

As he points out, this isn’t a new concept, with research papers cited that go back many years. At the core lies the signal processing technique called compressed sensing, which is incidentally also used with computed tomography (CT) and magnetic resonance imaging (MRI) scanners. Compressed sensing enables the reconstruction of a signal from a series of samples, by using existing knowledge of the signal.

In the case of this single-pixel camera, the known information is the illumination, which is a Hadamard matrix pattern displayed on the 64 x 64 pixel LED matrix, ergo 4,096 possible patterns. A total of 4,096 samples are thus recorded, which are subsequently processed with a Matlab script. As pointed out, even 50% of the maximum possible matrices can suffice here, with appropriately chosen patterns.

While not an incredibly fast method, it is fully solid-state, can be adapted to use other wavelengths, and with some tweaking of the used components probably could cut down the sampling time required.

Continue reading “A Single-Pixel Camera Without Moving Parts Using Compressed Sensing” →

PoE-powered GPIB Adapter With Ethernet And USB-C Support

May 10, 2025 by Maya Posch 9 Comments

In the world of (expensive) lab test equipment the GPIB (general purpose interface bus) connection is hard to avoid if you want any kind of automation, but nobody likes wrangling with the bulky cables and compatibility issues when they can just use Ethernet instead. Here [Chris]’s Ethernet-GPIB adapter provides an easy solution, with both Power over Ethernet (PoE) and USB-C power options. Although commercial adapters already exist, these are rather pricey at ~$500.

Features of this adapter include a BOM total of <$50, with power provided either via PoE (802.3af) or USB-C (5V-only). The MCU is an ATmega4809 with the Ethernet side using a Wiznet W5500 SPI Ethernet controller. There is also a serial interface (provided by a CH340X USB-UART adapter), with the firmware based on the AR488 project.

The adapter supports both the VXI-11.2 and Prologix protocols, though not at the same time (due to ROM size limitations). All design documents are available via the GitHub repository, with the author also selling assembled adapters and providing support primarily via the EEVBlog forums.

The Apple II MouseCard (Credit: AppleLogic.org)

The Apple II MouseCard IRQ Is Synced To Vertical Blanking After All

May 9, 2025 by Maya Posch 5 Comments

Recently [Colin Leroy-Mira] found himself slipping into a bit of a rabbit hole while investigating why only under Apple II MAME emulation there was a lot of flickering when using the (emulated) Apple II MouseCard. This issue could not be reproduced on real (PAL or NTSC) hardware. The answer all comes down to how the card synchronizes with the system’s vertical blanking (VBL) while drawing to the screen.

The Apple II MouseCard is one of the many peripheral cards produced for the system, originally bundled with a version of MacPaint for the Apple II. While not a super popular card at the time, it nevertheless got used by other software despite this Apple system still being based around a command line interface.

According to the card’s documentation the interrupt call (IRQ) can be set to 50 or 60 Hz to match the local standard. Confusingly, certain knowledgeable people told him that the card could not be synced to the VBL as it had no knowledge of this. As covered in the article and associated MAME issue ticket, it turns out that the card is very much synced with the VBL exactly as described in The Friendly Manual, with the card’s firmware being run by the system’s CPU, which informs the card of synchronization events.