[Starhawk] is a man with a problem. More accurately, he’s a man whose mother has a problem, but ultimately that ends up being the same thing. Her wide-format Canon printer recently stopped working after better than a decade of reliable service, and he wants to know why. Rather than spend the money on buying a new printer, he’s determined to find out if she’s been the victim of planned obsolescence by reverse engineering the Canon i9900 to see what makes it tick (or stop ticking, as the case may be).
In the absence of any obvious hardware faults, [Starhawk] has suspicions that the machine’s QY6-0055 printhead has run over some internal “odometer” and simply turned itself off. We’ve all seen similar trickery at play when trying to use third party ink cartridges in our printers, so it’s certainly not outside the realm of possibility that the Canon i9900 is designed to reject heads once they’ve seen enough usage. Perhaps the biggest clue is that the QY6-0055 has a Seiko S93C56BR EEPROM on the board that’s keeping track of…something.
Right now, [Starhawk] is devoting his energies on trying to make sense of the data he pulled from the EEPROM using his TL866A programmer. But that’s no easy feat with a sample size of just one, which is why he’s looking for help. He’s hoping that other hackers with similar printers (and ideally ones that use the same QY6-0055 head) could submit their own EEPROM dumps and the community could get to work trying to decipher what’s stored on the chips. He’s really hoping that somebody at Canon might be willing to sneak him a couple tips on what he should be looking for, but at this point we think he’ll take whatever assistance he can get.
Now to be fair, there’s really no way to know definitively if there’s some flag stored on the EEPROM that’s keeping the printer from working. It could just be good old fashioned hardware failure, which would hardly be a surprise for a piece of consumer electronics from 2005. But even if the effort to understand the Canon’s EEPROM doesn’t get him any closer to a working printer, we still think it’s a fascinating example of real-world reverse engineering that’s worth it for the experience alone.
There’s a long history of hackers doing battle with their printers, from emulating an ink cartridge with a microcontroller to reinking the ribbon of a vintage 1980s behemoth. We’re interested in seeing where this project takes [Starhawk], but no matter what happens there are likely to be some interesting discoveries made along the way.
For whatever reason, the Video Graphics Array standard seems to attract a lot of hardware hacks. Most of them tend to center around tricking a microcontroller into generating the signals needed to send images to a VGA monitor. We love those hacks, but this one takes a different tack – a microcontroller-free VGA display that uses only simple logic chips and EEPROMs.
When we first spied this project, [PH4Nz] had not yet shared his schematics and code, but has since posted everything on GitHub. His original description was enough to whet our appetite, though. He starts with a 27.175-MHz clock and divides that by 4 with a 74HCT163, which has the effect of expanding the 160×240 pixels image stored in one of the EEPROMs to 640×480. Two 8-bit counters keep track of horizontal and vertical positions, while the other EEPROM takes care of generating the Hsync and Vsync signals. It’s all quite hackish, but it works. [PH4Nz] tells us that the whole thing is in support of a larger project: an 8-bit computer made from logic chips. We’re looking forward to seeing that one too.
This isn’t the first microcontroller-less VGA project we’ve seen, of course. Here’s a similar one also based on EEPROMs, and one with TTL logic chips. And we still love VGA on a microcontroller such as the ESP32; after all, there’s more than one way to hack.
Thanks to [John U] for the tip.
There are plenty of techniques and components that we use in our everyday hardware work, for which their connection and coding is almost a done deal. We are familiar with them and have used them before, so we drop them in without a second thought. But what about the first time we used them, we had to learn somewhere, right? [TheMagicSmoke] has produced just what we’d have needed then for one component that’s ubiquitous, the I2C EEPROM.
These chips provide relatively small quantities of non-volatile memory storage, and though they are not the fastest of memory technologies they have a ready application in holding configuration or other often-read and rarely written data.
Since the ST24C04 512-byte device in question has an I2C bus it’s a straightforward add-on for an Arduino Mega, so we’re shown the wiring for which only a couple of pull-down resistors are required, and some sample code. It’s not the most complex of projects, but it succinctly shows what you need to do so that you too can incorporate an EEPROM in your work.
If learning about I2C EEPROMs piques your interest, perhaps you’d like to read a previous look we made at them.
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”