Dubbed the “Robot Radio” by [Brek], this clinking-&-clunking project merges three generations of hackers’ favorite technologies: robots, vacuum tubes, and microcontrollers. After the human inputs the desired radio frequency the machine chisels its way through the spectrum, trying its best to stay on target.
This build began its life as a junky old tube radio that [Brek] pulled out of a shed. The case was restored and then the hacking began. Inserted between the human and the radio, a PIC 16F628A keeps watch in both directions. On one side, the radio’s tank circuit is monitored to see what frequency the radio is currently playing. On the other, the human’s input sets a desired frequency. If the two do not match, the PIC tells a stepper motor to begin cranking a pair of gears until they do.
Another interesting feature is that as the tubes and other electronics warm up and change their values, the matching circuit will keep them in line. [Brek] shows this in the video by deliberately sabotaging the gears and seeing the robot adjust them back where they belong.
As an afterthought, the Robot Radio was supplemented with a module that adds 100khz to the signal so that the information from a nearby airport can be received.
[Brek] styled the whole machine up with some copper framing and other bits, similar to his spectacular atomic clock build we featured last month.
See the video of the radio tuning after the break.
Continue reading “Robotically-Tuned Tube Radio”
The NeXT slabs and cubes were interesting computers for their time, with new interesting applications that are commonplace today seen first in this block of black plastic. Web browsers, for example, were first seen on the NeXT.
Running one of these machines today isn’t exactly easy; there are odd video connectors but you can modify some of the parts and stick them in an LCD monitor. It’s a tradeoff between a big, classic, heavy but contemporary CRT and a modern, light, and efficient LCD, but it’s still a great way to get a cube or slab up and running if you don’t have the huge monitor handy.
The NeXT cube doesn’t have a single wire going between the computer and the monitor; that would be far too simple. Instead, a NeXT Sound Box sits between the two, providing the user a place to plug the monitor, keyboard, mouse, and audio connectors into. [Brian] took the board from this Sound Box and put it inside an old NEC LCD monitor he had sitting around. 12V and 5V rails were wired in, the video lines were wired in, and [Brian] created a new NeXT monitor.
There are two versions of the NeXT Sound Box – one for ADB peripherals (Apple IIgs and beige Macs), and another for non-ADB peripherals. [Brian] also put together a tutorial for using non-ADB peripherals with the much more common ADB Sound Board.
When an air quality display project needed a display, [Inderpreet] looked into small character-based LCDs. [Inderpreet’s] chosen LCD used an I2C interface, which was new to him. Rather than shy away, [Inderpreet] grabbed his Bus Pirate and dove in!
I2C or Inter-Integrated Circuit serial interfaces are often mentioned here on Hackaday. They generally are easy to use, but as with all things, there are little gotchas which can make the road a bit more bumpy the first time you travel it. One of those things is voltage interfacing – I2C uses bidirectional open drain lines, so interfacing 3.3 V and 5V circuits requires a voltage level shifter circuit designed to handle that requirement. Thankfully in [Inderpreet’s] case, both his TI launchpad target devboard and the LCD used 3.3 volt logic levels.
Before using the TI though, [Inderpreet] wanted to test with the Bus Pirate first. This would allow him to verify the hardware, and to make sure he was correctly using the I2C bus. The Bus Pirate can operate at 3.3V or 5V logic levels, and has on-board programming specific to the I2C bus. Controlling the Bus Pirate is as easy as hooking up a serial terminal program and plugging in a USB cable.
The I2C bus protocol is relatively simple, but can still be confusing to a new user. Each transaction needs an address, read/write bit, and a start command sent in the proper sequence before the data bytes can begin flowing. There are also acknowledge bits which prove that the data bytes are actually being received by the LCD. The Bus Pirate made all this easy, allowing [Inderpreet] to quickly display “Hello” on his LCD module.
The I2C bus is just the tip of the iceberg for the Bus Pirate. If you’re interested in learning more, check it out over at The Hackaday Store!
[via Dangerous Prototypes]
The Apple I, [Woz]’s original, had about sixty chips on a single board. Most of these chips were logic glue or hilariously ancient DRAMs. The real work was done by the 6502, the 6821 PIA, and the Signetics video chip. It’s a simple computer, really, and following the now popular tradition of two-chip computers, [Dave] built a replica of the Apple I using a 6502 and an ATMega.
The ATMega in this project takes care of everything – the 4k of RAM, the few bytes of ROM, the IO, and even the clock. With the 6502 you can have a little bit of fun with the clock; because the 6502 reads data off the bus a few nanoseconds off the falling edge of the clock and writes on the rising edge, [Dave] played around with the duty cycle of the clock to give the ATMega a bit more time to do its thing. With a 50% duty cycle, the 16Mhz ‘Mega has about eight cycles to decode an address and read or write some data. By making the low part of a clock cycle longer, he has about 45 cycles on the ‘Mega to do all the work. All of this was inspired by a fantastic tutorial on the 6502 clock.
Right now [Dave] has some hex values displaying on a small LCD, while the real I/O is handled by a serial connection to a computer. It’s retro enough, and a future update will include a faux cassette interface, possibly using an SD card for storage.
The old cartridges for the Commodore 64 use EEPROMs to store their data, and the newer Flash carts use either a Flash chip or an SD card to put a whole bunch of games in a small plastic brick. [Stian] and [Runar] thought that wasn’t good enough – they wanted to program cartridges in real time, the ability to reboot the C64 without ever touching it, and a device for coding and testing. What they came up with is the latest advance in Commodore cartridge technology.
The device presents 8k of memory to the C64, but it doesn’t do this with Flash or an EEPROM. Instead, [Stian] and [Runar] are using a dual-port static RAM, specifically one from the IDT7005 series. This chip has two data busses, two address busses, and /CE, /OE, and R/W lines for either side of the chip, allowing other digital circuits to be connected to one small section of the C64’s memory.
Also in the cart is an ATmega16 running V-USB to handle the PC communications. It takes about 1 to 1.5 seconds to transfer an entire 8k over to the cartridge, but this chip can read and write the RAM along with the C64 simultaneously.
If you want a box that will give you the ability to put ever game in existence on a single cartridge, this isn’t the one. However, if you want to write some C64 games and do some live debugging, this is the one for you. The Eagle files are available, and there’s a video demo below.
Continue reading “Dual Porting a C64 Flash Cart”
The Macintosh Classic – a small all-in-one computer with a 9″ monochrome screen – was one of the more interesting machines ever released by Apple. It was the company’s first venture into a cost-reduced computer, and the first Macintosh to sell for less than $1000. Released in 1990, its list of features were nearly identical to the Macintosh Plus, released four years earlier. The Classic also had an interesting feature not found in any other Mac. It could boot a full OS, in this case System 6.0.3, by holding down a series of keys during boot. This made it an exceptional diskless workstation. It was cheap, and all you really needed was a word processor or spreadsheet program on a 1.44 MB floppy to do real work.
[Steve] over at Big Mess O’ Wires had the same idea as the Apple engineers back in the late 80s. Take a Macintosh Plus, give it a bit more ROM, and put an OS in there. [Steve] is going a bit farther than those Apple engineers could have dreamed. He’s built a rewritable ROM disk for the Mac Plus, turning this ancient computer into a completely configurable diskless workstation.
The build replaces the two stock ROM chips with an adapter board filled with 29F040B Flash chips. They’re exactly what you would expect – huge, old PDIPs loaded up with Flash instead of the slightly more difficult to reprogram EEPROM. Because of the additional space, two additional wires needed to connected to the CPU. The result is a full Megabyte of Flash available to the Macintosh at boot, in a computer where the normal removable disk drive capacity was only 800kB.
The hardware adapter for stuffing these flash chips inside a Mac Plus was made by [Rob Braun], while the software part of this build came from [Rob] and [Doug Brown]. They studied how the Macintosh Classic’s ROM disk driver worked, and [Rob Braun] developed a stand-alone ROM disk driver with a new pirate-themed startup icon. [Steve] then dug in and created an old-school Mac app in Metrowerks Codewarrior to write new values to the ROM. Anything from Shufflepuck to Glider, to a copy of System 7.1 can be placed on this ROM disk.
This isn’t the first time we’ve seen ROM boot disks for old Macs. There was a lot of spare address space floating around in the old Mac II-series computers, and [Doug Brown] found a good use for it. Some of these old computers had optional ROM SIMM. You can put up to 8 Megabytes in the address space reserved for the ROM, and using a similar ROM disk driver, [Doug] can put an entire system in ROM, or make the startup chime exceptionally long.
This is a wonderful example of the phenomenon of “feature creep”. [Gert] was working on getting a VGA output running on an mbed platform without using (hardly) any discrete components. Using only a few resistors, the mbed was connected to a VGA display running at 640×480. But what could he do with something with VGA out? He decided to emulate an entire Sinclair ZX81 computer, of course.
With more than 1.5 million units sold, the Sinclair ZX81 was a fairly popular computer in the early ’80s. It was [Gert]’s first computer, so it was a natural choice for him to try to emulate. Another reason for the choice was that his mbed-VGA device could only output monochrome color, which was another characteristic of the ZX81.
[Gert] started by modifying a very lean Z80 emulator to make the compiled code run as efficiently as possible on the mbed. Then he went about getting a picture to display on the screen, then he interfaced an SD card and a keyboard to his new machine. To be true to the original, he built everything into an original ZX81 case.
This isn’t the first time we’ve seen a ZX81, but it is one of the better implementations of an emulated version of this system we’ve seen.
Thanks to [Jeroen] for the tip!