[Jason P], evidently an enjoyer of old reliable laser printing tech, spilled a drink (nitter) onto his Panasonic KX-P5400 SideWriter. After cleanup, everything worked fine — except that the PSU’s 5 V became 6.5 V during the accident, and the EPROM with LocalTalk interface firmware died, connection between VCC and GND seemingly interrupted inside the chip. Understandably, [Jason] went on Twitter, admitted the error of his ways, and sheepishly asked around for EPROM dumps.
Instead, [Manawyrm] wondered — would the chip have anti-ESD body diodes from GND to IO pins, by any chance? A diode mode multimeter check confirmed, yes! It was time for an outlandish attempt to recover the firmware. [Manawyrm] proposed that [Jason] connect all output pins but one to 5 V, powering the EPROM through the internal VCC-connected body diodes – reading the contents one bit at a time and then, combining eight dumps into a single image.
After preparing a TL866 setup, one hour of work and some PHP scripting later, the operation was a success. Apparently, in certain kinds of cases, dead ROM chips might still tell their tales! It’s not quite clear what happened here. The bond wires looked fine, so who knows where the connection got interrupted – but we can’t deny the success of the recovery operation! Need a primer on dumping EPROMs that are not dead? Here you go.
The Bad Apple!! video with its silhouette animation style has long been a staple graphics demo for low-end hardware, a more stylish alternative to the question “Will it run DOOM?”. It’s normal for it to be rendered onto a screen by a small microcomputer or similar but as [Ian Ward] demonstrates in an unusual project, it’s possible to display the video without any processor being involved. Instead he’s used a clever arrangement involving a 32K byte EPROM driving a HD44780-compatible parallel alphanumeric LCD display.
While 32K bytes would have seemed enormous back in the days of 8-bit computing, even when driving only a small section of an alphanumeric LCD it’s still something of a struggle to express the required graphics characters. This feat is achieved by the use of a second EPROM, which carries a look-up table.
It’s fair to say that the result which can be seen in the video below the break isn’t the most accomplished rendition of Bad Apple!! that we’ve seen, but given the rudimentary hardware upon which it’s playing we think that shouldn’t matter. Why didn’t we think of doing this in 1988!
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.
Like many of the early attempts at putting a computer in your pocket, the Psion II had removable modules, which were dubbed “Datapaks”. The earliest versions of the Datapaks were little more than an EPROM chip on a small PCB, and the technical limitations of the day plus the quirky way of addressing the memory made it possible for [Amen] to mimic a Datapak using a modern microcontroller.
The first version was a breakout board that extended out of the Datapak slot significantly, with a Pico, OLED display, SD card slot, and a bunch of pushbuttons. That prototype proved that the Pico was indeed fast enough to fool the Psion into thinking a legit Datapak was plugged in. [Amen] later refined the design by making a board that stuffs everything into the Datapak slot, with the exception of the OLED which still dangles out where it can be seen. He puts the faux memory to the test in the video below.
It’s great to see groundbreaking tech of yesteryear like the Psion being taken care of and returned to use. We’ve seen others try before; here’s a hack that uses a Pi to connect a Psion Organiser to the internet through its RS-232 serial port.
The 68000 chip was ubiquitous in the computing world well past its heyday in the 1980s. It was used as the basis for many PCs and video game consoles, and even in embedded microcontrollers. Now, one of its niche applications is learning about the internal functions of computers. 68000 builds are fairly common when building homebrew computers from scratch, but projects like these can be complicated and quickly get out of hand. This 68000 project, on the other hand, gets the job done with the absolute minimum of parts and really dives into the assembly language programming on these chips. (Google Translate from Spanish)
[osbox68] built this computer by first simulating its operation. Once he was satisfied with that, the next step was to actually build the device. Along with the MC68008 it only uses two other TTL chips, a respectable 32 kilobytes of ram, and additionally supports a serial port and an expansion bus. A few 74-series chips round out the build including a 74HC574 used for debugging support. With a custom PCB to tie everything together, it’s one of the most minimal 68000 builds we’ve seen that still includes everything needed to be completely functional.
After all, including the TTL and 74XX chips the entire circuit board only uses 10 integrated circuits and a few other passive elements for a completely functional retro computer. [osbox68] also includes complete schematics for building a PCB based on these chips to make construction that much easier. Of course, emulating an old microcontroller instead of using TTL components can save a lot of real estate on a PCB especially if you’re using something like an FPGA.
On the scale of things worth worrying about, having to consider whether your EPROMs will be accidentally erased by some stray light in the shop is probably pretty low on the list. Still, losing irreplaceable data can make for a bad day, so it might just pay to know what your risks really are.
To address this question, [Adrian] set out to test just how susceptible to accidental erasure some common EPROM chips are. An EPROM, or “erasable programmable read-only memory”, is a non-volatile memory chip that can be programmed electrically and then erased optically, by exposing the die inside the chip to light at a specific wavelength, usually in a special chip erasing tool. But erasure can also happen in daylight (even if it takes a few weeks), so [Adrian] cooked up an experiment to see what the risk really is.
He exposed a selection of EPROMs with known contents to UV and checked their contents. Three of the chips had a simple paper or foil label applied, while one had its quartz window exposed to the UV. As expected, the unprotected chip was erased in just 30 minutes. The covered chips, though, all survived that onslaught, and much more — up to 780 minutes of continuous exposure.
So rest easy — it seems that even a simple paper label is enough to protect your precious retro EPROMs. It’s a good data point, and hats off to [Adrian] for taking a look at this. But now we can’t help but wonder: what would a little sunscreen applied to the quartz window do to erasability? Sounds like a fun experiment, too.
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.