BMOW title
Floppy Emu banner

Archive for the 'Bit Bucket' Category

What’s on the BMOW Bookshelf

Over the decades, I’ve pared my collection of books down to just four shelves – only about 100 volumes from a lifetime of reading and studying. Because who needs physical books in an age where everything is available online? The few books that remain in my collection have survived a relentless process of repeated culling, until only the most meaningful and valuable ones remain. Want to take a peek? Here are some selections from the shelves.

Computation Structures, by Ward and Halstead. This was my original digital electronics textbook, covering everything from the transistor to CPU design, and is the only one of my bazillion university textbooks to have survived the cull. This book and MIT’s 6.004 class are what first got me excited about building with electronics. The book is a bit dated now: for something more up-to-date, maybe try Horowitz and Hill instead.

At the end of Computation Structures are schematics and control software for a DIY 8-bit computer called the MAYBE, from which I liberally borrowed ideas for my BMOW 1 computer. I built the MAYBE on a giant breadboard in a suitcase, chip by chip and wire by wire, over a semester-long class.

Practical Electronics for Inventors, by Scherz and Monk. This is a great reference for all those electronics details I should have learned, but didn’t. It puts an emphasis on practical engineering applications, with just enough theory to make sense of it all. When I find myself staring at some Forrest Mims schematic or other inscrutable circuit full of bipolar transistors and passives with unknown purpose, this book is a helpful deciphering aid.

The Black Art of Video Game Console Design, by André LaMothe. Ignore the slightly misleading title. This book is a great how-to guide for designing and building digital electronics projects of all types, with a particular emphasis on microcontroller projects. It covers analog and digital theory, circuit analysis, prototyping techniques, computer architecture, video synthesis, relevant tools, and more. If I could only have a single reference book for all my BMOW projects, this would probably be it.

FPGA Prototyping with Verilog Examples, by Pong P. Chu. For anyone that’s interested in building things with FPGAs or CPLDs, but finds it hard to get past the phase of blinking an LED, check out this book. Verilog can be a difficult language for someone coming from procedural languages like C++. It looks superficially similar, but is actually radically different, with every line of “code” running in parallel. This book goes beyond the Hello World stuff, and provides well-explained examples like a digital stopwatch, a soft UART, PS/2 keyboard IO, and a memory controller. There’s also a VHDL version of this book by the same author, if you prefer that to Verilog.

Macintosh Repair and Upgrade Secrets, by Larry Pina. This book is the bible for vintage Mac collectors. It’s long out of print, but I managed to snag an old copy from eBay. Does you Mac Plus make a “flupping” sound and refuse to turn on? Got an original Mac 128K with floppy drive problems, or video that’s reduced to a single horizontal line? Larry explains how to fix it, pointing to exactly which components need testing and replacement. These were the good old days when hackers could fix their busted motherboard by replacing transistor Q5 with a Radio Shack soldering iron, instead of making an appointment at the Genius Bar.

The New Apple II User’s Guide, by David Finnigan. Unlike Macintosh Repair and Upgrade Secrets, Finnigan’s Apple II bible was published in 2012 and is therefore relatively up to date. It covers all the common repairs for the Apple II family, as well as lots of reference material for collectors who may not have grown up with an Apple II, or forgotten what CALL -151 does. What’s better, it also discusses many of the challenges and options for using an Apple II computer in the 21st century. These include how to get your Apple II on the internet, solid state floppy disk alternatives, archiving tools, and the like.

Web Database Applications with PHP and MySQL. This book is essentially “how to build an interactive web site for dummies” using 2004 technology, so it’s dated now, but I still refer to it occasionally. Even for someone with no plans to build a web site, it’s a good introduction to the concepts of how web sites work under the hood. The book describes the ever-popular LAMP stack (Linux, Apache, MySQL, PHP) used to build the front-end and back-end of web applications. Using the skills learned from this book, augmented with more online learning, I’ve built about a dozen different web sites over the years.

Reversing: Secrets of Reverse Engineering, by Eldad Eilam. This is a fascinating look at how software programs are put together, and how they can be pulled apart and modified. I’m not aware of any other books like this one, which makes it that much more entertaining. Reverse engineering sometimes gets a bad reputation, and some people believe it’s only relevant for defeating copy-protection or other morally questionable purposes. The author introduces other uses, such as dissecting and analyzing malware, or understanding software that lacks source code and documentation. For anyone who enjoyed my post about what happens before main(), or my quest to create the smallest possible Windows executable, I recommend checking out this book.

