[Tsvetan Usunov] has been Mr. Olimex for about twenty five years now, and since then, he’s been through a lot of laptops. Remember when power connectors were soldered directly to the motherboard? [Tsvetan] does, and he’s fixed his share of laptops. Sometimes, fixing a laptop doesn’t make any sense; vendors usually make laptops that are hard to repair, and things just inexplicably break. Every year, a few of [Tsvetan]’s laptops die, and the batteries of the rest lose capacity among other wear and tear. Despite some amazing progress from the major manufacturers, laptops are still throwaway devices.
Since [Tsvetan] makes ARM boards, boards with the ~duino suffix, and other electronic paraphernalia, it’s only natural that he would think about building his own laptop. It’s something he’s been working on for a while, but [Tsvetan] shared his progress on an Open Source, hacker’s laptop at the Hackaday | Belgrade conference.
Continue reading “The Open Source Hacker’s Laptop”
If you have a computer on your desk today, the chances are that it has an Intel architecture and is in some way a descendant of the IBM PC. It may have an Apple badge on the front, it may run Linux, or Windows, but in hardware terms the overwhelming probability is that it will be part of the Intel monoculture. A couple of decades ago though in the 16- and early 32-bit era you would have found a far greater diversity of architectures. Intel 3-, and 486s in PCs and clones, Macintosh, Commodore, and Atari platforms with the 68000 family, the WDC 65C816 in the Apple IIGS, and the Acorn Archimedes with an early ARM processor to name but a few.
In the tough environment of the 1990s most of these alternative platforms fell by the wayside. Apple survived to be revitalised under a returning Steve Jobs, Atari and Commodore withered under a bewildering succession of takeovers, and Acorn split up and lost its identity with its processor licensing subsidiary going on to power most of the mobile devices we take for granted today.
Surprisingly though some of the 16-bit platforms refused to die when their originators faded from view. In particular Commodore’s Amiga has lived on with new OS versions, new platforms, and community-supported hardware upgrades. News of just such a device came our way this morning, [Lukas Hartmann]’s MNT VA2000, a graphics card for the Amiga 2000 using a GPU implemented on an FPGA.
Continue reading “Bootstrapping an Amiga 2000 Graphics Card Because Vintage is Pricey”
Researchers at Binghamton University have built their own graphics processor unit (GPU) that can be flashed into an FGPA. While “graphics” is in the name, this GPU design aims to provide a general-purpose computing peripheral, a GPGPU testbed. Of course, that doesn’t mean that you can’t play Quake (slowly) on it.
The Binghamton crew’s design is not only open, but easily modifiable. It’s a GPGPU where you not only know what’s going on inside the silicon, but also have open-source drivers and interfaces. As Prof. [Timothy Miller] says,
It was bad for the open-source community that GPU manufacturers had all decided to keep their chip specifications secret. That prevented open source developers from writing software that could utilize that hardware. With contributions from the ‘open hardware’ community, we can incorporate more creative ideas and produce an increasingly better tool.
That’s where you come in. [Jeff Bush], a member of the team, has a great blog with a detailed walk-through of a known GPU design. All of the Verilog and C++ code is up on [Jeff]’s GitHub, including documentation.
If you’re interested in the deep magic that goes on inside GPUs, here’s a great way to peek inside the black box.
Have you ever started a project, run into an issue, started a new project to solve the issue, and completely forgot about the original project? [Andy] went down a rabbit hole of needing a tool to calibrate an MCU oscillator, but not having an accurate way to measure frequency. Most people would just buy a frequency counter and be done with it, but [Andy] decided to build his own.
The Nanocounter is an accurate, open source frequency counter that uses an Android phone as its display. It’s based on a high accuracy temperature compensated crystal oscillator (TCXO) fed into a phase locked loop (PLL) to create a high frequency, accurate reference clock.
This reference clock, along with the signal to be measured, are sent into a Xilinx FPGA which uses a method called equal precision measurement to determine the frequency. A STM32F072 microcontroller uses a SPI interface to get this data out of the FPGA, and controls the whole system. Finally, a cheap HC-06 Bluetooth module facilitates communication with an Android device.
The project achieves the goal of frequency counting, though [Andy] doesn’t remember what project sparked the idea to build it. (Classic yak shaving!) But the result is a great read of a detailed writeup, and you can watch a video of the Nanocounter in action after the break. That’s a win in our book.
Continue reading “Nanocounter: Frequency Counter with an Android UI”
We have talked about a whole slew of logic and interconnect technologies including TTL, CMOS and assorted low voltage versions. All of these technologies have in common the fact that they are single-ended, i.e. the signal is measured as a “high” or “low” level above ground.
This is great for simple uses. But when you start talking about speed, distance, or both, the single ended solutions don’t look so good. To step in and carry the torch we have Differential Signalling. This is the “DS” in LVDS, just one of the common standards throughout industry. Let’s take a look at how differential signaling is different from single ended, and what that means for engineers and for users.
Single Ended: TTL, CMOS, LVTTL, Etc.
Single Ended and Sources of Noise
Collectively, standards like TTL, CMOS, and LVTTL are known as Single Ended technologies and they have in common some undesirable attributes, namely that ground noise directly affects the noise margin (the budget for how much noise is tolerable) as well as any induced noise measured to ground directly adds to the overall noise as well.
By making the voltage swing to greater voltages we can make the noise look smaller in proportion but at the expense of speed as it takes more time to make larger voltage swings, especially with the kind of capacitance and inductance we sometimes see.
Enter Differential Signaling where we use two conductor instead of one. A differential transmitter produces an inverted version of the signal and a non-inverted version and we measure the desired signal strictly between the two instead of to ground. Now ground noise doesn’t count (mostly) and noise induced onto both signal lines gets canceled as we only amplify the difference between the two, we do not amplify anything that is in common such as the noise.
Continue reading “When Difference Matters: Differential Signaling”
Many successful large-scale projects don’t start out large: they start with a small working core and grow out from there. Building a completely open-source personal computer is not a weekend project. This is as much a retelling of events as it is background information leading up to a request for help. You’ll discover that quite a lot of hard work has already been put forth towards the creation of a completely open personal computer.
When I noticed the Kestrel Computer Project had been submitted via the Hackaday tips line I quickly tracked down and contacted [Samuel] and asked a swarm of questions with the excitement of a giddy schoolgirl. Throughout our email conversation I discovered that [Samuel] had largely kept the project under the radar because he enjoyed working on it in his down time as a hobby. Now that the project is approaching the need for hardware design, I posed a question to [Samuel]: “Do you want me to write a short article summarizing years of your work on Kestrel Project?” But before he could reply to that question I followed it up with another: “Better yet [Samuel], how about we tell a more thorough history of the Kestrel Project and ask the Hackaday community for some help bringing the project home!?”
Continue reading “Kestrel Computer Project”
I’ve worked with a lot of students who want to program computers. In particular, a lot of them want to program games. However, when they find out that after a few weeks of work they won’t be able to create the next version of Skyrim or Halo, they often get disillusioned and move on to other things. When I was a kid, if you could get a text-based Hi-Lo game running, you were a wizard, but clearly the bar is a lot higher than it used to be. Think of the “Karate Kid”–he had to do “wax on, wax off” before he could get to the cool stuff. Same goes for a lot of technical projects, programming or otherwise.
I talk to a lot of people who are interested in CPU design, and I think there’s quite a bit of the same problem here, as well. Today’s commercial CPUs are huge beasts, with sophisticated memory subsystems, instruction interpreters, and superscalar execution. That’s the Skyrim of CPU design. Maybe you should start with something simpler. Sure, you probably want to start learning Verilog or VHDL with even simpler projects. But the gulf between an FPGA PWM generator and a full-blown CPU is pretty daunting.
Continue reading “Crawl, Walk, Run: Planning Your First CPU Design”