SB Mini II Is A Homebrew Apple II Clone

July 7, 2026 by Tyler August 17 Comments

On the one hand, the original Apple II has been copied over and over again since at least the early 80s, so maybe this hack is old hat to the greybeards around here. On the other hand, this is the year 2026. When Apple released it back in 1977, who could have predicted people would still be building these things nearly five decades later?

In that sense, a homebrew Apple II in the current year is pretty remarkable. It’s a really well done project by [simonboak], nicely open sourced with a case to match, so is worth looking at on its own merits.

It doesn’t run *DOOM*, but neither did the original. *Oregon Trail* is more this unit’s speed.

Unlike the later models, the original Apple II only used commercially available ICs, making it an easy target for recreation. No FPGAs required, just good old-fashioned DIPs. OK, these are modern CMOS versions of the chips, but other than that, the biggest concession to modernity is space on the board for a Raspberry Pi Pico to allow for connecting a USB keyboard.

The accompanying blog post lists some other differences from 1977’s favorite home computer: SRAM vs DRAM — because you know the Woz would have used it if he could — and omitting the composite video circuitry in favor a late-model VGA card. There’s no need for the composite output since he’s eschewing the period-appropriate CRT for a retro-styled LCD monitor, which is also 3D printed and available on Printables. It’s crazy to think that the Apple II family lived long enough not only to see the dawn of VGA but also well into its sunset.