Compute! Magazine, January 1985. This is the only remaining example of my once-mighty collection of computer magazines. There’s no special significance to this particular issue, other than that it was the only one to escape the recycling bin. It’s always amusing to browse. Loading software from cassette tape? Compuserve ads? And who didn’t love typing in those 20-page long BASIC program listings?

Flatland, by Edwin A. Abbott. This classic 1884 science fiction “romance of many dimensions” will blow your mind in just 92 pages. Imagine you’re a three-dimensional being attempting to explain things to inhabitants of Flatland, a 2D world. Imagine those Flatlanders attempting to explain their world to the miserable inhabitants of 1D Lineland. Now ponder the implications for our own three-dimensional existence: is it any more real than Flatland or Lineland? Where are the 4D visitors to Earth, and what might they look like? It’s a fantastic thought experiment, and the side-plot satire of Victorian society values is a hilarious bonus.

The Monopoly Companion, by Philip Orbanes. If you thought Monopoly was just a silly game for kids, you’re wrong. Back in my university days, my group of friends played many hundreds of Monopoly rounds, arguing strenuously over trading and strategy. A good friend was the Massachusetts champion one year, and represented the state at the National Monopoly Championships held in Atlantic City. The book describes general strategies like a preference for certain color groups (orange is best), and the importance of building to the three house level. We created a detailed software simulation accounting for all board squares, rents, cards, and dice roll probabilities, and ran it millions of times to determine the best strategy. Then we sent a letter to this book’s author, disputing some of his conclusions. God, what a bunch of nerds we were.

Your Money or Your Life, by Dominguez and Robin. We all spend a tremendous amount of time and energy in the attempt to accumulate money, sometimes without really considering why. Yes we need a safe place to live, food to eat, and other necessities – but what then? The money itself won’t bring happiness. Have we really thought about exactly what will bring happiness? How much of our life’s energy are we willing to trade away for those things? Having identified them, might there be other ways to get similar things that require less or no money? Can money even buy them at all? Your Money or Your Life helps guide readers towards a future where they may not be rich in dollars, but are rich in the things they value most.

Finding Your Own North Star, by Martha Beck. Where are we headed? Why? What’s important to our essential self? Like other self-help books or the time-honored What Color is Your Parachute, this book aims to help identify paths that are best-aligned with one’s values. It resonated with me in a way that other similar books didn’t. One clever exercise was to get everybody on your side, by intentionally redefining who “everyone” is. Another was an invitation to envision the best possible personal future imaginable, and map it out. The act of defining a goal already brings it closer.

The Goldfinch, by Donna Tartt. A friend and I read this Pulitzer Prize winning novel at the same time. She thought it was just OK. I thought it was outstanding. It was one of those books that when you finish, you set it gently in your lap and just stare vacantly into space for a long while, trying to digest it all. Tartt’s prose is rich and evocative like a master painting, and her story of loss and disaffection is heartbreaking. But what really moved me was the portrayal of the awkward intimacy of adolescent male friendships, the things said and unsaid but understood, the struggle to carry those relationships into adulthood. I felt Tartt had snooped inside my mind and extracted feelings I didn’t even know were there.

A family bible from 1817. Not many artifacts survived the past two centuries with my family, but this one did. It’s a huge volume with an imposing leather cover, and on the inside leaf are inscribed the births and deaths of generations.

“Joshua Ladd was born 1st mo. 7 1817”. That’s January 7 to us, so Joshua just had his 201st birthday recently. He was my great-great-great-great-grandfather, a farmer originally from Virginia who at age 14 moved to Ohio with his mother and siblings after the death of their father. Ohio had just become a state, and the family moved in search of new opportunities. Joshua opened a grocery and supply store in the town of Westville, near Damascus OH. I still have the wedding gloves of Joshua’s daughter Sarah tucked safely in a box. Any Ladds in your family tree? Maybe we’re related.

Essays by Ralph Waldo Emerson. This particular volume is from 1883, and was passed down through generations to my father and then me. Sometimes I think those Transcendentalist authors like Emerson, Longfellow, and Thoreau had everything figured out in 1870, and we haven’t accomplished much since. “When you were born you were crying and everyone else was smiling. Live your life so at the end, you’re the one who is smiling and everyone else is crying.”

Read 3 comments and join the conversation 

Meltdown and Spectre Vulnerabilities Explained

