This project is submitted for

Description

In 1975 Wozniak famously designed the Breakout arcade game out of 44 simple chips, without using a microprocessor, simply because those weren't available to him at the time. When one year later the MOS 6502 and Zilog Z80 were launched, his Apple 1 started the microcomputer revolution. The debate still rages about which processor was the better one. But more interesting is to investigate if these devices were really necessary for the personal computer revolution at all: what would have happened if they had never appeared?

Details

History followed one pathThere were many other waysIt will always be like that

Can fewer than 40 old-skool TTL chips implement a multi-megahertz microcomputer with video and sound?

This project started as an exploration of what you can build from 30-40 simple logic chips. It has turned into a general purpose 8-bit microcomputer without any microprocessor driving it. I initially designed this on a large breadboard in early 2017, but soon after that I converted it all to a small PCB. It has VGA-compatible 60 Hz video in 64 colors and can display full-screen images, scroll them and play sound. Soon it will be running games like Pac Man and Space Invaders. But just for fun, I'll keep everything compatible with the breadboard design.

This is what we have now:• 8-bits system built out of 1970s TTL chips (74LS)• 34 TTL ICs, or 930 logic gates, for the CPU proper• No microcontroller and no complex chips (such as the 74181 ALU)• Only simple ICs, such as AND/OR, 4-bit adders, multiplexers, registers and so on• 6.3 MHz. Might be pushed to 8 MHz• 32kB 70ns RAM• Harvard architecture with EPROM for program/data• Operates on 2.5W, or below 0.5W for the 74HCT version• RISC with pipelining: 1 instructions per clock (sometimes 2...)• Instruction decoding with diodes• Nice instruction set: ADD/SUB/AND/OR/XOR, conditional jumps, many useful addressing modes• 60Hz 64 color VGA and 4 sound channels bit-banged from software• Designed and built on a solderless breadboard in 6 weeks• Runs ported versions of classic games, WozMon, BASIC, ...

The build has become a contradiction of itself. To reduce the parts count, every hardware function is essentially software-defined: video, audio and I/O are all handled by software. Video at the pixel level. Audio at the sample level, in 4 channels. Even the applications themselves are running in a non-existent 16-bit processor (aka interpreter).

Yet there is no microprocessor chip in there that runs the software of any of those virtual subsystems: it's all handled by the TTL circuit, acting as a minimalistic CPU and switching rapidly between these tasks. Not only does it work, the board is smaller and faster than the microcomputers of the day, including the first IBM PC. Having no microprocessor might have been better than having any of the time :-)

Check the videos for the current capabilities. The HaD blog section has the full story in all detail, so don't miss that if you're interested.

Some concepts to ponder about before starting

How many bits? 4, 8, 16, 32, ...

Software-generated video or hardwired?

Harvard or Von Neumann architecture?

Single cycle or multi cycle? Pipelining?

ALU chips or not?

Sliced ALU or full width?

A rule of thumb is that a minimalistic four bit system can be done in 10 chips, an eight bitter needs no more than 20 chips and going to 16 bits roughly doubles that again. Not all units double in chip count, but by extending the buses you will also have need for more addressing modes for it all to make sense. For example, a four bitter might work fine with a 256 word memory and absolute addressing, but with larger memories you'll need ways to construct addresses dynamically. Also, add more chips if extra functionality is required, such as high speed, a stack pointer, interrupts, a custom ALU or video.

Simplest possible concept

One concept, probably the simplest, is to replace the TrinketPro from the earlier breadboard VGA from TTL and SRAM with a minimalistic 4-bit TTL CPU. We will then get a working system with around 25 chips, or about 30 if we make a custom ALU. It will indeed be good enough for Pac Man and Space Invaders, but that will then also be the limit: no chance at all to have any fast scrolling, fast color changes, smooth moving objects, large objects, etcetera. Upgrading...

Project Logs

