In my last post, I figured out how to use Apple’s leaked Flasher utility from the 1990s to reflash a ROM SIMM inside of my Performa 630. It’s basically the Mac equivalent of a BIOS update, but only for Apple’s developers. The research involved in that post was quite a journey of reverse engineering from both a software and hardware perspective. I had to disassemble the code to figure out which computers were compatible and what the software was expecting to find. I also had to create a replica of an Apple development ROM SIMM that was wired exactly the way Macs of the era expected it. Although I was very excited about my discoveries, one big question remained:

What was the purpose of the bottom right half of the main window labeled “PDS ROM Info”? And what would it take to enable it?

Read the rest of this entry

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 ran it on my LC 475 and this is what it looked like:

Read the rest of this entry

After getting the PWM backlight working in my last post (here are links to parts 1, 2, 3, 4, 5, and 6), there was only one piece remaining for having a fully functional display in my Chumby 8: the touchscreen controller. The display output worked perfectly fine but I couldn’t detect presses on it.

The Chumby 8 and Insignia Infocast 8 have a 4-wire resistive touchscreen:

These aren’t so common anymore — it seems like almost everything is capacitive touch nowadays. I wasn’t familiar with the theory of operation behind resistive touchscreens until I wrote this post. Basically there are two transparent resistive layers. One layer goes left and right and the other goes up and down. When you press the touchscreen they connect together. You can calculate the X and Y positions where the layers meet by driving a voltage across one layer and then measuring the voltage of the other layer. Here’s a nice document that does a great job of explaining it in detail.

Read the rest of this entry

TL;DR: The pinout of modern programmable Mac ROM SIMMs needs to be changed for correct operation in Quadras. If you’re interested in how I reached that conclusion, or at least want to see some cool pictures, read on below.

If you’ve been paying attention to the Classic Mac scene these days, you’re probably familiar with custom Mac ROM SIMMs such as the ROM-inator II. If not, here’s some intro material about them. JDW also made an awesome YouTube video explaining them.

One thing that you usually discover when searching for info about these programmable ROM modules is that they’re compatible with the earliest 68030-based desktop Macs: the SE/30, IIx, IIcx, IIci, IIfx, and IIsi. The most common use of them is to set up a special custom bootable ROM disk using Rob Braun’s driver, Big Mess o’ Wires’ driver based on Rob’s, or Garrett’s Workshop’s driver. In general, the compatible ROM images out there are all using the IIsi ROM which is capable of booting any of the aforementioned Macs.

What you may not know is that most of the later 68k Macs also have provisions for a ROM SIMM socket, but aside from the very first Quadras (700/900/950) which always have the socket installed, it’s not usually populated. Some early production or prototype units have it, but most just have empty through-holes filled with solder where the socket would go.

Don’t worry, I already replaced those leaky capacitors before they had a chance to damage the board.

Read the rest of this entry

Several months ago, Will from CayMac Vintage reached out to me looking to resurrect my old Mac ROM SIMM programmer project. As a quick summary of that project, it provides a convenient way to program custom 64-pin ROM SIMM modules for vintage Macs from the late ’80s to early ’90s. There are several reasons you might want to do this, including: replacing an original ROM module that has gone bad, disabling the startup RAM test to decrease boot time in systems with a lot of RAM, bbraun’s amazing bootable ROM disk hack, or my startup chime hack. JDW recently made a cool YouTube video explaining custom ROM SIMMs if you’re curious about them. He even included some footage from 2003 of me playing basketball!

I used to make programmer boards and programmable ROM SIMMs and sell them to hobbyists, but it burnt me out. In particular, assembling the boards and the logistics of shipping were not fun to deal with. Thankfully, in 2016, Steve from Big Mess o’ Wires stepped in to take over. He made his own customizations to the programmer and made some really neat improvements to the bootable ROM disk driver. He still sells the Mac ROM-inator II SIMM to this day, but he stopped selling the programmer board. In the meantime, many other players have entered the market with custom ROM SIMMs, but nobody has been making the programmer available to the community, likely due to my non-commercial license on the PCB design.

Will was looking to fill that void. I helped him get going, but we discovered that the AT90USB646 microcontroller that I originally used was hard to find due to the chip shortage. At the time, it was easier to find the AT90USB1286 instead, which is essentially just the exact same chip, but with 128 KB of flash instead of 64 KB of flash.

Read the rest of this entry