This week brought some fascinating news for CPU nerds: the revelation of security vulnerabilities in the basic hardware architecture of many modern processors. The Meltdown and Spectre vulnerabilities affect virtually all modern computers, according to a sensationalist headline at The Register which called them the “worst ever” CPU bugs. Unlike bugs in a specific software program or operating system that can be fixed with a patch, these are fundamental flaws in the very design of the CPU.

What are these vulnerabilities exactly, how do they work, and how are Meltdown and Spectre different from each other? I must have read twenty different news stories without finding a clear answer. The best I could get was that these vulnerabilities somehow involve the CPU’s use of speculative execution: an optimization trick that executes code before it’s known whether the code should really be executed, discarding the results if it’s later determined that the code wasn’t needed. But as a guy who designs custom CPUs as a hobby, I needed a better answer than that. So I started poking beyond the news headlines into the gory tech details.

What follows below is my attempt to explain Meltdown and Spectre to myself, and by extension to readers of this blog. It assumes readers already have some basic knowledge of concepts like CPU internals, caches, and operating systems. But moreso than normal for this blog, I’ll be discussing details that I don’t fully understand myself, and my explanations may be flawed. If you find an error or omission, kindly post a comment and let me know.

 
Speculative Execution + Caching = Vulnerability

Both Meltdown and Spectre exploit the fact that speculatively executed code can modify the CPU cache. Even if the code is never “really” executed, meaning that it never modifies CPU registers or memory or other processor state, the cache effects of the speculatively executed code can be observed by cleverly-constructed code that follows it, by testing what is and isn’t cached. Consider this example, taken from Google’s Project Zero Blog:

struct array {
  unsigned long length;
  unsigned char data[];
};

struct array *arr1 = ...;
unsigned long untrusted_offset_from_caller = ...;

if (untrusted_offset_from_caller < arr1->length) {
  unsigned char value = arr1->data[untrusted_offset_from_caller];
  ...
}

If arr1->length is not presently in the cache, the CPU won’t immediately know whether the if clause will evaluate true or false. If it guesses true, then the if body will execute speculatively while arr1->length is fetched from main memory. Speculative execution will cause arr1->data[untrusted_offset_from_caller] to be loaded from main memory into the cache. This behavior can be leveraged in several different ways (see below) to gain information about protected regions of memory that are supposed to be private: memory owned by other processes or the kernel. The ability to observe protected memory makes it possible to read passwords, Bitcoin keys, emails, or other sensitive information.

 
Spectre: Speculative Execution in Branch Prediction

The Spectre vulnerability requires getting the victim (the kernel or another process) to run specially-constructed code, which then leaks information through the cache effects of speculative execution. Consider an expanded version of the previous example.