If a homebuilt Apple ][ doesn’t impress, what about a PC-compatible circa 1995?

Why The NES Put Out A Wobbly Picture

July 7, 2026 by Jenny List 13 Comments

The NTSC television standard is a masterpiece of mid-century engineering, to pack a color image into the transmission bandwidth of a monochrome one, and to do so while maintaining backward compatibility with earlier monochrome TV sets. In terms of its timings and choice of sync and carrier frequencies it’s elegantly thought out for maximum quality on a 1950s round-CRT color TV set.

The trouble is, that while the standards are exacting, the receivers are quite forgiving, and will display adequately even with substantially off-spec video. [Nicole Express] is here with an in-depth examination of a time when that was pushed just a little bit too far, explaining why the Nintendo Entertainment System (NES) displayed wobbly color images.

We’re treated to a run-through of the NTSC standard itself, and a look at how some of the other consoles and home computers of that era either had similar problems, or managed to avoid them. The key lies in the exacting timing required to achieve perfect interlacing, and the NES’s use of a single crystal to provide all the clocks. The dot clock on adjacent frames was almost right, but not quite, leading to a side-to-side wobble that while barely perceptible, was exacerbated by some graphics. It’s a fascinating read.

We’ve looked at composite video in detail in the past.

NES image: JCD1981NL, CC BY 3.0.

Performance Improvements For Open-Source 80386

July 6, 2026 by Fenix Guthrie 3 Comments

The Intel 80386 is a rather fascinating slice of computer history. It marked the first 32 bit X86 processor, and was a staple of early desktop computing. Like all chips, it has a number of quirks, one of which being the fact that all commands are executed in microcode. By this nature, it was a rather excellent prospect to be re-implemented in an FPGA core called the z386. However, it was lacking a feature native to the original 386, early start memory access. So to bring some performance to the z386 project, [nand2mario] went forth to fully implement this feature for FPGA 80386s.

Instead of taking a cycle to find and allocate the memory required for executing the next instruction, the 386 would start this in the previous cycle. This is achieved in hardware by nature of having a separate memory management unit. In the FPGA, the key difficulty proved to be in getting the computation fast enough to execute within a single cycle. This change netted an approximate 9% performance benefit. However, for [nand2mario] this was too small a performance uplift.

Some rewrites of the store cue allowed for cutting a cycle out of the process further improving the performance. However, more performance required slight deviations from the design of the original 386. Because code-branches are performance critical, the z386 project now computes the branch memory jump several cycles earlier than the 386, reducing the cycle time for the jumps from 9.25 to a mere 6. Some final changes to the microcode decode frontend rounded out the optimizations covered in this latest blog post.

The net result is an approximate 39% increase in performance in the all important DOOM benchmark. The z386 still not a complete project, the performance is still lacking compared to the 386, and it remains unable to boot Windows. X86 is complicated, which will take time, so make sure to stay tuned for more coverage! While you wait, make sure to check out our original writeup of the z386 project.

Pauli Rautakorpi, CC BY 3.0.

The Bit79 Was A Famicom Clone That Took The “Family Computer” Name Seriously

July 6, 2026 by Tyler August 10 Comments

While the original name of what much of the world knows as the NES was the Nintendo Family Computer, or Famicom for short, it was very rarely used as a family computer. Sure, there was a basic cartridge and an add-on keyboard sold in Japan, but it was always a sideshow to the games.

Nintendo recognized that when they brought their Entertainment System overseas. Most of the various famiclones — which date back to the mid-80s — are the same. BIT in Taiwan had a different idea: their Bit 79 would be a full home computer. Picture a C=64 that plays Nintendo games, and you might not be too far off. [Inkbox] tells the full story in his latest YouTube video, and it’s a must-watch for anyone interested in the history of 8-bit machines that are totally unknown in the West.

Continue reading “The Bit79 Was A Famicom Clone That Took The “Family Computer” Name Seriously” →

He Comes To Bury Segmented Memory, Not To Praise It

July 6, 2026 by Al Williams 39 Comments

[BillPg] has been designing a fantasy 1980s-era home computer. As part of the exercise, he’s reevaluating all the assumptions that have grown organically over time in the small computer landscape. Hindsight is, so they say, 20/20, but sometimes hindsight can also be colored by modern thinking. Sometimes an idea that seems stupid today made sense in the context of its time. In particular, [Bill] has thoughts on the much-maligned 8086 memory segments.

If you haven’t run into it before, the 8086/8088 had a problem. It wanted to be more or less conceptually software compatible with the 8080 and Z80 computers, which had 16-bit addresses, leading to a limit of 64K of memory. When Intel was designing the next generation of chips, it knew that 64K had to go, but telling developers that code would require huge reengineering was a non-starter. So the idea was to provide multiple 64K spaces broken up into segments.

Continue reading “He Comes To Bury Segmented Memory, Not To Praise It” →

Using Flatpak To Run A 1996 Version Of The GIMP On Modern Linux

July 4, 2026 by Maya Posch 4 Comments

Although there’s probably no good reason to want to run image editing software from 1996 other than for nostalgia’s sake, if you ever wanted to run the GIMP version 0.54 from back when Windows 98 was still called Windows 97, you can do so now from the comfort of a modern-day Linux desktop. What enables this is a Flatpak version of a beta release, assembled by [balooii] for everyone’s enjoyment.

It wasn’t a simple matter of compiling the old software’s code and packaging it up, with the repository for the project containing a series of patches that were required to make this possible. Also of note is that this is the first version of GIMP with full surviving source code. Back then, GIMP used the Motif widget toolkit. Later on, it switched to the GIMP Toolkit (GTK).

Continue reading “Using Flatpak To Run A 1996 Version Of The GIMP On Modern Linux” →

Disk Polishing Goes Open Source

July 4, 2026 by Tyler August 10 Comments

Optical media is great — it’s pretty high density, relatively durable, and decently long-lasting if

a selection of before-and-after shots — “That’ll buff out” is very often true when it comes to disks.

well cared for. If not well cared for, well, it’s only relatively durable, and we’ve probably all picked up a second-hand disk that’s too scratched to use. The X-Box 360 is notorious for causing circular damage, and while decent disk cleaners were easy to get in the 90s, we’re not sure how far we trust what’s on offer at retailers today. Hence [Dennis], aka [RetroGameRevival]’s RGR ezBuff polishing machine, which does exactly what it says on the tin: buffs disks to a polish, easily.

We’d say the whole thing is 3D printed, but of course you still need a motor and controller — if you had to turn a crank, that would just be a Buff polishing machine, no ez — and we’ve yet to see a printer poop out polishing compound. If you build it, keep in mind that you’re taking the top layer of material off the disk to polish scratches away, so don’t overdo it. It’s entirely possible to ruin a disk beyond repair with too-aggressive buffing; it’s also possible for disks to be scratched too deeply to save. Polishing can’t save genuine disk rot, though in our experience you’re more likely to find scratched disks than rotten ones. Still, [Dennis]’s birthday gift to the community — it was apparently released on his birthday — should keep more than a few disks out of the trash.

With Sony getting out of the disk game, physical media is becoming more precious than ever, so it’s good to see what looks like a quality polishing option for those of us who either never had a polisher or didn’t save theirs. If you really want your disks to last, maybe we should bring back CD caddies.

Thanks to [Dean] for the tip, via timeExtension.com.