Posted on December 29, 2015
Ever upgraded your laptop, and wished that you could use the screen on the old laptop for something useful? I feel like I’ve seen a lot of posts on the internet, and myself have looked into reusing the bits and pieces from old machines so as not to throw them away with still working parts inside!
I recently nabbed a severely water-damaged macbook pro 17″ (mid-2009) from the e-waste pile at work. Someone had already taken the hard drive and memory from the machine, but there was still a perfectly functional screen in there, so I took it home. These displays have a 1920×1200 panel inside. Mine in particular happens to be a Samsung LTN170CT10-105, which has an LED backlight and a nice matte finish. It’s still a TN panel (not a nice IPS like my x220 has), but it still looks pretty good.
The big difference with laptop displays vs. your average desktop computer monitor is that they don’t have a standardized connector. Most of them these days are LVDS, but LVDS doesn’t describe the LCD timings, just the method of signaling to the display. There are also a number of different varieties of tiny delicate connectors to plug into the display. For laptop manufacturers this isn’t a problem since you aren’t going to be swapping LCDs all the time, you just need to drive the one display with one set of timings, and doing it this way eliminates chips to convert to a standard like DVI and back again, lowering your BOM and thus your price point. This is why it’s complicated to rip a laptop LCD off the laptop and just use it like a monitor – it doesn’t have that ability! You need to add some intelligence in between since the laptop’s video card is specifically designed or programmed to send out the correct signals for the LCD of that device. I think this is beginning to change now that some newer displays, notably the Retina iPad display, come with embedded DisplayPort on board which makes interfacing to them much less of a pain. The ever-awesome Adafruit sells them as the Qualia 9.7, if you’re interested!
I did a bit of research, and I found out that someone seems to have decided the market niche for reusing laptop displays is worth pursuing. There are loads of auctions on ebay for different variants of the M.NT68676.2A boards, which are capable of being loaded with different timings for nearly any LCD using an LVDS connection with up to 2048×1152 resolution. I found an auction for the M.NT68676.2A board, plus a backlight driver board, the correct LVDS cable, and a control button board for about $50CAD, which already had the timings for my Samsung display programmed into it. Plug and play:
Once the board arrived, I (very excitedly!) plugged it into the monitor, and it worked right away. Perhaps it was lucky, but it was super easy to get working. The driver chip supports RGB adjustment, so I may even throw a white frame up and see if I can get it close to accurate with the spectrophotometer at work.
The bulk of the work of this project has been in attaching the driver boards and constructing a stand for it. The eventual goal is to have the stand work somewhat like an ipad smart cover, but made out of fabric-wrapped acrylic. The first step was to mount the new electronics to the monitor, which required some new holes in the nice shiny machined aluminum – the slots are for the LVDS data cable and the backlight power cable:
And then with the boards attached:
After that, I decided I was going to need some protectors for my spanky new electronics, which I quickly whipped up in inkscape and cut on the hacklab laser cutter. I also cut two pieces of acrylic for the front, one which attaches to the screen’s original hinges (to allow it to fold up), and one which will fold under the first piece to act as a stand. Here’s what that looks like:
The final step is to wrap everything in fabric to hold it together. The fabric will attach with high-strength spray adhesive, and also acts as a ‘hinge’ to allow the cover to flip down and under to support the whole thing. Here’s what it looks like, with bonus cute cloud fabric:
I’m super pleased with how this project turned out! It’s great when doing things that require a little more space than the 1366×768 resolution of my thinkpad, like pcb layout (which I am soon to be doing a lot of) or writing code where I need to have an API reference available – or as a Raspberry PI monitor for the initial stages of configuration.
I’ve posted the inkscape files I used to my github – they are pretty specific to this particular project, but if anyone’s doing a similar thing perhaps they’ll be helpful!
Posted on December 23, 2015
I’ve been working on this for some time now, but it’s finally at a stage where I understand what I’m doing well enough to start documenting it out loud.
For years I’ve wanted to build a CPU from scratch. There are no direct benefits to this, although many, many people have done so before. The best part of taking on a project like this, for me anyhow, is that it forces you to think about the design considerations of all the many features and pieces that can go into a device as complicated as a CPU. How many registers should you have? How much addressable RAM will there be? What kind of arithmetic and logic operations need to be supported?
For the Retron-1, I wanted to keep things relatively simple, while still incorporating some concepts that I didn’t fully understand. By having a hardware-controlled stack, for instance, I was forced to think about and learn how a stack integrates with the rest of a system and the ways in which it might be used within a program. I’ve tried to keep the overall CPU simple, and my main inspiration for the device has been the humble 6502. I spent some time learning about how the PDP-11, PDP-8, Z80, and 8080 chips worked as well though, to try and get a broad understanding of the sorts of features I might want to include before settling down on the finer points of the design.
The Retron-1 is a TTL CPU, which will hopefully run around 1MHz when complete. With the exception of the EEPROMs and SRAM, the entire design is implemented in 74xx logic. The main data bus is 8 bits wide, as are all the general-purpose registers (ACC, X, Y, MEM_U, MEM_L). The program counter is 16 bits, allowing for addressing up to 64kb of memory. I/O devices are memory mapped directly into the CPU’s memory space, and share the memory using interrupts. The ALU is composed of two 74181 chips, which are 4-bit ALUs with a carry output allowing them to be chained together. The CPU is microcoded, meaning that even at its basest level, it is reprogrammable. The microcode is held in 3 quartz-windowed 8-bit EEPROMs, rom0, rom1, and rom2. There are 255 total possible opcodes, though not all of them are used. Where possible, I’ve attempted to make the instruction set orthagonal so that it’s easier to program.
The best part of a microcoded CPU architecture for this build case is that if I find myself needing an instruction, I can write a new one if the hardware facilities exist to support it. In addition, it makes the overall logic of the CPU simpler since most of the decoding of instructions is done via the control lines coming out of the ROMs instead of a complicated series of logic.
The initial design pass was done using a piece of software called Logisim, which simulates logic gates, as well as providing memory and chip design features as well. Using Logisim, I could find the 74xx part that performed the function I needed, look up its datasheet, and then recreate it as a chip within Logisim. This means that even at the most basic level, I have some awareness of each and every gate that is working away inside the CPU. In the future I would certainly consider using an HDL, however to keep the new concepts to a minimum I thought it best to go with something that was a little easier on my brain while I was pondering how to implement things like registers and program counters.
I’ve also got a few python scripts which have been really helpful. One, microcode_builder.py does as it says – it builds microcode ROM files to load into Logisim. Once I’m ready to do so, I’ll modify it to also output ROM files to be burned to an EEPROM. Within this file, each instruction has its own stanza, which defines the microcode steps required to define a given instruction. I’ll write up how this works at another time, but the basic gist of things is that it allows me to concisely control the lines coming out of each ROM in an abstracted way, so that I can specify, for example, which register to set and what value (memory, another register, etc.) to set it to. Or I can control what the ALU is doing for that particular clock tick.
Secondly, I’ve written a very basic assembler. I don’t plan to put much work into this project since the ideal would be to have a self-hosting assembler at some point once the CPU is up and running, though it has been helpful for troubleshooting instructions – it’s much easier to code assembly in opcodes than by typing the hex value of instructions into RAM by hand!
The github for this project is available here, and now that I’ve mostly completed the software simulation of the CPU, the next step is to start prototyping hardware. I’m fully certain that because I don’t fully understand the design considerations of complicated circuits, I’ve made a few errors that won’t translate well to actual hardware in the Logisim version of the CPU. Because of this, I’m expecting the design to change considerably and so I’m going to be making a breadboard for each sub component and testing that it behaves the way I want. Then, I’ll draw the schematics out in something like EAGLE or KiCAD and homebrew some PCBs! The cost of having 5-10 large boards done with a professional house is prohibitive, so it’s going to make a lot more sense to etch my own.
And there you have it – the basics of the Retron. I expect to be posting more frequent status updates soon as I begin the trial and error process of prototyping!
Posted on December 15, 2015
I work in a basement. The job is pretty sweet but the view sucks sometimes. There is, however, a window in one of our machine rooms where nobody really goes. So I decided to make use of it to at least be able to see what it’s like outside, even if I can’t look out the window myself.
I bought a raspberry pi camera from aliexpress for ~15USD, and plugged it into the raspberry pi I already have in that window – I’m using a canon point and shoot camera to do a timelapse of the building construction going on next door already, so adding a camera to the pi was easy to do.
I also picked up two 9g servo motors from aliexpress, and 3d printed a bracket to hold everything together. The bracket was designed in the excellent openSCAD software, and the files are available here.
I was also pleasantly surprised to see that there is a very easy to use raspberry pi webcam package that’s easy to install. It’s available at elinux.org. For servo control, you’ll need a separate 5V power supply (I have tons of these kicking around – just make sure you set the voltage before using them in a circuit!) and the servoblaster package. Connect each axis to a GPIO pin on the pi, give the servos power, and enable the directional controls, and you’ve got a pan/tilt webcam.
The best part of the whole project was the ready availability of good software to run things. Now I can check to see if the rain has stopped before running out for lunch, or just keep an eye on how dark it is so my brain knows what to expect when leaving the basement!