Maybe we shouldn’t say “built” since [Steve Chamberlin] hasn’t actually heated up his iron yet. From the finished schematic above that is puzzling at first, until you realize the scope of the project. His Nibbler implements a 4-bit CPU using 7400 logic chips. Because he’s come up with the architecture himself he’s taking a lot of steps to check all of his work before committing to a PCB.
We linked to his category for the project which is still in progress. Most recently he wrote a program to prove that it’ll run on the hardware. That’s a feat considering this is still just a design idea. It was made possible because he wrote a simulator based on the design. The C++ tool simulates data and control buses and features a full set of debugging tools.
Careful testing of the design before the build is the best possible way to go. The simulator and debugging tools will be useful for software development even after the hardware is built. And testing before wiring is a must as these things get out of control quickly in terms of soldering complexity.
[via Dangerous Prototypes]
There are basically two ways to compute data. The first is with a DSP, a chip that performs very specialized functions on a limited set of data. These are very cheap, have amazing performance per watt, but can’t do general computation at all. If you’d like to build a general-purpose computer, you’ll have to go with a superscalar processor – an x86, PowerPC, or any one of the other really beefy CPU architectures out there. Superscalars are great for general purpose computing, but their performance per watt dollar is abysmal in comparison to a DSP.
A lot of people have looked into this problem and have come up with nothing. This may change, though, if [Ivan Godard] of Out-of-the-Box computing is able to produce The Mill – a ground-up rethink of current CPU architectures.
Unlike DSPs, superscalar processors you’d find in your desktop have an enormous amount of registers, and most of these are rename registers, or places where the CPU stores a value temporarily. Combine this with the fact that connecting hundreds of these temporary registers to places where they’ll eventually be used eats up about half the power budget in a CPU, and you’ll see why DSPs are so much more efficient than the x86 sitting in your laptop.
[Ivan]’s solution to this problem is replacing the registers in a CPU with something called a ‘belt’ – basically a weird combination of a stack and a shift register. The CPU can take data from any position on the belt, perform an operation, and places the result at the front of the belt. Any data that isn’t used simply falls off the belt; this isn’t a problem, as most data used in a CPU is used only once.
On paper, it’s a vastly more efficient means of general purpose computation. Unfortunately, [Ivan] doesn’t quite have all the patents in for The Mill, so his talks (two available below) are a little compartmentalized. Still, it’s one of the coolest advances in computer architecture in recent memory and something we’d love to see become a real product.
Continue reading “The Mill CPU architecture”
The two circular displays seen above are Dekatrons built into an optical drive enclosure. [Matt Sylvester] picked up a couple of different types of these tubes on eBay. He etched his own driver, and was able to control them with an Arduino. After a few months went by he decided to revisit the project to see if it would work as a CPU and RAM usage meter.
These tubes need high voltage to get the neon display glowing brightly. This raised some concerns about having those voltage levels inside of his PC, as well as the noise which may be introduced by the supply. To deal with those issues [Matt] gutted an old optical drive, using its case to physically isolate the circuitry, and some optoisolators to protect the logic connections. His driver board uses an ATmega328 running the Arduino bootloader. It connects to the PC using an FTDI USB to Serial cable. This makes it a snap to push the performance data to the display. It also has the side benefit of allowing him to reprogram the chip without opening the case.
If you can’t find one of these tubes for your own project consider faking it.
Continue reading “Drive bay form factor dual Dekatron readouts for RAM and CPU usage”
You’re going to like [Ivan’s] write-up for this LED computer status monitor. Of course he didn’t just show-and-tell the final product — if he had you’d be reading this in a Links post. But he also didn’t just detail how he put the thing together. Nope, he shared pictures and details of every iteration that got him here.
It started off with a tachometer. Yeah, that analog display you put on the dashboard of your car which reads out RPM. He wanted to make it into a USB device which would read out his CPU load. But that’s an awful lot of work when it can only display one thing at a time. So he decided to add an 8×8 LED module which would display the load for each individual core of his CPU. It looks great next to the illuminated tachometer. From there he added resolution by transitioning to an RGB module, which ended up sucking him into a coding project to extend the data pushed to his embedded hardware. In the end his ReCoMonB (Real Computer Monitoring Block) displays CPU load, RAM usage, several aspects of HDD activity, as well as the network up and down traffic.
We think he’s probably squeezed all that he can from this little display. Time to upgrade to a TFT LCD.
Continue reading “LED module used to display load, traffic, and status data for your PC”
The popularization of FPGAs for the hobbyist market means a lot more than custom LED controllers and clones of classic computer systems. FPGAs are also a great tool to experiment with computer architecture, creating new, weird, CPUs that don’t abide by the conventions the industry has used for 40 years. [Victor] is designing a new CPU that challenges the conventions of how to access different memory locations, and in the process even came up with a bit of example code that runs on an ARM microcontroller.
Most of the time, the machine code running on your desktop or laptop isn’t that interesting; it’s just long strings of instructions to be processed linearly. The magic of a computer comes through comparisons, an if statement or a jump in code, where the CPU can run one of two pieces of code, depending on a value in a register. There is the problem of reach, though: if a piece of code makes a direct call to another piece of code, the address of the new code must fit within an instruction. On an ARM processor, only 24 bits are available to encode the address, meaning a jump in code can only go 16 MB on either side of its call. Going any further requires more instructions, and the performance hit that comes along with that.
[Victor] decided a solution to this problem would be to create a bit of circuitry that would be a sliding window to store address locations. Instead of storing the literal address for jumps in code, every branch in the code is stored as a location relative to whatever is in the program counter. The result is an easy way to JMP to code very far away in memory, with less of a performance hit.
There’s an implementation for this sliding window token thing [Victor] whipped up for NXP’s ARM Cortex M3 microprocessor, and he’ll be working on an implementation of this concept in a new CPU over on his git.
[Quinn Dunki] pulled together many months worth of work by interfacing her GPU with the CPU. This is one of the major points in her Veronica project which aims to build a computer from the ground up.
We’ve seen quite a number of posts from her regarding the AVR-powered GPU. So far the development of that component has been happening separately from the 6502 centered CPU. But putting them together is anything but trivial. The timing issues that were so important to consider when developing the GPU get even hairier when it comes writing to the VRAM from an external component. Her first thought was to share a portion of the external RAM between the CPU and GPU as a way to push rendering commands from one to the other. This proved troublesome both in timing and in the number of pins available on the AVR chip. She ended up using something of a virtual register on the AVR chip that can receive commands from the CPU asynchronously. Timing dictates that these commands be written only during vertical blanking so this virtual register also acts as a status register to let the CPU know when it can send the next command.
Her post is packed with the theory behind the design, timing tests on the oscilloscope, and a rather intimidating schematic. But the most important part is the video showing her success in the end.
We’d bet everyone reading this article has played a game on an emulator at some time or another. And you may have a base idea of how those emulators work. But we’d wager the vast majority of you are clueless about the actual implementation of game emulators (we know we are). But that has all changed after seeing this demonstration of how [Bisqwit] wrote his own NES emulator. The description doesn’t cover anything more than the basics of writing code that emulates the NES CPU hardware itself. But it’s presented in such a way that makes it quite easy to understand for anyone who has a basic knowledge of programming. He starts with a switch statement for handling the processor’s opcodes and then moves through piece by piece showing how he refined his code to make it work while keeping it readable. We think this is a great teaching method and appreciate the time he put into producing this tutorial.
The explanation starts about 4:22 into the video which is embedded after the break. You’ll also find the first two demo videos there. Those involve mostly fast-motion text editing of the emulator coding process with some gameplay tests at the end of the second video.
Continue reading “Emulators 101: how to write a program that functions like an NES CPU”