It might be difficult for modern audiences to believe, but at one point Microsoft Windows fit on floppy disks. This was a simpler time, with smaller hard drives, lower resolution displays, and no hacker blogs for you to leave pessimistic comments on. A nearly unrecognizable era, to be sure. But if you’re one of the people who looks back on these days fondly, you might wonder why we don’t see this tiny graphical operating system smashed into modern hardware. After all, SkiFree sure ain’t gonna play itself.
Well, wonder no more. A hacker by the name of [redsPL] thought that Microsoft’s latest and greatest circa 1992 might do well crammed into the free space remaining on a ThinkPad X200’s firmware EEPROM. It would take a little fiddling, plus the small matter of convincing the BIOS to see the EEPROM as a virtual floppy drive, but clearly those are all minor inconveniences for anyone mad enough to boot their hardware into a nearly 30 year old copy of Visual Basic for a laugh.
The adventure starts when [redsPL] helped a friend install libreboot and coreboot on a stack of old ThinkPads by using the Raspberry Pi as an SPI flasher, a pastime we’re no strangers to ourselves. Once the somewhat finicky software and hardware environment was up and running, it seemed a waste not to utilize it further. Especially given the fact most firmware replacements only fill a fraction of the X200’s 8 MB chip.
Of course, Windows 3.1 was not designed for modern hardware and no proper drivers exist for much of it. Just getting the display resolution up to 1024×768 (and still with only 256 colors) required patching the original video drivers with ones designed for VMWare. [redsPL] wasn’t able to get the sound hardware working, but at least the PC speaker makes the occasional buzz. The last piece of the puzzle was messing around the
xz commands until the disk image was small enough to sneak onto the chip.
Believe it or not, this isn’t the first time we’ve seen Windows from this era running on a (relatively) modern ThinkPad. For whatever reason, these two legends of the computing world seem destined to keep running into each other.
[Thanks to Renard for the tip.]
What if you didn’t have to risk your life to disconnect the power during a catastrophic storm? That’s a question many people in Houston were asking themselves as they watched water from Hurricane Harvey and other storms surge through the streets, swell in the gutters, and flood their homes.
Among these Houstonians were engineering students [Jon] and [Cyrus Jyan]. They watched as homeowners fought to safely disconnect their homes from the power grid and said, it shouldn’t have to be this way. They designed the Flood Fault Circuit Interrupter to monitor target areas and disconnect the power automatically when a credible threat is detected.
The FFCI is built on top of existing protection schemes like GFCIs and Arc Fault Circuit Interrupters. It isn’t meant to replace them, but instead tie them together and turn them off based on input from float switches.
As floodwaters rise, an EEPROM does a lookup and compare to decide if the threat is enough to shut it down. If so, an alarm signal to a shunt trip breaker can either throw the whole system to OFF, or else switch over to an alternate power source. The system is built around a standard security panel and keypad interface that supports 12 V alarm output. We particularly like the float switch enclosures that allow water to enter while keeping out debris.
One of the most challenging projects you could ever do with an 8-bit microcontroller is generating VGA signals. Sending pixels to a screen requires a lot of bandwidth, and despite thousands of hackers working for decades, generating VGA on an 8-bit microcontroller is rarely as good as a low-end video card from twenty years ago.
Instead of futzing around with microcontrollers, [Marcel] had a better idea: why not skip the microcontroller entirely? He’s generating VGA frames from standard logic chips and big ‘ol EEPROMs. It works, and it looks good, too.
VGA signals are just lines and frames, with RGB pixel values stuffed in between horizontal sync pulses, and frames stuffed between vertical sync pulses. If you already know what you want to display, all you have to do is pump the right bits out through a VGA connector fast enough. [Marcel] is doing this by saving images on two parallel EEPROMs, sending the output through a buffer, through a simple resistor DAC, and out through a VGA connector. The timing is handled by a few 74-series four-bit counters, and the clock is a standard 25.175 MHz crystal.
There’s not much to this build, and the entire circuit was assembled on a breadboard. Still, with the clever application of Python to generate the contents of the ROM, [Marcel] was able to build something that displays eight separate images without using a microcontroller.
Autodetection of hardware was a major part of making computers more usable for the average user. The Amiga had AutoConfig on its Zorro bus, Microsoft developed Plug And Play, and Apple used NuBus, developed by MIT. It’s something we’ve come to take for granted in the modern age, but it doesn’t always work correctly. [Evan] ran into just this problem with a video capture card that wouldn’t autodetect properly under Linux.
The video capture card consisted of four PCI capture cards with four inputs each, wired through a PCI to PCI-E bus chip for a total of sixteen inputs. Finding the cause of the problem wasn’t too difficult – the driver was detecting the card as a different model with eight inputs, instead of the sixteen inputs actually present on the card. The driver detects the device plugged in by a unique identifier reported by the card. The code on the card was identical to the code for a different model of card with different hardware, causing the issue.
As a quick test, [Evan] tried fudging the driver selection, forcing the use of a driver for a sixteen-input model. This was successful – all sixteen inputs could now be used. But it wasn’t a portable solution, and [Evan] would have to remember this hack every time the card needed to be reinstalled or moved to a different computer.
Looking further at the hardware, [Evan] discovered the card had four 24c02 EEPROM chips on board – one for each PCI card on board. Dumping the contents, they recognised the unique identifier the driver was using to determine the card’s model. It was then a simple job to change this value to one that corresponded with a sixteen-input card to enable functional autodetection by burning a new value to the EEPROM. [Evan] then published the findings to the LinuxTVWiki page. Continue reading “EEPROM Hack to Fix Autodetection Issues”
There was a time, not so long ago, when all the cool kids were dual-booting their computers: one side running Linux for hacking and another running Windows for gaming. We know, we were there. But why the heck would you ever want to dual-boot an Arduino? We’re still scratching our heads about the application, but we know a cool hack when we see one; [Vinod] soldered the tiny surface-mount EEPROM on top of the already small AVR chip! (Check the video below.)
Aside from tiny-soldering skills, [Vinod] wrote his own custom bootloader for the AVR-based Arduino. With just enough memory to back up the AVR’s flash, the bootloader can shuffle the existing program out to the EEPROM while flashing the new program in. For more details, read the source.
While you might think that writing a bootloader is deep juju (it can be), [Vinod]’s simple bootloader application is written in C, using a style that should be familiar to anyone who has done work with an Arduino. It could certainly be optimized for size, but probably not for readability (and tweakability).
Why would you ever want to dual boot an Arduino? Maybe to be able to run testing and stable code on the same device? You could do the same thing over WiFi with an ESP8266. But maybe you don’t have WiFi available? Whatever, we like the hack and ‘because you can’ is a good enough excuse for us. If you do have a use in mind, post up in the comments!
Continue reading “Dual-boot Your Arduino”
Flash memory is the king today. Our microcontrollers have it embedded on the die. Phones, tablets, and computers run from flash. If you need re-writable long term storage, flash is the way to go. It hasn’t always been this way though. Only a few years ago EPROM was the only show in town. EPROM typically is burned out-of-circuit in a programming fixture. When the time comes to erase the EPROM, just pop it under an ultraviolet (UV) bulb for 30 minutes, and you’re ready to go again. The EPROM’s quartz window allows UV light to strike the silicon die, erasing the memory.
The problem arises when you want to use an EPROM for long term storage. EPROM erasers weren’t the only way to blank a chip. The sun will do it in a matter of weeks. Even flourescent light will do it — though it could take years.
Continue reading “Staring at the Sun: Erasing an EPROM”
You will probably be familiar with I²C, a serial bus typically used for not-very-fast communication with microcontroller peripherals. It’s likely though that unless you are an I²C wizard you won’t be intimately familiar with the intricacies of its operation, and each new device will bring a lengthy spell of studying data sheets and head-scratching.
If the previous paragraph describes you, read on. [Clint Stevenson] wrote a library for interfacing I²C EEPROMs to Arduino platforms, and when a user found a bug when using it on an ATtiny85, he wrote up his solution. The resulting piece is a clear explanation of how I²C EEPROMs talk to the bus, the various operations you can perform on them, and the overhead each places on the bus. He then goes on to explain EEPROM timing, and how since it takes the device a while to perform each task, the microcontroller must be sure it has completed before moving to the next one.
In the case of [Clint]’s library, the problem turned out to be a minor incompatibility with the Arduino Wire library over handling I²C start conditions. I²C has a clock and a data line, both of which are high when no tasks are being performed. A start condition indicates to the devices on the bus that something is about to happen, and is indicated by the data line going low while the clock line stays high for a while before the clock line starts up and the data line carries the I²C command. He’s posted samples of code on the page linked above, and you can find his library in his GitHub repository.
If you want to know more about I²C, take a look at Hackaday Editor [Elliot Williams’] masterclasses on the subject: What could go wrong, I²C edition, and Embed With Elliot, I²C bus scanning.
Serial EEPROM die picture, By Epop (Own work) [CC0], via Wikimedia Commons.