[Sprite_TM] had a Vectrex console that he wanted to play with. Alas, his makeshift multicart had fallen into disrepair. Rolling up his hacking sleeves, he set about making a new one, a better one. His PCB design included his microcontroller of choice: the ST STM32F411, a 32-bit 100Mhz ARM Cortex M4, along with a 16MB SPI flash chip. [Sprite_TM] wanted to make programming games onto the multicart simple. Using the libopencm3 firmware library for the STM in conjunction with Elm-Chans FatFS, the multicart could be plugged into a computer’s USB port and have any game data dragged and dropped onto it like a USB stick. The PCB then connects directly into the Vectrex’s cartridge port. The first cartridge file is a basic menu that lists all of the game ROMs stored in the flash memory. When the user selects the game the STM loads that ROM file which the menu software then boots.
After loading his entire Vectrex ROM library onto the multicart, [Sprite_TM] realized he had far too much space left over – so he decided to add some extras. His first choice was Bad Apple (YouTube link), a music video made by fans of the Touhou Project game series. The video features black and white silhouettes of the many game characters in a shadow art style. Since its debut, Bad Apple has been ported from everything from the Sega Genesis (YouTube link) to laser scanners (YouTube link). It was time for the Vectrex to join the list.
After ripping the video from YouTube, [Sprite_TM] used MPlayer to save each frame as a PNG along with a wave file of the music. Next, he ran Potrace on the PNG files to get vector versions. Using a custom PHP script, the resulting JSON file was post-processed into relative vectors the Vectrex uses. Digital audio was possible by having the Vectrex’s 8-bit DA-converter perform double duty both for the video circuit and the audio. However, the volume must be turned to the max in order to hear the music. Incidentally, the DAC can only output audio in this scenario when vectors are not being drawn, so the event timing needed to be adjusted. The video and audio data was re-parsed after a modified version of VecX was used to get the timing events synchronized before transferring Bad Apple onto the multicart.
You can see the Vectrex version of Bad Apple after the break, along with a 3D-engine based on Doom levels. The engine is written in C and makes use of the Z-buffer, creating the effect of solid 3D-objects in front of each other. There are no weapons or enemies to dispatch here, but the effect is impressive nonetheless.
Continue reading “Extreme Vectrex Multicart Plays Bad Apple”
We keep wondering where the Arduino world is headed with the hardware getting more and more powerful. If the IDE doesn’t keep up what’s the point? Now we have at least one answer to that problem. Energia is the Arduino-like-framework for Texas Instruments based boards. They just came out with a multitasking system built into Energia targeted at the ARM Cortex-M4F based MSP432 Launchpad which we covered a few weeks back.
The announcement post gives a couple of examples of uses for multitasking. The simplest is blinking LEDs at different rates. If you wanted to do this closer to the metal you’re talking about multiple timers, or multiple compares on a single timer, perhaps a interrupt-driven-system-tick that has a high enough resolution for a wide range of your blinking needs. But these are not always easy to set up unless you are intimately comfortable with this particular architecture. The Energia multitasking will handle this for you. It’s upon the TI Real Time Operating System (TI-RTOS) but wraped in the familiar IDE.
The UI divorces you from thinking about the hardware at all. You simply launch a new tab and start coding as if you’re using a completely separate piece of hardware. The announcement post linked above mentions that these Sketches are running “in parallel”. Well… we know it’s not a multi-core system like the Propeller but we’ll let it slide. It is certainly easier than building your own scheduler for this type of hardware.
Like just about everyone we know, [Luis] decided a gigantic RGB LED matrix would be a cool thing to build. Gigantic LED matrices are very hard to build, though: not only do you have to deal with large power requirements and the inevitable problems of overheating, you also need to drive a boat load of LEDs. This is not easy.
[Luis] found a solution to the problem of driving these LEDs with a new, fancy ARM Cortex M4 microcontroller. All Cortex M4 ARMs have DMA, making automatic memory transfers to peripherals and LED strips a breeze.
The microcontroler [Luis] is using only supports 1024 transfers per transfer set, equating to a maximum of 14 LEDs per transfer. This problem can be fixed by using the ping-pong mode in the DMA controller by switching between data structures for every DMA request. Basically, he’s extending the number of LEDs is just switching between two regions of memory and setting up the DMA transfer.
The result is much better than [Luis]’ original circuit that was just a bunch of SPI lines. It also looks really good, judging by the video below. It’s not quite a gigantic LED matrix yet, but if you want to see what that would look like, check out the huge 6 by 4 foot matrix hanging in the Hackaday overlord office.
Continue reading “The Possibility Of Driving 16,000 RGB LEDs”
A word clock – a clock that tells the time with illuminated letters, and not numbers – has become standard DIY electronics fare; if you have a soldering iron, it’s just what you should build. For [Chris]’ word clock build, he decided to build an RGB word clock.
A lot has changed since the great wordclock tsunami a few years back. Back then, we didn’t have a whole lot of ARM dev boards, and everyone’s grandmother wasn’t using WS2812 RGB LED strips to outshine the sun. [Chris] is making the best of what’s available to him and using a Teensy 3.1, the incredible OctoWS2812 library and DMA to drive a few dozen LEDs tucked behind a laser cut stencil of words.
The result is blinding, but the circuit is simple – just a level shifter and a big enough power supply to drive the LEDs. The mechanical portion of the build is a little trickier, with light inevitably leaking out of the enclosure and a few sheets of paper working just enough to diffuse the light. Still, it’s a great project and a great way to revisit a classic project.
Conventional wisdom says small, powerful embedded Linux like the Raspberry Pi, Beaglebone, or the Intel Edison are inherently manufactured devices, and certainly not something the homebrew tinkerer can produce at home. [hak8or] is doing just that, producing not one, but two completely different tiny Linux computers at home.
The first is based on Atmel’s AT91SAM9N12 ARM processor, but the entire board is just about two inches square. On board is 64 MB of DDR2 DRAM, a USB host and OTG port, and not much else. Still, this chip runs a stripped down Linux off of a USB drive.
The second board is based on the Freescale i.MX233. This board is similar in size and capabilities, but it’s not exactly working right now. There’s an issue with the DRAM timings and a capacitor underneath the SD card is a bit too tall.
The real value of [hak8or]’s project is the incredible amount of resources he’s put into his readme.mds for these repos. If you’ve ever wanted to build an embedded Linux device, here’s your one-stop shop for information on booting Linux on these chips.
Texas Instruments’ MSP430 series of microcontrollers has been the standard extremely low power microcontroller for several years now. It’s not an ARM, though, so while there are fans of the ‘430, there aren’t a lot of people who would want to port their work in ARM to a completely different architecture. Here is TI’s answer to that. It’s called the MSP432, and it combines the low power tech of the ‘430 with a 32-bit ARM Cortex M4F running at 48MHz.
This is not the first ARM Cortex M4F platform TI has developed; the Tiva C series is based on the Cortex M4F core and was released a few years ago. The MSP432 is a little bit different, leveraging the entire development system of the MSP430 and adding a DSP engine and a FPU. If you’re looking for something that’s low power but still powerful, there you go. You can find the official press release here.
If you’d like to try out the MSP432, there’s a LaunchPad available. $13 to TI gets you in the door. The most capable MSP432 with 256 kB of Flash, 64 kB of SRAM, and 24 ADC channels hasn’t hit distributors yet, but you can sample it here.
Microcontroller Dev Boards have the main hardware choices already made for you so you can jump right into the prototyping by adding peripherals and writing code. Some of the time they have everything you need, other times you can find your own workarounds, but did you ever try just swapping out components to suit? [Andy Brown] documented his process of transplanting the clock crystal on an STM32F4 Discovery board.
Even if you don’t need to do this for yourself, the rework process he documented in the clip after the break is fun to watch. He starts by cleaning the through-hole joints of the crystal oscillator with isopropyl alcohol and then applies some flux paste to each. From there the rest is all hot air. The crystal nearly falls out due to gravity but at the end he needs to pluck it out with his fingers. We’re happy to see others using this “method” as we always feel like it’s a kludge when we do it. Next he grabs the load caps with a pair of tweezers after the briefest of time under the heat.
We’d like to have a little bit of insight on the parts he replaces and we’re hoping there are a few crystal oscillator experts who can leave a comment below. [Andy] calculates a pair of 30pf load caps for this crystal. We understand the math but he mentions a common value for board and uC input capacitance:
assuming the commonly quoted CP + CI = 6pF
So we asked and [Andy] was kind enough to share his background on the topic:
It’s a general “rule of thumb” for FR4 that the stray capacitance due to the traces on the board and the input (lead) capacitance of the the MCU is in in the range of 4-8pF. I’m used to quoting the two separately (CP,CI) but if you look around you’ll see that most people will combine the two and call it just “CP” and quote a value somewhere between 4 and 8pF. It’s all very “finger in the air” and for general purpose MCU clocks you can get away picking the mid-value and be done with it.
That leaves just one other question; the original discovery board had an in-line resistor on one of the crystal traces which he replaces with a zero ohm jumper. Is it common to include a resistor and what is the purpose for it?
Continue reading “Swapping Dev Board Crystals to Suit Your Needs”