With the Pi Pico standing in for the original ROM, updating firmware takes a fraction of the time and doesn’t require you to actually disconnect any of the hardware. [Nick] had done something similar with FPGAs in the past, but the far cheaper and easier to work with Pi Pico makes this version particularly appealing. The secret to getting it to work is the overclocking potential of the Pico, which he says has been pushed to 400 MHz for this particular application.
The downside is that you can’t access the Pico’s onboard flash when the chip is running that fast. To get around that limitation, all of the code is loaded into the microcontroller’s RAM. With a healthy 264 KB of memory this isn’t really a problem when emulating 32 KB chips, but [Nick] says his method would quickly fall apart for larger ROMs.
Beyond the Pi Pico itself, [Nick] is using a trio of 74LVC245AN 8-bit logic level shifters so the chip can talk to the 5 V logic of his homebrew 6502 computer. With everything wired up on a simple breadboard, PicoROM has no trouble serving up the operating system as it hums along at 2 MHz.
Has it really come to this? Are we really at the point that dishwashers have proprietary detergent cartridges that you’re locked into buying at inflated prices?
Apparently so, at least for some species of the common kitchen appliance. The particular unit in question goes by the friendly name of Bob, and is a compact, countertop unit that’s aimed at the very small kitchen market. [dekuNukem] picked one of these units up recently, and was appalled to learn that new detergent cartridges would cost an arm and a leg. So naturally, he hacked the detergent cartridges. A small PCB with an edge connector and a 256-byte EEPROM sprouts from each Bob cartridge; a little reverse engineering revealed the right bits to twiddle to reset the cartridge to its full 30-wash count, leading to a dongle to attach to the cartridge when it’s time for a reset and a refill.
With the electronics figured out, [dekuNukem] worked on the detergent refill. This seems like it was the more difficult part, aided though it was by some fairly detailed specs on the cartridge contents. A little math revealed the right concentrations to shoot for, and the ingredients in the OEM cartridges were easily — and cheaply — sourced from commercial dishwashing detergents. The cartridges can be refilled with a properly diluted solution using a syringe; the result is that each wash costs 1/75-th of what it would if he stuck with OEM cartridges.
For as much as we despise the “give away the printer, charge for the ink” model, Bob’s scheme somehow seems even worse. We’ve seen this technique used to lock people into everything from refrigerator water filters to cat litter, so we really like the way [dekuNukem] figured everything out here, and that he saw fit to share his solution.
If you really think hard about it, a CPU is just a very general-purpose state machine. Well, most CPUs are, anyway. The MC14500 is a one-bit computer that has only 16 instructions and was meant to serve in simple tasks where a big CPU wouldn’t work for space, power, or budget reasons. However, [Laughton] took the idea one step further and created a single-bit computer with no real instructions to control a printing press. The finished machine uses a clever format in an EEPROM to drive an endless program.
Honestly, we’d say this is more of a state machine, but we like the idea of it being a minimal CPU which is also true. The design uses the EEPROM in an odd way. Each CPU address really addresses a block of four bytes. The byte that gets processed depends on the current phase and the status of the one-bit flag register.
When learning a new programming language, it’s best to have a goal in mind and work towards it. [Timo] thought it was about time to learn python, and he also had a project in mind: removing the BIOS supervisor password from his old Thinkpad. From there it was just a few keystrokes (and some soldering) and he was able to change the BIOS password of this black box from the outside.
The build utilizes a BeagleBone to communicate with the laptop’s EEPROM via the I2C bus. An oscilloscope also monitors the bus to look for a specific window every four-seconds when the computer is not accessing the bus. During that short period, the EEPROM can be read and written to. Once the window opens, the BeagleBone executes the Python script, which attempts to read the EEPROM and can also perform actions such as removing or changing the BIOS supervisor password.
Of course, tinkering with the EEPROM on a laptop has a high risk of bricking the device, and not all laptops use the same security measures or even memory addresses for things like this, so documentation and precision are key. Also, with Thinkpads of this vintage it’s possible to replace the firmware on these chips entirely with a FOSS version called libreboot, and even though the process is difficult, it’s definitely recommended.
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?
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.
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.