struct array {
struct array {
  unsigned long length;
  unsigned char data[];
};

struct array *arr1 = ...; /* small array */
struct array *arr2 = ...; /* array of size 0x400 */
unsigned long untrusted_offset_from_caller = ...;

if (untrusted_offset_from_caller < arr1->length) {
  unsigned char value = arr1->data[untrusted_offset_from_caller];
  unsigned long index2 = ((value&1)*0x100)+0x200;
  if (index2 < arr2->length) {
    unsigned char value2 = arr2->data[index2];
  }
}

If arr1->length is not currently in the cache, speculative execution will continue inside the body of the if clause. Either arr2->data[0x200] or arr2->data[0x300] will be fetched from main memory and cached, depending on the least significant bit of arr1->data[untrusted_offset_from_caller]. After the speculative execution has ended, the attacking user mode code can measure how much time is required to load arr2->data[0x200] and arr2->data[0x300]. Whichever one was cached will load faster, revealing whether the LSB of arr1->data[untrusted_offset_from_caller] is 0 or 1. By repeating this process with other bit masks, the attacker can eventually read all of arr1->data[untrusted_offset_from_caller]. And by the choice of untrusted_offset_from_caller, the attacker can read any memory location.

That’s the general idea. Some implementation details and optimization methods are described in the Project Zero blog. The blog also describes another Spectre variant exploiting speculative execution through indirect branches, which I didn’t examine.

How can a user process get the kernel to run this kind of specially-constructed code? It turns out that the Linux kernel has a feature called eBPF that’s designed for this exact purpose, presumably to allow for device drivers or socket filters or other snippets of user-provided code that need to run in the kernel. I’m assuming Windows and Mac OS have something similar. Since running arbitrary user-provided code in the kernel would be a huge security vulnerability itself, eBPF actually runs the code in an interpreter or a JIT engine. But that’s enough to exploit this vulnerability.

Note: after writing this post, I found a second explanation of Spectre from a group of academic researchers working independently from Google Project Zero. Their paper describes Spectre slightly differently, and discusses attacking other processes rather than the kernel. It also includes a proof of concept Javascript attack, in which a malicious bit of Javascript is able to read private memory from the web browser process. Relying on the fact that Javascript is typically JIT compiled to native code, and using debug tools to examine the native output, the authors were able to iteratively tweak the Javascript source code until it produced native code containing an exploitable conditional branch of the kind shown above.

Spectre affects essentially all modern CPUs, given the proper conditions: Intel, AMD, ARM, etc.

 
Meltdown: Exploiting Out of Order Execution

Meltdown is similar to Spectre, in that they both leak information through the cache from instructions that were never “really” executed. However, with Meltdown there’s no branching involved. The attack relies on the way modern CPUs optimize performance by employing out of order instruction execution. Due to the availability of CPU execution units and dependent data, instructions are sometimes executed in a different order than they appear in a program, but they are retired (registers and state are updated) in order. The fact that they were executed out of order should be invisible to the program, but Meltdown shows that’s not always true. The details are described at cyber.wtf and in a separate academic paper.

When instructions are executed out of order, but aren’t yet retired, their results exist in a kind of limbo that’s very similar to speculatively executed code from branch prediction. However, it’s not clear whether this should properly be called speculative execution. The Meltdown paper refers to these as “transient instructions”, which seems like a good term.

Consider this code:

mov rax, [someKernelAddress]
and rax, 1
mov rbx,[rax+someUserModeAddress]

The first instruction should cause an exception if executed from a user mode process, because it’s an attempt to access kernel memory. However, at least on Intel architectures, it appears that the exception doesn’t occur until the instruction is actually retired. If this code is executing as part of a transient instruction sequence, no exception will yet occur, the privilege violation (bypassing kernel memory protection) will be ignored, and the transient read will succeed. The following transient instructions that use the read value will also succeed, and will affect the cache state in the same way as Spectre, creating a side-channel for leaking information about kernel memory.

Eventually, the first instruction will be retired and the exception will occur. The state changes related to the following instructions will be discarded, because those instructions were never really executed, but their cache side effects will remain. After an exception handler resolves the exception, further code can measure how long it takes to load from address someUserModeAddress vs someUserModeAddress+1, thereby inferring the LSB of someKernelAddress. Further iterations can read the other bits.

To ensure that the Meltdown code sequence executes as an out-of-order transient sequence, the cyber.wtf technique includes a long series of filler instructions ahead of it. These filler instructions all use a different execution unit than the units needed by the Meltdown sequence, and create a long chain of interdependent instructions. So the CPU must sequentially execute the filler instructions one at a time, but meanwhile it can also jump ahead and execute the Meltdown instructions out of order.

Note that “out of order” here refers to the Meltdown code being executed out of order relative to the filler instructions. The Meltdown instructions themselves are executed in order relative to each other, since each one is dependent on the previous one.

At this time, Meltdown appears to be limited to Intel CPUs only. It’s uncertain whether this is due to a fundamental difference in how Intel handles memory protection with respect to out-of-order execution, or is simply due to differences in the size of the reorder buffer between CPU vendors. In a short aside on Meltdown, the Spectre paper states “Meltdown exploits a privilege escalation vulnerability specific to Intel processors, due to which speculatively executed instructions can bypass memory protection.” However, the Meltdown paper reports that the authors were able to observe bypassing of memory protection during out of order execution on ARM and AMD processors too, but were unable to construct a working exploit.

 
Impact and Mitigation

Both of these vulnerabilities are very bad, enabling user mode code to read other protected memory. However, they’re both local exploits: the attacking code must be running on the machine being attacked, so an attacker must somehow get their code onto your machine first. For this reason, the greatest risk is probably to cloud computing environments, where processes from many different people are running on the same machine, supposedly isolated from one another thanks to memory protection. But there’s also a risk in any situation where one computer runs code received from another, even inside a VM or sandbox.

It’s not clear how Spectre can be fixed in software, because it relies on CPU features that are fundamental to all modern processors. In fact, I don’t think it can be fixed in software – at least not in any general way. One web site says, “as Spectre is not easy to fix, it will haunt us for a long time.” The only good news is that convincing the kernel to run an attacker’s special code with eBPF or other methods isn’t easy. And web browsers can be patched to protect against the sort of Javascript Spectre attacks described in the research paper. But other opportunities for Spectre attacks will remain. Future CPUs may contain hardware fixes for Spectre, but they’ll likely come with a complexity and performance penalty. Maybe cache lines will have to be treated as process-specific data instead of as shared resources.

Meltdown is the more serious of these two vulnerabilities, because it happens entirely in a single user space program and doesn’t require any special code in the victim process or kernel. In the real world, this makes it much easier for an attacker to exploit. Fortunately Meltdown can be fixed at the operating system level, but the fix carries a performance penalty that may be as high as 30%.

In the Meltdown sample code, readers may have wondered how an instruction like mov rax, [someKernelAddress] could possibly work in user mode code, even speculatively, since the kernel uses a different virtual to physical address mapping than the user mode process. It turns out that Linux (and I assume other operating systems too) maps the kernel’s memory into the address space of every user process, for performance reasons. By keeping the kernel permanently mapped, there’s no need to flush the TLB when switching between user and kernel space, and TLB entries for kernel space never need to be flushed. The processor’s MMU can normally be trusted to prevent user processes from accessing this kernel memory – except in the case we’ve just seen. The details are nicely explained in the description of a related technology named KAISER.

The “fix” is KPTI: kernel page table isolation. This ends the longstanding practice of mapping kernel memory into the address space of user processes. This ensures that mov rax, [someKernelAddress] won’t be able to reveal any information. However, it means that the TLB must be flushed every time there’s a switch between user and kernel code. If a user process makes frequent kernel calls, the constant TLB flushing will be expensive and have a significant negative performance impact.

 
The Future

Meltdown and Spectre are scary, not only because of what they can do themselves, but because they introduce a Pandora’s Box of new vulnerability types we’re sure to see more of in the future. We can no longer think about security analysis as something that gets applied to specific software programs or operating systems, examining the code and imagining it being executed instruction by instruction in an abstract environment. We must now consider the specific highly complex CPU (often not fully documented) that runs this software, and understand the many subtle ways in which the true hardware behavior differs from the instruction-by-instruction conceptual model.

The KAISER document mentions techniques like exploiting timing differences in fault handling, observing the behavior of prefetch instructions, and forcing faults using the Intel TSX (transactional memory) instructions. This will be a new frontier for most developers, forcing them to peel back a layer of abstraction when evaluating future computer security issues. The world just got a lot more complicated.

Read 4 comments and join the conversation 

Custom Mini Case for Macintosh LC, P475, Q605

Here’s a custom laser-cut case for the Macintosh LC family, Performa 400 series, and Quadra 605. By removing the internal floppy drive and fan, and replacing the internal SCSI drive with a SCSI2SD board, I was able to make a design that’s about half the size of a standard LC case. The pieces fit together loosely with tabs and slots, and then screws and nuts in T-slots provide extra support to make everything nice and solid. The finished case isn’t much bigger than my keyboard, which is neat. Here it is outfit with a Floppy Emu and an ADB-USB Wombat:

The logic board is screwed into the base piece, and the PSU is strapped down with zip ties. The case is a simple six-sided box, with the addition of a seventh interior piece that I call “the shelf.” This piece separates the rightmost interior region into lower and upper sections. The lower section houses any PDS plug-in card, and the SCSI2SD rests on top of the shelf in the upper section. Because of the way the SCSI cables are oriented, the SCSI2SD is mounted upside-down.

Here are the parts before assembly:

And the final product is shown at the top of this post. It’s an obnoxious shade of orange with a clear top. Who wants beige, anyway?

The speaker is taped to the inside of the case to prevent it from moving around, which is ugly. There’s not enough space for it to lie flat, so it’s propped up at a strange angle. I’ll hunt around for a smaller 16 ohm speaker to use in its place.

There’s a slot in the front where I’ve run a floppy ribbon cable, so I can hook up a Floppy Emu when needed.

The space above and below the shelf is very cramped, and I probably should have made it larger. Initially I couldn’t get my PDS ethernet card to fit, but after shaving a few millimeters by removing the metal shield from around the ethernet jack, it just barely squeezes in. The SCSI2SD was also a very tight fit. Using a SCSI cable with integrated strain relief, it wouldn’t fit, and I had to substitute a different SCSI cable without strain relief that’s a couple of mm thinner.

The case opening for the PDS card is fine, but without the metal shield, there’s a gap around the ethernet jack. Bonus ventilation! Here’s a photo of that, along with the right side vents:

With no fan I thought the computer might overheat, so I was prepared to take some temperature measurements. Stuffed with the guts of a Performa 475, I used an IR thermometer to take some readings at different spots inside the case, and I couldn’t find anything warmer than 112 F / 44 C. I was ready to mount a tiny fan inside, but that doesn’t look necessary now since the passive cooling is adequate.

If anybody wants to build their own, or use this as a starting point for further experiments, take these files. There are two files: one for the bottom and sides, and one for the top and shelf, so you can have the two different sheets made in different colors. Upload the files to ponoko.com, and have each one cut on a P2 sized 3mm thick acrylic of your color choice. You can also use 3mm MDF wood if you want a different look. Along with the case pieces, you’ll need 11 M3x10mm screws with matching nuts. #4-40 size screws probably fit too, but I haven’t tried it. You’ll also want some plastic zip ties to strap down the power supply.

A few things I’d do differently, if I were going to do this again:

