Ever wonder why analog TV in North America is so weird from a technical standpoint? [standupmaths] did, so he did a little poking into the history of the universally hated NTSC standard for color television and the result is not only an explanation for how American TV standards came to be, but also a lesson in how engineers sometimes have to make inelegant design compromises.
Before we get into a huge NTSC versus PAL fracas in the comments, as a resident of the US we’ll stipulate that our analog color television standards were lousy. But as [standupmaths] explores in some depth, there’s a method to the madness. His chief gripe centers around the National Television System Committee’s decision to use a frame rate of 29.97 fps rather than the more sensible (for the 60 Hz AC power grid) 30 fps. We’ll leave the details to the video below, but suffice it to say that like many design decisions, this one had to do with keeping multiple constituencies happy. Or at least equally miserable. In the end [standupmaths] makes it easy to see why the least worst decision was to derate the refresh speed slightly from 30 fps.
Given the constraints they were working with, that fact that NTSC works as well as it does is pretty impressive, and quite an epic hack. And apparently inspiring, too; we’ve seen quite a few analog TV posts here lately, like using an SDR to transit PAL signals or NTSC from a microcontroller.
Continue reading “Never Twice the Same Color: Why NTSC is so Weird”
In a lifetime of working with electronics we see a lot of technologies arrive, become mighty, then disappear as though they had never been. The germanium transistor for instance, thermionic valves (“tubes”), helical-scan video tape, or the CRT display. Along the way we pick up a trove of general knowledge and special skills associated with working on the devices, which become redundant once the world has moved on, and are suitable only reminiscing about times gone by.
When I think about my now-redundant special skills, there is one that comes to the fore through both the complexity and skill required, and its complete irrelevance today. I’m talking about convergence of the delta-gun shadow mask colour CRTs that were the height of television technology until the 1970s, and which were still readily available for tinkering purposes by a teenager in the 1980s.
Continue reading “My Most Obsolete Skill: Delta-Gun Convergence”
Despite the existence of FPGAs and CPLDs, there’s still a necessity for very small programmable logic devices. GALs, PALs, and other old tech just won’t cut it, though, and so we are left with a new generation of programmable devices that aren’t microcontrollers or CPUs. The GreenPAC from Silego fill this niche quite nicely, with the ability to implement counters, ADCs, logic glue, level shifting, and comparators in a single chip. For any homebrew electronics tinkerer, these devices have one very obvious problem: they’re really, really small. The smallest GreenPAC device has 12 pins stuffed into a 1.6 x 1.6mm QFN package. You’re not hand soldering this thing.
For [Nick Johnson]’s Hackaday Prize entry, he’s taking these small programmable logic chips and making it easy to create your own custom ICs. Basically, it’s a breakout board for GreenPAC devices that stuffs these tiny chips onto a much more reasonable DIP package.
Breakouts aren’t enough, and to program these small chips, [Nick] is also building a board based on an ARM microcontroller. With USB input, a way to generate the 7.5V used for programming, and a breadboard friendly format, this programmer will tell these tiny chips what to do.
Not many people are building stuff with PALs and GALs anymore, but there are still a lot of work that can be done with small programmable chips. There’s certainly a place for tiny programmable logic chips like this, and anything that gets them in to the hands of more people is okay in our book.
Back in the bad old days, if you needed a little bit of custom logic you would whip out a tiny chip known as a PAL. A Programmable Logic Array is just what it sounds like and is the forerunner of modern, unsolderable CPLDs and FPGAs.
PALs and GALs have died off, left to the wastes of the Jameco warehouse, and now it seems the only programmable logic you can buy are huge, 100-pin monstrosities. [Nick] at Arachnid Labs was working on his Tsunami signal generator when a user asked if they could add just one more feature: a programmable divider to count 256 iterations of a clock. This is the perfect application for dumb logic, but if you’re looking for a part that’s not recommended for new designs, you only need to look to old programmable logic.
Enter the Greenpak. [Nick] had a dev kit for these ‘modern PALs’ sitting around and decided to give it a go. They’re small – they max out at 20 pins – but there are a few features that make it a little more interesting than a simple array of AND and OR gates. The Greenpak3 features analog comparators, look-up tables, RC oscillators, counters, and GPIO that will work well enough as circuit glue. They also work at 5V, something you’re just not going to find in more complex programmable logic.
These tiny chips are programmed in a graphical IDE, but the datasheet (PDF) includes full documentation for the bitstream; someone needs to write a Verilog or VHDL compiler for it soon. The one downside with these chips is that they’re tiny; 0.4mm pitch QFN packages. If you can solder that, you’re too good at soldering.
Way back in the 70s, the UK and BBC rolled out teletext – an information retrieval service that’s much closer to the ‘television screens connected to computers the size of a room’ popularized by 1960s futurists than the Internet and world wide web. For about 30 years, teletext was one of the most reliable means of information distribution until it was quietly shelved with the rollout of digital television.
Playing with dead protocols is fun, though, and since the Raspberry Pi has an analog video out, [Alistair] thought it would be fun to turn his Pi into a teletext generator and display.
This isn’t [Alistair]’s first teletext rodeo; earlier he built an add-on board for the Raspi that uses an AVR and an LM1881 video sync separator to mux the video output of a Raspi with teletext signals. The new build does away with this completely, allowing any Raspberry Pi to generate and display information from a teletext service. Right now there are two demos, a Raspi status display that shows the CPU frequency, usage, memory, and temperature. There’s also a ‘clock cracker’ with a picture of Tux that should help diagnose reception issues.
All the code is available on the project’s github, although [Alistair] hasn’t released the scripts to output teletext pages captured from broadcast signals years ago.
Continue reading “Teletext on a Raspi With Zero Additional Parts”
There are a few dozen classic re-imaginings of classic game consoles, using hardware ranging from the ATMegas of the Uzebox to everyone’s favorite, stuffing some ROMs on a Raspi and calling it a day. You don’t necessarily learn anything doing that, which puts [Mike]’s custom game console head and shoulders above the rest.
The build started off as a plan for a Z80 computer with a dual ATMega GPU. He progressed far enough in the design where it would have been a masterpiece, but the inability to mill double-sided boards at home killed the design. Plans then moved on to an FPGA, then to an ATMega with the Analog Device AD725 PAL/NTSC encoder chip. That idea had a similar architecture to the Uzebox, but [Mike] wanted more power. He eventually settled on a PIC32 with the AD725.
This setup was capable of pumping out some impressive graphics, but for moving bits to a screen, you need DMA. [Mike] ran into a problem where the DMA timer runs at a maximum rate of 3.7 MHz. It’s a problem documented in a few projects, leading [Mike] to change his plan once again, this time to the STM32F4.
The bugs are worked out, and now [Mike] can stream a whole lot of pixels to a screen while still having some processing power left over to play a game. It’s a project that’s more than a year and a half old at this point, and so far he’s learned a lot.
Everyone is having a go at building their own 8-bit 80s-era microcomputer now, and [Petri] thought he would throw his hat into the ring with ERIC-1, a homebrew, 6502-based computer that’s running at about 2MHz.
We’re about 30 or 40 years ahead of the game compared to the old-school 6502 designs, and [Petri] decided to capitalize on that. Instead of a separate ROM, VIA, and other peripherals, [Petri] is connecting a microcontroller directly to the data and address pins. This is a technique we’ve seen before, and [Petri] is doing it right: the micro and 6502 share 64k of RAM, with the ROM stored in the micro’s Flash. Video (PAL in this case) is handled by the ATMega, as is clocking and halting the CPU.
There were a few changes [Petri] made along the way to make this microcomputer a little more useful. One of the biggest changes was switching out the old NMOS Rockwell 6502 with the modern CMOS W65C02 from Western Design Center. The CMOS variant is a fully static design, keeping the registers alive even if the clock is stopped and making single-stepping and halting the CPU easier.
The CMOS variant also has a Bus Enable (BE) pin. Like similar pins on later, more advanced processors, this pin puts the address, data, and R/W pins into a high impedance state, giving other peripherals and microcontrollers the ability to write to RAM, peripherals, or anything else. It’s a handy feature to have if you’re using a microcontroller for everything except the CPU.
It’s already a great build, and since [Petri] has the skills to program this 8-bit ‘duino game, he’s sure to come up with something even better for this computer.
Oh, if you’re looking for something even cooler than a 3-chip 6502, there’s a bunch of stuff over on hackaday.io you should check out. Everything from 4-bit computers built from discrete components to dual AVR board can be found there.