The joy of using hypermodern multiple e-beam direct-write lithography to "advertise" TTL technology from the 1960s... This is an electron microscope image of the Gigatron startup screen. This time it isn't displayed on a VGA monitor (or on a supercon badge), but printed on a silicon test wafer as used for IC making. The image was printed using a Mapper FLX-1200 e-beam writer. For comparison, a human hair is typically 75 µm in thickness.

The Mapper principle is much like that of an ink jet printer head with hundreds of nozzles, except we're using accelerated electrons here instead of ink, and silicon wafers instead of paper (and there are no colors). The beams each have a spot size of under 30 nm and they're scanning the surface with a positioning accuracy of below 3 nm. They're all perfectly stitched together to seamlessly cover the large area needed to make complex devices. The wafer was coated with a thin layer of resist material, and everywhere a sufficient number of electrons landed, an image formed that could be developed.

This tiny area of 24 µm x 18 µm shown above was printed in just a few milliseconds by a couple of hundred parallel and independently controlled electron beams, all focussed on the wafer in a high-vacuum chamber. This image is a small part of a much larger test pattern. The resolution is in the 40-50 nm range here. The e-beam writer has tens of thousands of beams all working in parallel. The data stream to support that is about 3 Tbit/second and is generated by a large rack filled with FPGAs.

A SEM is needed to view the result because the details are too small for optical microscopes. This super fast e-beam technology is developed to make new types of security ICs possible, but it has other applications in nano-fabrication as well (one is entertaining the engineers working with it).

The image contains a schematic of the iconic 7400 quad NAND chip, introduced in the late 1960s. An actual NAND gate, or even a single transistor from the day, would be much larger than this entire image. The typical line widths in those early days of IC manufacturing were in the order 10 µm.

The 8-Bit Guy just published his review of Pluggy McPlugface, Tiny BASIC v2 and the new games in ROM v3. And oh... we'll show it at the Superconference this weekend!

For those interested, I brought a very limited number of kits to Pasadena. They can go for a nice discount because I don't want to bring them back home.

Update: The conference badge was screaming for this hack:

The emulation is slow as molasses, running at 3 frames per second, instead of 60 frames. Contrary to my expectation, the slowdown doesn't come from the LCD update. Instead it's all due to the cycle-exact simulation which is based on the gtemu.c reference.

Hex file and modified sources attached to the project. Game controller button [A] is mapped to the DEL button. The BKSP button takes over the role of [Select] for switching between video/speed modes. You don't see the different scan line effects, because the LCD always only displays the first out of every 4 VGA scan lines (even in "full mode", aka "mode 0"), with the odd LCD lines always black. The applications still run faster depending on the mode. Continuous presses don't work, you have to simulate them by repeating. I managed to play Racer that way. Typing in Tiny BASIC v2 goes remarkably well.

Credits must go to @shaos, @jaromir and @rogerrandom for helping me plow through all the PIC stuff, as I never worked with any of that before.

Today, a circle closed at the Centre for Computing History in Cambridge, UK.

How? Well, one week before this project started here on Hackaday, I was at the Computer History Museum in Mountain View, US, and jokingly posted the following remark on Facebook:

[screenshot]

That's an original Apple-1. The Apple-1 next to the Gigatron is a beautifully done replica. It's fully functional, complete with cassette interface. The PCB is drawn in the same way and the chips even have 1970s date codes on them. It's on display in an operational state. I could play around and type commands in the original Woz Mon to verify that the Gigatron version works the same.

One of my side projects is to convert a board to original TTL series where possible, or at least to 74LS series with the oldest chips I can find. The breadboard prototype was fully 74LS, the kit edition is 74HCT.

At a local electronics shop I recently found quite a few ICs that were manufactured more than 43 years ago, in 1975. These are "new old stock": never used before and the pins still unbent. Some are indeed original TTL series as existed in the 1960s, not 74LS (Low-power Shottky) as introduced in 1971. They're plug-in compatible with the Gigatron design and the system works fine at full speed:

Although it is cool, it also gets hot! Original TTL consumes an order of magnitude more power. Due to this so far I only "upgraded" to original TTL the upper half the logic unit, the X register, the memory address unit and the program counter. Those 14 chips, together with a few 74LS replacements as well, already increase the current to 740 mA, or about a ten-fold from the kit version. Above that the multi-fuse and MCP start to do their thing. Remember that USB safety is the reason the kit comes with much more power-efficient 74HCT components in the first place.

The nice thing about the 7400-series is that improved series remained compatible in pin layout and voltage levels.

1966: introduction of the original 7400 series

1971: introduction of 74LS series

1983: introduction of 74HC(T) series

I have them all on a board now. The difference in generations is clearly visible. The old TTLs get up to 60 degree Celsius. The blue square isn't a cool oasis in the middle of a hot desert. It is a reflection on the gold plated ceramic lid of a vintage SRAM.

I almost forgot about the project's original objective that I had in mind when it started one and a half year ago: to build a circuit from TTL components that can play Tic-Tac-Toe on an LED matrix. So lets correct that: today, with minor adjustments, Tom Pittman's Tic-Tac-Toe from 1977 is running on the Gigatron :-) Source code in GitHub.

Ok, the planned LED matrix has morphed into a video screen along the way. That's just feature creep.

The original is 254 bytes, my version is $254 bytes . About half of that is for terminal output (character printing). The Apple-1 had dedicated hardware for that... With this, all original Apple-1 firmware has been ported to the Gigatron :-)

Now you can inspect memory locations, write to them and execute code.

Tutorials for the original WozMon, such as this nice one, are applicable as I tried to deviate as little as possible from the original: the differences are essentially cosmetic or slightly improved usability. The Gigatron-specific differences are:

There are several methods brewing for hooking up a keyboard. The one most in line with the system is WattSekunde's four chip design for a matrix keyboard interface. But such keyboards might be hard to find, while PS/2 keyboards are still easy to get. But their protocol is convoluted and it is unclear how to handle that with a few simple logic chips. So... we cheat!

PS/2 is simply too modern, and we need a time machine to translate its fast and complex signals to the simple signals that the Gigatron will understand. The ATtiny85 will be our Babel fish.

To get some idea: the ATtiny85 must be configured to run at 8 MHz to do its magic. 1 MHz won't be good enough to catch and transfer simple key strokes. Here is the system in action:

Hello. I have a small question for creators. This design seems damn effective and useful, but I still have to wonder: why exactly something like this wasn't built in late 60/early 70 despite TTL logic was avaiable since 1966?

Two reasons. First but not foremost is that the RISC architecture was not recognised as commercially viable until much later, like 1985 or so. Doing RISC drops your component count by an order of magnitude. Second is that the real hero in this design is the RAM chip. That chip allows for software to do a lot of stuff you would normally do with circuitry. Dating it: if the design were to be retrofitted for slower TV signals of the day, something like this might have existed around 1985 considering part availability. (Mind: slowest VGA speed = 4x TV speed). The CPU-part could still be made from early 1970s logic. The total system would have been expensive because 32KB SRAM (not DRAM) at that time was expensive.

I have scored some amazingly cool milspec SRAM chips from eBay that are from 1988. They *WORK* in the VGA version! In fact they are already 3 times faster than required for that (25ns while 70ns needed). They must have cost a fortune back then. I did go through a lot of old BYTE magazine's component ads: you can't find such amazingly fast specs in the commercial offerings at the time... Nothing even close.

"First but not foremost is that the RISC architecture was not recognised as commercially viable until much later, like 1985 or so." --- I suspect you're right about this, despite the fact that the clearly *were* people in the industry who knew this was the best approach. Seymour Cray had been building designs that were effectively RISC systems and which dominated the high performance computing world from the mid 60s right up to the end of the 80s, but nobody else really seemed to understand what lesson to learn from that.

