Following my Open-ended computer ideas section, I got some nice feedback suggesting that the page was a potential seed for big-sky thinking.
However, while thinking as big as the universe can sometimes lead to creative new ideas, there's a time and a place to think somewhat inside the box (both literally and figuratively) as well. At some point, vague ideas and intangible concepts need to be turned into something concrete, or they'll never take the form of actual computer hardware and software. Ideas in the mind may be their own end, but this is, after all, a page about computers.
With this in mind, then, I've set about compiling a small list of what I feel are worthwhile hacks to explore for the person who wants to do interesting things with their computer. These hacks are not particularly open-ended, but I believe they capture the true spirit of hacking, an art which is simultaneously about learning new things while also asserting your control over the machine. Perhaps the spirit of these hacks will lead to ideas for still others. Even though these ideas are somewhat closed-ended in where they lead, a bit of creativity might still bring you to places you never expected.
Of course, for more ideas along these lines, you can find several sites on the web. Perhaps the most notable of these is Hack a Day, which tends to have some of the most genuinely useful and thoughtful hardware hacks I've ever seen. However, as with any blog-style site, the quality of the hacks there is bound to be variable, and so I humbly offer this more static list of hacks as a time capsule of ideas that represent computer hacking as it's really meant to be.
People forget that one of the most powerful attributes of a computer is its simple ability to blend input, output, and processing, something no other machine in the world really does. Why not combine these attributes in original ways?
For example, what does your memory look like? If you assign a color to each possible byte value in memory and then use the pixels on your screen to form an array representing each byte of a memory range, what patterns might certain blocks of your memory reveal? Why not find out? To a certain extent, this idea is enacted in almost every computer every day, since video memory really is simply a series of bytes in which byte values correspond to specific colors, but this idea entails looking at regions of memory OTHER than the standard video-memory ranges. Can you read an entire book from your computer's RAM just by plotting its byte values as pixel colors in an array on the screen? Can you learn to recognize programs by what their data structures look like while they're running?
Any PC retrogamer can tell you that it's important to be able to control how many cycles per second your CPU is running at. Many games made in the 1980s for DOS will run far too quickly on a gigahertz-CPU computer. Most people deal with these issues by turning to emulation software such as DOSBox, or CPU slowdown utilities like CPUKiller and Mo' Slo. How much better would it be, however, if you could actually control how fast your CPU is running?
This really isn't rocket science. The timing clock for your CPU is nothing more than a square wave, among the most simple of all electronic signals. So why shouldn't you just be able to control the speed of that square wave that goes into your CPU, thereby controlling how fast it runs? There's no good reason why you can't.
Once you've got a good thing going, why stop there? Why not wire an amplifier and a speaker to that square wave so you can hear exactly how fast your CPU is running? If you develop perfect pitch, you'll learn to hear exactly what the right tone for running a specific game is.
After being a solitary pursuit for a while, sometimes computing becomes social. Once you've gotten the hang of matching CPU speeds to specific tones, you can set up several computers with varying-speed CPU clocks whose tones wind together to create square-wave harmonies. Then you can create LAN parties in which each player's computer plays a specific register (tenor, baritone, soprano, or whatever) and have every player's computer constantly changing its CPU speed so the computers collectively play music together. This would make for a pretty chaotic LAN party, but once people learn to match notes with speeds, they'll come to anticipate how fast their game is about to run. LAN gaming and polyphonic square-wave harmony come together in an art-meets-science gaming extravaganza.
Speaking of square wave clocks, can you make your own VGA clock signal?
A VGA monitor detects what video mode is being sent to it based on two square waves: One for horizontal sync, the other for vertical. Actual video data (which is based on analog voltages representing pixel brightness intensities) is sent independently of these sync signals.
Can you make a circuit which takes, as an input, a signal from a VGA video card and converts it into a VGA signal at a completely separate resolution while still retaining the video content? This VGA mode converter would be a simple way for you to create resolutions that your video card doesn't support.
Most PCs today are largely integrated. Most of the functions are built into the motherboard. Get a metal-and-plastic box to stick the motherboard into, and a power supply to supply its lifeblood of electric voltage, and there you go: Instant computer. But there's one thing which is still usually offboard: Storage drives. So why not hack your drive interfaces?
Suppose you have a file on your hard drive which you want to protect. Perhaps you want to prevent anyone from reading it. This is easy to do: Find out the location of the file on the hard drive, then make a circuit which watches activity on the IDE cable and interrupts the signals to the drive if the IDE controller tries to access the block(s) which the file is stored on. Once you do this, no amount of software can read the file; the IDE channel tap will simply filter those read-access commands out.
Similarly, if you have a file which you want to make read-only, all you need to do is configure the IDE tap to look for write attempts on that block, and filter out those write commands. Problem solved: The operating system becomes physically incapable of writing to that block of the disk.
A hack like this truly proves that the hardware really is mightier than the software. The most clever software in the world can't access or overwrite your data if the hardware can't get to it!
It used to be that PCs had a lot of expansion cards. There would be, at a minimum, a video card to send a picture to the monitor and a drive-controller card to control the disk drives (whether hard or floppy).
Today, not only are the above two functions typically built onto a motherboard, so are most of the auxiliary functions that people typically got expansion cards for: Audio, I/O ports (RS-232, parallel, USB, etc.), and LAN connectivity. Even so, most motherboards today still have several expansion slots, meaning that whereas expansion slots were often at a premium in the 1990s, most PCs today have at least a couple of spare slots they're not using. Why not take advantage of these slots by interfacing something to them? You can wire a microcontroller chip directly to the address, data, and control buses of your computer, then use it to toggle on or off things like desktop fans; then all you need to do to cool off is send a specific byte to a specific I/O port.
Once you've done this, there's really no good reason to not take it a step further and give yourself a whole system to tap into the buses of your computer. The expansion slots on the motherboard are the only accessible way to do this, short of peeling the solder mask off the motherboard to get at its traces. USB ports and RS-232 ports won't let you get at the computer's actual address, data, or control buses. Only slots let you do that. Make a system which allows you to examine any byte in memory at any time at the hardware level. Then modify the system so that you can modify any byte in memory at any time WITHOUT needing to grovel for the operating system's approval. Once again, the most clever software in the world can't override what happens in the physical realm! Once you've done something like this, you're ready for the next idea...
Actually debug your software.
I'm serious. Most software "debugging" today occurs at such a ridiculously high level that even programmers don't know the first thing about how their software really works. Make a system that allows you to control every bit in memory. Then, the next time your operating system (or other software) crashes, don't just complain about how badly-written it is; figure out why it crashed. Examine the bytes on the buses so you can see exactly where the CPU's instruction-pointer is and what cycle it's stuck on. Then un-crash your computer by repairing the broken bits in memory. Your computer will never freeze again! Or, more accurately, when it freezes, you'll be able to un-freeze it and carry on from where you left off without having to reboot and start from scratch.
Put a real user interface in your BIOS. PCs don't come with a true UI; they rely on the operating system to do this. This is in contrast with computers like the Commodore 64 or the Apple II, which came with a full command-line interface (CLI) in ROM and allowed you to boot and access the RAM, I/O, etc. without needing any storage media whatsoever. The PC has never done this by design; the BIOS of a PC has always been designed to just provide some hardware-level functions while leaving the actual user interface to an operating system loaded from disk.
Change that. Make a real CLI in your BIOS. Rewrite the ROM chip that holds the BIOS so that you can get a real UI even if you have no storage. Now you can do anything with your computer, even if you don't have a disk. Box it up and put it in the attic for 20 years. Then, when you pull it out and all your disks have gotten lost or been repurposed for other data-storage purposes, you'll still be able to power up your PC and begin using it immediately because its ROM contains a usable UI.
Having a usable UI in the firmware also means there's no longer any need for boot disks. No longer are you crippled by your dependency on having bootable media sitting around, because even if you don't have a boot disk and have just plugged in an empty hard drive, you can manually write an OS kernel to that hard drive by directly poking commands into the IDE controller's registers. Never be stuck for lack of bootable media again! Huzzah!
In Neal Stephenson's novel Cryptonomicon, Randy Waterhouse deals with a situation in which he can't use his computer monitor to read text by writing a program that outputs text through his keyboard LEDs via Morse code. Those three standard LEDs--Num Lock, Caps Lock, and Scroll Lock--have more potential to communicate information than most people realize.
What about other LEDs on your computer? Most PCs have no other LEDs except power and drive-access lights. The former are usually not software-controllable, as they are typically hard-wired in circuit with the actual power circuitry. So why not make a program that transmits Morse-code messages using your hard drive's access light?
This hack requires fairly low-level control of the activity of the hard drive. In some ways, it is a descendant of the "walking drive" hacks which used to be legendary in the days when hard drives were the size of washing machines; these hacks involved writing software to jiggle the mechanical actuator arm of a hard drive so rapidly that the drive actually scooted across the floor. Such a feat is mechanically impossible with the 3.5" hard drives commonly used in desktop PCs today, but it should be possible to control when the drive-access light comes on. This is easy enough when the computer is doing nothing but sitting there (all you need to do is read random blocks at specific intervals, which makes the access light turn on); for an added challenge, try writing drive-access routines that actually force the drive-access light to transmit Morse code during everyday computer usage. You obviously wouldn't want to do this on a production system since it would dramatically slow down drive-access times, but on a test system, it might be interesting.
PCs today are designed to be able to turn themselves off. This was an innovation introduced by the ATX PC architecture, which replaced the AT architecture that was standard in the late 1980s and early 1990s. An instance of this process is called a "soft-off," and it happens every time you tell your operating system to "Shut Down" and the computer turns itself off. Before ATX architecture, such things were not possible; it was necessary to turn the computer off using a mechanical switch which engaged or disengaged electrical contacts.
Can you modify your computer so that it can't soft-off? What does your operating system do if the computer just won't turn itself off? Do you remember (or have you ever seen in the first place) the "It's now safe to turn off your computer" messages which operating systems would show on AT-architecture computers which required the user to physically flip a switch to power-down? It shouldn't be that difficult to lock out the signal that causes a computer to soft-off, ensuring that your computer will never turn itself off without your consent. This could actually have practical use, as some viruses or worms may try to turn off your computer by calling the software interrupt routine which causes a computer to soft-off. Physically bypassing the wire that enables such behavior would prevent such malware from working.
Some caution is always warranted when you start playing with electrical-power hacks like this. Fortunately, ATX-architecture computers contain no high voltage within the main computer case; the only high voltage is found in the power supply itself. This is in contrast to AT-architecture computers, which actually had wall voltage brought out to the switch that would be used to turn the computer on and off. ATX computers are fairly safe to poke around inside as long as you don't open the power supply. (And observe static-electricity precautions, of course, as you're more likely to cause a harmful zap to the PC than it is to you.)
For a much more challenging and potentially dangerous electrical hack (WARNING: DO NOT attempt something like this if you don't know what you're doing!), try seeing how stable you can make your computer's power-line-filtering circuitry.
Any device which runs on digital electronics (like most desktop computers today) requires a rather stable stream of DC power. If these DC voltages vary outside of certain tolerances, the computer is likely to crash. Such voltage fluctuations can be instigated by surges or heavy loads plugged into the same branch circuit as the computer.
How stable can you make your PC in the presence of huge induction motors? Try plugging an electric air compressor into the same power outlet as your computer. Can you solder enough capacitors on the motherboard of the computer to keep it reliably running even when the motor is repeatedly started and stopped? How much filtering circuitry do you need? Will there be room to close the lid on the computer's case once all those passives are there? If so, can you keep things going with 10 air compressors all plugged into the same branch circuit and turned on simultaneously? Have a high-current workshop set up for this one, as almost every household in the world will rapidly blow its fuses or circuit breakers (if you're lucky) if you try this at home, kids.
Overvoltage experimentation can be fun, as well. Try getting a lightning rod and connecting it directly to the power lines that your PC plugs into. How good can you make your surge-suppression circuitry when lightning runs directly into the PC's power supply? You may need to modify the power supply somewhat, but part of the goal here is to get everything to fit in a standard form-factor PC without needing to give it a larger case. Most folks aren't willing to burn down multiple houses just for the sake of experimentation, so this is a good one to get right the first time.
Also try experimenting with variable-frequency equipment, such as the variable-frequency drives (VFDs) typically used to control large industrial induction motors. If plugged into the same branch circuit as a PC, VFDs tend to rapidly destroy the switching power supplies usually used in most PCs today. You may need to switch to a linear power supply on the PC for this one.
The upshot of all this is that when you're done, you'll have a PC which should readily be able to accept whatever surges, brownouts, or frequency transients the power company throws at it.
When you get right down to it, your computer's CPU is probably the most complex component of the system. The other circuitry has complexity of its own, but really, the CPU is where things go beyond the ability of a single person to comprehend everything that's going on.
So why not hack it?
I previously mentioned the idea of an IDE tap: A circuit which monitors your IDE channel and intervenes if desired. Why couldn't you do the same thing with your CPU? Nothing's stopping you from attaching lines to the CPU which will affect how it operates.
Remember the infamous Pentium floating-point division bug? Most people sat around and waited for Intel to release a version of the chip which had a fix built in, but there's no reason why people couldn't just make an in-series circuit that watches for the FDIV opcode (it's just a series of 1s and 0s, after all), does its own math, then passes the resultant quotient along to the data bus instead of accepting the answer which comes from the Pentium's own pins. There you go: Problem solved. No need to wait for the chip manufacturer to fix their own problems!
Similarly, the other infamous Intel CPU bug was the F00F bug, which would cause the CPU to enter an infinite loop that required a reboot to recover from. If you had a CPU with such a bug, all you'd need to do would be to put a hardware block in place which watched for that opcode and prevented it from ever reaching the CPU, probably replacing it with a simple NOP or something similar. Presto, problem eliminated. How easy can it get?
If your CPU has other opcodes you don't like, feel free to tap them out. Or, if you're bored with your CPU and think it needs a new architecture, just remove it altogether and clone it in an FPGA, which you can then tweak at the code level. Why tie yourself to a single manufacturer's manufacturing defects when you can debug your own core? It's a no-brainer: Building your own CPU makes sense.