Why The NES Put Out A Wobbly Picture

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

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

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

[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

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

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.

Yesterday’s Technology, Re-engineered Today

Watching [sprite_tm]’s build of a handheld 486-based gaming computer, we got to thinking about retro computers and the eternal questions of how much of the computer needs to be actually “old” for it it be retro. Where is the soul of a retro computer? The CPU? The old yellowing plastic case? Maybe it depends on what you’re trying to get out of the hobby.

There is of course a spectrum of people playing around with old computers. For some people, let’s call them “vintage computer enthusiasts”, half of the fun is in keeping the actual old hardware running. This group tends to know what teletype lubricant smells like, and how to tell which capacitors need replacing.

For others, “team retro”, the joy is in using the machine itself, whether that be teaching the old dogs new tricks, or simply loading up nostalgic video games. Team retro is more content with emulations or emulations that are wrapped up neatly in hardware workalikes. They know which registers need POKEing, and whether or not Commander Keen is running at the right framerate.

I think [sprite_tm]’s project falls in with yet another camp, the retro-reengineers. Here, the idea is to step through the engineering lessons of the past by re-designing something from a bygone era. So when [sprite_tm] went with a period 486 CPU backed up by a modern FPGA, perhaps ironically borrowing code from the modern MiSTer project, it makes sense for his goals. Retro-reengineers know the bus architecture and the memory timings, and they are reinventing the wheel as a learning experience. Or in the case of [Voja Antonic]’s imaginary four-bit machine, it’s a teaching experience.

How you work often reflects what you’d like to get out of the project, and at Hackaday, of course, we love all of the above! We’ve identified at least three broad schools of fooling around with old computers. Are we missing any?