"Second is that the real hero in this design is the RAM chip. [...] The total system would have been expensive because 32KB SRAM (not DRAM) at that time was expensive."

For reference of how expensive: I found an advert from Dec 1981 (which would probably have been about the last date a machine like this could have launched and been commercially successful -- any later and it'd have to compete with the C64) that priced 70ns SRAM at $30/4kilobits, so you'd be looking at about $2000 worth of RAM to build this machine at the time. That said, I wonder how well it would work with, say, 8KB of fast SRAM for critical parts of the system and 16-64KB of slow DRAM for bulk storage, which would put the build cost at approximately the same price as the retail cost of a C64 at launch.

Updated: I found another advert from 1981 that suggests the first price I found was ridiculously over the top -- although I'm making some assumptions in interpreting it -- Byte vol 6 issue 11 has an advertiser on page 546 selling "2147" chips for $3.15 each... there are multiple manufacturers who used that number, but of the ones I've looked at (Intel and Mostek), 70ns was the slowest they were still producing in 1981 (Mostek had a 90ns variant in 1979, but seemed to have dropped it by 81), so I'm making an assumption that these were in fact 70ns chips.

With pure 1970s components the CPU section could certainly be built using 74LS parts, but something else has to be done around the RAM. At least make it DRAM, slow down the clock to match (which might be ok for slower TV signals). It is difficult to really go back to that era, because RAM chips of those days are practically unavailable now. So it will look a bit different, but either way still be expensive for the 32KB RAM capacity (even if it were DRAM).

About BASIC: it is just a lot of work. Microsoft could become a company precisely because they had done a BASIC and the microcomputers of the day needed it. This project is a bit in the same state. Unfortunately, Bill Gates is doing different things nowadays! There is a proper assembler already written by user at67 on GitHub. It does both the 8-bit native instruction set as the 16-bit vCPU instruction set.

You want several steps:

- Direct or indirect keyboard hookup. Indirect is easy, but a bit cheating. Direct hookup is a harder nut to crack (at least: if you want to stay with the minimalistic spirit of the rest of the system. If not, just use the Arduino).

- BASIC parser/interpreter. Several weeks of full time effort for an "integer basic".

We did more archeology. Personally I always believed that the SRAM was the anachronism in the design, but it turns out not the case: Julian has been digging into old BYTE magazines for us, and surprisingly, 2147 (4096x1bit) "high speed" or "arcade" SRAM was available for $3.15 in... 1981. Ebay lists such parts with date codes as early as 1978. The slowest grade mentioned in data sheets I can find is 70 ns, and the March 1980 Intel application note AP-74 talks about speeds of 55 ns as if it is old news. I'm completely surprised by all of this. It's part of an interesting quest to date the Gigatron.

Kit worked great, placing the chips in position on the foam like that simplified things hugely and the build manual was very clear - my only soldering error was leaving one pin unsoldered which resulted in a strange offset on the VGA signal, till I spotted it. I'd be keen to learn more about exactly why it is that for instance this clump of 74xx chips are the ALU and that clump are a register, etc - once that kind of info is made available it could be a great teaching resource along the lines of the excellent Elements of Computer Systems / From NAND to Tetris (https://www.amazon.co.uk/Elements-Computing-Systems-Building-Principles/dp/0262640686) which @monsonite once pointed me towards.

Might I suggest Google Groups as a quick & easy way to get a forum community up?

Hi Bob, sorry I missed your update, but I think I saw it on Twitter :-)

We recognise the usefulness for a forum, but we're super busy so we're really in need of helping hands here, otherwise it isn't going to happen anytime soon. If somebody starts one and I like it, I will join threads I'm interested in. I have to say that I find Google Groups disappointing from user point of view, and for this project there are builders and tweakers/hackers and those threads shouldn't mix. The bbCode type of forums are so much nicer in presentation, and they can support two sections under one roof: Assembly and Hacking (no need to divide it up further, I would be against that).

