We often take for granted how easy it is to get information in today’s modern, Internet-connected world. Especially around electronics projects, datasheets are generally a few clicks away, as are instructions for building almost anything. Not so in the late 80s where ordering physical catalogs of chips and their datasheets was generally required.
Mastering this landscape took a different skillset and far more determination than today, which is what makes the fact that a Japanese electronics hobbyist built a complete homebrew video game system from scratch in 1987 all the more impressive.[Alex] recently discovered this project and produced a replica of it with a few modern touches.
The original console, called the Z80 TV Game, was built on an 8-bit Z80 processor. The rest of the circuitry is fairly intuitive as it uses various integrated circuits that have straightforward wiring. It supports cartridges with up to 32 KB of ROM, outputs a 168×210 black and white image as well as 1-bit audio.
There are around 26 games for this platform developed mostly by the original creator of the console and another developer named [Inufuto] who also developed a multi-platform compiler for the system. [Alex]’s version adds PCBs to the overall design making assembly much easier. He’s also added a cartridge port for the various games and included controller ports for Genesis or Master System controllers.
Even outside the context of the 80s the console is an impressive build, encouraging development of homebrew games that continues to this day. The original creator maintains a site about the console as well (Google Translate from Japanese). There are a number of development tools still available for this platform that allow modern gamers and enthusiasts to interact with it, and all of [Alex]’s schematics and other information are available on his website as well.
For a more modern take on a homebrew system, take a look at this one based on a PIC32 that can not only run homebrew games, but original Game Boy ROMs as well.
Something seems slightly off in the raster timing ROM…
It’s a 4096 address ROM and there’s no obvious way to reset the address counter early. This means it can either draw 16 addresses per scanline and 256 scanlines (6ish too few), or 15 addresses per scanline and 273-ish (10ish too many) scanlines. Neither seems fantastic for NTSC compatibility, but maybe that’s good enough?
I think old CRTs didn’t care so much about the exact timing. When they get a sync, they begin pulling the beam back. It’s a hack but it would work for some TVs. Professional consoles skirted the standard quite a bit too.
But it won’t work on LCD displays which use pixels instead of CRT line scanning.
Would have to buffer it through something if it’s an issue. Although I’d love to test it on actual hardware, some of the LCDs are pretty forgiving of the consoles being standard-ish.
It will work, it might not look great, don’t forget the output from this isn’t a pixel stream with synced dot clock, it’s analogue.
Because of that most (all?) devices which can handle analogue input tend to be somewhat forgiving of timing variances.
The designers of an awful lot of the vintage stuff used all sorts of “hacks” and “close enough” methods to make use of what was available and/or to save money which worked well enough on contemporary CRT displays, some of those hacks even added “features” like extra colours by taking advantage of the more lax standards.
So far, I’ve been surprised with how many sets it works on. I’ve tried it with:
A Ferguson 3MM02G5 green-screen composite monitor (c. 1984)
A Samsung TI-14C8 TV/VCR (c. 1997-1998)
The Sony Trinitron KV-14LM1U seen in my photos (c. 1998-2000)
A modern Samsung UE55NU7470UXXU smart TV (2018)
All of them worked fine.
That said, the only TVs it has any chance of working with are those that can sync to both NTSC and PAL, so it’s possible that an NTSC-only TV will be less lenient with what it accepts as a compliant signal.
I’m certain that the HSync pulse happens every 15 addresses. The VSync pulse appears to be much longer than the standard for some reason.
There’s also been some reverse engineering of the sync ROM done here:
https://forum.vcfed.org/index.php?threads/z80-tv-game-a-homebrew-games-console-from-the-1980s.1255026/
According to the homebrew nerds on AtariAge forums, an improper number of scanlines can make an analog TV picture “roll”, so some/many TVs did care about scanline count to some degree.
Some (more than one?) OG releases had such scan line count flaws. But, I don’t remember the nitty gritty details.
Back in the Late 70’s, Dad got an Apple ][ Computer that had ‘Color’ Graphics.. Took it to a TV Store and Tried it on the Display TV in the Showroom.. Looked Great.. Then Hooked it up to a ‘New Out of Box’ TV he was going to Purchase.. Graphics were Terrible.. He walked out with the Floor Model TV as it was better..
Some things are Unpredictable..
Cap
Interesting beast! If I understand the schematics correctly, video RAM is read even during Hsync. Using one of the unused outputs of the raster EPROM the first byte during hsync could be latched into a 6 bit color register. The current video bit could be used to switch a mix between 2×3 bits. Initializing the latch to 111-000 it would be backwards compatible. Two colors out of 8 per scanline would make some of these games shine!
TVs with vertical hold knobs in America don’t care about the number of lines when vertical hold became a digital control the chips assumed there was a particular number of lines in an ntsc picture and things stopped working.
I know this because I have ntsc TVs that run 48 HZ not 59.94