I recently ran into an interesting warning on newer versions of ARM GCC, including the latest (as of this writing) Arm GNU Toolchain 12.3.Rel1. In particular I’m dealing with arm-none-linux-gnueabihf-g++. Here’s a very simple example program that demonstrates the warning:

#include <vector>
#include <iostream>

int main(int argc, char *argv[])
{
	std::vector<double> test;
	test.push_back(50.0);

	std::cout << test[0] << std::endl;

	return 0;
}

Read the rest of this entry

I recently released a big update for my Mac ROM SIMM Programmer software which is written using Qt for cross-platform compatibility. As part of the update I wanted to release the Mac build as a universal x86_64/arm64 binary so that M1/M2 Mac users would be able to run it natively. It doesn’t currently compile for Qt 6, although I think I can fix that in the future without too much effort. However, Qt 5.15.9 and later do support creating universal binaries out of the box, so I decided to figure out how to set it all up.

Even though I think I have pretty decent Google-fu, it was difficult to piece everything together to accomplish this goal. I’m hoping this post can serve as a reference for people in the future. These instructions are based on Qt 5.15.10 because that is the latest version of 5.x that is currently open source. I did this on an M2 Mac Mini running macOS 13.5.1 Ventura.

First of all, before anybody suggests it, you can’t use homebrew to install Qt for this because it doesn’t supply a universal build of Qt. If you’re going for an open-source build, you will need to build your own Qt instead. I’m assuming people with a commercial license can just get compiled binaries from Qt. So if you have access to that, you can probably skip the step of building Qt. Otherwise, follow along with me…

Read the rest of this entry

In the previous post in this series (here are links to parts 1, 2, 3, 4, and 5), I really got the Chumby to start looking like a Chumby. The display was alive! But getting the LCD controller working was really only one puzzle piece when it came to the display. The backlight needed more work so that I could control the brightness, and the touchscreen controller is a completely nonstandard design that is specific to the Chumby.

Let’s start with the backlight. This should be pretty straightforward, right? Looking at the schematics, the backlight control is connected to GPIO_84 (also known as PWM_OUT1) on ball A4 of the PXA166. I already knew that I could turn the backlight on full blast by using this pin as a normal GPIO pin and driving it high. That’s what I did in the previous post in order to quickly get it working.

Read the rest of this entry

A couple of months ago I stumbled upon a post on Hackaday about an inexpensive open-source USB 2.0 sniffer created by Alex Taradov. This is a really cool project! Normally, USB sniffers like this can cost thousands of dollars, especially if you’re paying for fancy protocol decoding and also want high-speed 480 Mbps support. This one costs about $50 in parts to assemble yourself, although it will take hours to solder and you will need some experience with hot air (or reflow oven) soldering since the USB PHY is a QFN chip with an exposed pad underneath.

I actually have an Ellisys USB Tracker 110b that I bought on eBay many years ago, but it only does low-/full-speed decoding. I thought this would be a good opportunity to upgrade my capabilities to also be able to handle high-speed USB sniffing, while also providing some good soldering practice.

Here’s my (very long) video about the process of building up one of these and programming it. I left in all the mistakes I made along the way. Why not show the world that it’s normal to make dumb mistakes when you build stuff?

I thought I’d use this post to explain in a little more detail what exactly a USB sniffer is. Why would I buy (or make) a hardware USB sniffer when Wireshark already has software USBPcap support in Windows?

Read the rest of this entry

At this point in my Chumby kernel upgrade project (parts 1, 2, 3, and 4 here), I had made a ton of progress but there wasn’t really much to show for it because I didn’t have the LCD working. Even though I had put a ton of work into the project, the display was still black. I knew it was time to get it working.

I started out with U-Boot. As a very basic overview of the LCD controller in the PXA168, basically you just set aside some of your RAM for a framebuffer, copy image data into it, tell the controller the format and address of the framebuffer, set up the clocking and timing, and turn it on. Then it just handles everything in the background for you.

The steps I listed above are overly simplified — there is more stuff going on with the PXA168’s display controller. But it’s enough to get a splash screen working in U-Boot. I booted into the old kernel and dumped the LCD registers using devmem. Here’s an example of this process. The LCD_SPU_DMA_CTRL0 register contains a bunch of format configuration bits for the framebuffer, such as which bits are red/green/blue. It’s at offset 0x190 in the LCD controller, and the LCD controller is located at an offset of 0xD420B000, so I could dump the 32-bit register value with this command:

devmem 0xD420B190 32

This resulted in a printout of the value of the register:

0x8441111

Read the rest of this entry