But then also beggars can't be choosers. Now some programming discussions happen on GitHub for example.

I'm aware. Let me say I have just have no real positive experiences with Google Groups. The groups I know and sometimes check out feel disconnected to me and the overview and content presentation is poor, as if it is still running on Usenet. Also no inline images, no markup. I find it frustrating to use for technical content, and therefore groups is not something I would personally frequently checkout and become like a home.

Interesting video from 8bit guy. It's sort of extraordinary that the gigatron outperforms a VIC 20 using only discrete logic gates for a CPU, but the trick is using modern memory chips & cost. If it just drove a serial port instead of driving a CRT, it could run much more powerful demos. 8 bit guy was hard on it because he only saw the default firmware spending all its clockcycles driving the CRT.

We absolutely love his episode! We don't think he is hard on it at all... He presents the project in a superb manner. As he mentions at the end, the programmability is a matter of software, and it is the next phase of the project. The Apple-1 didn't come with a built-in BASIC either, for the same reason: it takes time to build a software environment.

Thanks :-) It can make proper bleeping sounds though. It has 4-bits sound output (16 levels) and the default loop squeezes 4 software channels through that. They can synthesise pulse, triangle, sawtooth, etc. It sounds crappy but charming, just right!

Given a lot of music was constructed with those four primitives… that's probably just fine. The SID chip does similar with 3 voices.

My only concern here is look out for the DMCA trolls, while it's clear to us (and anyone with intelligence) that the music is just co-incidentally playing in the background … some lawyer might have a momentary lapse of reason and declare the entire video a derivative work. :-)

The full schematic might appear in some later stage as it is quite a mess in need of serious cleanup and I'm working on software the upcoming weeks. But the ALU is described adequately elsewhere: the "Logic" stage comes from here http://www.6502.org/users/dieter/a1/a1_4.htm (bottom of the page) and the ALU uses two of those with two 4-bit adders, as described here: http://www.6502.org/users/dieter/a1/a1_6.htm except that my design does without the 3rd stage that only provides right-shifting. So in total it is 8x'153 and 2x'283 with 5 control signals going in. Dieter's pages suggest that you need 8 signals, but most of them have the same value for the common operations. The carry-out goes back into the condition decoder where it acts as an allzero-indicator during jumps. There is no flags register as it costs too many chips for too little added value. I do right-shifting in software using the "single-instruction subroutine" technique described in the log on pipelining. This computer doesn't need shifting that much because the graphics layout is 1 byte = 1 pixel.

I'm suitably impressed with the elegance of your design that I have taken time to transcribe it to EagleCAD, so that I can get a better understanding of the control and data paths.

After pondering your Control Unit schematic for an hour yesterday lunchtime, and how it decodes the ALU instructions and generates the various addressing modes and jumps, I was happy that I could figure from the bus and dataflow diagram how most of the rest of it worked.

Now that the bulk of the design is captured, I'm figuring out a way of using an ATmega1284 as an easy to update ROMulator device, running code from faster RAM and a way of extending by adding more VRAM.

When you consider that the first Sinclair ZX80 machine took 18 TTL chips, plus Z80, ROM and RAM to create a monochrome TV picture of 32 x 24 8x8 characters, for just another 18 chips they could have replaced the Z80 and had something that produced colour graphics and ran at 4 or 5 times the speed.

I don't think schematics are ever really "finished", but the schematic that the layout was made from would be most helpful even if it is a mess. I would like to see them because I would like to try to recreate it in an FPGA. You could post them now, and then replacement them with a cleaned up version once you have it finished.

Thanks. I can find the first. I do have ALU chips available, I just don't feel like using them in this build. Do you have data sheets for the second series? I have trouble finding out what it is. Some memory? I plan on using 62256 for RAM and 2x AT28C256 for ROM, with a possibility to extend the memory using the AT27C1024.