If you know anything about how films are made then you have probably heard about the “green screen” before. The technique is also known as chroma key compositing, and it’s generally used to merge two images or videos together based on color hues. Usually you see an actor filmed in front of a green background. Using video editing software, the editor can then replace that specific green color with another video clip. This makes it look like the actor is in a completely different environment.
It’s no surprise that with computers, this is a very simple task. Any basic video editing software will include a chroma key function, but have you ever wondered how this was accomplished before computers made it so simple? [Tom Scott] posted a video to explain exactly that.
In the early days of film, the studio could film the actor against an entirely black background. Then, they would copy the film over and over using higher and higher contrasts until they end up with a black background, and a white silhouette of the actor. This film could be used as a matte. Working with an optical printer, the studio could then perform a double exposure to combine film of a background with the film of the actor. You can imagine that this was a much more cumbersome process than making a few mouse clicks.
For the green screen effect, studios could actually use specialized optical filters. They could apply one filter that would ignore a specific wavelength of the color green. Then they could film the actor using that filter. The resulting matte could then be combined with the footage of the actor and the background film using the optical printer. It’s very similar to the older style with the black background.
Electronic analog video has some other interesting tricks to perform the same basic effect. [Tom] explains that the analog signal contained information about the various colors that needed to be displayed on the screen. Electronic circuits were built that could watch for a specific color (green) and replace the signal with one from the background video. Studios even went so far as to record both the actor and a model simultaneously, using two cameras that were mechanically linked together to make the same movements. The signals could then be run through this special circuit and the combined image recorded all simultaneously.
There are a few other examples in the video, and the effects that [Tom] uses to describe these old techniques go a long way to help understand the concepts. It’s crazy to think of how complicated this process can be, when nowadays we can do it in minutes with the computers we already have in our homes. Continue reading “How Green Screen Worked Before Computers”
Developed in the very late 60s and through the 70s, the PDP-11 series of minicomputers was quite possibly the single most important computer ever created. The first widely distributed versions of Unix and C were developed on the PDP-11, and it’s hardware influence can be found in everything from the Motorola 68000 to the MSP430.
When [Dave Cheney] saw the recent 8086 simulator written in 4kB of C code, he realized simulating entire computer systems doesn’t actually require a whole lot of resources outside a big chunk of memory. Armed with an Arduino Mega clone, he set out on one of the coolest projects we’ve seen in a while: simulating a PDP-11 on an AVR.
[Dave] used an ATMega2560-powered Arduino Mega clone with an Ethernet module for the hardware of this build. Attached to it is a shield filled up with a pair of RAM chips that expand relatively limited amount of RAM on the ‘Mega.
So far, [Dave] has his simulated system booting Unix V6 off an SD card. For PDP-11 storage, he’s also simulating an RK05 disk drive, a massive 14 inch platter containing 2.5 Megabytes of data. Compared to the original PDP-11/40, [Dave] estimates his machine is about 10 times slower. Still, an original 11/40 system fills multiple server racks, and the most common installations consume several kilowatts of power. The Arduino Mega can fit in a pocket and can be powered over USB.
Future developments for this system include improving the accuracy of the simulator, running more advanced operating systems and the DEC diagnostic programs, and possibly speeding up the simulation. We’d suggest adding some switches and blinkenlights on an additional shield, but that’s just us.
All the code can be found on [Dave]’s git, with a description of his SPI RAM shield coming shortly.
Ah, the VT100, the first dumb terminal that was controlled with a microprocessor. This ancient beast from the late 70s is quite unlike the terminals you’d find from even five years after its vintage – the keyboard connects via a TRS quarter-inch jack – the electronic and code design of this terminal is a bit weird. [Seth] was up to the challenge of making this mechanical keyboard work as a standard USB device, so he created his own USB adapter.
On the little quarter-inch to USB adapter, [Seth] included an HD 6402 UART to talk to the keyboard, along with a Teensy dev board and a few bits of circuits stolen from DEC engineers. The protocol between the keyboard and terminal is a little weird – first the terminal sets a bit in a status word, then the keyboard scans all the key rows and columns in sequence before telling the terminal it’s done. Yes, this gives the VT100 full n-key rollover, but it’s just weird compared to even an IBM Model M keyboard that’s just a few years younger.
[Seth] finally completed his circuit and wired it up on a perfboard. Everything works just as it should, although a little key remapping was done to keep this keyboard adapter useful for Mac and Windows computers. It’s a wonderful bit of kit, and any insight we can get into the old DEC engineers is a wonderful read in any event.
Continue reading “USB adapter for an old VT100 keyboard”
This Digital IR Theremin creates tones based on the distance of an object from its IR sensor. There’s no microcontroller here, since the project is part of an Introduction to Digital Electronics course. Instead, it uses a handful of comparators, transistors, AND gates, and a 555 timer to make noise.
The comparators are connected to create window comparators. This configuration will output a digital 1 if the input is between two reference voltages, and 0 if it is not. Using this, the analog output of the IR range sensor can be converted to digital values.
The 555 timer takes care of creating the output waveform. A specific resistor is switched in to the timer’s RC circuit depending on which window comparator is active. This allows for a different tone to be played depending on the distance from the IR sensor.
The result is a square wave, which has a frequency dependant on how close an object is to the IR sensor. By selecting the right resistances for each distance, the theremin can be tuned to play a specific scale.
This is a neat project for people looking to learn digital electronics, and the write up does a great job of explaining the theory. After the break, check out a video of the theremin generating some tones.
Continue reading “Digital IR Theremin”
Unhappy with the 120 degree range of movement for this digital servo motor [Malte] set out to expand its flexibility. He settled upon a hack that alters the feedback potentiometer in order to give the motor a wider range (translated).
The test video (embedded after the break) shows tick marks for before and after his alterations. You can see that the wider tick marks get much closer to the 180 degree range he’s interested in. The control method is no different than it was before, the internal circuitry is still listening for a control signal with pulses between 1 and 2ms to establish the position of the servo horn. [Malte] added resistors on the two outside legs of the feedback potentiometer. This is what that control circuit measures in order to judge the position of the servo horn. He’s using 1.6k Ohm resistors in this demonstration. But he didn’t just drop them in willy-nilly. His writeup discusses the calculations he used to determine the target voltage for the motor position he wants.
Continue reading “Increasing a digital servo motor’s range of motion”
Random number generation is a frequent topic of discussion in projects that involve encryption and security. Intel has just announced a new feature coming to many of their processors that affect random number generation.
The random number generator, which they call Bull Mountain, marks a departure from Intel’s traditional method of generating random number seeds from analog hardware. Bull Mountain relies on all-digital hardware, pitting two inverters against each other and letting thermal noise tip the hand in one direction or the other. The system is monitored at several steps along the way, tuning the hardware to ensure that the random digits are not falling more frequently in one direction or the other. Pairs of 256-bit sequences are then run through a mathematical process to further offset the chance of predictability, before they are then used as a pseudorandom number seed. Why go though all of this? Transitioning to an all-digital process makes it easier and cheaper to reduce the size of microchips.
A new instruction has been added to access this hardware module: RdRand. If it works as promised, this should remove the need for elaborate external hardware as a random number source.
In our hands-on review of the Digilent chipKIT Uno32, we posed the question of what the lasting appeal might be for a 32-bit Arduino work-alike. We felt it needed some novel applications exploiting its special features…not just the same old Arduino sketches with MOAR BITS. After the fractal demo, we’ve hit upon something unique and fun…
Continue reading “chipKIT Sketch: Mini Polyphonic Sampling Synth”