M1 Development Board From Scraps

Apple is fairly notorious for building devices that are difficult to repair, but with the right tools it’s often not completely impossible to circumvent some of their barriers. As they say, every lock has a key. [dosdude1] has wanted a specific M1 development board for a while now and has been slowly piecing together everything he needs to cobble one together, and finally got this unit running despite many roadblocks put in his way by Apple.

The development kit is a Developer Transition Kit  or “DTK” meant for developers during Apple’s transition from Intel chips to their own in-house ARM-based M1 platform. This particular version is in a Mac Mini form factor but it has a few hurdles to clear before it powers on. First, the board was cut in a critical location that shorted out many of the PCB layers, so this had to be carefully filed down to remove the shorts. It was also missing a few tiny surface mount components and a NAND chip, but these were scavenged from other scrapped parts and assembled into a fully working machine.

There are a number of other non-physical problems to solve here as well, too. Apple coded their NAND chips to work with specific WiFi modules so if these aren’t programmed to work together the computer will get stuck in a boot loop. But with that and a few other details out of the way [dosdude1] finally has his DTK up and running in a 2018 Mac Mini chassis, right down to the working power LEDs. We’ve seen all kinds of PCB damage before (although not often quite this intricate) and even PCBs repaired that were snapped in half.

Thanks to [CodeAsm] for the tip!

Continue reading “M1 Development Board From Scraps”

Reverse Engineering The Apple Touch Bar Screen

The Apple Touch Bar was an oddity on a fairly small number of Apple laptops which replaced the function key row with a touch display. Yet what is special about this display other than its odd form factor when you consider it as a generic touch display? As [Wenting Zhang] describes in a recent reverse-engineering video, this 2,170 x 60 pixel display is somewhat limited in that it doesn’t support the MIPI DSI video mode, only command mode, along with a special instruction (0x3C) for automatic address offsets. The results of this project can be found on the GitLab account.

In a way these limitations make sense when you consider Apple’s use case for these special MIPI-DSI displays. As a touch screen with dynamic controls being displayed on it, features such as video playback never were a goal, and thus Apple likely decided to save a few bucks, possibly also due to MIPI licensing costs. What this means is that if you had dreamed of snapping up an extremely long and narrow OLED display for a video project you’re in for somewhat of a bad time. Although animated content is possible – as [Wenting] demonstrates – this comes with all the limitations of command mode, meaning slower updates, higher power usage and a lot more overhead.

Continue reading “Reverse Engineering The Apple Touch Bar Screen”

ThunderScan: The Wild 1980s Product That Turned A Printer Into A Scanner

Back in the 1980s, printers were expensive things. Scanners were rare, particularly for the home market, because home computers could barely handle basic graphics anyway. Back in these halcyon days, an obscure company called Thunderware built a device to convert the former into the latter. It was known as the Thunderscan, and was a scanning head built for the Apple ImageWriter dot matrix printer. Weird enough already, but this device hides some weird secrets in its design.

The actual scanning method was simple enough; the device mounted a carriage to the printer head of the ImageWriter. In that carriage was an optical reflective sensor which was scanned across a page horizontally while it was fed through the printer. So far, so normal.

The hilarious part is how the scanner actually delivered data to the Macintosh computer it was hooked up to. It did precisely nothing with the serial data lines at all, these were left for the computer to command the printer. Instead, the output of the analog optical sensor was fed to a voltage-to-frequency converter, which was then hooked up to the handshake/clock-in pin on the serial port.

The scanner software simply looked at the rate at which new characters were becoming available on the serial port as the handshake pin was toggled at various frequencies by the output of the optical sensor. Faster toggling of the pin indicated a darker section of the image, slower corresponded to lighter.

Interestingly, [Andy Hertzfeld] also has his own stories to tell on the development, for which his software contribution seems to have netted him a great sum of royalties over the years. It’s funny to think how mainstream scanners once were; and yet we barely think about them today beyond a few niche uses. Times, they change.

Thanks to [J. Peterson] for the tip!

Affordable Networking For Your Classic Mac

The Mac SE and in particular the Mac SE/30 number among the more sought-after of the classic all-in-one Apple computers, and consequently their peripherals including network cards are also hard to find and pricey. Even attempts at re-creating them can be expensive, usually because the chips used back in the day are now nearly unobtainable. But if the search is widened to other silicon it becomes possible to create substitutes, as [Richard Halkyard] is doing with a modern version of the SE Ethernet card.

