Game cartridges are perhaps the hardiest of all common storage schemes. Short of blunt traumatic force or application of electrical surges to the cartridge’s edge connectors, damaging a game cartridge is hard to do by accident. The same is also true for the data on them, whether one talks about an Atari 2006 cartridge from the late 1970s or a 1990s Nintendo 64 cartridge.
The secret sauce here are mask ROMs (MROM), which are read-only memory chips that literally have the software turned into a hardware memory device. A mask layer unique to each data set is used when metalizing the interconnects during chip fabrication. This means that the data stored on them is as durable as the processor in the game console itself. Yet this is not a technology that we can use in our own hobby projects, and it’s not available for personal long-term data storage due to the costs associated with manufacturing what is essentially a custom chip.
Despite its value as truly persistent storage, MROM has fallen out of favor over the decades. You may be surprised to find a lot of what’s currently used in the consumer market is prone to data corruption over time spans as short as one year to one decade depending on environmental conditions.
So what are we to do if we need to have read-only data that should remain readable for the coming decades?
Continue reading “Game Cartridges And The Technology To Make Data Last Forever”
Here at Hackaday we cast a wary eye at tips that come in with superlative claims. Generally, if we post something that claims to be the fastest or the smallest of all time, we immediately get slapped down in the comments by someone who has done it faster or smaller. So we present the simplest TTL video card ever knowing the same thing will happen, but eager to see how anyone might scale things down.
To be fair, [George Foot] does qualify his claim to the simplest usable VGA adapter, and he does note that it descends from [Ben Eater]’s “world’s worst video card”, which he uses for his 6502 breadboard computer. But where [Ben]’s VGA adapter uses about 20 TTL chips and an EEPROM, [George] has managed to decrease the BOM to just four TTL chips along with the memory and a crystal oscillator. This required a fair number of compromises, of course; the color depth is fairly low, as is the resolution. Each pixel appears as a thin horizontal bar rather than a small square, leading the images to be smeared out across the screen. They’re still surprisingly viewable, though, which probably says more about the quality of the pattern-recognition wetware between our ears than anything about the quality of the adapter. [George] gives a tour of the circuit in the brief video below.
It looks like [George] has posted a few improvements to the project since we first spotted it, so we’re looking forward to seeing how much the parts count went up. We’re also keen to see if anyone can outdo the simplicity of this effort — be sure to let us know if you give it a shot.
Continue reading “Super-Simple VGA Adapter Sports Low-Res Output With Only Four TTL Chips”
Everyone who builds embedded systems wants tools to help build and debug systems faster, so it isn’t uncommon to see boards outfitted with various tools like serial port sniffers. We’ve seen a few incarnations and the latest is Glasgow. The small board uses an FPGA and claims to do the following:
- UART with automatic baud rate determination
- SPI or I2C
- Read and write common EEPROMs and flash chips
- Read and write common EPROMs including a data rescue function
- Program AVR chips via SPI
- Play back JTAG SVF files
- Debug ARC and some MIPS CPUs
- Program XC9500LX CPLDs
- Communicate to several wireless radios and CPUs
- Do sound synthesis
- Read raw data from floppy drives
The revC board is the first to be relatively functional and sports 16 I/O pins operating at up to 100 MHz, although the documentation hints that 6 MHz might be the top of what’s easily accomplished. The software is written in Python and the iCE40 FPGA toolchain that we’ve talked about many times in the past.
This already looks like a useful tool and the reconfigurable nature of FPGAs makes it a good platform to expand. The documentation discusses the difficulty in debugging things for the board, so the base software offers support such as a built-in logic analyzer to help.
We have seen dev boards become bench tools, like using the iCEstick as a logic analyzer. It’s nice to see dedicated tools like this one built up around the speed and versatility of FPGAs.
Continue reading “Glasgow Uses An FPGA As An Embedded Systems Multitool”
[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.]