  • Add about 3mm to the height under the shelf, to fit thicker PDS cards
  • Add about 3mm to the height above the shelf, to fit thicker SCSI cables
  • Integrate small feet into the side pieces, to elevate the case for better underside airflow
  • Have fewer vents around the PSU, and more vents around the CPU and PDS card
  • Cut the vent slots into the shape of an Apple logo
  • Reposition the floppy cable slot, so it’s better aligned with the logic board’s floppy connector
  • Add an opening for a power LED so I can tell when it’s on

Now back to playing with my little orange monster…

Read 5 comments and join the conversation 

Future Hardware with Animal Names

Yesterday’s post mentioned some hypothetical marsupial-themed hardware: WiFi Wallaby, Video Platypus, and others. While these were meant as a joke, they got me thinking about what exactly a “Video Platypus” and friends might do, and I’m outlining some possibilities below. These are all tied loosely into vintage Macintosh hardware, although other ideas of interest to the general Arduino/RPi audience would be nice too.

 
Video Platypus

This might be a way of providing video out for compact Macs like the Plus and SE. I’ve discussed a few potential methods for doing this before. One approach is to directly tap the CRT video and synchronization signals and resample/convert them to a standard format. Another possibility is sniffing the address and data bus to watch for CPU writes to the framebuffer region of main memory, then use that to construct a new video signal.

Video Platypus could also be a converter or upscaler for the Mac II series and later machines. VGA adapters for these machines are inexpensive and easy to find, but VGA itself is a slowly dying standard. It would be nice if I could get a direct HDMI or DVI-D output from my 680X0 or PowerMac. Probably this wouldn’t need to be Mac-specific – it would just be a VGA to HDMI converter with a different physical connector to support the Mac. Something like this must surely exist already?

 
Disk Kangaroo

An external fileserver would be nice for old Macintosh computers: a device you plug into the computer and that appears as a large local or remote disk. Floppy Emu already serves this purpose when it’s configured in HD20 hard disk mode, but only a small number of Macintosh models support HD20 and have the necessary external floppy connector.

Disk Kangaroo could be something like a Floppy Emu for LocalTalk. Just plug it into the Mac’s LocalTalk port (the printer port), and it would appear as a fileserver. You wouldn’t be able to boot from it the way you can from Floppy Emu, but it would work on virtually every Mac model and system software version. The I/O speed would be about the same as Floppy Emu, I think.

The same idea could be applied to a SCSI disk instead, so the device would appear as a local disk and the computer could boot from it. This would be similar to SCSI2SD, except instead of formatting the whole SD card as a Macintosh disk, the SD card would contain a library of disk images to choose from, just like Floppy Emu. This would make it easier to set up and use for file transfers to and from an internet-connected PC.

Both the SCSI and LocalTalk disks could also use remote storage instead of an SD card. The files could be served from a PC on the same LAN, which would might require some special software on the PC, or the device could potentially do Appletalk-to-Samba translation. Or files could be served directly from a cloud storage account like DropBox.

 
WiFi Wallaby

Everybody loves the ESP8266 for connecting oddball things to WiFi. What might this do for a vintage computer? Most old Macs are capable of Ethernet networking, although many require an add-in networking card that’s now rare. I’m not sure if it’s easy or even possible to go from that to a wireless network connection.

What might you use this wireless connection for – general web surfing, email, and FTP? Or for connecting to other vintage Apple computers and printers wirelessly with Appletalk?

Maybe this could be like a WiFi version of Farallon PhoneNet. Connect a WiFi Wallaby to each of your computers and printers and they’ll auto-connect and form an Appletalk network. Same idea as the phone cables in PhoneNet, but wireless.

 
Printer Koala

A clever microcontroller board with the necessary physical connector could emulate an Imagewriter II or other 80’s – 90’s Apple printer. What would be the point of that? Maybe it could act as a print server or translator, enabling the old Macs to use modern printers. The need for printer drivers could make that difficult, though. Or maybe “printing” could perform another function like converting the document to PDF and storing it on an SD card or on a cloud-based server. Or it might implement a print-to-Facebook or print-to-Twitter feature.

Working in the opposite direction could be interesting too: a device that connects to an Imagewriter II or Stylewriter or LaserWriter. The device could put these classic printers on a network so that modern computers could print to them from Windows, OSX, or Linux. There would be a question of printer drivers again, but for relatively simple printers like the Imagewriter that might be doable.

Read 12 comments and join the conversation 

Build an Electric Scribble Machine

Looking for a creative project for kids to build? The Electric Scribble Machine is an entertaining device that’s easy to build from common parts – great for a scout troop project, school science fair, or just a lazy afternoon at home. For the past several years, as part of our local elementary school’s annual Discovery Day, I’ve led groups of kids ages 7-11 through the construction of a scribble machine. Tomorrow will be my last turn at Discovery Day, so I’m documenting the scribble machine design here for reference.

The basic concept is simple, and is borrowed from an Exploratorium design:

  • An off-center weight on an electric motor will cause it to wobble and vibrate
  • Mount the wobbly motor to a body made of plastic, cardboard, recycled bottles, or whatever’s available
  • Attach colored felt-tip markers to the body to create legs

When the machine is placed on a large sheet of paper, it will wobble and jump around erratically, drawing interesting patterns as it moves.

 
Step 1 – Motor

I use cheap DC hobby motors rated for 1.5V to 6.0V. They work fine with just a single AA battery, but are better with 2xAA batteries.

 
Step 2 – Off-Center Weight

Anything that can be mounted onto the motor’s shaft will work. The more unevenly the weight is distributed, the better. I’ve found that glue sticks for hot glue guns work nicely, and are easy to mount thanks to their texture.

I use generic 4 x 0.44 inch glue sticks, and cut them in half with kitchen scissors to make 2 inch sticks. I hammer in a finishing nail near one end of the stick, then pull out the nail, leaving a small hole behind. The hole makes it easy to press-fit the glue stick onto the motor shaft without any additional tools: just push the shaft into the hole. The rubbery texture of the glue stick holds the shaft tightly, so it won’t easily pull loose.

 
Step 3 – Battery Holder (optional)

A 2xAA battery holder with an integrated on-off switch helps to create a reliable finished project. In the first years of building scribble machines, I held the motor wires directly to the battery terminals with rubber bands. It worked, but was a constant source of frustration when the wires came loose.

I’ve found that the wires on cheap battery holders are often poor quality, and break easily. Last year, about half of the battery holder / motor units suffered some kind of wire breakage during the day, leading to a lot of unhappy kids and emergency solder repairs. This year, I’ve added a drop of hot glue to the outside of each battery holder at the point where the wires exit. I’m hoping this will serve as a strain relief, and help reduce the number of broken wires.

 
Step 4 – Soldering (optional)

For the most reliable results, the battery holder wires should be soldered to the motor terminals. This is as easy as soldering gets, and it takes only a few seconds. A $15 Radio Shack soldering iron will do the job nicely.

As an alternative to soldering, the battery holder wires could be twisted around the motor terminals with pliers. There’s normally a small hole in the center of each motor terminal, which makes the job fairly easy.

 
Step 5 – The Body

Here’s an opportunity to get really creative – the body can be made from virtually anything! Try empty water bottles, plastic baskets, DVDs, cardboard, foam board, or whatever else might be handy. In past years I used empty plastic water bottles, sometimes with a few rocks inside to act as ballast. The plastic bottles work fairly well, although they do sometimes get partly crushed by kids who are overzealous in their construction efforts.

This year I’m trying something new: flat cardboard bodies, with holes drilled for the motor and felt-tip markers. It’s definitely possible to create these from old cardboard boxes, but cutting and drilling is time-consuming and tedious when making more than one or two. I took the easy path, and got squares of laser-cut double-thickness cardboard made by a local service. They were only 84 cents each, and the precise cut-outs for the motor and markers make it easy to snap the components into place. I added eight holes for markers, so the kids can experiment with different placements.

You’re welcome to use my laser-cut design. The Ponoko service will make them for you, if you add the design to your “personal factory” and select a material. Mine were cut from double layer corrugated cardboard, 6.7 mm thickness, 181 x 181 mm size (Ponoko’s standard P1 size).

 
Step 6 – The Legs

The legs of the Electric Scribbling Machine are generic colored felt-tip markers. Many parents already have dozens of these stuffed into every odd drawer and closet. Washable markers are nice for recovering from accidents, but not required. I used this cheap 30-pack of fine tip markers.

Three legs or four? I’ve tried both, but usually go with four. The design of the scribble machine requires some fine-tuning of stability, and four legs create a more stable base than three. Too much stability isn’t necessarily a good thing, however, since a certain degree of wobbling is required to make a good scribble design. But a high degree of wobbling will quickly lead to wild gyrations, and then the machine will topple over in a sad pile. It takes a few minutes of experimentation with leg lengths and ballast weights to find a happy medium.

 
Step 7 – Assembly and Use

I normally prepare the battery packs, motors, and glue sticks ahead of time. On the day of the event, the kids combine these with the batteries, body, and legs to assemble a finished machine. It sounds simple, but the assembly process always seems to require a surprisingly large amount of time, usually 30 minutes or more.

Duct tape, masking tape, rubber bands, or hot glue can be used to mount the motor and battery pack onto the body. These are the heaviest components, so it’s best to place them near the center of the body. I’ve found that most 7 to 11-year-olds don’t have the physical dexterity to work with rubber bands, so duct tape is my preferred adhesive method. After mounting the motor and battery, the legs are attached the same way. The caps on the markers add about 1.5 inches to their length, which needs to be considered while mounting them, otherwise the finished machine will sit too low to the ground when the caps are removed.

After watching the machine scribble random designs for a while, it’s time for some directed experiments.