The chip which makes this possible is the Microchip ENC624J600, an embedded 10/100 Ethernet controller with an impressively configurable interface that can be easily mated to the 68k bus. For The SE it’s mapped to a memory area, while for the /30 there can be a declaration ROM which informs the machine where it is.

This is an as yet unfinished project, a work in progress. But it deserves to succeed, and if we can provide encouragement by featuring it here then it’s definitely worth a look. Or course, this is by no means the only replacement for an original board.

SE/30 picture: Cornellanense, CC BY-SA 4.0.

Wine Is For Windows And Darling Is For MacOS

Wine has become a highly optimized and useful piece of software for those that live in Linux, but occasionally need to walk on the Windows side. In case you’d wondered, there’s a similar tool for when you need to run a MacOS program in your Linux environment. Enter Darling, the translation layer you’ve needed all along.

Just as Wine is not an emulator, nor is Darling. As a translation layer, it duplicates functions of the MacOS operating system that programs need to operate but within Linux. It’s fast, because it’s effectively running the MacOS software directly. Initially, Darling was mostly only capable of running MacOS apps at the console level. However, there is rudimentary support for running graphical applications that are based on the Cocoa framework.

Hilariously, if you’re into weird recursive situations, you can go deeper and run Darling within Windows Subsystem for Linux, itself running within Windows. Why? Well, you’re probably bored or just trying to for the sake of it. Regardless, we don’t judge. If you’ve got your own nifty translation or virtual machine hacks in the works, don’t hesitate to let us know!

A Flasher Mac, 25 Years Later

Apple Macintosh computers of the 1990s came with a system ROM containing an Open Firmware implementation and the Mac Toolbox required to start the operating system. In many cases this was on a SIMM-like daughter board, and it would have been a true ROM that was unable to be reprogrammed. This is not the end of the story though, and [Doug Brown] set out on the trail of a Flash-based ROM module allowing the firmware on these machines to be updated.

The trail was warm thanks to an Apple developer utility found on a secondhand Mac prototype, allowing ROM flashing. A little disassembly allowed a list of valid IDs to be made, and this info coupled with a bit of reverse engineering from online photos of a real Apple Flash ROM from the ’90s allowed a new board to be created with four Am28F020  chips. He can now flash at will, with such oddities as running ROMs from different machines with the “wrong” startup chime. It’s an interesting little piece of 1990s Mac trivia, settled.

This isn’t the first time we’ve peered at Apple ROMs, indeed some of the older ones had plenty of Easter eggs hidden within.

Easy Hackintosh With Docker-OSX: Soon To Be Impossible?

The Docker-OSX project has to be among one of the easiest ways to get a fully functional Hackintosh off the ground on any Linux or Windows (10+) system, with the Docker image handling the heavy lifting of keeping the copy of MacOS happy and satisfied, even as the legality remains questionable, as we previously reported on in 2021. Officially, Apple’s software license for MacOS states that it can only be installed and use on Apple-branded hardware, which precludes the installation in e.g. a Docker container. This has left Docker-OSX in a gray zone where it’s technically illegal, but as it’s being advertised by its developer [Sick Codes] to be for use by security researchers who participate in Apple’s Bug Bounty program (including iOS, which requires XCode, which requires MacOS, etc.), it seems to slip through the cracks.

An obvious issue which may soon spell the end of MacOS-on-x86_64 and with it this use of Docker-OSX is that MacOS is now straddling Apple Silicon and Intel’s x86_64 architecture, with the latter no longer being sold by Apple’s in any of its systems after the recent introduction of its Apple Silicon-based Mac Pro. Although MacOS Sonoma (14) still supports x86_64, this support could be cut in MacOS 15 or 16, at which point running Docker-OSX with an Apple Silicon-only MacOS image would at the very least require an AArch64-based ARM system, though likely with an ISA extension level that matches the lowest-end Apple Silicon (ARMv8.5-A for M1).

Although this should not make it impossible to run Docker-OSX on future Linux (and perhaps Windows) systems on AArch64-based systems, it would make it more complicated and expensive as using one’s existing x86_64-based PC is no longer an option aside from adding a sluggish Qemu layer in between, which would add a significant performance penalty. If you are using Docker-OSX, what are your experiences and plans here?

Continue reading “Easy Hackintosh With Docker-OSX: Soon To Be Impossible?”