Maybe you’ve heard of a TV show called The Simpsons. Steamed Hams make a one-gag appearance in an unforgettable luncheon where Principal Skinner poker-faces his way out of a disaster with Superintendent Chalmers. Meanwhile, over on imgur, [Agumander] has put a black and white screencap from Steamed Hams in a printed circuit board.
The memory for this chip is an AT28C64, a 64 kilobit or 8 kilobyte steamed RAM. You call it a steamed RAM despite the fact that it is obviously a ROM. There is no microcontroller on this board or really anything resembling programmable logic. Everything is just logic chips. This board displays a 256×256 1 bit per pixel image over composite video. The sync is generated with the help of a 14MHz crystal and some circuitry taken from the original PONG board. Other than that, it’s just a bunch of NANDs and ORs that roll through the address space of the ROM and spit values out over a composite video port.
The build began by breadboarding everything save for a nifty solderless breadboard power adapter. Three ROM chips were programmed with different images — a cat, something to do with vaporwave, and some guy that looks like the poster from Eraserhead. Everything worked on the breadboard — yes, even at 14 MHz — so the build moved on to a printed circuit board.
The result is fantastic, and should work well on anything with a composite video port. We’re awarding bonus points for putting a socket on the ROM, simply so [Agumander] can change the image without whipping out the desoldering braid. If you need a refresher on Steamed Hams, it’s from the 7th season Simpsons episode ’22 Short Films About Springfield’.
The fragility of SD cards is the weak link in the Raspberry Pi ecosystem. Most of us seem to have at least one Pi tucked away somewhere, running a Magic Mirror, driving security cameras, or even taking care of a media library. But chances are, that Pi is writing lots and lots of log files. Logging is good — it helps when tracking down issues — but uncontrolled logging can lead to problems down the road with the Pi’s SD card.
[Erich Styger] has a neat way to avoid SD card logging issues on Raspberry Pi, he calls it a solution to reduce “thrashing” of the SD card. The problem is that flash memory segments wear out after a fairly low number of erase cycles, and the SD card’s wear-leveling algorithm will eventually cordon off enough of the card to cause file system issues. His “Log2Ram” is a simple Unix shell script that sets up a mount point for logging in RAM rather than on the SD card.
The idea is that any application or service sending log entries to /var/log will actually be writing them to virtual log files, which won’t rack up any activity on the SD card. Every hour, a cron job sweeps the virtual logs out to the SD card, greatly reducing its wear. There’s still a chance to lose logging data before it’s swept to disk, but if you have relatively stable system it’s a small price to pay for the long-term health of a Pi that’s out of sight and out of mind.
One thing we really like about [Erich]’s project is that it’s a great example of shell scripting and Linux admin concepts. If you need more information on such things, check out [Al Williams’] Linux-Fu series. It goes back quite a way, so settle in for some good binge reading.
From the title, you might think this post is going to be some lame story about someone plugging in some RAM and maybe updating a BIOS. That’s where you’d be wrong. [Downtown Doug Brown] has a much more interesting and instructive story.
[Doug] found his motherboard was rated for 8 GB maximum and decided he’d make 16 GB of RAM work despite the limitation. He updated the BIOS and it worked — in Linux. He was able to see all the memory and it tested good. If that was it, you wouldn’t be reading about it here. The story gets interesting when he tried to boot Windows 10 and it refused, showing its kinder and gentler blue screen of death. For many people, that would be the end of the story, especially since Windows 10 doesn’t give you much information about why it crashed.
Like so many problems, this one had to be peeled back like an onion. The first thing to do was to change the Windows registry to allow the blue screen to output some technical information that was present in older versions of Windows. The error code indicated that the issue had to do with the BIOS reporting overlapping memory regions.
With some investigating in Linux, whose log files get a lot more BIOS information, [Doug] realized the E820 interface was returning a memory region that conflicted with ACPI’s information. It seems as though the motherboard was reserving space at the top of the 8 GB range for PCI operations which was punching a hole in the system’s (now larger) memory. Turning off a setting in the BIOS fixed the problem, but only because it makes Linux and Windows both see only 4GB of memory. That also wouldn’t be a very interesting story. [Doug] theorized that if he could move the mapping area to the top of the 16 GB range, things would work.
What follows is a great exposition of the Linux tools for reading and changing system information. Did he get it to work? Read the post and find out. But we will tell you that he did manage to have grub patch his system information.
Most of the motherboard hacks we’ve seen relate to hardware, not software. Of course, you could just buy a new motherboard. If you need ideas for what to do with the old one, here you go.
Everyone loves NeoPixels. Individually addressable RGB LEDs at a low price. Just attach an Arduino, load the demo code, and enjoy your blinking lights.
But it turns out that demo code isn’t very efficient. [Ben Heck] practically did a spit take when he discovered that the ESP32 sample code for NeoPixels used a uint32 to store each bit of data. This meant 96 bytes of RAM were required for each LED. With 4k of RAM, you can control 42 LEDs. That’s the same amount of RAM that the Apollo Guidance Computer needed to get to the moon!
His adventure is based on the thought that you should be able to generate these signals with hardware SPI. First, he takes a look at Adafruit’s DMA-Driven NeoPixel example. While this is far more efficient than the ESP32 demo code, it still requires 3 SPI bits per bit of NeoPixel data. [Ben] eventually provides us with an efficient solution for SPI contro using a couple of 7400 series chips:
[Ben]’s solution uses some external hardware to reduce software requirements. The 74HC123 dual multi-vibrator is used to generate the two pulse lengths needed for the NeoPixels. The timing for each multi-vibrator is set by an external resistor and capacitor, which are chosen to meet the NeoPixel timing specifications.
The 74HC123s are clocked by the SPI clock signal, and the SPI data is fed into an AND gate with the long pulse. (In NeoPixel terms, a long pulse is a logical 1.) When the SPI data is 1, the long pulse is passed through to the NeoPixels. Otherwise, only the short pulse is passed through.
This solution only requires a 74HC123, an AND gate, and an OR gate. The total cost is well under a dollar. Anyone looking to drive NeoPixels with a resource-constrained microcontroller might want to give this design a try. It also serves as a reminder that some problems are better solved in hardware instead of software.
Continue reading “Inefficient NeoPixel Control Solved With Hardware Hackery”
If you want to not take for granted how easy and seamless computers have become, take up vintage computing as a hobby. If you venture down the retro path, you’ll quickly question how anyone ever got any useful work done with computers, and the farther back you go in computer history, the more difficult everything seems to become.
Case in point: how do you easily transfer files between a home-brew PC/XT and your modern desktop? Back in the day we did it with null modem cables or by sneaker-netting stacks of floppies, but [Scott M. Baker] found another way — putting a Raspberry Pi on the ISA bus as a virtual floppy drive. The heart of the ISA card is an IDT7130, a 1-kb RAM chip that allows simultaneous asynchronous access over dual ports. One port talks to the ISA bus and the other talks to the GPIO of the Pi, after level-shifting to make everything voltage compatible, of course. [Scott] wrote a driver for the card, plugged a Pi Zero W into the header pins, and threw a Python server together that makes local images available to the shared memory on the card. The upshot of this is that the retro machine thinks it has a floppy in it, but it’s actually a server. The video below has tons of detail and shows the card in action. Pretty slick.
[Scott]’s projects are always fun to check out, and he really seems to have the retro life dialed in. Whether it’s old jukebox hacks or a Unix-ish OS for Z80s, there’s plenty to learn. Although we’d like to see more about that PC/XT in the video; are those Nixies we spy along the front panel?
Continue reading “Making Vintage Computing Easy, The Hard Way”
Modifying the Amiga 500 to speed up access to RAM in a memory expansion pack is a well documented procedure, with guides on the process written in the early 1990’s when the hardware was only a few years old. But as they were written for contemporary hardware, they make no concessions for how one should be treating a vintage computer that’s now over 30 years old. In 1993, cutting traces on the Amiga 500 motherboard was just a last ditch effort to eek a few more months of service life out of an outdated desktop computer. But in 2018, it’s kind of like when that old lady tried to “restore” a fresco of Jesus in Spain; it might be done with the best of intentions, but you still screwed the thing up good and proper.
Such things don’t fly over at [Inkoo Vintage Computing]. There you can find a guide that details the impressive lengths one can go to if they want to perform the classic modification without any irreversible changes to the motherboard. To avoid the cut traces and soldered bodge wires, this version of the modification makes use of a novel adapter that breaks out the necessary connections on the 8372A chip.
The adapter is simply a homemade PCB with both male and female plastic leaded chip carrier (PLCC) connectors. The few pins on the chip that needed rerouting are exposed as solder pads on the adapter for easy wiring. There are even a couple jumpers on the adapter to turn the modifications on and off.
Not surprisingly, the trickiest part of building this adapter was sourcing the antiquated PLCC connectors. Assuming you can even find them, you are then left with the challenging task of soldering them together. Judging by the pictures on the [Inkoo Vintage Computing] page, it’s no walk in the park.
Another similar arrangement is used in the expansion bay of the Amiga, where a pin is virtually “cut” in the connector. A tiny PCB is soldered to a 3×2 header to reroute the signals, and another jumper is used to enable and disable the pin. Luckily, the long pins on the Amiga memory expansion are forgiving enough that the little board can fit in between them without breaking electrical contact.
We’re no stranger to the Amiga 500 around these parts. We’ve covered how to get the 1987-vintage machine online in the 21st century, as well as employing a Raspberry Pi to emulate the original floppy drive. You can even make your own faux-Amiga with a 3D printed case, if you suffer from a sort of existential dread when working on a computer that’s older than you are.
Have you ever upgraded your computer’s memory sixteen-fold, with a single chip? Tynemouth Software did for a classic Sinclair micro.
For owners of home computers in the early 1980s, one of the most important selling points was how much RAM their device would have. Sometimes though there just wasn’t much choice but to live with what you could afford, so buyers of Sinclair’s budget ZX81 computer had to put up with only 1 kiB of memory. The system bytes took up (by this writer’s memory) around 300 bytes, so user programs were left with only around 700 bytes for their BASIC code. They were aided by Sinclair’s BASIC keywords stored as single bytes, but still that was a limit that imposed coding economy over verbosity.
Sinclair sold a 16 kiB upgrade, the so-called “Rampack”, which located on the ’81’s edge connector and was notorious for being susceptible to the slightest vibration. Meanwhile the mainboard had provision for a 2 kiB chip as a drop-in that was never sold in the UK, and enterprising users could fit larger capacities with soldered combinations of other chips piggybacking the original. And this is what the Tynemouth people have done, they’ve replaced their machine’s dual 1 kiB x 4 chips with a single 62256, and with a bit of pin-bending they’ve managed to do it without the track-cutting that normally accompanies this mod.
Adding chips to a 36-year-old home computer for which there are plenty of available Rampacks might seem a bit of a niche, but in doing so they’ve made a standalone ’81 that’s just a little bit more useable. They’ve also brought a few other components up-to-date, with a composite video mod, switching regulator, and heatsink for the rare ULA chip. If you are of a Certain Generation, it might just bring a tear to your eye to see a ZX81 being given some love.
Did you lose your ZX81 along the way? How about emulating one in mbed?