  • What happens if one leg is a different length than the others?
  • What’s the effect of moving the legs closer to or further from the body’s center of mass?
  • Can you configure the machine to wobble forward in a straight line instead of gyrating randomly? Try racing them.
  • Reconfigure the motor to lie on its side, spinning the weight in the vertical plane. How does the machine’s motion change?
  • Decorate the bodies with stickers and give them cool names.

 
Shopping List

Supplies for 30 kids:

30 electric motors $45.00
15 hot glue gun sticks $8.69
30 battery holders $24.36
60 AA batteries $11.87
30 laser-cut cardboard bodies $25.20
100 colored markers $17.44

The total cost is about $132, or $4.42 each.

If you build an Electric Scribble Machine, send me a note and tell me how it went!

Be the first to comment! 

How to Clean a PCB

Lately I’ve been assembling a lot of Retro USB boards, and that’s got me thinking about the best way to clean them after assembly. I use a “no clean” flux for my assembly work, so in theory I don’t have to have to clean it off, but if I don’t then it will leave an ugly sticky mess. Unfortunately the black soldermask of Retro USB boards seems to highlight flux residues more than other colors. I’ve also recently started using a gel flux in a syringe instead of a flux pen, and it’s stickier and leaves more residue. So good cleaning is more important now than ever.

In the past, my standard cleaning method was regular cotton swabs (Q-tips) with 99% isopropyl alcohol. It dissolves the flux residue, but the swabs snag easily on the sharp corners of parts, quickly become shredded, and leave tiny cotton fibers everywhere. I’ve now started using Chemtronics cotton tips, which are basically fancy Q-tips designed for industrial use. The cotton is packed and wound more tightly than Q-tips, and they’re “low lint”, whatever that means. It helps reduce shredding and stray cotton fibers, but doesn’t completely eliminate them.

The isopropyl alcohol also leaves a residue that’s visually unattractive, as you can see here. Its visibility depends greatly on the angle of the light, and I’ve intentionally chosen the worst angle for the photo. I’m uncertain if this residue is really from the alcohol, or whether it’s the remnants of the flux dissolved in the alcohol, but whatever it is leaves streaks on the PCB when it dries. I’ve found I need to wait until it dries, then use another dry cotton swab to buff the dried areas and remove the streaks. The end result still isn’t perfect, though it’s pretty good. But the whole cleaning process can be very time consuming, requiring several minutes per board.

It’s my understanding that commercial PCB assemblers wash the finished boards in hot deionized water and some kind of solvent. It’s essentially a special dishwasher for electronics. I don’t have that kind of equipment though, and I wouldn’t be excited about washing PCBs where my kitchen dishware and utensils go. In the past I’ve tried hand-washing finished boards with ordinary hot water and dish soap, and it worked OK but still wasn’t squeaky clean. Washed boards also require a special dryer, or a long period of air-drying to ensure all the water is out before powering the board.

Do you have a favorite method of board cleaning? Leave a note in the comments.

Read 8 comments and join the conversation 

Older Posts »